[Shootout-list] Re: threading (was Many tests cheat)

[skaller]

On Wed, 2004-11-03 at 22:35, Einar Karttunen wrote:
> On 03.11 22:25, skaller wrote:
> > On the other hand Felix provides fast scalable microthreading.
> > (telco environment originally)
> 
> Sounds nice, are they pre-emptive? 

No, not by themselves. You can make them concurrent,
but that's a different thing. A typical design uses
N CPUs to share workload .. that's N threads, plus
a few I/O threads to fill the input queue with messages.
But the microthreads don't interact directly in a typical
application: they synchronise via the driver if necessary.
Pre-emptive multi-tasking is slow and rarely needed on
a large scale.

As I mentioned,telco (phone calls) is a target application.
There you're dealing with 300 calls per second, 3 minutes
average.. but people mainly yabber on phones, the logic
is for accounting, connecting, etc. So the threads don't
do much work. Other targets include games and GUI .. 

What the translator provides is control inversion:
stackless procedural operation with yields to read
messages. The stackless operation makes posix threads
tricky.

> I think that was at least
> implied as a requirement in some of the concurrency tests.

More than implied.

> However as allways there are some exceptions to the rule.

Is this one, and why?

> > So perhaps, two tests -- both ring of messages,
> > one requiring pthreads, and one without that
> > restriction (language without microthreads can
> > stick with posix threads .. or use callbacks,
> > setjump based coroutines managers .. etc ..
> 
> Is there any reason to require pthreads? 


The algorithm shall be as follows:

     1. Each test program should spawn eight thousand execution contexts
        (processes, though languages with limited concurrency can use
        threads.)
-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net