I got to thinking about this the other day and contemplated on whether or not this applied to more than just execution speed performance. Specifially, I was wondering if we're still in the free lunch phase with regards to energy efficient performance or if developers can still coast on their laurels since new hardware continues to become still better at using less and less energy.

I arrived as this existential conundrum as I was looking over an internal presentation for an upcoming processor release from Intel. One prominent feature that was touted was the increase in energy efficiency to be realized by the new chip. Better technology has reduced the energy leakage within processor circuits. I imagine that there is more research and development (or already has been such R&D) that can be and will be done in the near future to get even better energy performance from processors. If that is the case, why should software developers be concerned with programming applications that actively conserve power?

(If you're a laurel coaster, stop here, don't read the rest of this post, and go check out your favorite online comic strip.)

For those of you that are still reading, let me first say, you can be sure that your competitors are taking steps to write software that uses the processing cores more efficiently. In terms of performance, the fastest software will be the one that sells more copies. Energy efficiency has become another dimension for comparing competing software products. In some cases, it might even be the more important dimension for a consumer's choice.

Mobile devices have become nearly ubiquitous (or so they tell me). After some amount of use these devices need to be recharged. If your application runs down the stored battery power faster than an alternative product, users will gravitate to that competing software. Device owners have already spent a pretty penny on their current hardware.  It is highly unlikely they are willing to wait months to upgrade to a model with a better energy conserving processor in order for your software to not drain the battery as quickly. If this is your strategy for energy efficient performance, you've already lost the sale. Even if users would be willing to wait, they'll be using something else and getting familiar with that software. Besides, the better energy efficiency of a new processor will also benefit your competition's software.

Secondly, it's really not all that hard to program for energy efficient performance. Many of the things you would already do for execution optimization and performance (use better algorithms, multiple threads, compiler optimizations, etc.) will directly benefit the power consumption rate of your software. For more techniques and ideas on how to upgrade your applications to be more energy efficient, visit the Intel Power Efficiency Community.

Sitting around and waiting for the next helping of improved energy efficient hardware "free lunch" to make your software better is easy. (Heck, you might even be able to surreptitiously take time off from work to practice your drumming at the beach.) But if you're interested in making your software the best that it can be and the most desired products to consumers, be proactive and start looking at how to improve your application's power considerations today. There will be time for beach drumming after you make that first million dollar$.

What seemed most disturbing to me was the limit on the number of cores being self-inflicted. Surely we can't have reached the maximum number of cores that are possible to squeeze onto a chip? The whole "right turn" idea to add cores rather than try to cool processors reaching rocket engine temperatures was less than 10 years ago. I'm not sure where the physics starts to overshadow Moore's Law, but I thought I'd  heard that a few more generations of smaller wire sizes in processor dies were still possible. So why not push more and more cores into the same package?

It might be that the average server application (and, perhaps even more so, consumer applications) can't scale well beyond some fixed number of cores. How many cores does it take to type and post a tweet or update your Facebook status or to watch a streaming video? Would any of those tasks be faster or somehow enhanced if there were twice the number of cores available?

If we stop increasing the core counts in the next 5 years, how will new chips keep fulfilling the ever-growing hunger for more performance by consumers? Maybe it won't be about faster and faster application exeuction, but more about less energy consumption while maintaining a level of performance. I guess at some point we'll stop being concerned about Gigahertz or core counts because all processors will be able to do many of the same tasks in about the same amount of time.

I do know that power consumption is going to be a major driving design force as HPC moves closer toward Exascale platforms.  Thus, if the THX-1138 processor draws power twice as fast as the CFM602 processor, I would be more likely to build my system equipped with the former.

The authors look to evaluate which of three possible processor core architectures might be best for parallel execution that minimizes energy consumption. The three model core arrangements are 1) multi-core (several large processing cores on a single chip), 2) manycore (lots and lots of simpler, more power efficient cores), and 3) a combination of a single large core with many simpler cores. The first is like the current dual-, quad-, and hexa-core processors, the second is akin to a GPU, and the third is a hybrid conglomeration of large core sitting on a GPU.

For the purposes of the model formulas, the maximum power consumption of a single large core is normalized to 1 and the power consumption of an idle processor is an added variable, k. For the first architecture, the new variable is used in the traditional Amdahl's Law formula as a multiplier to the serial percentage of time multiplied by the (n-1) idle cores. Some simple algebraic manipulation and the authors generate a formula for estimating the average power consumption, in watts (W), for a parallel application with n cores and the stated percentages of parallel and serial work. A similar derivation is done for the manycore model with the power consumption per simple core being 0.25 of the large core. With the hybrid model, the assumption used to derive a corresponding formula is for the large single core to handle the serial execution and the simpler cores do the parallel work.

Since a measure of the watts consumed is provided by the model, the authors then compute performance per watt (Perf/W) by computing the original Amdahl's formula divided by the formula to compute W. In order to compare the three model to each other, a power budget is imposed, which sets the number of cores available for each model.

The conclusions drawn from comparing the model with various numbers of cores and fractions of parallel execution of the overall execution time are probably the most interesting part of the article. For example, the first result reported is that to achieve the highest Perf/W value in the multi-core model, the parallelization must scale linearly. If the application doesn't scale linearly,the processor (model) must dissipate more energy than the serial version since the idle power of the extra cores scales linearly.

The ultimate result of the paper was that the hybrid model, one large core and many small cores, was the most power scalable. The manycore option does well with high amounts of parallelism and lower power budgets (fewer total cores), but as that budget increases, the number of simple cores increases and the effective serial execution performance does not. The hybrid model, with the single large core in place of several simpler cores, can more efficiently handle the serial portions of the execution (than one simple core out of the dozens sitting idle).

As I was reading the paper I could identify which was the model of current standard multi-core processors available in abundance today. The manycore model could easily be a GPU or MIC accelerator by itself. The hybrid model suggested the combination of a manycore accelerator and a dual-core processor (in the absence of  heterogeneous core chips). I wondered where vector hardware fits into the three models. Considering just the vector registers alone might suggest it would be an instance of the manycore model. However, these registers are part of a larger core, which makes me think of the hybrid model. Maybe they are a second level of parallel execution that isn't accounted for in the three models.

It's a good paper. But I have a couple of quibbles. First, the only way that parallel execution on the multi-core model underachieves the serial equivalent execution is if the sequential code is run on a single core system. A later comment in the paper makes me think that this is the assumption, but it's not too clear. This assumption is not valid in the real-world. For a true apples-apples comparison, the serial code needs to be run on a multi-core processor, too. If that were the case, I contend that the parallel execution consumes less energy.

For example, assume that we have an execution time of 10 time units (let's call them moops) . On a quad core processor running the serial code we would have one core running full speed for 10 moops and the other three cores generate an aggregate 30 moops of idle consumption. If the algorithm is 50% parallel, we would have 5 moops of  full power consumption in serial, 5 moops of full consumption in parallel across four cores, and 15 moops total of idle consumption. Even if the code is 10% parallel there would only be 27 moops of total idle consumption. Any level of (perfect) parallelism is going to prove to consume less energy than the serial equivalent on the same system. Am I missing something?

Note that I included '(perfect)' at the end of the previous paragraph. There will always be overhead in parallel computations and this will expand the execution time of the parallel portions and, consequently, the full consumption time of the execution (e.g., the 50% parallel portion above might require 5.4 moops of full consumption).

Second, Amdahl's Law is an estimate of speedup. Speedup is a dimensionless number. That is, I divide the execution time of the serial code with the time of the parallel execution to get a simple  number since the moops of the two quantities cancel each other out in that calculation. If I need 10 moops of serial time versus 6.35 moops of parallel time, I get a 1.57X speedup. 1.57 whats? ('X' is not a unit.) Speedup is a metric of relative performance, but it's not what I really think of when I think of performance.

To me "performance" is more absolute. Typically this is some countable quantity like number of transactions, floating-point operations, or feet traveled. It can be associated within a time unit measure, too, like transactions per moop, floating-point operations per second, or furlongs per fortnight. Thus, the metrics of transactions per watt or flops per watt or feet per watt make sense to me. Improvements that raise the performance value or lower the watt value show a trend in the right direction for achieving better energy efficient performance.

I'm still not able to quite wrap my head around the efficacy of speedup per watt (or even speedup per joule, which is also used in the Woo and Lee paper) as an absolute measure of energy efficient performance. It may be that I'm reading too much into this and the metrics are simply used to compare the three architectural models described (within the assumptions given). Perhaps it is simpy just a model after all.

A few weeks back I went on eBay and got myself two Pogoplug devices. Very nice little media and file sharing devices, you plug storage in the USB ports and you get access to the data anywhere on the internet. The devices are not expensive at all and very functional. One of the things that interested me in the device is that you can enable SSH on them, login and install and run more software. Of course, the Meshcentral peer-to-peer agent would be a great target for such a device. You can leave your Pogoplug on all the time and then, use it as a low-power presence on the network to wake up other computers, monitor sleeping Intel AMT computers, etc. Best of all, you can use both Meshcentral along with the original Pogoplug software.

So, earlier today I downloaded the proper cross-compiler. I am really getting the hang of this, it took me about an hour to compile the mesh agent and get it running on the device! I also added the new mesh agent to the list of available agents on Meshcentral.com. Now, this is not for everyone just yet, you need to have a good idea what you are doing with Linux and the command prompt. I also did not research how to auto-start the mesh agent yet when the device boots up. Regardless, enable SSH on the Pogoplug web site in the settings and security menu, then I log in and remount the root file system and create a new folder with these commands:

mount -o rw,remount /
mkdir /usr/local/mesh
cd /usr/local/mesh

I am then ready to cut & paste the agent download and launch code from the Meshcentral.com account page (hit the Install link). After about a minute, the device will show up on Meshcentral.com and you can access file, get the command prompt, etc. Obviously, no remote desktop available.

That's it for now. Have fun with your new Pogoplug features!

Ylian
meshcentral.com

• Cppsample.zip
• Download End User License Agreement

Initializating COM

The beginning of CppSample.cpp starts with COM initialization as follows so that COM is initialized before _tmain and de-initialized after _tmain is done. EzPwrLibrary.dll itself should be imported as a header.

Initializing COM

Setting up parameters

• Create a smart pointer: create an interface to the library - "IEzPwrCtrlPtr pEzPwrCtl" followed by instantiation -"pEzPwrCtl.CreateInstance(L”EzPwrLibrary.EzPwrCtl”);"
• Log file: The library takes a log file name and append the time stamp to the log file name. In order to specify the file name, assign the file name to "ExportFileName" property. Usually, full path to the file is specified. In order to get the file name, use "GetExportFileName" or "GetExportFileNameExtended" to get the exact file name with the time stamp appended. In order for GetExportFileNameExtended to succeed, the logging should have been started by setting "Logging" property to 1. Setting "Logging" property to 0 stops the logging.
• Sampling Resolution: The gadget itself is updated once every second. But you can specify much finer sampling resolution for the logging by calling  "Reset(millisecond)" method. It is not guaranteed to get the specified resolution due to thread scheduling, but it will try to get up to the resolution. It is recommended to set this to 50 ms.

Setting up Parameters

Getting Power and Frequency Information

All the methods in the library are non-blocking calls, but the actual data is updated once per second. The log however, has much finer resolution as specified in the "Reset" method.

• Multi-socket support: The library supports multi-socket systems and can get the power and frequency information per socket. You can get the number of sockets in the system by calling "GetNumSockets" method.
• Frequency: In order to get the base frequency (maximum frequency without turbo,) call "GetMaxFreq" method. Be aware that modern processors including Penryn, Nehalem, Sandy Bridge, and Ivy Bridge can not only throttle down the frequency to save power, it can go higher than the base frequency temporarily for performance. It is very important to understand the frequency is not fixed to the base frequency to properly understand power / performance. CPU utilization alone is not going to tell the whole story - x % of CPU utilization really doesn't mean much without the running frequency information at the moment. "GetFrequency" method gives the average frequency from all the sockets, and GetSocketFrequency(int iSocket) gives individual frequency for each socket. If there is only one socket, both methods have the same result.
• Power: There are 2 ways to get power - total power from all the sockets (GetPackagePower) and individual sockets (GetSocketPower(int iSocket)). GetPackagePower is just a sum of all GetSocketPower.

Getting Power and Frequency

Clean up

Be sure to stop logging and close & release the interface.

Clean up

There are all kinds of ideas to be found on the Power Efficiency Community site on how to accomplish this assignment. What I'd like to know is how you prove to your boss that you have accomplished the task. Or, if you've already optimized the you-know-what out of the application, what do you measure to label your software is energy efficient?

With serial applications, the metric of better performance is easy: less time is better.  Parallel applications have similar metrics: either run the same workload in less time than an equivalent serial version or run more workloads than the serial code can process in the same time.

I've found that energy efficiency is a little more nebulous. Talking with engineers that deal with this question around Intel, I've gotten three potential answers.

Total Energy Consumed

This is simply the amount of energy used during the run of your application or an average of energy used per time unit (since the needs of the application might fluctuate based on the processing done). Certainly the less total energy used, the more efficient your application will be. On laptops and Ultrabooks and other mobile devices, applications that use less energy will preserve battery life.

But, how much energy does the application NOT have to use to be considered efficient? Is there a minimum achievable level of energy consumption for a given computation? When do you know that there is no more efficiency that can be squeezed from your tuning efforts? With parallel computation we have Amdahl's Law and other theoretical models that can be used to compute an upper bound on the amount of parallelism we might be able to eke out of an application. Is there a similar model for energy efficient performance limits?

Performance per Watt

This measures how much work is done per watt of power. Clearly, if your optimizations result in more work done with the same amount of energy used or the same computation with less energy expended, your application is more efficient than it was before. Most applications will have some easy metric of performance. Things like FLOP/s or pixels rendered or transactions processed or frames per second are all common measures of the work being done in applications.

Again, a relative measure of before and after is easy to keep track of during the tuning process. If your application starts with 10 FAUXtoe-ops per watt and eventually reaches 20 FAUXtoe-ops per watt, your tuning efforts are headed in the right direction. As with the previous measure, I wonder if there is an absolute (theoretical?) value that can be held up as the goal of your optimization efforts? Dependent on what work unit your application uses, of course. And would such an energy efficiency measure need to take into account the target hardware configuration (battery, power supply, processor, chipset, GPU, etc.)?

Application Idle Behavior

One idea that I find repeated over and over is that the processor should be kept idle as much as possible. That is, it should reside in the lowest C-state as much as possible. For an application, this rule of thumb can be summarized with the acronym HUGI (Hurry Up and Get Idle). Do whatever is needed to complete any processing as quickly as possible and then have the application sit idle (and do that as energy efficiently as possible). Thus, the measure is to determine how well an application spends time waiting for user input or some other interrupt.

Judging how efficiently an application executes during its idle time will be as simple as measuring the percentage of low C-states (C3, C6) residency. This metric can be an absolute percentage of execution time or measured relative to the idle state of the system without any other application running, i.e., the quiescent state of the OS. Sounds good for user-interactive applications that can run faster than the user can type or click, but what about heavily compute-intensive executions? When I ran a version of my Akari application, less than 3% of the time was spent in C3 while achieving a 22.56X speedup on 80 threads. With all the parallel tasks that get spawned to inhabit all the threads/cores available, should that application be considered energy efficient?

What do you think?

So, when you read the first two paragraphs, did you think of any of the metrics I outlined here? Maybe it was some variation on a theme or did you have a completely different idea?

Performance was, is, and always will be the driver of the need for software tuning and optimization. Would there ever be a trade-off of lower performance (longer execution time) in order to conserve energy consumed? Perhaps a question for a future blog. For now, though, assuming a preservation or improvement of application performance is a requirement, how do you demonstrate that your application is also efficient in the energy used during execution?

With this post, I want to cover how Meshcentral.com powers up sleeping computers. As many of you know, you can go on the web site, see all your computers and select one or many and remotely powered them off, reset them, etc. These operations are fairly simple, just tell the mesh agent to instruct the operating system to do the operation. The real magic comes when you want to wake a system back up. I use this operation myself to wake up my Microsoft Home Server which is set to go to sleep after an hour.

To remotely wake a computer, the web site can't just hop in a cab, go to the computer's location and press the power button... but almost all desktop computers sold in the last 10 years support "wake-on-lan", also know as the "magic packet". Your are very likely to have this on your computer if, when you power your computer down, your Ethernet port is still blinking. Meshcentral has two requirements to get wake working. You need another mesh computer on the same network powered on, and you need your computer to have wake-on-lan enabled.

The first requirement is required since, in order to get passed the home router, there needs to be a mesh agent acting as the relay. The relay node can be a full computer, a laptop, a plugpc, router or android device. As long as it runs the mesh agent and belong to your account, you are set. If you have more than one, even better.

The second requirement is also important since, by default Wake-on-LAN is often disabled. You may need to go into the BIOS and enable it, also in Microsoft Windows, go in the device manager, go in the properties of your network card, power management tab and enable it. I suggest also selecting "Only allow a magic packet to wake the computer" because if you don't any packet that hits a listening port with wake the computer (it's called wake on pattern) and it causes the computer of wake up too often.

Well, that is it. If you meet these two requirements, your computer will wake up, even from a full S5 power off using Meshcentral.com or the Meshcentral mobile application.

Have fun!
Ylian
meshcentral.com

With all the excitement going on, I couldn’t be more energized about being the community manager for this new form factor.  The community is structured around the main opportunities for ISVs to focus their development efforts at.  At the moment, those main areas are Power- efficiency, Performance and Graphics.

In the Power-efficiency section you’ll learn about and get help with the things you can do to make sure that your software is playing its role in keeping the ultrabook’s battery life as long as possible.  The only true way to get the most out of the batteries is if the hardware and the software are both playing “green” together.

On the Performance side, the current ultrabooks are powered by 2nd Generation Intel® Core™ processors.  These are some powerful processors!  And just like with desktops and standard laptops, your software needs to take advantage of the performance offered by these multicore chips.  So this section will be dedicated to helping you thread your applications to run on multiple processing cores.

And in the Graphics area, you’ll get the information and insight to help you look your best on the new ultrabooks.  With these new form factors, there’s not much room for discrete cards.  In fact, I’m not even sure how they got the processors in there.  So you’ll likely be depending on the performance of the integrated graphics processing to deliver your visuals to your customers.  This area will be the spot to help you put your best foot forward…visually.

This, of course, is just how to engage with the current model releases.  2012 and 2013 promise to bring about some exciting developments for ultrabooks, with new features, designs and operating systems introduced.  And with these new developments, the opportunities for ISVs will continue to grow.  And this community will be the place for you to go to figure out what your next steps should be.  But for now go ahead and get your applications optimized for the power-efficient performance and graphics capabilities of ultrabooks as these enabling vectors will surely be the foundation of on which future feature will be built on.

Visit the Ultrabook Community here.

To start ESRV with the Intel® Power Gadget, type:

• 1 socket:  esrv --start --daq --library "C:\Program Files\Intel\Power Gadget 2.0\daq_driver.dll" --channels "1-4" --default_suffixes "decimals = 2" --counters "Number of Sockets=C1, CPU Average Power (Watt)=C2, CPU Energy Consumed (Joule)=C3 integral, CPU Frequency (MHz)=C4"
• 2 sockets: esrv --start --daq --library "C:\Program Files\Intel\Power Gadget 2.0\daq_driver.dll" --channels "1-7" --default_suffixes "decimals = 2" --counters "Number of Sockets=C1, CPU Average Power_0 (Watt)=C2, CPU Energy Consumed_0 (Joule)=C3 integral, CPU Frequency_0 (MHz)=C4, CPU Average Power_1(Watt)=C5, CPU Energy Consumed_1 (Joule)=C6 integral, CPU Frequency_1 (MHz)=C7 "
• Etc.

 To monitor – this is not required –, start the PL GUI Monitor typing the following command. Double-click on the newly created PL configuration file in the C:\productivity_link folder (and click Cancel when done). The following figure shows the monitor output. Note that these commands can be saved in a batch file for convenience. 

 pl_gui_monitor --gdiplus --process --trend --transparency 30 --format --geometry "gauges=3x1 position=topxright" --top --title "Powered by Power Gadget"

Intel® Energy Checker SDK

Please refer to the EC User Guides – including the Companion Applications User Guide – for details on ESRV and PL GUI Monitor and advanced options from Intel® Energy Checker SDK.

EC SDK is shipped with ESRV (Energy Server) which monitors a platform’s energy consumption of monitored or instrumented components. ESRV provides counters for the cumulative energy consumed, as well as the immediate power draw from the power meter or power supply. More detailed information can be found in the Intel® Energy Checker Device Driver Kit User Guide.

ESRV also provides a Data Acquisition (DAQ) mode, which allows the monitoring of system components, such as memory or IO subsystems.

No, it was the fact that Gordon is the world's first supercomputer that uses flash memory instead of disk drives. This is the world’s largest thumb drive (300 Terabytes across 1024 Intel 710 series drives), as Allan Snavely, SDSC Associate Director, noted. There are quite a few advantages for using flash memory drives in place of spinning disks including lower power consumption, lower latency to access data, and fewer moving parts that can have mechanical failure. This just seems so logical that I'm surprised it hadn't happened sooner.

On a coincidental note, I saw a report earlier today that stated Intel was lowering Q4 revenue projections due to a drop in microprocessor demand from PC manufacturers. This is a direct result of not having enough disk drives available, which was caused by flooding in Thailand earlier this year.

I would think that the expected hard drive shortage will open the doors for wider adoption of SSD drives in the PC market and provide a hefty revenue stream for companies that can supply those drives. Big-scale projects like SCSD's Gordon computer just reinforce the efficacy of SSDs in desktops and laptops and even smaller form factors.

At LinuxConf (LCA2010) James Reinders gave a talk about the Threading Building Blocks (TBB) library, a C++ threading library that sets out to make multicore programming more accessible to the average programmer. We took this idea on board and explored the possibilities of opening up this approach to an even wider audience, namely the audience of web application developers working in script languages.

Many websites require a non-trivial amount of per-request processing in the application layer, perhaps to retrieve, consolidate or otherwise manipulate data. Achieving better performance at this level improves response times and the overall user experience. Even when processing time at application level is not critical, parallelizing access to database and web service back-end layers can yield substantial improvements in perceived performance.

This drove our goal of adding TBB support into PHP and Perl, starting with HipHop as the PHP implementation of choice and later on adding Perl support to the game.

HipHop is a PHP to C++ cross compiler that was developed by Facebook to cut down on resource needs and speed up the execution times of their gigantic web infrastructure that was started on a classic PHP/MySQL stack and now has to scale to hundreds of millions of users. The HipHop project is a PHP implementation that is thread safe and already uses TBB for some memory management. We started by extending the existing support and added first only the new *parallel_for* function. Later, we added concurrent data structures and re-implemented our first approach.

What we have now is a robust implementation of *parallel_for* and *parallel_reduce* with the data structures needed to support them. What we learned on the way was both, very enlightening and quite frustrating at times. Our aim to make TBB more widely accessible was reached by getting the language extension into HipHop but we also tried to get it into Zend PHP. This turned out to only work with a language compatibility module that does not provide the full glory we can offer on the HipHop platform. The reason for this is the architecture of the PHP interpreter.

Implementing threading into language interpreters turns out to be very hard. There are two dormant/failed approaches in Perl and every attempt in PHP has failed so far. The core developers on both sides are very much in doubt if it is a path worth going down at all. The problem is global locking and copying/sharing of data structures that are thread local. Our Perl implementation is a starting point that could influence not only the Perl community but other interpreter designers and interpreter developers as well.

In the Perl community we are trying to lobby for a const keyword that would lock a data structure and remove the need to copy it into every thread. The ability to make something immutable is missing in Perl and PHP and this makes the startup cost of any worker thread very expensive. For the Perl library we wrote a lazy clone module that would only clone a data structure if the worker thread really accesses it. That way we only penalize the worker thread for accessing data - we can possibly get around cloning structures at all if they are not accessed within this task.

In our work with the PHP HipHop compiler we also wrote a patch set for WordPress and enhanced WordPress with our new *parallel_for* language extension. This trial brought us instant success in reduced page load times. The patch set for WordPress only replaced some key *foreach* loops with *parallel_for* and was our first real success with the TBB library in PHP. Based on that success we started out to re-implement our initial approach and tidy up our patch set for HipHop to make it more accessible to others.

The Perl project worked towards a Perl module that can be used to get access to TBB functions directly. We also started out to implement the core memory structures and then built on top of those the *parallel_for* functionality. The module we have now is stable enough to demonstrate the gains we can get by using TBB in Perl.

To round the project off we implemented two little tools as real world demo and as working code to look at. The demo is based around the HTML5 geo tag which is present in modern browsers and can be read with a Javascript API. In the HipHop version we use it to read the current Lat/Lon from the accessing browser and then parse the Twitter firehose to find tweets with embedded image URLs.

In the Perl demo we query Flickr and fetch a grid of 4x4 images, cache them locally and then render one big image out of scaled versions of the single images. The demos are running on geopic.me

To sum up our experience with TBB and script languages we know now that threading interpreters buries its very own set of challenges but we were able to get further than others did on the same mission by using TBB. The libraries we produced so far - which are open source and can be found on our github account - will be further developed and maintained.

We will continue working on both platforms to expose the power of multicore CPUs to developers in an approachable way. Along the way we also produced a number of more detailed white papers covering various aspects of the project:

* threads::tbb
* TBB in WordPress
* WordPress on HipHop

Get in touch if you are interested in these projects or have questions about the work we did. There is further information on our website OpenParallel.com

Contact: Nicolas Erdody

Modeling parallelism with Intel® Parallel Advisor

Please register for this presentation using the following link:

https://www1.gotomeeting.com/register/662997241

Here is a short abstract of the presentation:

An application written in a sequential language like C++ can be understood in two ways. It can be understood as an exact specific of how a program must execute, or it can be understood as a specification of the kinds of computations that must be performed. In the Parallel Advisor, we exploit the second interpretation by introducing a modeling language that can be embedded into your sequential application. This modeling language allows you to precisely specify where and how the sequential execution of your application is over-constrained and what flexibility you are willing to utilize to harness parallel execution. This talk will describe the modeling language, show the benefits of parallel modeling over parallel execution, and illustrate the correspondence of the parallel modeling language to common idioms available in Intel® Threading Building Blocks and Intel® Cilk™ Plus.

Please register for the presentation now and attend it on July 21st at 9am PDT. You can ask Paul questions during the second half of the presentation.