thousands of cores

[Gerald de Jong]

Hmmm.. no reaction on my request for comments about our first gathering.

Anyway, I was talking about High Performance Computing and
parallelism, and here's something from Intel:

http://news.cnet.com/8301-13924_3-9981760-64.html?part=rss&subj=news&tag=2547-1_3-0-5

--
Gerald de Jong
Beautiful Code BV
http://www.beautifulcode.eu
ph: +31629339805

[kir...@gmail.com]

well, all I can say is that it's gonna take quite some time before
our languages and development tools are ready to cope with all these cores.
And I don't see Java being a winner here.

2008/7/3 Gerald de Jong <gerald...@gmail.com>:

[Gerald de Jong]

Okay, so which languages then? Scala? Erlang? C/C++? Something else?
I think it might be more about how software is structured than about
the language.

[Artem Baguinski]

On Thu, Jul 3, 2008 at 2:49 PM, Gerald de Jong <gerald...@gmail.com> wrote:
>
> Okay, so which languages then? Scala? Erlang? C/C++? Something else?
> I think it might be more about how software is structured than about
> the language.

java/c/c++ make you think about how to do parallel processing. it is a
sort of different mode, and a special one - you have to cast some
spells to do go into it (and even to stay there).

in open gl shader languages, for example, parallelism is the implied
mode: your shader will be executed on multiple cores of the gpu to do
multiple little boring tasks in sort of chunks. you don't care how
many cores you've got, how many threads start etc - you just describe
what is to be done and the compiler / driver does the rest.

in other languages (e.g. fortress), non-homogenic operations might run
in parallel as well and it's up to compiler / run-time to rehash your
algorithm for multiple cores. for example:

compare( image_features(img1), image_features(img2) );

in fortress might run two (expensive) calls to image_features() in
parallel without programmer doing anything special. programmer
concentrates on algorithm and compiler / runtime concentrates on
parallelisation / optimization.

compilers of pure(ish) functuional languages can do that sort of thing
much more easily, because side effects are avoided and compiler can
reason about the control flow / dependencies.

doesn't mean they won't come up with some massively parallel jvm or
another dozen of C++ keywords though. but in languages like fortress
the assumption that everything that can be parallelized might be
parallelized is builtin part of semantics, making utilizing parallel
hardware easier. i think, i haven't even install fortress - just heard
interview with Guy Steele about it and read the manual.

http://research.sun.com/minds/2005-0302/

QUOTE

Guy Steele leads a small team of researchers in Burlington,
Massachusetts, who are taking on an enormous challenge -- create a
programming language better than Java.

Think of it as Java for scientists, Java for the programmers of a
peta-scale supercomputer.

UNQUOTE

:-)

> On Thu, Jul 3, 2008 at 2:35 PM, <kir...@gmail.com> wrote:
>>
>> well, all I can say is that it's gonna take quite some time before
>> our languages and development tools are ready to cope with all these cores.
>> And I don't see Java being a winner here.
>>
>> 2008/7/3 Gerald de Jong <gerald...@gmail.com>:
>>>
>>> Hmmm.. no reaction on my request for comments about our first gathering.
>>>
>>> Anyway, I was talking about High Performance Computing and
>>> parallelism, and here's something from Intel:
>>>
>>> http://news.cnet.com/8301-13924_3-9981760-64.html?part=rss&subj=news&tag=2547-1_3-0-5
>>>

--
cheers,
artm

http://lab.v2.nl/

[kir...@gmail.com]

I totally agree with Artem. His post is right to the point.
I can only mention another language which is a great candidate for
parallel computing and which I'm growing to love - Haskell. Although
being a pure functional language it can be a real pain sometimes.

[Gerald de Jong]

On Thu, Jul 3, 2008 at 4:07 PM, Artem Baguinski <femis...@gmail.com> wrote:
> in open gl shader languages, for example, parallelism is the implied
> mode: your shader will be executed on multiple cores of the gpu to do
> multiple little boring tasks in sort of chunks. you don't care how
> many cores you've got, how many threads start etc - you just describe
> what is to be done and the compiler / driver does the rest.

Hey Artem, I would be very interested to hear more about these shader
languages. Would you consider giving a talk about that at the next
Greythumb meeting? Can you give us some good links?

[Artem Baguinski]

On Thu, Jul 3, 2008 at 5:14 PM, Gerald de Jong <gerald...@gmail.com> wrote:
>
> On Thu, Jul 3, 2008 at 4:07 PM, Artem Baguinski <femis...@gmail.com> wrote:
>> in open gl shader languages, for example, parallelism is the implied
>> mode: your shader will be executed on multiple cores of the gpu to do
>> multiple little boring tasks in sort of chunks. you don't care how
>> many cores you've got, how many threads start etc - you just describe
>> what is to be done and the compiler / driver does the rest.
>
> Hey Artem, I would be very interested to hear more about these shader
> languages. Would you consider giving a talk about that at the next
> Greythumb meeting? Can you give us some good links?

if I can make it i'd love to do a demonstration of some misuse of shaders...

here, general info on consumer-grade GPUs' shading langauges with links:

http://en.wikipedia.org/wiki/Shading_language#Real-time_rendering

some modern languages:

http://en.wikipedia.org/wiki/GLSL
http://en.wikipedia.org/wiki/Cg_programming_language
http://en.wikipedia.org/wiki/High_Level_Shader_Language

and i guess the most interesting for the list - general purpose GPU:
using SLs for not necesserily graphical tasks:

http://www.gpgpu.org/

(one of the first programs I saw there years ago was conway's life
running on GPU using texture for the grid)

On their site - more experimental GPU based high level languages:

http://www.gpgpu.org/cgi-bin/blosxom.cgi/High-Level%20Languages/index.html

[Artem Baguinski]

hi again

while doing some research for some unrelated multithreading problem,
came accross these lists of concurrent / parallel programming
languages:

http://en.wikipedia.org/wiki/Concurrent_computing#Concurrent_programming_languages
http://en.wikipedia.org/wiki/Parallel_programming_model

had a look at some, and they feature some weird looking / sounding
constructs :-)

[Anne van Rossum]

Hi all,

On the moment I am with the neuromorphic engineering guys. Die hards
about how sensory and locomotion systems can be implemented on robots
in analog hardware (even reconfigurable analog hardware, compared to
FPGA: FPAAs: http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=205916545).
However, they have no clue about GPUs. Now, I know that this group is
more about robot bodies, but I guess a lot of people are also
interested in the control architecture that drives such a body. Part
of the locomotion is of course governed by the (spring) dynamics of
the physical system, another by control structures like the brain.

The brain is a huge organ, so I am very interested in CUDA, I know
that there is a commercial framework in which neurons are implemented
with CUDA at evolvedmachines.com. But perhaps there are also open-
source frameworks available? If anyone can give me some clues, I will
appreciate it very much!

Anne

[Gerald de Jong]

Hey Artem,

Are you going to be able to be in Den Haag on tuesday? I expect it
might be too far for you, if you're not in the neighborhood already.

-Gerald

--

[Artem Baguinski]

no, Gerald, I can't: Annemiek gives a lesson in the evening and our
normal babysitter can't be here on Tuesday :(