in reply to Re^13: High Performance Game of Life (updated)
in thread High Performance Game of Life
When testing with the 32 bit version, the range of coordinates
should be restricted to what a 16 bit number can hold, from roughly -32000 to 32000 (to be safe :)
The 32 bit version does pass the tests, and runs OK on my system with a much smaller createblinker.pl range.
That -900000 is way out of range.
As for problems with the 64 bit version, sorry I can't help :(
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^15: High Performance Game of Life (updated)
by marioroy (Prior) on Aug 15, 2017 at 02:12 UTC | |
Update: Found the reason why cperl is failing with 64-bit, described below. Hi tybalt89, Perl is passing with 32 and 64 bits. Regarding cperl, it is passing 32 bits ($half = 16), but not 64 bits ($half = 32).
bin/perl
bin/cperl
The reason cperl is failing on 64-bit hw ($half = 32) is due to numbers converting to exponential notation.
Running $half = 30 resolves the issue. If you want, $half may be set programmatically.
Regards, Mario | [reply] [d/l] [select] |
by marioroy (Prior) on Aug 15, 2017 at 05:30 UTC | |
Update 1: Added results for the original version and initial improvements. In this thread, we've learned that pack i2 is faster than pack ii. Furthermor, functions having inner loops benefit greatly by inlining critical paths. In essence this is what we've done. The pack i2 solution fully optimized is found here, by tybalt89. The mapping of two numbers into one can be found here. Similarly, a shorter implementation by tybalt89 is found here. The fastest time was noted for each run with nothing else running in the background. The maximum key length for $c, obtained separately, is 7, 12, and 18 for pack i2, the mapping of two numbers, and the shorter solution by tybalt89, respectively. The fix for the latter solution, when running cperl on 64-bit hardware, is using 30 bits instead of 32, described here. The x and y tmp files were made using eyepopslikeamosquito's createblinker.pl script, found at the top of this thread.
Benchmark results were captured on a 2.6 GHz laptop (i7 Haswell). I apologize for not having something older to benchmark on. If anything, the OP's machine is faster than mine. ;-) Results:
cperl:
Pack returns unreadable data, but is fast. Readable keys may be preferred for storing into a DB. Stringification "$x:$y" is one way. Unfortunately, that requires split to extract the values and a text field versus numeric if storing into a DB. Bit manipulation is another way. Running Game::Life::Infinite::Board consumes lots of memory. If possible, check for 8 ~ 10 gigabytes of available memory to minimize the OS from swapping. It also takes ~ 10 seconds during global cleanup while exiting. eyepopslikeamosquito, infinite isn't running ~ 2x slower as reported here for 1.5 million cells. My laptop has 1600 MHz RAM and verified available memory before running. Regards, Mario | [reply] [d/l] [select] |
by tybalt89 (Monsignor) on Aug 15, 2017 at 22:06 UTC | |
New entry.
| [reply] [d/l] |
by marioroy (Prior) on Aug 16, 2017 at 03:57 UTC | |
by eyepopslikeamosquito (Archbishop) on Aug 16, 2017 at 13:09 UTC | |
by tybalt89 (Monsignor) on Aug 16, 2017 at 14:16 UTC | |
| |
by eyepopslikeamosquito (Archbishop) on Aug 15, 2017 at 22:38 UTC | |
Re having an old PC - and rubbing salt into tybalt89's wounds - please note that my (Haswell 4770K-powered) home PC is unchanged from when I mentioned it over three years ago in The 10**21 Problem (Part 2) and so is getting rather old and creaky now. Definitely due for an upgrade. :) Though my ancient PC does have 32 GB of memory (and so there is no swapping), given my very slow benchmark results with Game::Life::Infinite::Board, I'm suspicious that my doddering, ancient memory is starting to fail, due to being so old. This may be contributing to the significantly different results I am seeing. When running: with my originally shortened Organism.pm: I get 62 seconds, while after making the excellent improvements suggested by tybalt89 I get 80 seconds.
Update: These tests were run with perl v5.24.0: Need to upgrade that ancient Perl. :) Update: After upgrading to perl v5.26.0, both are faster: (62 secs, 80 secs) improved to (53 secs, 71 secs). | [reply] [d/l] [select] |
by marioroy (Prior) on Aug 16, 2017 at 02:42 UTC | |
by eyepopslikeamosquito (Archbishop) on Aug 16, 2017 at 13:03 UTC | |
| |
by tybalt89 (Monsignor) on Aug 15, 2017 at 02:23 UTC | |
To get decent times for testing purposes with the smaller number of blinkers, increase the number of ticks. | [reply] |