On 29/03/2015 19:03, Marko Rauhamaa wrote:
BartC <b...@freeuk.com>:
As Chris mentioned, when I say 'faster than C', I mean X running my
algorithm was faster then C running Marko's algoritim (on Ian's data).
This was just an illustration of algorithm being more important than
language.
Be careful with the benchmark comparisons. Ian's example can be solved
with the identical algorithm in eight different ways (four corners, left
or right). I ran the example with my recent Python solver and got these
times in the eight cases:
884 s
2.5 s
13 s
499 s
5.9 s
128 s
1360 s
36 s
(That suggests a slight modification to the original strategy: solve it
in each of the eight ways "in parallel" and the worst case should be
significantly alleviated.)
I'm actually fascinated by the Python modifications that were
conceptually insignificant but dramatically speeded up the execution
(7880 seconds to 884 seconds). That's something I'll have to keep in
mind in the future.
Marko
One thing I have come to rely on over the years is never, ever trust
your gut instincts about Python performance, you're almost inevitably
wrong. When I first came across the Norvig solver I made a change,
purely for fun, to replace two calls to len() with a single call and
save the result. The run time to solve each puzzle dropped by around
5%. I believe this meets your "conceptually insignificant".
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
