Is there any standard speed test script for Pike? I want to do "make test_speed"...
What's the © status of the source used for the language shootout?
I'd like to create such a make target, with some standard timing figures. With that source, if possible. (Since it's good tests.)
/ Mirar
Previous text:
2002-12-06 12:58: Subject: speed
Not really.
(Unless you count the language shootout.)
/ Peter Bortas
Regardless of the status of the shootout, including it would not be good for it's independent status. Rewring some of those tests and including would be a good idea though.
/ Peter Bortas
Previous text:
2002-12-06 13:10: Subject: speed
What's the © status of the source used for the language shootout?
I'd like to create such a make target, with some standard timing figures. With that source, if possible. (Since it's good tests.)
/ Mirar
How do I start a new, similar pike the Right Way?
Peeking into the master to build arguments to create_process doesn't seem very simple.
Also, any simple way of figuring out how much memory the current process is using? Other then looking at linux' /proc/*/statm. getrusage doesn't seem to work.
/ Mirar
Previous text:
2002-12-06 13:10: Subject: speed
What's the © status of the source used for the language shootout?
I'd like to create such a make target, with some standard timing figures. With that source, if possible. (Since it's good tests.)
/ Mirar
Anyway, I checked in the performance tests now. They reside in Tools.Shoot:
| % pike --shoot | test total user mem (runs) | Pike start overhead........ 0.033s 0.000s 3240kb (25) | Ackermann.................. 0.724s 0.649s 3440kb (7) | Array & String Juggling.... 0.789s 0.720s 3488kb (7) | Compile.................... 1.354s 1.162s 4872kb (4) | Compile & Exec............. 1.256s 1.130s 3496kb (4) | Matrix multiplication...... 0.514s 0.447s 4728kb (10) | Loops Nested............... 0.374s 0.316s 3256kb (14) | Loops Recursed............. 1.568s 1.470s 3256kb (4)
The tests are rewritten with some inspiration from the shootout. I also tuned them to be measurably slow, but not annoyingly slow.
New tests are added by adding a new <whatever>.pike in that directory, with base from Test.pike.
/ Mirar
Previous text:
2002-12-06 16:33: Subject: speed
How do I start a new, similar pike the Right Way?
Peeking into the master to build arguments to create_process doesn't seem very simple.
Also, any simple way of figuring out how much memory the current process is using? Other then looking at linux' /proc/*/statm. getrusage doesn't seem to work.
/ Mirar
Personally I think `pike -x shoot' had been better than a new option to the master, but maybe that's just me...
Nice anyway.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-12-06 18:27: Subject: speed
Anyway, I checked in the performance tests now. They reside in Tools.Shoot:
| % pike --shoot | test total user mem (runs) | Pike start overhead........ 0.033s 0.000s 3240kb (25) | Ackermann.................. 0.724s 0.649s 3440kb (7) | Array & String Juggling.... 0.789s 0.720s 3488kb (7) | Compile.................... 1.354s 1.162s 4872kb (4) | Compile & Exec............. 1.256s 1.130s 3496kb (4) | Matrix multiplication...... 0.514s 0.447s 4728kb (10) | Loops Nested............... 0.374s 0.316s 3256kb (14) | Loops Recursed............. 1.568s 1.470s 3256kb (4)
The tests are rewritten with some inspiration from the shootout. I also tuned them to be measurably slow, but not annoyingly slow.
New tests are added by adding a new <whatever>.pike in that directory, with base from Test.pike.
/ Mirar
Agreed. On booth opinions.
I'll take this oppertunity to point out that 7.5 still isn't patched with the /etc/make.conf change 7.4 got. At least if the CVS viewer is to be belived.
/ Peter Bortas
Previous text:
2002-12-06 18:31: Subject: speed
Personally I think `pike -x shoot' had been better than a new option to the master, but maybe that's just me...
Nice anyway.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
The CVS viewer doesn't show some checkins that I know exist, so it's probably not done indexing yet.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-12-06 18:34: Subject: speed
Agreed. On booth opinions.
I'll take this oppertunity to point out that 7.5 still isn't patched with the /etc/make.conf change 7.4 got. At least if the CVS viewer is to be belived.
/ Peter Bortas
I agree that it should use the Standalone feature so that we need not clutter the master. I think pike -x benchmark or pike -x bench is even better.
/ Martin Nilsson (hehe Torgny)
Previous text:
2002-12-06 18:31: Subject: speed
Personally I think `pike -x shoot' had been better than a new option to the master, but maybe that's just me...
Nice anyway.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Perfect, now we can test if the mmx.h hurts or helps. :-)
/ Per Hedbor ()
Previous text:
2002-12-06 18:27: Subject: speed
Anyway, I checked in the performance tests now. They reside in Tools.Shoot:
| % pike --shoot | test total user mem (runs) | Pike start overhead........ 0.033s 0.000s 3240kb (25) | Ackermann.................. 0.724s 0.649s 3440kb (7) | Array & String Juggling.... 0.789s 0.720s 3488kb (7) | Compile.................... 1.354s 1.162s 4872kb (4) | Compile & Exec............. 1.256s 1.130s 3496kb (4) | Matrix multiplication...... 0.514s 0.447s 4728kb (10) | Loops Nested............... 0.374s 0.316s 3256kb (14) | Loops Recursed............. 1.568s 1.470s 3256kb (4)
The tests are rewritten with some inspiration from the shootout. I also tuned them to be measurably slow, but not annoyingly slow.
New tests are added by adding a new <whatever>.pike in that directory, with base from Test.pike.
/ Mirar
Have you taken a look at my tests that I presented in my weblog (eg. http://pike.ida.liu.se/development/team/weblog/nilsson/index.xml?date=200211... I've considered making a program that calculates the O for the tests so that you can make an overall linear runtime scaling.
/ Martin Nilsson (hehe Torgny)
Previous text:
2002-12-06 18:27: Subject: speed
Anyway, I checked in the performance tests now. They reside in Tools.Shoot:
| % pike --shoot | test total user mem (runs) | Pike start overhead........ 0.033s 0.000s 3240kb (25) | Ackermann.................. 0.724s 0.649s 3440kb (7) | Array & String Juggling.... 0.789s 0.720s 3488kb (7) | Compile.................... 1.354s 1.162s 4872kb (4) | Compile & Exec............. 1.256s 1.130s 3496kb (4) | Matrix multiplication...... 0.514s 0.447s 4728kb (10) | Loops Nested............... 0.374s 0.316s 3256kb (14) | Loops Recursed............. 1.568s 1.470s 3256kb (4)
The tests are rewritten with some inspiration from the shootout. I also tuned them to be measurably slow, but not annoyingly slow.
New tests are added by adding a new <whatever>.pike in that directory, with base from Test.pike.
/ Mirar
No, didn't know they were there. Currently the test has no input parameters, they are simply run over and over again until N seconds has passed or the test has been run M times. (N=5, M=25 right now.)
It should be simple enough to add new tests, at least when the permissions are worked out.
/ Mirar
Previous text:
2002-12-06 18:45: Subject: speed
Have you taken a look at my tests that I presented in my weblog (eg. http://pike.ida.liu.se/development/team/weblog/nilsson/index.xml?date=200211... I've considered making a program that calculates the O for the tests so that you can make an overall linear runtime scaling.
/ Martin Nilsson (hehe Torgny)
I'm writing a wrapper for the Standalone module that takes some arguments and renames the shoot targets to bench.
/ Martin Nilsson (hehe Torgny)
Previous text:
2002-12-06 19:28: Subject: speed
No, didn't know they were there. Currently the test has no input parameters, they are simply run over and over again until N seconds has passed or the test has been run M times. (N=5, M=25 right now.)
It should be simple enough to add new tests, at least when the permissions are worked out.
/ Mirar
The permissions are fixed.
/ Peter Bortas
Previous text:
2002-12-06 19:28: Subject: speed
No, didn't know they were there. Currently the test has no input parameters, they are simply run over and over again until N seconds has passed or the test has been run M times. (N=5, M=25 right now.)
It should be simple enough to add new tests, at least when the permissions are worked out.
/ Mirar
pike-devel@lists.lysator.liu.se