Emeka Nwafor

Introducing Performance Studio

What is Performance Studio? Is it:

1. Some kind of hair product

2. A new "clinic" for MLB players

3. Full name: : Wind River Linux Performance Studio for Intel® Architecture; a new add-on product for Wind River Linux that helps you get the most performance out of your embedded Linux device software running on Intel hardware 

If you correctly answered "3", give yourself a round of applause.

Our portfolio of development solutions have long addressed a broad set of embedded device development concerns in the areas of system definition, bring-up, software construction, integration & test, and maintaining and retro-fitting embedded device software and hardware. Now, with the introduction of Performance Studio, we not only have the broad development solutions portfolio but also further extend it with capabilities that enable us to go deeper into the platform and obtain the best performance out of embedded Linux software running on Intel® Core(™), Xeon(™), and Atom(™) processors. 

Performance Studio integrates the Intel C/C++ Compiler to generate hardware optimized code, the Intel Integrated Performance Primitives to adapt your algorithms to take advantage of Intel acceleration capabilities (SIMD, AVX, AES, SSE, …), and VTune to help pinpoint areas in the application that are candidates to be optimized.

Want your software to run faster on your Intel embedded platform? Concerned with getting the most out of your Intel embedded hardware? Need to optimize a computational-intensive algorithm? Thinking about portability to future platforms? Need to get deeper insight into where your CPU is spending time, wasting time, or simply waiting?

We invite you to learn more about Performance Studio and its integration with Wind River Linux and Wind River Workbench. Also, check out a great blog posted by my colleague in the Wind River Linux Developer Community that provides some additional technical insights into this product.

Many thanks to the teams in the Intel Developer Products Division and in the Wind River product group for the effort in bringing this solution to market.

I also want to use this time to wish our readers best wishes for this holiday season and peace, health, and happiness in 2012.

 

For additional information from Wind River, visit http://www.facebook.com/WindRiverSystems.  

 

 

Kill Bugs: Volume 1

The Bride: [Japanese] I need Japanese steel. 

Hattori Hanzo: [Japanese] Why do you need Japanese steel? 

The Bride: [Japanese] I have vermin to kill. 

Hattori Hanzo: [English] You must have big rats if you need Hattori Hanzo's steel. 

The Bride: [English] ... Huge. 

(from Kill Bill: Vol. 1)

I will probably need the help of a therapist to assist me in decoding why I think of that passage from Tarantino's great movie whenever I think of our portfolio of multicore development tools. When I ponder the personality of our development tools (i.e. the fearless Hattori Hanzo and his sword) and the risks presented to our customers in getting their multicore software to be correct (i.e. vermin - in reference to the challenges and bugs, not our customers) the exchange works for me. 

I digress.

We just announced a new release that extends our capabilities for multicore and virtualization for embedded applications. As always, I'm very proud of our development tools engineering team. A special shout-out to our teams in Canton and Vannes for their efforts in delivering this release.

Last week, my colleague - Bill "The Truth" Graham - blogged about the importance of development tools in reducing the inherent complexity of the task at hand. This latest release - actually, two product releases - is special because we have extended our hypervisor support to support Intel Xeon processors AND we have extended our development tools capabilities to now include "hypervisor-aware" debugging with our JTAG debuggers.

Why do I think this is important?

My mind goes back to a conversation with one of our early adopters of our hypervisor technology. The folks we met with were responsible for developing and stabilizing the software platform. The hypervisor technology is a critical component of their project as they are looking to consolidate multiple processors onto a single multicore device. They depend on our technology for memory protection to ensure the reliability of their system. One of the clearest memories I have from that day was when they asked "how do I debug my system running on the hypervisor"? The question was not asked out of curiousity - in their situation having assurances that we could address their needs in this area was critical for success.

So, what have done to help Kill Bugs when using virtualization?

The latest release of our Wind River On-Chip Debugging solutions enables debugging of a system running on the hypervisor without the need to add a target resident agent (see Figure 1). This new capability helps developers with tools to develop and debug hardware initialization code, virtual board bring-up, kernels, and drivers. When developing software for virtualized systems, these solutions give developers the confidence to know that they can set breakpoint, watch memory, or analyze stack frames.

Figure 1 - Overview of Hypervisor-aware debugging using Wind River On-Chip Debugging [click to enlarge]

This capability borrows from the concepts applied when debugging Linux processes using a JTAG debugger, but extends them to include the concepts of virtual boards running on the hypervisor. One of the special attributes of our solution is that we go beyond the MMU support provided by the processor to provide visibility and control over all of the virtual boards running on the system - not just the instance that is currently executing.

There's much more that can be discussed on this topic. More information and videos can be found here and there on our site. More importantly, we would like to hear your views on how to Kill Bugs when developing virtualized systems.

Simulation? Virtualization? What's in a name?

Check out this great panel round-table conversation about Virtualization & Simulation featuring a great set of panelists from Virtutech, Freescale, Cadence, GreenSocs, and our own Wind River CTO. The discussion touches on a number of important topics, including:

• the differences between virtualization and simulation
• the level of abstractions in models and their importance in predicting a system's behavior
• methodologies driving vendors solutions for virtualization and simulation
• programmable hardware and vanilla (i.e. standard) platforms

While the panelists do not agree on all points, I had a few great takeaways from the discussion:

1. Platform simulation is important to software engineers for managing complexity and risk when analyzing software performance - beyond MIPS and footprint. This is particularly the case when migrating existing software to multicore and dealing with race conditions resulting from parallelization of existing algorithms.
2. Multiple abstract models can be leveraged to ensure application integrity and timing, even before silicon is available. This involves abstract models ranging from cycle accurate instruction simulators to fast OS simulators. 
3. Software development can be fast-tracked using one or more abstract models of the hardware.

Proprietary and commercial simulation solutions have been around for many years. The need to shorten hardware-software integration time and achieve the goal of having working software when silicon/hardware arrives is a good reason to give virtual systems development solutions a good look.

 

2009 Autumnal Equinox

September 21st marks the last full day of the memorable summer of 2009, a summer that was memorable on several fronts - including personal and professional. My summer of 2009 includes memories of rainfalls of near biblical proportions, personal triumphs and losses, the passing of several social icons, and the evolution of the embedded software market.

There is some small debate as to when summer officially ends and when we must stop wearing white to work. If the sun could talk, I would guess that it would suggest that summer officially ends and fall begins at the moment of the autumnal equinox. This is the moment in the September when the sun is vertical to the equator. This year's autumnal equinox will occur on September 22nd at 17:18 ET (21:18 UTC) - just about five hours and eight minutes after the opening keynote at the 2009 Intel Developer Forum being held in San Francisco, California. This is also about nineteen and half hours before the day 2 keynote titled "Developing for the Continuum of Intel Platforms".

The team has been working intensely to prepare for IDF and the Day 2 keynote. We have contributed a short segment that we call "A Day in the Life of an Embedded Multicore Developer... in under 5 minutes". This portion of the keynote is intended to convey how Wind River's development tools and run-times work together cohesively to simplify dealing with the challenges of adapting existing uniprocessor code for multicore. The demo will showcase the Tilcon Graphics suite, Wind River Workbench, and a preview of soon to be available JTAG debugging solutions for Core 2 Duo and Xeon processors. (This is an extension of the Atom configuration of the solution that was made generally available this past July) I am very appreciative of the effort the team put in to create the demo systems.

These types of demonstrations are going to be important as we continue to evolve in the multicore era. A few months ago, I participated in a multicore development tools panel with Dave Stewart of Critical Blue. Dave made a comment to the effect that embedded developers "don't know what they don't know about multicore development" [editor's note: I am paraphrasing] and stressed the importance of education on the different technologies and techniques involved with multicore software. This comment resonates with me and I feel that it puts onus on vendors to support our "techno-speak" with demonstrable proof-points.

If you have an area of interest as it relates to our development tools support for multicore, drop me a comment and I'll put together a posting or video that helps to show the solution in action.

[You can follow Emeka's feed on Twitter - http://twitter.com/enwafor ]