2008/7/7 Todd Blanchard <tblanchard at mac.com>:
> It seems that there is a general assumption that threads will remain the
> unit of computational parallelism.  After attending Apple's WWDC and seeing
> some of the stuff in Snow Leopard, I don't believe this assumption is
> correct.
> Simply saying smalltalk threads must map to system threads is short sighted
> I think.  There are new models in the pipe that bear looking at.
> "Snow Leopard delivers unrivaled support for multi-core processors with a
> new technology code-named "Grand Central," making it easy for developers to
> create programs that take full advantage of the power of multi-core Macs.
> Snow Leopard further extends support for modern hardware with Open Computing
> Language (OpenCL), which lets any application tap into the vast gigaflops of
> GPU computing power previously available only to graphics applications.
> OpenCL is based on the C programming language and has been proposed as an
> open standard."
> Apple press release.  The unit of computation is not pthreads.  There is
> recognition that threads only get you so far and it is looking like it isn't
> far enough.

Its just a press release :)

We may call it thread or fiber or string, no matter what, but at base
we having a sequence of operations which should be performed in an
order, defined by programmer (which also known as algorithm).
Its about human's nature and perception: we separate the concept of
time onto three categories: past, present and future.
So, i think the concept of 'threads' will likely to stay until last
human lives on planet :)


> I think there's a major game change afoot and it is too early to make bets.
> On Jul 6, 2008, at 8:45 PM, Peter William Lount wrote:
>
> If the Smalltalk/Squeak/Commercial community doesn't want to move forward to
> take maximal general purpose advantage of the multi-core cpus that would be
> a big disappointment indeed. The other languages will leave Smalltalk in
> their dust. That is what clients are telling me and I happen to agree with
> them.
>
> I ask the Squeak Smalltalk (and Commerical Smalltalk) virtual machine
> developers and communities to please reconsider the general purpose many
> native threads per image solution for the next versions of your virtual
> machines.
>
> I think it's best to let each developer-user choose how many native threads
> per image and how many images are loaded and which images are loaded. After
> all it's their program. Isn't our job as language and systems designers to
> provide them with the tools that they need to build the systems that they
> want to build? I think so. What do you think?
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.