RE:Dual Core
- To: mathgroup at smc.vnet.net
- Subject: [mg70142] RE:Dual Core
- From: albert <awnl at arcor.de>
- Date: Thu, 5 Oct 2006 03:32:53 -0400 (EDT)
- References: <eg02p8$86s$1@smc.vnet.net>
Hi, > Welcome to the world of performance evaluation. You ask 'Is Mathematica > really unable to use both cores at the same time ?' while the answer to > the question is staring you in the face -- no it cannot. it was announced it can and I am quite sure that this is true, but of course only for some special tasks, and you have to make it aware of the number of processors, as others have suggested... > You probably > have a right to expect the operating system (if it is multicore aware) to > distribute separate threads of execution onto different cores, so you can > (again probably -- the only true answer is derived by testing and > experimentation) run Excel on one core (in one thread) and Mathematica on > the other (in another thread). or two math kernels at the same time. I think usually you would call these two processes not two threads and it is by far the most efficient way to make use of two (or more) processors in your machine... > In general the task of splitting a computation onto 2 cores is the same as > writing 2 programs which, cooperatively and while running at the same > time, solve a problem. Imagine, if you wish, writing 2 Mathematica > programs to carry out 1 computation. Not so easy. And possibly we > shouldn't expect Mathematica to do this automatically for us, not with the > current state of the art. There are many many algorithms that work in parallel, nevertheless computer algebra algorithms are said to be hardly or not at all possible to be parallelized (at least that's what I learned about 6 years ago). It depends on the internal workings and data structures of the systems whether this is true (there are counter-examples, but I think most of them are rather exotic) and for what I know (which is not much) about Mathematica, it is like the other mainstream CA-systems among the ones that are not well suited for parallelism in general. Anyway, Mathematica does now do a lot of other things than just computer algebra. It does graphics, numerics (e.g. linear algebra) and other things where parallelism is not an exotic thing at all, so I would expect that more and more of these algorithm will take advantage of the current and coming multicore processors, and in fact the linear algebra routines are supposed to already take advantage of multicore processors (or more than one processor per machine in general) in version 5.2, I think. > I'm extremely doubtful that the internal > workings of Solve, Reduce, etc are easily distributable onto multiple > cores -- I guess someone from WRI will put me (us) right on that if I'm > dead flat wrong. I think for these functions your guess is quite right. > Mathematica doesn't have, as languages such as Java do, > programming constructs for managing separate threads of execution, unless > you jump to MathLink programming. There has been a package which made that possible by Roman Maeder, it did distribute calculations onto as many processes you can afford (you'll need a licenses for them!). Each of these kernels can run on a separate core, processor or even computer. As user you would have special commands like MapParallel[] which would make it fairly easy to write parallel programs. And there is GridMathematica which to my understandig should also make it possible to write parallel programs in Mathematica. > If you watch the task manager very closely while you're working with > Mathematica you might (just) see the front-end and the kernel on different > cores since they are (and have long been) handled by different threads of > execution. But the amount of time most of us spend in the front-end is > insignificant and it may not appear high up the list of tasks if at all. Usually the work that the frontend has to do is indeed insignificant. But if you let it render an animation of say 100 3D-Plots you might find that a second processor helps. I sometimes wished I had a second one... hth, albert