speed...

[Joe Armstrong (AL/EAB)]

> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of Rob
> Sent: den 10 januari 2005 23:08
> To: erlang-questions@REDACTED
> Subject: speed... 
> 
> 
> I was interested if anyone has any opinions about the following.
> 
> I was looking through  for the language shootout because I 
> was thinking 
> about learning "D" (D and erlang hold a similar attraction 
> for me) and 
> wanted some programs to start with. I was happy to see that 
> the newest 
> round of "benchmarks" includes a new test where erlang starts 
> to shine 
> http://shootout.alioth.debian.org/benchmark.php?test=message&l
> ang=all&sort=cpu
> Although they will probably not ramp the test up to where erlang is 
> strongest since most other languages will start to fail at less than 
> 5000 threads.

The interesting thing is to start measuring at the point where things start
to fail and observe if the failure is catastrophic or not - 
Ramping the number of processes up to higher than the
maximum allowed number of OS processes will sort out the sheep from the goats.

Just a general comment of benchmarks - the benchmarks measure two non-functional
properties of a program (speed, and memory usage) but there many more non-functional
properties which a virtually impossible to benchmark.

IMHO the non-functional property of a program which I call "isolation" is
very difficult (maybe impossible) to measure. Isolation means - your program shouldn't be able to crash my program. 

If we put two programs in a machine (call them A and B) it doesn't matter a fig
if A is super fast and proved correct if it is possible for B to crash A.

If you choose your language on the basis of speed/memory you should end up with assembler
which has many other non-desirable non-functional properties.

Erlang processes try to be like OS processes in so much as they try to isolate
errors occurring in one processes from another process, benchmarking or even measuring
this property would be very difficult.

>The thing I am wondering about is the performance of Clean
>http://shootout.alioth.debian.org/benchmark.php?test=all&lang=clean&sort=cpu

> I don't understand why a small, relatively obscure functional language 
> could surpass the performance of compilers that have had massive amounts 
> of academic and industry scrutiny, testing and tuning over a period of 
> (in some cases) decades. For version 2.1 of Clean they have re-written 
> their compiler in Clean, is it that function languages are that much 
> superior for compilers?

Is this surprising - it doesn't surprise me - how does *massive* help
Rinus and Marko are very smart guys - If a problem can be solved by a very
small number of people (preferably one) then the solution will almost always
be better than if it were solved by many people.

Making a programming language/OS is a job suitable for a very small team -
delivering it to millions of people, translating the manuals to 100 languages,
and selling it to the world requires lots of people.

> I am thinking that I'd like to use some Clean functions for some serial 
> processing within the context of an Erlang program that does all the 
> concurrency management - Any opinions about something like that?

Fine - but make sure that get the concurrency model right.
What you want to constantly be flipping backward and forwards between Erlang and clean
Better to stay in one world for a relatively long time - every time you change from
Erlang to clean you'll get an impedance mismatch between the language - so you should have
a clear idea of what Erlang is good for and what Clean is good for and use them
appropriately.
 
/Joe

> TIA,

> Rob

> PS I noticed their erlang fasta program is failing:
> http://shootout.alioth.debian.org/sandbox/benchmark.php?test=fasta&lang=erlang&sort=cpu