Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
Working on it a little :) and I would like Blair's 3 am pepper extract (50 USD). Kartik Thakore On 23-Nov-09, at 1:47 AM, Jonathan Leto jal...@gmail.com wrote: Howdy, I seem to recall that we have a pressing need for another perl5 VM to deliver on the promise of being able to run your perl5 code in perl6 programs. --Eric This is called Blizkost [0], a project stared by Jonathan Worthington [1], one of the core Rakudo developers. It allows Parrot to run Perl 5 code. Currently we need to get loading of XS from Perl 5 working on Blizkost, it is described in detail in the TODO [2]. If you get use Data::Dumper; working in Blizkost, I will buy you a beverage of your choice. Fork some repos and write some tests/code and docs, people! git clone git://github.com/jnthn/blizkost.git Duke [0] - http://github.com/jnthn/blizkost [1] - http://www.jnthn.net [2] - http://github.com/jnthn/blizkost/blob/master/TODO -- Jonathan Duke Leto jonat...@leto.net http://leto.net
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
Howdy, I seem to recall that we have a pressing need for another perl5 VM to deliver on the promise of being able to run your perl5 code in perl6 programs. --Eric This is called Blizkost [0], a project stared by Jonathan Worthington [1], one of the core Rakudo developers. It allows Parrot to run Perl 5 code. Currently we need to get loading of XS from Perl 5 working on Blizkost, it is described in detail in the TODO [2]. If you get use Data::Dumper; working in Blizkost, I will buy you a beverage of your choice. Fork some repos and write some tests/code and docs, people! git clone git://github.com/jnthn/blizkost.git Duke [0] - http://github.com/jnthn/blizkost [1] - http://www.jnthn.net [2] - http://github.com/jnthn/blizkost/blob/master/TODO -- Jonathan Duke Leto jonat...@leto.net http://leto.net
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
* On Wed, Nov 18 2009, Aristotle Pagaltzis wrote: * David Golden xda...@gmail.com [2009-11-18 16:05]: So creating/destroying Perl objects -- even just for things like argument passing on the stack -- is part of the cost of the flexibility of Perl. When that becomes a bottleneck in a tight loop, that's when XS becomes a potential option. That's not a knock on Perl -- that's just part of the design. It isn’t inherent in the language design. A tracing JIT runtime *could* make Perl go faster than compiled code. So untrue. Python has this problem, but people wrote new implementations anyway. Psycho, PyPy, and Unladen Swallow may not run every program ever written, but the programs they do run run much faster. If someone were to write a new VM, legacy code could run on the old VM, and new code can be tested and tweaked to run on the new VM. If you don't want to use the new VM, then don't. Get that 1000x speedup some other day... The real reason for the lack of another Perl VM is that Perl programmers are very, very lazy. ;) -- print just = another = perl = hacker = if $,=$
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
# from Jonathan Rockway # on Thursday 19 November 2009 07:06: The real reason for the lack of another Perl VM is that Perl programmers are very, very lazy. ;) In this case, you mean 'perl' programmers. :-D I seem to recall that we have a pressing need for another perl5 VM to deliver on the promise of being able to run your perl5 code in perl6 programs. --Eric -- software: a hypothetical exercise which happens to compile. --- http://scratchcomputing.com ---
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
Quoth enoba...@gmail.com (Eric Wilhelm): # from Jonathan Rockway # on Thursday 19 November 2009 07:06: The real reason for the lack of another Perl VM is that Perl programmers are very, very lazy. ;) In this case, you mean 'perl' programmers. :-D I seem to recall that we have a pressing need for another perl5 VM to deliver on the promise of being able to run your perl5 code in perl6 programs. Not really. Just embed the existing perl 5 interpreter, with a shim layer to translate. It's the same, really, as Inline::Java. (When I say 'just'... :) ) Ben
flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
Dear Module Authors, recently in one of the Amsterdam Perl Mongers meetings the question came up how much faster actually the XS version of Date::Calc (Date::Calc::XS) was as compared to the Pure Perl version (Date::Calc::PP). Here is the answer (see attached script - you will need to have Date::Calc 6.3 and Date::Calc::XS 6.2 installed to run this script successfully): FreeBSD 7.2.-stable: $ perl benchmark.pl Running under Date::Calc::PP version 6.3 timethis 5000: 17.3147 wallclock secs (17.24 usr + 0.06 sys = 17.30 CPU) @ 288.94/s (n=5000) Running under Date::Calc::XS version 6.2 timethis 5000: 1.02551 wallclock secs ( 0.97 usr + 0.06 sys = 1.03 CPU) @ 4848.48/s (n=5000) Windows XP SP3: Running under Date::Calc::PP version 6.3 timethis 5000: 17.1034 wallclock secs (16.86 usr + 0.00 sys = 16.86 CPU) @ 296.58/s (n=5000) Running under Date::Calc::XS version 6.2 timethis 5000: 1.3329 wallclock secs ( 1.28 usr + 0.00 sys = 1.28 CPU) @ 3900.16/s (n=5000) Another (faster) Windows XP SP3 machine: Running under Date::Calc::PP version 6.3 timethis 1: 20.5605 wallclock secs (20.55 usr + 0.00 sys = 20.55 CPU) @ 486.69/s (n=1) Running under Date::Calc::XS version 6.2 timethis 1: 1.44224 wallclock secs ( 1.42 usr + 0.00 sys = 1.42 CPU) @ 7032.35/s (n=1) One can see from these results that the XS version quite consistently runs approximately about 15 times faster than the PP version. The test script benchmarks a function which calls all functions in Date::Calc once, each. Other similar results from XS/PP pairs of modules would be interesting - maybe not for any practical purposes, but just for the fun of it (or maybe to give deciders convincing arguments to upgrade to an XS version or not). Cheers, Steffen benchmark.pl Description: Binary data
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
* O. STeffen BEYer ost...@gmail.com [2009-11-18 13:10]: One can see from these results that the XS version quite consistently runs approximately about 15 times faster than the PP version. This is flame bait? Why is this flame bait? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
Maybe he thought there were a debate on XS v.s PP performance. If only we could be this flame retardent in the uneeded perl5 v.s perl6 debate. Kartik Thakore On 18-Nov-09, at 7:29 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote: * O. STeffen BEYer ost...@gmail.com [2009-11-18 13:10]: One can see from these results that the XS version quite consistently runs approximately about 15 times faster than the PP version. This is flame bait? Why is this flame bait? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
It might be seen as flame bait because there have been endless discussions on the Perl vs. C execution speed issue on Perl newsgroups in the past. :-) 2009/11/18 Kartik Thakore thakore.kar...@gmail.com Maybe he thought there were a debate on XS v.s PP performance. If only we could be this flame retardent in the uneeded perl5 v.s perl6 debate. On 18-Nov-09, at 7:29 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote: This is flame bait? Why is this flame bait?
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
Steffen- As always, I think benchmarks are important. As you've shown below, in your case, the XS implementation certainly is faster. I think it all depends on whether the speed of the system is bound by external factors (like disk speed, speed of a network stream) or your CPU. Certainly I've found for tight loops with lots of calculations, XS/C is going to be faster. Why? Because it's compiled into machine code and executed directly on the chip. On the other hand, Perl is compiled into bytecode which is then executed by the Perl Virtual Machine. However, this means you are also more prone to do things (in C/XS) that will result in nasty problems like segfaults. I see this debate as the same as Perl vs C or Language X vs Language Y. Each language and each system is built for different purposes with different advantages as well as limitations. What this email reminds us all is of the importance of benchmarking your code. Personally I use the one that gives tables comparing things. It's useful to see just how much faster an XS module is, since it does carry some additional risks (like nasty segfaults) over the PurePerl equivalents. Cheers, Jonathan On Wed, Nov 18, 2009 at 7:08 AM, O. STeffen BEYer ost...@gmail.com wrote: Dear Module Authors, recently in one of the Amsterdam Perl Mongers meetings the question came up how much faster actually the XS version of Date::Calc (Date::Calc::XS) was as compared to the Pure Perl version (Date::Calc::PP). Here is the answer (see attached script - you will need to have Date::Calc 6.3 and Date::Calc::XS 6.2 installed to run this script successfully): FreeBSD 7.2.-stable: $ perl benchmark.pl Running under Date::Calc::PP version 6.3 timethis 5000: 17.3147 wallclock secs (17.24 usr + 0.06 sys = 17.30 CPU) @ 288.94/s (n=5000) Running under Date::Calc::XS version 6.2 timethis 5000: 1.02551 wallclock secs ( 0.97 usr + 0.06 sys = 1.03 CPU) @ 4848.48/s (n=5000) Windows XP SP3: Running under Date::Calc::PP version 6.3 timethis 5000: 17.1034 wallclock secs (16.86 usr + 0.00 sys = 16.86 CPU) @ 296.58/s (n=5000) Running under Date::Calc::XS version 6.2 timethis 5000: 1.3329 wallclock secs ( 1.28 usr + 0.00 sys = 1.28 CPU) @ 3900.16/s (n=5000) Another (faster) Windows XP SP3 machine: Running under Date::Calc::PP version 6.3 timethis 1: 20.5605 wallclock secs (20.55 usr + 0.00 sys = 20.55 CPU) @ 486.69/s (n=1) Running under Date::Calc::XS version 6.2 timethis 1: 1.44224 wallclock secs ( 1.42 usr + 0.00 sys = 1.42 CPU) @ 7032.35/s (n=1) One can see from these results that the XS version quite consistently runs approximately about 15 times faster than the PP version. The test script benchmarks a function which calls all functions in Date::Calc once, each. Other similar results from XS/PP pairs of modules would be interesting - maybe not for any practical purposes, but just for the fun of it (or maybe to give deciders convincing arguments to upgrade to an XS version or not). Cheers, Steffen
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
On Wed, Nov 18, 2009 at 9:20 AM, Jonathan Yu jonathan.i...@gmail.com wrote: Certainly I've found for tight loops with lots of calculations, XS/C is going to be faster. Why? Because it's compiled into machine code and executed directly on the chip. On the other hand, Perl is compiled into bytecode which is then executed by the Perl Virtual Machine. That's one piece of it, but the other part is that any tight loop that is creating and destroying Perl primitives picks a lot of overhead. As an example, Vincent Pit just did some recent work in blead to optimize in-place array reversal in void context: @array = reverse @array; When this pattern is detected, the optimization just fiddles the internal pointers within the AV structure instead of reversing the array to a temporary list and then assigning it back. Vincent benchmarked it as several *orders of magnitude* faster (particularly as the array size grows). So creating/destroying Perl objects -- even just for things like argument passing on the stack -- is part of the cost of the flexibility of Perl. When that becomes a bottleneck in a tight loop, that's when XS becomes a potential option. That's not a knock on Perl -- that's just part of the design. -- David
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
Aristotle Pagaltzis wrote: This is flame bait? Why is this flame bait? well, if nothing else works, this could easily be turned into a Date::Calc vs. DateTime flame bait :-) cheers, Aldo
Re: flame bait: execution speed Perl vs. C (Date::Calc::PP vs. Date::Calc::XS)
* David Golden xda...@gmail.com [2009-11-18 16:05]: So creating/destroying Perl objects -- even just for things like argument passing on the stack -- is part of the cost of the flexibility of Perl. When that becomes a bottleneck in a tight loop, that's when XS becomes a potential option. That's not a knock on Perl -- that's just part of the design. It isn’t inherent in the language design. A tracing JIT runtime *could* make Perl go faster than compiled code. (Unfortunately the Perl 5 spec is perl, so there can be no other runtime, and the one we have cannot be retrofitted with a JIT any time soon. Bah.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
