5 ms·
Timing data comparing CClasp to C++, SBCL and Python
- rch 11y agoCython would make sense in this context (~19 seconds for me).
- markikka 11y agoUsing Numba (you just adnotate the function with @numba.jit) speeds it up from 51 sec to 0.46 for me
- rch 11y agoBrilliant. ~0.49 seconds for me too.
- lake99 11y agoOr even Pypy. This is how they measure up: % python2 fibtime.py elapsed time: 83.330840 seconds % python3 fibtime.py elapsed time: 89.325043 seconds % pypy3 fibtime.py elapsed time: 5.799757 seconds
- igouy 11y agohttp://pybenchmarks.org/ http://pybenchmarks.org/
- igouy 11y ago>>would make sense in this context<< Not really -- "I don’t want to start an argument about the speed of SBCL vs C++ here, my point is that CClasp has come a long way from being hundreds of times slower than C++ to within a factor of 4."
- rch 11y agoI meant only that Cython results would tell me more about relative CClasp performance than a comparison CPython does. I didn't want to get into the optimization game either, but I'm happy someone here reminded me to try numba.
- ngoldbaum 11y agoShould be a lot faster with type annotations.
- robmccoll 11y agoIn Python 2.7, shouldn't you be using xrange() rather than range()? xrange() is a generator whereas range() will actually create the entire list and iterate it. In case anyone isn't aware: in Python 3, range()'s implementation was effectively replaced with that of xrange().
- 0942v8653 11y agoFor me, range (the posted source) took 95 seconds, and xrange was only a little better at 85 seconds. I think most of the benefit of xrange comes from the decreased memory usage, not from lower CPU usage. But xrange is definitely closer to what the other code is doing.
- dekhn 11y agothat's almost a 10% improvement- not just a little better!
- dr_zoidberg 11y agoIt's Python 3 code, he used the print function without importing from __future__.
- Fede_V 11y agoI was a bit curious, so I did a short experiment: http://nbviewer.ipython.org/urls/dl.dropbox.com/s/l9naqibqytv8vjt/Numba_Fib.ipynb http://nbviewer.ipython.org/urls/dl.dropbox.com/s/l9naqibqyt... Using numba, and adding a one line decorator to the function (without any changes whatsoever) we get around 2 orders of magnitude speed up. Note - this doesn't involve any fancy re-writing, annotating, etc, you literally just add a decorator. Writing really fast numerical code in Python is very easy. There's absolutely no reason not to use numba if you have small functions that just do number crunching. numba can even inline other numba functions - so you don't even pay the function call overhead.
- agumonkey 11y agoIt's funny, reminds me of old arguments when CL code could be made fast by adding a tiny (declare ...). Now it's python turn. That speed increase is damn impressive though.
- igouy 11y agohttp://pybenchmarks.org/ http://pybenchmarks.org/
- lqdc13 11y agoI love numba, but I am never successful at compiling it. Using the Anaconda distribution results in some issues as that distribution is not compatible with some other libraries and requires installing everything through conda. Most packages use Cython for this reason instead.
- ycnews 11y agoI failed to get numba installed on a Raspberry Pi 2, and I'd been wanting to try Nim, which turned out to be easy to compile on the RPi running Ubuntu. nim -r -d:release c rw_fibn.nim ... Hint: operation successful (12152 lines compiled; 2.632 sec total; 8.870MB; Release Build) [SuccessX] /home/rw/git/Nim/examples/rw_fibn Result = 8944394323791464 elapsed time: 5.376946926116943 My first try at translating Python to Nim: $ cat rw_fibn.nim import times proc fibn(reps: int64, num: int): int64 = var z: int64 for r in 1..reps: var p1, p2: int64 = 1 rnum: int = num - 2 for i in 1..rnum: z = p1 + p2 p2 = p1 p1 = z return z var start: float = times.epochTime() var res = fibn(10_000_000, 78) var finish: float = times.epochTime() echo("Result = ", res) echo("elapsed time: ", finish - start)
- jlarocco 11y agoPeople are missing the point with the Python code. The C++ code and the Lisp code aren't particularly optimized, either. The point of the benchmark is to compare the relative speeds of roughly the same Fibonacci code out of the box. On SBCL, a memoized recursive fibonacci is about twice as fast as the Lisp code given also running in SBCL on my machine, for example. I'm more suspicious about why the C++ code is so slow. Edit: I wrote my own C++ Fib code and tried benchmarking it outside of Clasp (https://gist.github.com/jl2/4d74958b02b3caea2f5c https://gist.github.com/jl2/4d74958b02b3caea2f5c). It routinely ran in less than 0.005 seconds, which seemed too fast, so I looked at the assembly output. AFAICT, the compiler is smart enough to realize fib() has no side effects and is "pure", and is computing the value at compile time, reducing the function call to essentially be myfib = 8944394323791464. It almost seems like an unfair comparison, but since it's comparing compiler performance, I think it's relevant information.
- drmeister 11y agoThank you, you summed it up better than I could.
- wtbob 11y agoCClasp is looking really, really interesting. I'm still enjoy SBCL, but on the right project—why not try CClasp?
- zubairsaif007 11y agohttp://googler700.blogspot.com/2015/07/c-programming.html http://googler700.blogspot.com/2015/07/c-programming.html
- zubairsaif007 11y agohttp://googler700.blogspot.com/2015/04/project-list.html http://googler700.blogspot.com/2015/04/project-list.html