Never trust a statistics you didn't forge yourself

[Joe Armstrong (AL/EAB)]

> -----Original Message-----
> From: Ulf Wiger (AL/EAB) 
> Sent: den 22 februari 2006 14:36
> To: Joe Armstrong (AL/EAB); Michael Suess; Marc van Woerkom
> Cc: leopold@REDACTED; erlang-questions@REDACTED
> Subject: RE: Never trust a statistics you didn't forge yourself
> 
> Joe Armstrong wrote:
> > 
> > And by the way - you haven't sent me a gift certificate
> > - was the offer only open to people on the MPI list?
> > - did the other people on this list get any gift certificates?
> 
> I have no recollection of receiving one.
> 
> 
> > To start with Erlang is unique in your survey in the sense that 
> > concurrency is part of the language and not the OS.
> 
> To be fair, Java does support concurrency at the language 
> level. It just happens to do it poorly.

No it doesn't java thread map to OS threads - see for example 


<quote>
The Java programming language is naturally multi-threaded and because of
this the underlying OS implementation can make a substantial difference
in the performance of your application. Fortunately (or unfortunately),
you can choose from multiple threading models and different methods of
synchronization within the model, but this varies from VM to VM. Adding
to the confusion, the threads library will be transitioning from Solaris
8 to 9, eliminating many of these choices.

Version 1.1 is based on green threads and won't be covered here. Green
threads are simulated threads within the VM and were used prior to going
to a native OS threading model in 1.2 and beyond. Green threads may have
had an advantage on Linux at one point (since you don't have to spawn a
process for each native thread), but VM technology has advanced
significantly since version 1.1 and any benefit green threads had in the
past is erased by the performance increases over the years. 

http://java.sun.com/docs/hotspot/threads/threads.html 

</quote>

In other words the what you get depends upon the OS and the VM - ie the
semantics of concurrency depend upon the semantics of the underlying
OS - so it's "write once - debug on all known platforms".

Note that in 1.1 they did things correctly - then they thought about it
and went to the native OS threading model (1.2) - turning what might
have developed into a nice language into a mess. 

Note they even use the P word to justify this ("performance increases")
- yeah great - better performance at the cost of undefined semantics.

Do our process pre-empt? - who knows - run it and see.
 
This is why, or course, Erlang processes are far lighter weight than
java threads, because they are simulated in the Erlang run-time system,
so spawning a process only involves allocating a data structure and
assigning a few variables and not mucking around with page tables and
other nasty
OS internal things.

/Joe
 







> I would also suggest that OCaml does it, at least through 
> standard libraries. The libraries basically map the POSIX 
> thread model, but there are VM-level threads, which means 
> that OCaml programs can de- couple themselves from the OS 
> thread support.
> 
> /Ulf W
>