Re: [Caml-list] thousands of CPU cores

[Oliver Bandel <oliver@first.in-berlin.de>]

Zitat von Gerd Stolpmann <info@gerd-stolpmann.de>:

>
> Am Mittwoch, den 09.07.2008, 22:57 -0700 schrieb J C:
> > I know that Caml team wanted to see if many-core shared-memory
> systems
> > were going to stick around before bothering with Caml development
> that
> > takes advantage of them.
> >
> > Well, it looks like they are here to stay, after all:
> >
> > http://news.cnet.com/8301-13924_3-9981760-64.html
> >
> > As much as I hate to look a gift horse in the mouth, and I think
> Caml
> > has been a great and grossly underappreciated product, I need to
> see
> > if writing Caml is a viable code investment for the coming years or
> > something like Haskell, SML, F# or even Ada will be a better
> long-term
> > alternative.
> >
> > Are there plans to make Caml threads OS-native threads, or add
> > OpenMP-style primitives, or otherwise support multiple CPU cores?
> And
> > if so, roughly in what time frame?
>
> I wouldn't take this article too seriously. It's just speculation.
> Actually, the whole multi-core technology is a challenge for software
> development. You cannot simply take a program that runs well on 4
> cores
> and expect that it scales up to 400. Software must be designed from
> grounds up differently for such architectures.
>
> Just open up your mind to this perspective: It's a big risk for the
> CPU
> vendors to haven taken the direction to multi-core.
[...]

Well Sun has machines with a lot of processors and cores and
their machines are really workhorses. :)

I had worked on such a monster, if I remember correctly,
they had 8 cores, and later had upgraded the system to use 32 (?!).

I'm not quite sure on the numbers.

So, if we talk about Intel, they now tell us about 1000 cores...
...a while ago they didn't wanted to go into the multicore dirction
and had only seen a higher cpu-frequency up into the many-GHz
as a solution.
There are better architectures. Some DSPs had made more
instructions per second with some hundred MHz than some GHz-Intel CPU's,
becuase if you only need one cycle to load (more than none) new
instructions
while working at the current one, this means you are much faster.

Now Intel has decided to try more than one Core and their marketing
was good.... there already were multicore processors from other
technology
companies. OK, and while they slept for a while, now they talk about
100'ds, when they have just a few... and who want's this old 32-Bit
bullshit?
32 Bit's technology was available on workstations in the middle of the
eighties. It's about 20 years old.

And Intel processors are good to use, when the winter is cold ;-)


But in general multicore machines are a good idea.
And also other architectures are a good idea. I mean,
there are many ways in which technology can progress,
and only selecting one mostly seems to be a marketing thing, IMHO.


> Except for some
> standard components and some specially-adapted programs multi-core is
> more or less not exploited today.

Well, on systems like Sun's stations or other high-end servers,
there is a lot of parallelism exploited since a while.

But not on our small-budget home PCs.


> So these vendors are trying to push
> the software developers into this direction, and hope they find new
> ideas for designing multi-core-capable programs. This article is just
> propaganda for this hidden agenda. It can also happen that multi-core
> with too many cores turns out as failure - in the sense that the mass
> market is not ready for it.

OK, mass market is the key-word here!


>
> In Ocaml you can exploit multi-core currently only by using
> multi-processing parallel programs that communicate over message
> passing
> (and only on Unix).

Using multi-processes instead of multi-threads is the
usual way on Unix, and it has a lot of advantages.
Threads-apologetes often say, threads are the ultimative
technology... but processes have the advantage of encapsulation
of the wohole environment of the program.

This means a higher degree of saveness/security.

If there would be processes on Windows like on Unix/Linux,
they also would be more interesting to the people. And since
Threads are the only thing to make parallelism on Windows,
it's the only way, most people know of.
Again this is marketing and influence of the marketing leader.

Shell was nothing one would mention under Windows, and now M$
created a PowerShell, and then people on Windows one day will
ask, if there is something like a shell on Linux. Didn't M$ invented
shells?

The same with threads... they are heavy in use on Windows, so it seems
they must be used. But Processes also can be used - at least on Linux
and Unix.



On the above mentioned Sun machines there was paralellism
used a lot. It's their business. They do it. For them it's normal
business. And they heavily use processes. (This does not mean that there
are no multithreaded programs... if you have both, it's even better, of
course, but the processes can be swapt much easier from processor to
processor than threads.)



> Actually, it's an excellent language for this
> style.

Yes.

> http://wink.com). Ocaml is an excellent choice because you can
> quickly
> develop working programs that run 24/7. In the distributed world
> stability is quite important.

Hehe, stability is important also in non-distributed software.
But on the systems that are main stream, this is not the main issue ;-)
And threads btw. make programming stable programs quite harder,
especially if using C or C++. Ocaml ihas it's advantage here,
because it's quite safe/stable.


Ciao,
    Oliver