RemObjects Software Gears
 
       

Concurrency in Chrome 'Oxygène'

{#} by marc hoffman 12/04/07 11:58:16 am, 555 words, Categories: RemObjects, Oxygene, .NET, Visual Studio, ROFX, Delphi, Mono, Cocoa, Mac, Windows, Linux

As you probably know, while 'Joyride' is the current version of Chrome, and we plan to have many significant updates to it over the next half year, we're also already busy planning and implementing cool stuff for 'Oxygène', our next major release planned for late 2008.

Among many other cool language features we have in the works (some of which we might start talking about in a short while), we sat down last week to finish our planning of one big area - Parallelism.

What we're planning is really a set of independent features that will work together to bring unprecedented capabilities to multi-threaded development, allowing you to build applications that can leverage increasing core counts with more ease than any other mainstream language around.

Of course we have always had support for async methods and locking in the Chrome language from v1.0, but that has really only been the beginning. One of the coolest things we have planned for 'Oxygène' is native language support for futures.

A "future", for those unfamiliar with the term, is basically a promise to provide a value at a later time. For example, imagine you have a calculation that's split in two parts. Each part is independent, but takes a long time to compute. traditionally, you would write this sequentially, such as

  var part1: Int32 := 1+2;  // lets assume 1+2 is hard to calculate, here ;)
  var part2: Int32 := 3+4;
  result := part1+part2;

Of course part1 takes a long time to calculate, and while that is happening, your second cpu core sits idly by. Now, what if we could make a small change to this (note that this syntax is not set in stone yet):

  var part1: future Int32 := 1+2; 
  var part2: Int32 := 3+4;
  result := part1+part2;

Now, part1 is no longer an Int32, it is a "future Int32". What this means, it represents the value we expect for part1, but that value has not been fully calculated at the time the first statement executes. In fact. the first statement will execute in just about no time, and the main thread of your application will continue to calculate part2.

While part2 is being calculated, another thread (and hopefully another CPU) will get busy calculating part1, in the background.

Note that in our last statement, we can refer to part1, as if it were a plain Int32 (not a future). What's happening behind the scenes here? Simple: if our future has already been calculated in the background, we're simply grabbing the result and using it as part of the expression. If calculation is still in progress (maybe part2 was a bit faster), the expression will Wait for part1 to be completed.

The above example is a bit contrived of course - after all, a simple addition will execute in no time. But imagine part1 and part2 being two halves of a quick sort operation. Or calculations over two sides of a binary tree.

Futures (and Oxygène's other parallelism features that we will talk about another day) will make it easy to parallelize your application, while keeping your algorithms natural and intuitive, and without having to arbitrarily rearrange your code just based on what thread you want it to run on.

Stay tuned for more peeks ahead at 'Oxygène' soon, or grab our Future Subscription (pun not intended) to try Oxygène now, first hand!

Comments, Pingbacks:

Comment from: Barry Carr [Visitor] Email · http://www.barrycarr.org.uk
DZoned!
PermalinkPermalink 12/04/07 @ 12:29
Comment from: Joe White [Visitor] · http://www.excastle.com/blog/
Have you been following Microsoft's .NET "Parallel Extensions"? Might be a good source of ideas. (And if you're compiling to .NET 3.5, you might even have your syntactic sugar map to their APIs, and get their performance tuning for free. Unfortunately, they're 3.5-only.)
PermalinkPermalink 12/04/07 @ 14:46
Comment from: marc hoffman [Member] Email
Joe: yes, ‘Oxygène’ will definitely leverage the PFX, where possible.
PermalinkPermalink 12/04/07 @ 14:52
Comment from: Eber Irigoyen [Visitor] Email · http://ebersys.blogspot.com
that's a cool feature
PermalinkPermalink 12/04/07 @ 20:50
Comment from: amigo [Visitor] Email · http://onemilliontemplates.com
Nice site.Thanks for good information...
PermalinkPermalink 12/05/07 @ 02:03
Comment from: Fernando Madruga [Visitor] Email · http://memyselfanddelphi.blogspot.com
Looks promising but you started by saying that you're "allowing you to build applications that can leverage increasing core counts". How does this scale? In the example, there are two different parts and respective calculations: what happens with more parts or even with an undetermined at compile time number of parts?
PermalinkPermalink 12/05/07 @ 02:54
Comment from: marc hoffman [Member] Email
@Fernando: wherever possible, this will leverage PFX, the new Parallel Framework extensions coming from Microsoft. These already provide optimizations that scale to the number of available cores. For example, if you "only" have 4 cores, it will make sure that you don't get 20 threads running to compete for the CPU, instead it will schedule all async tasks to run on a number of threads that is optimal for the count of cores.

The same goes for features such as parallel for loops (which i didn't discuss before). Just because you're looping over 1000 elements doesn't mean it will create 1000 threads (that would be insane, and waste more time in thread switches than in actual work); it will create/reuse an optimal number of threads, and schedule the 1000 elements among them.

this way, even on a single core, you will see negligible overhead compared to non-threaded code, and with 2 or more cores, the app will scale seamlessly* depending on the number of cores.

(*obviously, it will still be possible to write code that scaled badly, there's no such thing as a free lunch. but when used properly, these things will scale well and transparently, as core count increases)
PermalinkPermalink 12/05/07 @ 10:15
Comment from: Phil Hackett [Visitor] Email
All sounding very smart indeed. Nice!
PermalinkPermalink 12/05/07 @ 18:17
Comment from: Maria [Visitor] Email · http://music-collection.net
Thank U so much Admin.Nice article
PermalinkPermalink 12/18/07 @ 05:17

Leave a comment:

Your email address will not be displayed on this site.
Your URL will be displayed.

Allowed XHTML tags: <p, ul, ol, li, dl, dt, dd, address, blockquote, ins, del, span, bdo, br, em, strong, dfn, code, samp, kdb, var, cite, abbr, acronym, q, sub, sup, tt, i, b, big, small>
(Line breaks become <br />)
(Set cookies for name, email and url)
(Allow users to contact you through a message form (your email will NOT be displayed.))
This is a captcha-picture. It is used to prevent mass-access by robots.
Please enter the characters from the image above. (case insensitive)

 

marc hoffman

Chief Software Architect &
Spare-time Photographer

mh

Links

Twitter

marc hoffman (follow)
    loading...
Mike Orriss (follow)
    loading...

Navigation

XML Feeds 

Who's Online?

  • Guest Users: 8