-sam

I recall hearing things like a 15% slowdown for using threads and nothing close to 50% as well. Here is the simple wc.pl script used and timings for 5.6.1(no-threads) and 5.8.0(threaded).

############
# here's a real wc on the data.txt file

$ wc data.txt 
 208048 1675832 11021496 data.txt


############
# here's the test wc.pl script

$ cat wc.pl 
#!/usr/bin/perl -w
use strict;
my $total = @ARGV > 1;
my($lines, $words, $bytes);
while(<>){
  my @words = split;
  $words += @words;
  $bytes += length;
  $lines++;
}
printf "%7d %7d %7d %s\n",$lines,$words,$bytes,$ARGV;

############
# here's results for 5.6.1 no-threads in /usr/bin/perl

$ /usr/bin/perl -v

This is perl, v5.6.1 built for i686-linux

$ time /usr/bin/perl wc.pl data.txt 
 208048 1675832 11021496 data.txt

real    0m7.220s
user    0m7.030s
sys     0m0.080s


############
# here's results for 5.8.0 threaded in /usr/local/bin/perl

$ /usr/local/bin/perl -v

This is perl, v5.8.0 built for i686-linux-thread-multi

$ time /usr/local/bin/perl wc.pl data.txt 
 208048 1675832 11021496 data.txt

real    0m15.591s
user    0m15.350s
sys     0m0.130s
[download]

For 5.8.0 non-threaded but with 64-bit integer support the above ran at 9.2 seconds (circa 20% slower).

Be careful mixing times for 32-bit perls and 64-bit perls, especially on systems that emulate 64-bit integers, like gcc/libc on the x86 systems do. There's a lot of extra overhead there and, while the ultimate numbers are slower, you're not comparing apples to apples. Even native 64-bit systems like the alphas may perform more slowly, since you're slinging more data across the bus and using more cache memory for each variable.

Use a benchmark utility like Benchmark.pm to get your figures. Using time on a Unix system is notoriously inaccurate for measuring differences in perl. I have no doubt that 5.8 is slower (it is, after all, doing more work with Unicode and all), but 50% sounds too horrendous for any developer to accept. My bet is that by using time, you're also counting the startup time for perl, which is probably significant considering how much more has been built into it. For those small 7-15 second jobs, it might take 1.5-2 seconds for perl to startup and compile everything it needs to.

I compiled threaded and non-threaded versions of 5.8.0 today and I timed the wc.pl script shown above on a largish file using both 5.8.0's and my earlier 5.6.1. The threaded-5.8.0 was in the neighborhood 50% slower than the 5.6.1 release --- the unthreaded-5.8.0 was about 20% slower. So I decided to run perlbench to compare these three perls and try to pinpoint the problem. Follow the readmore tag for discussion and results ...

For the record I have posted a message to p5p regarding this. Ill post any relevant comments that come up.

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

BTW did you tried comparing 5.005_03 and 5.6.0? Isn't same tendency there?

Thanks.

For real fun, try it with perl 5.004_05 as a base performance measure. (But compile it with the same compiler--no fair using a better optimizer for 5.8.0 than you did a few years ago for 5.004_05)

---

On Wed, 24 Jul 2002, demerphq wrote:

Hi All.

I just wanted to draw your attention to a thread on perlmonks.org

relative speed of 5.8.0

In it a user asks about a %50 slowdown when using threaded 5.8 and a %20 slowdown when using non threaded 5.8.

I did some simple trials on SPARC and noticed a 2.8% slowdown in split comparing 5.00503 and 5.8.0. I didn't have a 5.6.1 handy to check against. I don't have an unloaded x86 machine available at the present to try either.

Do make sure that the comparison is using similar build options, particularly with respect to 'long long' and 'long double' types. I could well imagine that they have different speeds.

I'd expect that programs that use split() a lot also probably do a lot of I/O. I'm unsure how the PerlIO system benchmarks against earlier stdio versions, particularly on systems where perl could "cheat" and poke around inside the stdio buffers.[*]

-- 
    Andy Dougherty		doughera_at_lafayette.edu
    Dept. of Physics
    Lafayette College, Easton PA 18042

---

Yves / DeMerphq
---
Please dont upvote this node. Its a repost FYI only. (Email addresses were obfued)

(reformatted repost from p5p)20020725153047.2333.2@bactrian.elixent.com

---

Andy Dougherty <doughera_at_lafayette.edu> writes:

I'd expect that programs that use split() a lot also probably do a lot of I/O. I'm unsure how the PerlIO system benchmarks against earlier stdio versions,

As are we all.

particularly on systems where perl could "cheat" and poke around inside the stdio buffers.[*]

On such system's PerlIO will normaly use :stdio layer as its underlying implementation. For the majority of calls that means a function call and a couple of indirections more that before.

If you want PerlIO and speed is important to you than using :perlio will normally be slightly quicker than :stdio. :perlio allows the poking around and does not have some of the overheads of a typical system's stdio (e.g. no MUTEX locking we don't share them between threads).

--
Nick Ing-Simmons
http://www.ni-s.u-net.com/

---

Yves / DeMerphq
---
Please dont upvote this node. It is posted FYI only.

use open IO => ":raw";
[download]