Re: [Numpy-discussion] debian benchmarks
On Sun, Jul 4, 2010 at 4:32 AM, Sturla Molden stu...@molden.no wrote: I was just looking at Debian's benchmark. LuaJIT is now (on median) beating Intel Fortran! Consider that Lua is a dynamic language very similar to Python. I know it's just a benchmark but this has to count as insanely impressive. Beating Intel Fortran with a dynamic scripting language... How is that even possible? If this keeps up we'll need a Python to Lua compiler very soon. And LuaJIT 2 is rumoured to be much faster than the current... Looking at median runtimes, here is what I got: gcc 1.10 LuaJIT 1.96 Java 6 -server 2.13 Intel Fortran 2.18 OCaml 3.41 SBCL 3.66 JavaScript V8 7.57 PyPy 31.5 CPython 64.6 Perl 67.2 Ruby 1.9 71.1 This means that LuaJIT can do in less than a day what CPython can do in a month. The only comfort for CPython is that Ruby and Perl did even worse. I wonder how much better CPython would do with NumPy on this benchmark? Sturla Hi Sturla, what is this even about ... ? Do you have some references ? It does indeed sound interesting ... but what kind of code / problem are they actually testing here ? Thanks, Sebastian Haase ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] [OT] Re: debian benchmarks
Sun, 04 Jul 2010 04:32:14 +0200, Sturla Molden wrote: I was just looking at Debian's benchmark. LuaJIT is now (on median) beating Intel Fortran! Consider that Lua is a dynamic language very similar to Python. I know it's just a benchmark but this has to count as insanely impressive. I guess you're talking about shootout.alioth.debian.org tests? Beating Intel Fortran with a dynamic scripting language... How is that even possible? It's possible that in the cases where Lua wins, the Lua code is not completely equivalent to the Fortran code, or uses stuff such as strings for which Lua's default implementation may be efficient. At least in the mandelbrot example some things differ. I wonder if Lua there takes advantage of SIMD instructions because the author of the code has manually changed the inmost loop to process two elements at once? -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] debian benchmarks
Sebastian Haase skrev: Hi Sturla, what is this even about ... ? Do you have some references ? It does indeed sound interesting ... but what kind of code / problem are they actually testing here ? http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php They are benchmarking with tasks that burns the CPU, like computing and bitmapping Mandelbrot sets and processing DNA data. Sturla ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] debian benchmarks
Sturla Molden skrev: http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php They are benchmarking with tasks that burns the CPU, like computing and bitmapping Mandelbrot sets and processing DNA data. It is also the kind of tasks where NumPy would help. It would be nice to get NumPy into the shootout. At least for the sake of advertising :-) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [OT] Re: debian benchmarks
Pauli Virtanen pav at iki.fi writes: -snip- It's possible that in the cases where Lua wins, the Lua code is not completely equivalent to the Fortran code, or uses stuff such as strings for which Lua's default implementation may be efficient. Note - not Lua's default implementation but LuaJIT. At least in the mandelbrot example some things differ. I wonder if Lua there takes advantage of SIMD instructions because the author of the code has manually changed the inmost loop to process two elements at once? Note - the fastest Fortran mandelbrot program is written to use OpenMP, but those u32 measurements are when the programs are forced onto one core. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] ANN: scipy 0.8.0 release candidate 1
I'm pleased to announce the availability of the first release candidate of SciPy 0.8.0. Please try it out and report any problems on the scipy-dev mailing list. SciPy is a package of tools for science and engineering for Python. It includes modules for statistics, optimization, integration, linear algebra, Fourier transforms, signal and image processing, ODE solvers, and more. This release candidate release comes almost one and a half year after the 0.7.0 release and contains many new features, numerous bug-fixes, improved test coverage, and better documentation. Please note that SciPy 0.8.0rc1 requires Python 2.4-2.6 and NumPy 1.4.1 or greater. For more information, please see the release notes: http://sourceforge.net/projects/scipy/files/scipy/0.8.0rc1/NOTES.txt/view You can download the release from here: https://sourceforge.net/projects/scipy/ Python 2.5/2.6 binaries for Windows and OS X are available, as well as source tarballs for other platforms and the documentation in pdf form. Thank you to everybody who contributed to this release. Enjoy, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
