Python versus C++ Speed

[dcraig]

Quote from nononsense:

Hi All,

Obviously, the anti-Python party will always come up with any argument that seems to fit.

On the contrary, I am not anti Python at all and look forward to having the time for me personally to do it justice. And I am very pro Open Source. But you must air these issues. One cannot make informed decisions otherwise.

As an aside I think Sun will eventually open up the JVM. Source for everything else including Swing is included with the JDK. In purely everyday practical terms, this can be very useful in providing enlightenment as to how to go about certain things.

Some in the Open Source world have been very critical of Sun for it's somewhat restictive attitude to Java. Sun have certainly made a lot of serious mistakes, but when you are protecting yourself from the 800 lb Gorilla that is MS it is somewhat easier to understand.

And as another aside, it has been reported that Sun is considering licensing Solaris under the GPL (GPL 3). If licensing issues can be sorted out this could be a very good thing as there are some things in Solaris 10 that could be of real benefit to Linux.

 

[nononsense]

Quote from fatrat:

Your understanding of user-space threads vs kernel-space threads is lacking. Consult books by Tanenbaum or Silberschatz regarding OS design to understand where your knowledge has fallen short.

The Python interpreter is incapable of scheduling fibers on multiple processors. Fibers exist within 1 process, which [I'm guessing in this case] has only thread of execution. It would need to instantiate a thread that is managed and scheduled by the kernel. Only then can it take advantage of future architectures. Java and C#'s threads are scheduled by the kernel, and the kernel scheduler in modern OS's that support SMP are aware of multiple processors and cores to schedule those threads on.

You obviously want to win an argument at all price. If you would have the slightest understanding and/or experience of hardware related programming, or for that matter scientific programming, you would certainly have grasped the irrelevance of your fiber & thread whining as to the topic under discussion in this thread.

I suggest you start a few new threads on your own, establishing the superiority of Java and C# as scientific programming languages. (If you don't find enough meat, mouth off a bit about Tannenbaum e.o.)
Don't forget about your other great thread about C# and Java being the truly forward looking languages for supporting SMP and dual core architectures.

Further, your affliction could be helped a bit if you would read up a bit on the design discussions around Python. You obviously failed to grasp the practical importance of this thread in pointing out the relative superiority of Python in achieving speed in design and execution of advanced scientific applications.

Awaiting your threads showing the desirability of your C# and Java. I'll be fast to switch but you will have to do much better than talking about Tannenbaum. In the meantime I'll continue with Python.

nononsense

 

[fatrat]

Quote from nononsense:

You obviously want to win an argument at all price. If you would have the slightest understanding and/or experience of hardware related programming, or for that matter scientific programming, you would certainly have grasped the irrelevance of your fiber & thread whining as to the topic under discussion in this thread.

I suggest you start a few new threads on your own, establishing the superiority of Java and C# as scientific programming languages. (If you don't find enough meat, mouth off a bit about Tannenbaum e.o.)
Don't forget about your other great thread about C# and Java being the truly forward looking languages for supporting SMP and dual core architectures.

Further, your affliction could be helped a bit if you would read up a bit on the design discussions around Python. You obviously failed to grasp the practical importance of this thread in pointing out the relative superiority of Python in achieving speed in design and execution of advanced scientific applications.

Awaiting your threads showing the desirability of your C# and Java. I'll be fast to switch but you will have to do much better than talking about Tannenbaum. In the meantime I'll continue with Python.

nononsense

This entire post of yours is clap-trap.

You're a grade-A fool if you think threading has nothing to do with performance. Thread scheduling is critical for increasing throughput. A platform that limits itself exclusively to user-space threads will have a tough time competing against a platform that takes advantage of kernel-threads and multiple cores.

Scientific applications or not, it doesn't matter. There are enough libraries and software packages for C++ that the properly designed C++ application will always, always beat the pants off of a properly designed Python application. They will just extremely beat the pants off properly designed Python applications when multiple threads and multiple cores are involved.

Continue to wallow in your ignorance. It's your piss-poor software performance, not mine.

 

[nononsense]

Quote from dcraig:

On the contrary, I am not anti Python at all and look forward to having the time for me personally to do it justice. And I am very pro Open Source. But you must air these issues. One cannot make informed decisions otherwise.

As an aside I think Sun will eventually open up the JVM. Source for everything else including Swing is included with the JDK. In purely everyday practical terms, this can be very useful in providing enlightenment as to how to go about certain things.

Some in the Open Source world have been very critical of Sun for it's somewhat restictive attitude to Java. Sun have certainly made a lot of serious mistakes, but when you are protecting yourself from the 800 lb Gorilla that is MS it is somewhat easier to understand.

And as another aside, it has been reported that Sun is considering licensing Solaris under the GPL (GPL 3). If licensing issues can be sorted out this could be a very good thing as there are some things in Solaris 10 that could be of real benefit to Linux.

You must be a Sun salesman.
Sun/Java keep on piling up goodies for the las 10 years, java, beans, JDK, ..., Eclipse and now everything swings about Swing.
Craig, better stay on topic. Python is Python, that's all. No indigestion of proprietary boxies with the vague promise of Sun perhaps considering 'Open' sourcing at some far away time in the future. What's the difference with your 800lbs gorilla?
Now all your stuff is quite off-topic. I asked you what you would put next to scipy under your Java. You only talk about Sun considering licensing Solaris.
I am so happy for you the way you love your Java.
I only stick to the best I know. When I'll have to I'll change rather quickly. I'm not preaching for Suns or Gorillas. Please tell us about scientific computing under Java. Drop all the rest or start your own Java scientific computing thread.
nononsense

 

[nononsense]

Quote from fatrat:

This entire post of yours is clap-trap.

You're a grade-A fool if you think threading has nothing to do with performance. Thread scheduling is critical for increasing throughput. A platform that limits itself exclusively to user-space threads will have a tough time competing against a platform that takes advantage of kernel-threads and multiple cores.

Scientific applications or not, it doesn't matter. There are enough libraries and software packages for C++ that the properly designed C++ application will always, always beat the pants off of a properly designed Python application. They will just extremely beat the pants off properly designed Python applications when multiple threads and multiple cores are involved.

Continue to wallow in your ignorance. It's your piss-poor software performance, not mine.

Poor soul,
Your argumentation seems to only rest on ignorance-calling slightly tending towards the obscene. Not very convincing about your fiber & thread wits.
Can't further bother with you fatrat,
nononsense

 

[Sparohok]

Just catching up on this thread. Lots of misunderstandings to clear up.

dcraig is absolutely right. Threading is important and the interpreter lock does hurt Python's ability to scale on shared memory multiprocessors. Such architectures are the future of computing, even for commodity hardware. Applications that cannot adapt to this reality will fall behind the state of the art. As it stands today, Python is part of the problem, not part of the solution.

fatrat is half right, but clearly does not understand how Python threading is implemented. Python uses kernel threads just like any compiled language. It uses kernel preemption and scheduling. However, the GIL prevents multiple Python threads from running simultaneously and thus eliminates any performance benefit of threading on multiprocessors. No matter what threading model you use to implement Python threading, .NET or whatever, you will have exactly the same limitation, unless the Python interpreter is fixed to be thread safe.

I'm a huge advocate of Python but the global interpreter lock is a serious problem. In order to circumvent this problem, I'm forced to run multiple processes and do synchronization through my SQL database which is a pain in the ass. The nice thing about this approach is that it scales easily from multiprocessors to clusters. The downside is that you can't do any fine grained locking because the synchronization latency is awful.

The only other way I know of to get reasonable parallelism under Python is to write your inner loops in C/C++ and release the global interpreter lock within your code. As long as you are careful you can achieve true parallelism without rewriting your entire application. Incidentally, I don't think numarray or scipy stuff does this today.

Martin

 

[fatrat]

Quote from Sparohok:

Just catching up on this thread. Lots of misunderstandings to clear up.

dcraig is absolutely right. Threading is important and the interpreter lock does hurt Python's ability to scale on shared memory multiprocessors. Such architectures are the future of computing, even for commodity hardware. Applications that cannot adapt to this reality will fall behind the state of the art. As it stands today, Python is part of the problem, not part of the solution.

fatrat is half right, but clearly does not understand how Python threading is implemented. Python uses kernel threads just like any compiled language. It uses kernel preemption and scheduling. However, the GIL prevents multiple Python threads from running simultaneously and thus eliminates any performance benefit of threading on multiprocessors. No matter what threading model you use to implement Python threading, .NET or whatever, you will have exactly the same limitation, unless the Python interpreter is fixed to be thread safe.

I'm a huge advocate of Python but the global interpreter lock is a serious problem. In order to circumvent this problem, I'm forced to run multiple processes and do synchronization through my SQL database which is a pain in the ass. The nice thing about this approach is that it scales easily from multiprocessors to clusters. The downside is that you can't do any fine grained locking because the synchronization latency is awful.

The only other way I know of to get reasonable parallelism under Python is to write your inner loops in C/C++ and release the global interpreter lock within your code. As long as you are careful you can achieve true parallelism without rewriting your entire application. Incidentally, I don't think numarray or scipy stuff does this today.

Martin

Ah, ok. Hence the label thread and not fiber. That makes sense.

 

[fatrat]

Quote from Sparohok:

Just catching up on this thread. Lots of misunderstandings to clear up.

dcraig is absolutely right. Threading is important and the interpreter lock does hurt Python's ability to scale on shared memory multiprocessors. Such architectures are the future of computing, even for commodity hardware. Applications that cannot adapt to this reality will fall behind the state of the art. As it stands today, Python is part of the problem, not part of the solution.

fatrat is half right, but clearly does not understand how Python threading is implemented. Python uses kernel threads just like any compiled language. It uses kernel preemption and scheduling. However, the GIL prevents multiple Python threads from running simultaneously and thus eliminates any performance benefit of threading on multiprocessors. No matter what threading model you use to implement Python threading, .NET or whatever, you will have exactly the same limitation, unless the Python interpreter is fixed to be thread safe.

I'm a huge advocate of Python but the global interpreter lock is a serious problem. In order to circumvent this problem, I'm forced to run multiple processes and do synchronization through my SQL database which is a pain in the ass. The nice thing about this approach is that it scales easily from multiprocessors to clusters. The downside is that you can't do any fine grained locking because the synchronization latency is awful.

The only other way I know of to get reasonable parallelism under Python is to write your inner loops in C/C++ and release the global interpreter lock within your code. As long as you are careful you can achieve true parallelism without rewriting your entire application. Incidentally, I don't think numarray or scipy stuff does this today.

Martin

Wait though -- if Python gets compiled to IL in .NET, why would there be a need for the interpreter lock, or the interpreter at all for that matter? That makes no sense. It should be able to get better performance and make use of .NET threading objects.

 

[prt_systems]

Thanks for the review of what everyone else already said ...... I think the issue was already covered.

You guys are arguing over something that can be stated in two sentences .... give it up.

For literally YEARS I have listened to people argue ad nauseum about threading, and most of the time they drone on and on over stuff that is irrelevant to a whole host of applications. Usually the people arguing are engaged in some type of monkey-like battle akin to flinging feces at each other.....

Here is a clue ... if it matters to your application then worry about it. ... For many applications this discussion is irrelevant .....

 

[Sparohok]

Hey prt,

If you're not interested, because your application doesn't need threads, then why not just go away? Some people do care about performance on multiprocessors, which is why we talk about it.

Martin