forwarded message from Christian Tismer (fwd)

[Shawn Pearce]

Wiger Ulf <ulf.wiger@REDACTED> wrote:
> Regular erlang? Well, on my measly 400 MHz Pentium running
> Windows 98, I measure about 800,000 context switches/s, which
> does not compare (even though it probably suffices for most
> applications). That's two erlang processes yielding to each other
> in a tight loop.

Aaaaaah!  The world is ending!  Erlang has been beat!

:-)

Move along folks.  Nothing to see here.  A Python hacker has come up
with an even faster way to context switch useless threads.  (By
useless I have to say:  do they support linking?  monitors?  private
heaps?  message queues?  distributed messaging?  floating point
context?  Doubtful.)

Erlang isn't the fastest platform.  I think we all know that.  We
also know that for most high level operations (where Erlang really
shines), its very hard to beat the toolkit that comes with Erlang,
and the language is actually pretty reasonable to program in
(compared to say Java!).


> OK, cute, but what is the application?

Fast context switching, so Python can implement better threading (but
still as useless as ever) then it already has.  IMHO, the killer
feature to threading is what Erlang already does:  no locks, messaging,
message queues, linking, monitoring, private heaps.  Of course deadlock
is still possible, but its a whole heck of a lot easier to write
complex threaded code in Erlang and not run into trouble.  I really
think the POSIX folks (and thus C++ and Java folks, Python, etc) have
all got threading wrong from the start.


Now I'd be a happy man if I could just find day-time work hacking
Erlang code.  Seems a tall order here in the states!


> From: "Bijan Parsia" <bparsia@REDACTED>
> 
> > Is Erlang up to this challenge?
> >
> > > Let me simply end this pamphlete with some simple sentences:
> > > Stackless Python is more capable of tasklets switching than any
> > > other light-weight threading software package.
> > > If anyone disagrees, please give me a runnable counter-example.
> > >
> > > Here are some impressive site-specific time measurements, which
> > > especially show, that 20.000.000 cframe tasklet switches per
> > > second are really, really hard to beat.
> > >
> > > Pythonon Win32:
> > >
> > > D:\slpdev\src\2.2\src\Stackless\test>..\..\pcbuild\python taskspeed.py
> > > 10000000 frame switches      took 3.83061 seconds, rate =    2610551/s
> > > 10000000 frame softswitches  took 2.40112 seconds, rate =    4164718/s
> > > 10000000 cfunction calls     took 2.13033 seconds, rate =    4694098/s
> > > 10000000 cframe softswitches took 0.49296 seconds, rate =   20285627/s
> > > 10000000 cframe switches     took 1.98907 seconds, rate =    5027486/s
> > > 10000000 cframe 100 words    took 3.93737 seconds, rate =    2539768/s
> > > The penalty per stack word is about 0.980 percent of raw switching.
> > > Stack size of initial stub   = 14
> > > Stack size of frame tasklet  = 58
> > > Stack size of cframe tasklet = 35
> 

-- 
Shawn.

  Steinbach's Guideline for Systems Programming:
  	Never test for an error condition you don't know how to handle.