News for hackers. Stuff that matters.
Re:N-Queen Problem: Python 2.6.5 vs PyPy 1.5.0 by dzorz on Sunday May 29, 2011 @04:33PM (#2597519)
I think this is an example where C++ really shines. The code is not much longer (44 vs 33 lines, although the output in python version is much nicer) than the python code and on my computer it is about 140x faster than python 2.7.1.
Re:N-Queen Problem: Python 2.6.5 vs PyPy 1.5.0 by patio11 on Sunday May 29, 2011 @04:50PM (#2597564)
We did a distributed N-queens solver to test the Gifu Prefectural Computing Grid that an ex-job helped to develop, and that was literally all ~35 of my lines of production C code ever. (Though most of the grid turned on "graphical" mode, which both a) solved in Java and b) solved in Java at the speed of the Swing ability to update the visual board... which, after realizing, I patched to sleep frequently and run the C in the background anyway.)

This was ~5 years ago, and I don't remember the exact magnitude of the speedup on Java vs. C. I do remember it being rather less than I was expecting.

Re:N-Queen Problem: Python 2.6.5 vs PyPy 1.5.0 by jrydberg on Sunday May 29, 2011 @04:42PM (#2597544)
That's why you write a C-extension to CPython when you need the performance. And if you don't need the performance you stay sane by not having to write stuff in C++.
Re:N-Queen Problem: Python 2.6.5 vs PyPy 1.5.0 by reinhardt on Sunday May 29, 2011 @04:51PM (#2597566)
Using a library for computing the permutations I guess? I haven't touched C++ for years but I'd be surprised if the 44 lines include a permutations implementation.
Re:N-Queen Problem: Python 2.6.5 vs PyPy 1.5.0 by dzorz on Sunday May 29, 2011 @04:55PM (#2597574)
next_permutation is in standard library (header algorithm).
Re:N-Queen Problem: Python 2.6.5 vs PyPy 1.5.0 by makmanalp on Sunday May 29, 2011 @07:18PM (#2597897)
For the curious, STL <algorithm> is one of those things that you wish you knew ages ago. Usually my code is much cleaner after I run through it and replace relevant parts of it with STL stuff.

http://www.cplusplus.com/reference/algorithm/

Re:N-Queen Problem: Python 2.6.5 vs PyPy 1.5.0 by megaman821 on Sunday May 29, 2011 @05:33PM (#2597661)
The optimized version of the PyPY code is around 17x faster than the first version of the Python code. That makes your C++ code 8x faster than the PyPy code, but I consider any Python code within an order of magnitude of C++ good.
Re:N-Queen Problem: Python 2.6.5 vs PyPy 1.5.0 by dzorz on Sunday May 29, 2011 @06:03PM (#2597729)
140x speedup was compared to optimized python version. I've tried it vs. pypy now (version 1.5) - it is 20x faster.
Re:N-Queen Problem: Python 2.6.5 vs PyPy 1.5.0 by StavrosK on Sunday May 29, 2011 @06:21PM (#2597775)
Would it be possible for you to try ShedSkin on it?
Re:N-Queen Problem: Python 2.6.5 vs PyPy 1.5.0 by dzorz on Sunday May 29, 2011 @06:48PM (#2597818)
I managed to compile the program using shedskin, but it throws a runtime error after it finds the first solution:

    ==== solution 1 =====
    (0, 2, 5, 7, 9, 4, 8, 1, 3, 6)
    terminate called after throwing an instance of '__shedskin__::TypeError*'
    Aborted
Re:N-Queen Problem: Python 2.6.5 vs PyPy 1.5.0 by StavrosK on Monday May 30, 2011 @02:07AM (#2598664)
Ah, that's too bad... Thanks for the effort, anyway.
Re:N-Queen Problem: Python 2.6.5 vs PyPy 1.5.0 by danielharan on Sunday May 29, 2011 @08:32PM (#2598000)
The proposed solution uses brute-force. How fast can you try another approach like backtracking if you're writing 30% more LOC?