Python versus C++ Speed

[dcraig]

It would seem that a serious issue for Python is the implementation of threads which use a global interpreter lock. This means that no matter how cleaver the threading design in a program is, it is not going to derive much benefit from SMP or multicore machines.

There seems little doubt that CPU design is heading for multicore on all but the bottom of the range machines (and perhaps even on them too). Sun now has 4 core SPARCs and no doubt it won't be long before AMD and Intel release quad core CPUs.

C, C++ and Java have no such issue. At this stage choosing Python for high performance multithreaded applications on muticore machines would seem to be a poor decision. Of course if the app can run in multiple processes (rather than threads) this is not an issue.

And maybe the threading implementation in Python will be improved.

 

[prt_systems]

Quote from dcraig:

It would seem that a serious issue for Python is the implementation of threads which use a global interpreter lock. This means that no matter how cleaver the threading design in a program is, it is not going to derive much benefit from SMP or multicore machines.

There seems little doubt that CPU design is heading for multicore on all but the bottom of the range machines (and perhaps even on them too). Sun now has 4 core SPARCs and no doubt it won't be long before AMD and Intel release quad core CPUs.

C, C++ and Java have no such issue. At this stage choosing Python for high performance multithreaded applications on muticore machines would seem to be a poor decision. Of course if the app can run in multiple processes (rather than threads) this is not an issue.

And maybe the threading implementation in Python will be improved.

Yes you are correct: Python threads are cooperative rather than pre-emptive. There is probably no real drive to change this given the uses of Python. Still, you perform a wide range of computations will relative ease. Like I said earlier , if you know what you need and when it breaks then all is well .....

 

[nitro]

In my experience, most financial applications need to be single threaded because of the need to serialize the access to the data, especially in a realtime environment. I have found that most speed ups rarely come from using one very powerful smp computer, but breaking up the problem into litttle pieces and running that on single CPU clusters. When the problem does not decompose easily that it can be run on a cluster, get the fastest single CPU machine you can.

I like Python very much and I use it for experimentantion, and while the threading issue is not a problem for me for reasons stated above (although I do use the threadpool but long after the data has been serialized), I find C# just as easily able and useful to prototype code in as python. Then taking that code and making it production is very straightforward.

nitro

Quote from dcraig:

It would seem that a serious issue for Python is the implementation of threads which use a global interpreter lock. This means that no matter how cleaver the threading design in a program is, it is not going to derive much benefit from SMP or multicore machines.

There seems little doubt that CPU design is heading for multicore on all but the bottom of the range machines (and perhaps even on them too). Sun now has 4 core SPARCs and no doubt it won't be long before AMD and Intel release quad core CPUs.

C, C++ and Java have no such issue. At this stage choosing Python for high performance multithreaded applications on muticore machines would seem to be a poor decision. Of course if the app can run in multiple processes (rather than threads) this is not an issue.

And maybe the threading implementation in Python will be improved.

 

[ktmexc20]

Quote from nitro:
In my experience...

Thanks nitro. Your comments on theading and clustering were helpful.

kt

 

[nononsense]

Quote from ktmexc20:

Hi nonon,

I thought they removed any need for fortran compilation. I was under the impression that scipy's old problematic building process (required: fortran compilation) was one of the main purposes for the nearly complete re-write.

Hi ktmexc,

I am not an 'internist' on scipy but I can tell you that in installing the latest version of scipy I did not have a fortran compiler installed, this due a recent linux reinstall. It simply did not work till I installed the GNU Fortran 77 Compiler. After that, everything went OK - it passed all the scipy tests.

In fact several options exist for installing scipy, mainly impacting on performance. I am still planning on looking in to this. In fact all thogether this is huge. Maybe you know something more about these?

 

[nononsense]

Quote from dcraig:


Unsurprisingly gcc code is significantly faster than Python code.

Nobody said the contrary. This is not the point being discussed in this thread.

Quote from dcraig:


Finally quality of design, algorithms used, familiarity/genuine expertise with the development environment can have an enormous impact on performance and swamp any difference that choice of programming language may make.

This is why python appears to be such a good choice for mathematical and scientific programming because it gives you access to an extremely wide range of tools honed over a very long time, running with practically the seem speed if called from python. The only comparable solution would be to program in C/C++ to call these libraries.
I don't think that C# or Java give you access to all these.

As I said before, if you are interested in threads under Python, go to the Python home and newsgroup. I use threading extensively in my applications and am quite satisfied. Obviously, like nitro pointed out, running scientific calculations under multithreading may require some thought. I essentially do these in one thread. I would hesitate to paint Java as the universal panacea for this. I keep on reading about unending problems with it if you come near to hardware functionality. I guess, the only good tools for this is C/C++. This is nice about Python because you have the choice to switch back and forth with ease.

 

[dcraig]

Quote from nitro:

In my experience, most financial applications need to be single threaded because of the need to serialize the access to the data, especially in a realtime environment. I have found that most speed ups rarely come from using one very powerful smp computer, but breaking up the problem into litttle pieces and running that on single CPU clusters. When the problem does not decompose easily that it can be run on a cluster, get the fastest single CPU machine you can.
nitro

This might be partially (or perhaps mostly) true today, but looking into the crystal ball a little, the trend is clearly towards multi core not just AMD and Intel and Sun, but also the Cell processor from IBM. Just speculating, but say in 3 years 8 way machines are available at PC prices. For many reasons including space, power consumption and interconnect speed these will offer compelling advantages over a small cluster of single core boxes.

Should this turn out to be the case, one would expect Python to move with the times to support threading properly in this new hardware enviroment. But it will have a lot of catching up to do with Java and C# and the job will be difficult.

 

[nononsense]

Quote from dcraig:

...
Should this turn out to be the case, one would expect Python to move with the times to support threading properly in this new hardware enviroment. But it will have a lot of catching up to do with Java and C# and the job will be difficult.

Craig,
You are obviously a Java lover. Python catching up with Java? I'm not going to repeat what has been posted on this before, but several leading business publications have pointed out that Java, a 1990's phenomenon, is in fact being considered on a downhill slope. C#? M$ just released a Pyhton version.
Future architectures - we'll see. I wouldn't bet on Java as being the real McCoy for these.

 

[ktmexc20]

Quote from dcraig:

This might be partially (or perhaps mostly) true today, but looking into the crystal ball a little, the trend is clearly towards multi core not just AMD and Intel and Sun, but also the Cell processor from IBM. Just speculating, but say in 3 years 8 way machines are available at PC prices. For many reasons including space, power consumption and interconnect speed these will offer compelling advantages over a small cluster of single core boxes.

Should this turn out to be the case, one would expect Python to move with the times to support threading properly in this new hardware environment. But it will have a lot of catching up to do with Java and C# and the job will be difficult.

Cell processors? Hmm interesting... First time I've heard of this.

I'm sure you're aware of the PyPy project (at least I've mentioned a few times) which is being developed by some of the highly reputable in the python community. The project is funded mostly by the European Union. I guess it's along the lines of Ruby-On-Rails, but I'm not at all familiar with Ruby's efforts.

I personally think that it's possible that PyPy (and I guess RoR) will revolutionize programming to optimize the vast benefits of compilers/interpreters with the easy syntax... and is definately considering the revolution of the now & upcoming HW innovations (portably). I say this because they are writing the whole thing in python... From assembly on up.

The beneifits of threading, continuation, and optimization are the reason the project was started to begin with.

 

[fatrat]

Quote from nononsense:

Craig,
You are obviously a Java lover. Python catching up with Java? I'm not going to repeat what has been posted on this before, but several leading business publications have pointed out that Java, a 1990's phenomenon, is in fact being considered on a downhill slope. C#? M$ just released a Pyhton version.
Future architectures - we'll see. I wouldn't bet on Java as being the real McCoy for these.

If business publications are always wrong about trends in the market, I'd think they might have difficulties forecasting trends in software development tools as well.

Secondly, your post is an argument for using C#. If MS did in fact make Python another .NET language that runs on top of their .NET framework and the CLR, then there's another reason to use C# -- you can mix it with components already written in Python! All in all, I like the .NET interface because of its ability to mix COM components and all the other things written in the various .NET languages because I can piece together solutions easily. When performance becomes an issue, I embody the performance intensive code inside unmanaged C++ code.

And as far as future architectures -- Java doesn't have to become "the real McCoy" -- it already is. Java's ability to manage threads already surpasses that of Python. They don't need to add much in the way of features to take advantage of multi-core systems. In fact, Java has some nice features like the "synchronize" keyword and internal monitor constructs to make using threads easier. These have been there for a long time.

From what it sounds like [I am not a regular Python programmer], Python doesn't have "real" threads. They sound like user-space scheduled fibers. If that's the case, you'll never be taking advantage of multi-core or multi-proc systems with process running python code. That kind of kernel-space scheduled threading support will have to be added. Of course, when it is added, it'll be anybody's guess how reliable it will be. You could save yourself the trouble now and use C#, C++, or Java. (Or, Python in the .NET framework!)