[squeak-dev] Prepare for Thousands of Cores --- oh my Chip - it's full of cores!

> Hi,
>
> Intel among others such as Tilera and NVidia are telling us - yes us
> smalltalkers - to prepare for tens, hundreds and thousands of cores on a
> single chip. It's up to us to bring this power to our end users - and
> ourselves too!
>
> Intel Says to Prepare For "Thousands of Cores"
> http://hardware.slashdot.org/hardware/08/07/02/1833221.shtml
> http://news.cnet.com/8301-13924_3-9981760-64.html?part=rss&subj=news&tag=2547-1_3-0-5
>
> What would be nice for a new version of squeak/croquet:
>
> HydraVM rewritten in Igor's new improved lambda+slang+exupery bypassing C
> altogether yet interfacing and generating C or Java or Javascript or Flash
> or ... as well for those deployment scenarios where that makes sense.
>

> To take advantage of multi-core what is needed is real native
> multi-threading per virtual machine + image not simply one native thread per
> image. Both are good for various application scenarios. Remember that a real
> multi-native threaded image can always just run one native thread if you
> want it too while a single native thread virtual machine + image will not
> run multiple native threads in the same image space. Sure multiple images in
> one program memory space is nice for some scenarios. I like that too and
> desire the option to deploy that way with multiple native threads per image
> space in one program memory space.
>

> Philippe Marschall wrote:
>
> 2008/7/5, Peter William Lount <[hidden email]>:
>
>
> Hi,
>
>  Intel among others such as Tilera and NVidia are telling us - yes us
> smalltalkers - to prepare for tens, hundreds and thousands of cores on a
> single chip. It's up to us to bring this power to our end users - and
> ourselves too!
>
>
> The same Intel that has told us that the future will be IA64 / EPIC?
> The same Intel that has promised us 20 Gigahurtz today? The same Intel
> that tried to sell us RAMBUST? The same Intel that builds SSE into
> it's processors to make the Internet faster?
>
> Cheers
> Philippe
>
>
>
>
> Hi,
>
> Yeah, the Itanium. An awesome chip architecture with an incredible
> instruction set. Gotta love it and it's doomed marketing.
>
> Yes, that Intel who showed an 80 core research chip last year.
> http://en.wikipedia.org/wiki/Teraflops_Research_Chip
> http://www.theinquirer.net/en/inquirer/news/2007/06/21/intel-shows-off-2-tflops-processor
> http://techresearch.intel.com/articles/Tera-Scale/1449.htm
>
> Yes, that Intel that is bringing out this little wonder.
> http://arstechnica.com/news.ars/post/20080205-small-wonder-inside-intels-silverthorne-ultramobile-cpu.html
>
> Intel isn't the only vendor up to the N-Core game. In fact they are getting
> beaten down hard by all the other contenders for the thrown. Hard.
>
> Yes, Multi-core from the companies listed here:
> http://en.wikipedia.org/wiki/Multi-core_(computing)
>
> Yes, that Tilera. They have 20 and Tile-64 core chips now, with 128 cores in
> the works. They have indicated that they plan up to 4096 with their
> technology.
> http://www.Tilera.com
>
> Yes, that NVidia who is already delivering tons of boards with massive
> numbers of GPGPUs. I have a couple of these boards already.
> http://www.NVidia.com
> http://en.wikipedia.org/wiki/GeForce_200_Series
> http://en.wikipedia.org/wiki/Nvidia_Tesla
> http://www.engadget.com/2008/07/03/nvidia-said-to-be-dropping-geforce-gtx-280-price-in-response-to/
>
> Yes, AMD and Intel who announced 8 core mainstream chips for next year.
>
> Yes, AMD (ATI) who announced this awesome speed beastie: 4870 X2 (RV770XT)
> cards. 800+ stream processing units!
> http://www.engadget.com/2008/07/03/amd-radeon-hd-4870-x2-images-leaked-rumored-for-august-release/
> http://ati.amd.com/products/Radeonhd4800/specs.html
>
> Yes, IBM who makes the 9 core cell processor chip.
> http://en.wikipedia.org/wiki/Cell_(microprocessor)
>
> Yes, Apple who just bought P.A. Semi.
> http://gizmodo.com/382929/apple-buys-itself-a-little-chip-company-known-for-super-efficient-processors
>
>
> These are not your or your fathers Transputer, most of these are real N-core
> processors available now.
>
> Looking at the cpu power available to us and comparing it with the software
> that is available one can't but be either sad or highly motivated to make
> use of the powerful chips to make much better software. Heck we're still
> programming with words! What ever happened to visual programming? We still
> have macosx and windows and ick linux and unix as the best of the breed
> systems? Ick. Sure I use them all but come on... we can and must do
> better...
>
> Cheers,
>
> Peter
>

> I am sorry to keep repeating myself, but we will be ready before they
> are. See this old picture of a Smalltalk machine with 1024 processors:
>
> http://cva.stanford.edu/projects/j-machine/
>
> Intel and Microsoft may have forgotten these lessons, but some of us
> haven't. And having them cough up $20M for a joint research project in
> multi-core software doesn't impress me very much. I bet just the coffee
> budget at either of these companies is a lot larger than that.
>

> Todd Blanchard wrote:
>>
>> This was pretty much the messages from Apple at WWDC recently as well.
>> Their next os version has several technologies based around this idea.
>> The shift is upon us.
>>
>
> Yeah, Apple is talking about two different approaches - program parallelism
> with multi-cores and data parallelism with GPGPUs from the likes of NVidia
> and AMD-ATI or possibly P.A.Semi (just a wild guess on P.A.Semi as their
> chips could be made with many many cores soon).
>
> And NO Smalltalk hasn't caught up yet. Just half a year ago in this very
> forum thread people were arguing against generic fully multi-threading of
> Smalltalk virtual machines. Cincom is against it. Instantiantions has been
> quite and likely won't do much.
>
> Only a few brave intrepid explorers get it and now we have experiments like
> HydraVM for croquet/squeak.
>
> Most smalltalks and smalltalkers are deeply stuck in the past of one native
> thread. Most in fact are not good at multi-threading with smalltalk
> non-native threads!!! It's difficult to learn and get right which is one
> motivator behind those wanting to take the easy road - one native thread per
> image, but that's the wrong route (in my view and obviously in others view
> as well) because it isn't general purpose enough. It involves hard work. No
> way around it.
>
> Igor, how will we gain access to writing for chips like NVidia when they
> keep it all secret? Use C with CUDA? Or hyjack OpenCL (to be part of LLVM
> and clang frontend if I'm not mistaken) when Apple gets it working?
>

> Todd Blanchard wrote:
>> This was pretty much the messages from Apple at WWDC recently as  
>> well.
>> Their next os version has several technologies based around this  
>> idea.
>> The shift is upon us.
>>
>
> Yeah, Apple is talking about two different approaches - program  
> parallelism with multi-cores and data parallelism with GPGPUs from  
> the likes of NVidia and AMD-ATI or possibly P.A.Semi (just a wild  
> guess on P.A.Semi as their chips could be made with many many cores  
> soon).
>
> And NO Smalltalk hasn't caught up yet. Just half a year ago in this  
> very forum thread people were arguing against generic fully multi-
> threading of Smalltalk virtual machines. Cincom is against it.  
> Instantiantions has been quite and likely won't do much.

>
> On Jul 5, 2008, at 6:40 PM, Peter William Lount wrote:
>
>> Todd Blanchard wrote:
>>>
>>> This was pretty much the messages from Apple at WWDC recently as well.
>>> Their next os version has several technologies based around this idea.
>>> The shift is upon us.
>>>
>>
>> Yeah, Apple is talking about two different approaches - program
>> parallelism with multi-cores and data parallelism with GPGPUs from the likes
>> of NVidia and AMD-ATI or possibly P.A.Semi (just a wild guess on P.A.Semi as
>> their chips could be made with many many cores soon).
>>
>> And NO Smalltalk hasn't caught up yet. Just half a year ago in this very
>> forum thread people were arguing against generic fully multi-threading of
>> Smalltalk virtual machines. Cincom is against it. Instantiantions has been
>> quite and likely won't do much.
>
> And in my opinion, the people who were arguing against it won the argument.
>  Concerns were raised about the cache-thrashing that could result, and
> relevant empirical research was linked to that seemed to validate these
> concerns.
>
>> Only a few brave intrepid explorers get it and now we have experiments
>> like HydraVM for croquet/squeak.
>
> Perhaps I misunderstood what you meant in the previous part of the
> paragraph.  Hydra is explicitly one-thread-per-image for 1) simplicity of
> implementation, 2) simplicity of use and 3) because many-threads-per-image
> hasn't been shown to be even theoretically desirable.
>
>> Most smalltalks and smalltalkers are deeply stuck in the past of one
>> native thread. Most in fact are not good at multi-threading with smalltalk
>> non-native threads!!! It's difficult to learn and get right which is one
>> motivator behind those wanting to take the easy road - one native thread per
>> image,
>
> Right, *one* motivator.
>
>> but that's the wrong route (in my view and obviously in others view as
>> well) because it isn't general purpose enough. It involves hard work. No way
>> around it.
>
> If you want to open up this discussion again, please bring some new facts.
>  Why would cache-thrashing not be an issue when running 64 cores on a single
> image?  I'm willing to be convinced, but I haven't seen even a sketch of a
> design that would avoid this.
>
>>
>>
>> Igor, how will we gain access to writing for chips like NVidia when they
>> keep it all secret?
>
> Keep what secret?  Both AMD and NVIDIA have exposed low-level instructions
> sets for their processors.  AMD's is called CTM, and I can't remember the
> name of NVIDIA's.  These instruction sets are at approximately the level of
> x86 assembly (i.e. low-level, but still portable across different GPU
> models).
>

> Hi,
>
> Intel among others such as Tilera and NVidia are telling us - yes us
> smalltalkers - to prepare for tens, hundreds and thousands of cores on a
> single chip. It's up to us to bring this power to our end users - and
> ourselves too!
>
> Intel Says to Prepare For "Thousands of Cores"
> http://hardware.slashdot.org/hardware/08/07/02/1833221.shtml
> http://news.cnet.com/8301-13924_3-9981760-64.html?part=rss&subj=news&tag=2547-1_3-0-5
>
> What would be nice for a new version of squeak/croquet:
>
> HydraVM rewritten in Igor's new improved lambda+slang+exupery bypassing C
> altogether yet interfacing and generating C or Java or Javascript or Flash
> or ... as well for those deployment scenarios where that makes sense.
>
> To take advantage of multi-core what is needed is real native
> multi-threading per virtual machine + image not simply one native thread per
> image. Both are good for various application scenarios. Remember that a real
> multi-native threaded image can always just run one native thread if you
> want it too while a single native thread virtual machine + image will not
> run multiple native threads in the same image space. Sure multiple images in
> one program memory space is nice for some scenarios. I like that too and
> desire the option to deploy that way with multiple native threads per image
> space in one program memory space.
>
> All the best,
>
> Peter

>
> From:
> http://en.wikipedia.org/wiki/CUDA
> ----
> Threads must run in groups of at least 32 threads that execute
> identical instructions simultaneously. Branches in the program code do
> not impact performance significantly, provided that each of 32 threads
> takes the same execution path; the SIMD execution model becomes a
> significant limitation for any inherently divergent task (e.g.,
> traversing a ray tracing acceleration data structure).
> ----
>
> Despite that we can program GPU, we can't make it to run different  
> code :(
> Also, its something utterly wrong with this statement.
> Since its waste to run 32 threads on same set of input data, it
> obvious that input is different. But since input data is different,
> how it possible that all branches taking same path for each thread?