[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ale] OT: Multi-core Utilization
- Subject: [ale] OT: Multi-core Utilization
- From: rev.null at gmail.com (Rev. Johnny Healey)
- Date: Fri, 8 Mar 2013 15:50:46 -0500
- In-reply-to: <[email protected]>
- References: <[email protected]>
Python is going to be a bad choice for multicore programming. It has a
global interpreter lock, so even when you have multiple python threads
running, there will be very little that they can do concurrently.
The only language I've encountered that seems to be able to take a
single-threaded program to multiple threads with minimal effort is
Haskell. It's one of the benefits of the purely functional nature of
the language that many operations on datasets can be divided and
conquered semi-transparently. It also offers neat stuff such as STM.
But the language itself comes with a steep learning curve (one that is
worth it for multiple reasons IMHO).
-Rev. Johnny Healey, Language Lawyer
On Fri, Mar 8, 2013 at 11:33 AM, Jeff Hubbs <jhubbslist at att.net> wrote:
> My *practical* experience has a hole in it when it comes to developing
> software to efficiently use multiple cores in a machine.
>
> If I'm writing code in the likes of C++, Python, or Fortran (acknowledging
> that I've got a range of programming paradigms there) and let's say that I'm
> subtracting two 2-D arrays of floating point numbers from one another
> element-wise, how is it that the operation gets blown across multiple CPU
> cores in an efficient way, if at all? Bear in mind that if this is done in
> Fortran, it's done in a pair of nested do-loops so unless the compiler is
> really smart, that becomes a serial operation.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo