Great response… thank you for reading.

I think that your response is in essence an echo of my original post: That keeping an eye on efficient cache usage is paramount. [Again.. hardly an original or earth shattering thought.] Pinning an RTOS to a specific core does help to efficiently use of the cache. In reply to you… no, it doesn’t hurt to put a legacy stack on a single core. Potentially it doesn’t help as much as it could, however.

The Intel study was interesting because it indicated that for this particular workload that one could utilize the cache even more efficiently by segregating the data, not the algorithm, to a single assigned core/cache unit. I hear so much about pinning an OS of whatever sort to a core that to read a different approach was refreshing and notable.

Your use case is absolutely en vogue. We have customers follow that approach frequently and I presume they do so because it has benefits.

I do wonder, though, as the core count scales upwards in the next decade when we will get to a point that we’ve run out of boxes and algorithms to consolidate onto a single multicore (eventually many-core) device? Will there be a second multi-core transition hurdle as developers finally break down their co-resident code silos and create actual multicore algorithms? I presume, like all things, it will happen piece by piece.

So it is hard to see how it could hurt to put a legacy stack onto a single core, and then have a Linux or other OS share the other cores. It is an engineering-wise very efficient approach, and also one that retain the key value in terms of latency, robustness, and similar traits that make traditional RTOSes technically better at many things than a more general-purpose best-effort OS like Linux.

I think a common pattern for using a four-core or eight-core multicore device is to gather software stacks that used to run on four or eight physically separate processors onto a single die. This means much reduced bill of materials and package size, while still not totally requiring a rewrite of software.

A completely homogeneous OS across all cores on a multicore is going to be pretty rare, I think, as it seems to make more sense to run multiple OS instances, some specialized for control, some for line processing, and some for operations and maintenance.

/jakob

You can find a repository of more information from MontaVista here: http://www.mvista.com/download/library.php

The host of the webinar yesterday will email all registrants a PDF copy of the presentation for your review. Very soon the webinar will also be available “on-demand” via their website. I’ll post here when those URLs become available.

As far as other educational materials go there are certainly some options:

* MontaVista’s resource library: http://mvista.com/download/library.php

* Earlier blog posts from me on multicore: http://mvista.com/blogs/dixon/category/multicore/

* As I mentioned in the presentation telecom/datacom applications have characteristics which make some highly scalable web applications a natural analog. Google’s Seattle Scalability Conference presentations and videos may help to enlighten on what is happening in that world: http://groups.google.com/group/seattle-scalability-conference.

Digging around through my notes I found this quote from the “Landscape of Parallel Computing Research” site at Bekeley: “While embedded and server computing have historically evolved along separate paths, in our view the manycore challenge brings them much closer together. By leveraging the good ideas from each path, we believe we will find better answers to the seven questions.”

Guess I’m not alone on this meme. Who ever is?

You can read more at the Berkeley site: http://view.eecs.berkeley.edu/wiki/Main_Page

* I also mentioned OpenMP ( http://www.openmp.org ) and Erlang ( http://www.erlang.org ) yesterday.

Thankyou for an informative session.
Where can I get a copy of the presentation and is there a repository of presentations, whitepapers and other information and education material I could access?

Thanks and regards,
Vincent Barrientos
CAE Professional Services

Ask any manager in a bureaucracy how much faster he can go if you double his staff.
Depending on his office organization - it might not help at all.

Consider getting a drivers license.
The front desk employee accepts your stuff and puts it in an envelope. The second person cuts the photo ID. The third person looks up the applicant in a database. The fourth actually creates the basic paper. Fifth attached the photo ID. Sixth laminates. The seventh calls the applicant that it’s ready and the eighth one hands it out. Typical pipe line - cars have been made like this for ages.
And you might have noticed in a modern plant: car manufactures stopped using this kind of straight production lines.
The message boxes are the bottle neck in the above design, not the amount of employees.
Adding 8 people to the above team will not improve throughput significantly (is one going to put glue on the photo and another going to affix?). Having each employee (just the original finish a drivers license completely will require a few more computers and more pairs of scissors. But it improves the variety of the job. And the department’s throughput speeds up.

I’ve seen too many software designs that show the above limitations. And because e.g. locking and context switches are more expensive on multi-core machines, the message pipes (or other synchronisation points) will kill your app - especially if you have as many cores as you have stages.

But to stick to my old-and-trusted airbag example: I’d prefer a simple, single processor to check if my airbag must inflate.
That’s not a task I’d like to run on a multi-core CPU - not even if it is a dedicated core.
What happens if some problem prevents that CPU from running in time?
Ask SGI what happens if you scale the current Linux to run on, say, 4096 cores. Some basic OS thingies take forever…
http://lwn.net/Articles/229873

Henry Ford’s assembly line was a good design - ages ago.
Computer software again is reinventing mechanic engineering principles…

You are all subscribers to LWN.net, aren’t you? If not you should be. It is affordable and always informative.

The LWN.net article deals with a valid line of questions around why couldn’t Red Hat just have the patent invalidated? Jonathan Corbet also asks and discusses “what about all of the other projects out there which are using object-relational glue layers?”

I am actually the technical lead who designed the air hockey demo. Thanks for mentioning
our demo on your site! Your analysis of the system is fair and accurate - it is fast and generally
good, but not unbeatable. However, since you have seen it we have made a few simple
algorithm improvements that make it play even better. I also wanted to mention that this
demo was put together by 3 engineers on the rapid time-scale of 2 months.

We were really happy to win “best in show” award at FTF 2008, out of over 700 demos/kiosks.

I invite anyone reading this blog to learn more about our capabilities at Nuvation. We are an
electronics design services company that works with other companies to develop their products.
We’ve got experts in board design, firmware, FPGA, signal processing, motor control, algorithm
design, and many other core areas of electrical engineering and comp science.

And if you have interest in a fun Air hockey robot for your home or business, let us know that as well - we can help you out.

Regards
Mohan Gurunathan
Principal HW Engineer
Nuvation Research Company
San Jose, CA
415-713-4081
mohan.gurunathan@nuvation.com