Build an erlang computer (was:Computers are fast)
Joe Armstrong (AL/EAB)
Wed Jan 25 09:40:59 CET 2006
In my never ending quest for inefficiency I have seldom met a problem
which could not be solved in the twinkling of an eye (apart, that is,
from our friend that wanted to do O(10^19) computations to force some
crypto system :-)
I don't know if this is the right place to discuss this, but
I've been thinking about building a quiet and fast computer.
Has anybody done this? - I think I'm beginning to understand
the things I have to do to make it quiet - but how do I make a fast
I want to maximize my bangs for the buck.
Any ideas on the tradeoffs between processor caches, main memory sizes,
CPU clock speeds etc.
I'd like to optimize for
- compiling programs with a few hundred source code files
- making a high performance web server
Where is my money better spent?
A cheapish processor with as much memory as possible
Say a Athlon 64 3000+ 2GHz 512KB cache at 1295 kr
With 4 G memory (about 1000 kr/G)
Or the cheapest dual core Athlon 64 X2 3800+ 2GH 1MB = 3250kr
With 2 G memory
In the old days I always said that buying more memory was better than
buying a faster processor - is this still true? - also what
is the effect of increasing the size of the processor cache contra
more main memory for the same money?
Has anybody made any measurements here?
How about cheapo processor, water cooling and overclocking????
Is this the way to go?
<aside> It would be interesting to have some timings
for (say) the time to compile all the Erlang in say
stdlib, done on different processors, with different cache
Question: Is there a simple program to make main memory totally
unavailable in my linux system? - I'd like to boot the system
saying "use only 100K of memory" or "use only 200K or memory"
(I currently have 512K) so I can measure the effect of different
memory sizes on performance.
> -----Original Message-----
> [mailto:] On Behalf Of David Hopwood
> Sent: den 25 januari 2006 03:16
> Subject: Computers are fast (was: Recursive list comprehension)
> Richard A. O'Keefe wrote:
> > maybe they're right to dismiss the cost as a sacrifice for
> > provably correct programs,
> > But they *DON'T* dismiss cost as an issue. They just
> aren't one-eyed
> > and prejudiced about it. They are aware that development
> time is a cost.
> > They are aware that a high level language enlarges the
> scope of what
> > you
> > *CAN* program at all. They are aware that cheap ($1000)
> computers are
> > now more than a thousand times faster than expensive ($1000000)
> > mainframes of 25 years ago and have about a thousand times
> as much memory.
> Absolutely. Recently, during the development of a soft
> real-time program, I accidentally left on a debugging option
> that was dumping megabytes per second of barely useful debug
> information to disk. But the machine was so damn fast that
> this wasn't at all noticeable from the program's performance,
> and it still met its real-time deadlines.
> Some programmers, usually those who do almost all their
> programming in C,
> C++ and similar languages, seem to be obsessed with low level
> C++ optimizations
> that shave off a few cycles here and there. They haven't
> internalized just how fast modern computers are capable of running.
> When a program runs perceptibly slowly, it is almost always
> due to misdesign, not programming language. Slow applications
> (and operating systems) are slow because they're doing the
> wrong thing, not because they're doing the right thing
> slowly. To effectively optimize at a high level, you need a
> high level language.
> David Hopwood <>
More information about the erlang-questions