Re: [MacPerl] MacPERL Performace vs. Intel Class systems

[pvhp@forte.com (Peter Prymmer)]

neeri@iis.ee.ethz.ch, mac-perl@iis.ee.ethz.ch
Subj:	Re: [MacPerl] MacPERL Performace vs. Intel Class systems 

Matthias Neeracher wrote a message received 3-JUN-1997 17:04:59.08:
!You all have correctly identified file system performance as the bottleneck.
!
!D.Thomas@vthrc.uq.edu.au (Danny Thomas) writes:
!>"Paul J. Schinder" <schinder@pjstoaster.pg.md.us> writes
!>>In 6 or so months, we can all upgrade what machines we can to Rhapsody and
!>>lose the file system bottleneck.  Until then, there's little to be done.
!
!Maybe not in this script, but in scripts that have a somewhat better balance
!between computation and I/O, there are theoretical possibilities to speed up
!MacPerl (through asynchronous writes), but I won't pursue them in the near
!future.

Um that sounds dangerously like a contemplation of something other than perl's 
famous and effective reference counting "garbage collection" scheme.  Are 
proposing an IO request collection scheme that scripters won't have control 
over?

!>I think Matthias said that the two big
!>problems using MacPerl as a scripting language are:
!>  1) it's use of memory
!
!Effectively a non-issue with a good VM subsystem, i.e. Rhapsody.
!
!>  2) single-threaded nature
!
!Effectively a non-issue with a good process scheduling subsystem,
!i.e. Rhapsody. 

Folks might also want to check out the benchmarks done in the July 1997 MacWeek 
(pentium vs ppc 604e) - nothing involving perl but an interesting comparison 
nonetheless.

!>I'm guessing that by the time of the unified Rhapsody release in a year or
!>so, that perl will include multi-threading (slated for perl 5.006).
!
!I guess so, but I also think you're missing the point here. People probably
!overestimate how much they want threads. Primarily, they want multiple scripts
!in the same language, executing concurrently. On MacOS, threads have big
!advantages providing that, so threading is the way to go. On Rhapsody,
!processes are much more affordable than on MacOS, so prcoesses (without any
!threading support in perl) will do the job just fine. Threads will be useful
!for applications such as internet servers, but not as widely as you might
!think.
!
!Matthias

Thank you for saying that Matthias.  A good reference on what threads can 
accomplish (as well as just how awful it is to code everything reenterable and 
cooking up your own mutex locking/resolution schemes) is the B<Pthreads 
Programming> book from O'Reilly.  In it they mention a couple of applications 
suitable for threading: servers on a single processor, matrix math on a 
multiple (hopefully symmetric) processor box.  The interesting case was the 
first of these as they coded sample servers without threads (on unix using 
fork() and such where process overhead is rather light) and with threads: the 
result was that the threaded server only gave a 33% speedup and only 
when heavily loaded by client requests. In fact, when lightly loaded the 
traditional non-threaded server outperformed the threaded one (presumably 
because of less thread lib and lock checking overhead).

Threading does seem all the rage but its payback is rather modest.

Peter Prymmer


***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch