Lua is faster than Fortran???
in [Python]
|
From: Felix on 9 Jul 2010 09:43 On Jul 9, 12:44 am, Stefan Behnel <stefan...(a)behnel.de> wrote: > Felix, 09.07.2010 05:39: > Well, at least its "parallel processing abilities" are quite good actually. > If you have really large computations, they usually run on more than one > computer (not just more than one processor). So you can't really get around > using something like MPI, in which case an additional threading layer is > basically worthless, regardless of the language you use. For computations, > threading keeps being highly overrated. That is certainly true for large computations. But many smaller tasks are run on single machines and it does make a difference if they take 1 minute per run or 10. The average number of cores per computer has been increasing for quite a while now. It seems unfortunate to be restricted to using only one of them at a time (for regular loops, not mathematical vector operations). Python has made so many complicated things easy, but I have not seen an easy way to parallelize a simple loop on a multicore CPU without having to set up infrastructure and/or incurring large overhead from many interpreters and marshalling data. Just the fact that there is such a large number of attempts out there to fix this suggests that something important is missing.
From: sturlamolden on 9 Jul 2010 13:03 On 9 Jul, 15:25, Felix <schle...(a)cshl.edu> wrote: > PS: No need to convince me that MATLAB is not the solution. What I mean is that Matlab and Mathematica are inherently "single threaded" interpreters. Yet they are still used for serious parallel computing. While Python has multiple threads but a GIL, only allowing one thread in the interpreter is even more restrictive.
From: Terry Reedy on 9 Jul 2010 17:10 On 7/9/2010 1:25 AM, sturlamolden wrote: > With OpenCL, Python is better than C for heavy computing. The Python > or C/C++ program has to supply OpenCL code (structured text) to the > OpenCL driver, which does the real work on GPU or CPU. Python is much > better than C or C++ at processing text. There will soon be OpenCL > drivers for most processors on the market. For those as ignorant as me, OpenCL = Open Computing Language (for parallel computing). Apple proposed, Khronos Group maintains spec (along with OpenGL), AMD, NVidea, Intel support. Send C-like text to device, as with OpenGL; device compiles and runs; mainly for number crunching with all resources a machine has. OpenCL and OpenGL can work together. There is already a Python binding: http://sourceforge.net/projects/pyopencl/ > But OpenCL drivers will not be pre-installed on Windows, as Microsoft > has a competing COM-based technology (DirectX Compute, with an > atrocious API and syntax). > -- Terry Jan Reedy
From: geremy condra on 9 Jul 2010 18:17 On Fri, Jul 9, 2010 at 5:10 PM, Terry Reedy <tjreedy(a)udel.edu> wrote: > On 7/9/2010 1:25 AM, sturlamolden wrote: > >> With OpenCL, Python is better than C for heavy computing. The Python >> or C/C++ program has to supply OpenCL code (structured text) to the >> OpenCL driver, which does the real work on GPU or CPU. Python is much >> better than C or C++ at processing text. There will soon be OpenCL >> drivers for most processors on the market. > > For those as ignorant as me, OpenCL = Open Computing Language (for parallel > computing). Apple proposed, Khronos Group maintains spec (along with > OpenGL), AMD, NVidea, Intel support. Send C-like text to device, as with > OpenGL; device compiles and runs; mainly for number crunching with all > resources a machine has. OpenCL and OpenGL can work together. There is > already a Python binding: > http://sourceforge.net/projects/pyopencl/ Its worth pointing out that right now you're generally better off with CUDA than OpenCL, and that pycuda bindings are usable, if not what I would call easy-to-use. Geremy Condra
From: Дамјан Георгиевски on 12 Jul 2010 17:15
On the positive side, Lua supports tail call optimization and coroutines are built in by default. -- дамјан ((( http://damjan.softver.org.mk/ ))) Education is one of the "prices" of freedom that some are unwilling to pay. |