Dual Core outlook

[malv]

Multiprocessing has been pushed into the field as the chip
manufacturers can no longer deliver as they were used to for many
years.
The general public has been conditioned to believe that 1 + 1 = 2 but
this is in fact not that simple.
Although software manufacturers can with some effort adapt packages to
exploit these dual core architectures, the same is not true for other
development work were no large distribution of the application is to
take place.
What is the outlook for programming languages in general?
Of course, multiprocessing has been used for many years but this always
involved a much higher level of sophistication on the part of the
designers. This point seems to be largely hidden from the public,
ignorant and semi-ignorant, by the chip manufacturers.
Will new languages see the light rendering the spreading of
applications over many processors quasi transparent?
What is the outlook for Python? Would Ironpython with .net do better?
What about talk by the Java lobby that Java would be very much suited
for taking advantage of dual-core? Is there any thruth to this?

These are questions that many Python users like myself would like to
find some answers for. One thing is clear. The old days will never come
back and the processor multiplication is likely to increase.
malv

[Xavier Morel]

malv wrote:

Of course, multiprocessing has been used for many years but this always
involved a much higher level of sophistication on the part of the
designers. This point seems to be largely hidden from the public,
ignorant and semi-ignorant, by the chip manufacturers.
Will new languages see the light rendering the spreading of
applications over many processors quasi transparent?
What is the outlook for Python? Would Ironpython with .net do better?
What about talk by the Java lobby that Java would be very much suited
for taking advantage of dual-core? Is there any thruth to this?

Python has support for OS threads, but it also has the GIL (a global
lock from the interpreter). This means that Python behaves the same way
Java or C# do as far as threads are concerned but for one field:
multiprocessor (or multicore) situations.

While C# or Java can execute two threads of the same process on two
separate cores/processors Python can't.

This means that you can't choke a multiprocessor/multicores machine with
Python threads, and that if you want to scale in a
multiprocessor/multicore environment (e.g. make use of all the available
cores/processors) you have to use processes not threads (e.g. you have
to launch multiple instances of the Python interpreter, each one having
the ability to execute on a different core/processor).

Now the question is: do you want to do it? Do you have several extremely
demanding computational threads? If yes, then Python probably isn't what
you need (unless you implement your computations in specific C modules
and get rid of the GIL issue). If not (a single computational thread and
several low-resources GUI/network/whatever threads), it's a non-issue.

[malv]

Thank you Xavier.
Maybe this is too simplistic, but given two programs, one in Python the
other in Java or C#. Would this mean that running the latter on a dual
core processor would significantly increase execution speed, whereas
the Python program would be running in one processor only without any
speed up?

Is a Java program capable of this "out of the box" or does this require
specific additional code?
malv

[Greg Copeland]

The short answer is, "maybe". Python will be CPU bound but not I/O
bound. This means you can have multiple threads concurrently
performing I/O. On the other hand, if you have two threads which are
CPU bound, only one will run at a time.

Having said that, there are plenty of ready work arounds. One is to
make an extension module which executes your CPU bound tasks while
releasing the GIL. The other is to break your script into a
multiprocess model rather than a multithreaded module; using IPC as
needed.

[Xavier Morel]

malv wrote:

Maybe this is too simplistic, but given two programs, one in Python the
other in Java or C#. Would this mean that running the latter on a dual
core processor would significantly increase execution speed, whereas
the Python program would be running in one processor only without any
speed up?
This is extremely dependent on the way the program is built.

To get significant increases in execution speed, you need multiple
*computational* threads, that means that you need 2+ threads that do the
heavy work (number crunching, compression, ...), if you have one thread
with heavy computations and the others handling low-computation parts of
the program (UI) you may get a more _responsive_ program, but it won't
be _faster_ (at least not noticeably), because the bottleneck of the
application (the heavy computations) will still run on a single
core/processor.

Multicore/multiprocessor is not magic, and it's not trivial at all, it's
hard to create correct multithreaded programs, and even harder to
parallelize the heavy computation part between various threads.
Is a Java program capable of this "out of the box" or does this require
specific additional code?

Java and C# both use unlocked OS threads any time you use their threads.

[Tom Anderson]

On Tue, 7 Feb 2006, malv wrote:

Maybe this is too simplistic, but given two programs, one in Python the
other in Java or C#. Would this mean that running the latter on a dual
core processor would significantly increase execution speed, whereas the
Python program would be running in one processor only without any speed
up?

Is a Java program capable of this "out of the box" or does this require
specific additional code?

If i understand the question correctly, the latter - you need to take
explicit action to make use of two processors in Java, or any other
mainstream language.

What i think you're asking is whether code like this:

public class MyApp
{

public static void main(String[] args)
{
// do a bunch of stuff
}

}

will run faster with two cores. The answer to that is definitely no (more
or less - see below!); this program has one thread of execution, and each
thread can only use one core at a time, so this program will only use one
core. In order to use multiple cores, you need multiple threads:

public class MyApp implements Runnable
{

public static final int NUM_THREADS = 4 ; // or whatever

public static void main(String[] args)
{
for (int i = 0 ; i < NUM_THREADS ; ++i)
new Thread(new MyApp()).start() ;
}

public void run()
{
// do a bunch of stuff
}

}

This program will get a roughly proportional speedup from multiple cores,
provided the actual work can be done without the threads threading on each
others' toes. If you try the equivalent in python (using the threading
module), you, AIUI, won't get a significant speedup, as python is
essentially single-threaded (is that really true?).

Now, as i promised above, the thing about single-threaded programs not
getting a speedup from multiple cores is not quite right. The thing is, a
program in which a single thread is executing your code is not actually
single-threaded - there are other threads running in the background, doing
mysterious system stuff; with the Sun 1.5.0 JVM on Windows XP, a minimal
program has eight threads running. One of the things those threads are
doing - or will be once JVMs start to adapt to the multi-core world - is
garbage collection; GC can eat a measurable, although not huge, fraction
of your execution time, so farming it out to a second core should speed
your program up a bit.

tom

PS Excuse any errors in the java - it's a long time since i've written
any!

--
Through the darkness of Future Past the magician longs to see.

[malv]

Hi All,
Thank you for your commentaries.
In the meantime, I read up in Python-Dev and came across a post by
Johnatan LaCour which kind of nicely sums up the state of affairs:
"Its really a shame. There seems to be some consensus about
multi-processing, but not a whole lot of interest in making it easier
out of the box. When it comes to multi-processing, batteries really
_aren't_ included. Sure, you have lead dioxide and some sulphuric
acid, but you have to put them together to make your battery. This
isn't the end of the world, but I find it tedious, and I am sure it
confuses and frustrates people new to Python."
Possibly things are not much brighter for other languages.

I'll keep on trying
malv