Philosophical question:

If you were targeting IronPython, and an optimization made the IronPython code run in half as much time, but the same optimization made Cpython take 4 times as much time, would you roll back the optimization?

I would.

This is a very interesting time to be a programmer, specifically a Python programmer. Python3000 has the opportunity to be informed by the Python implementations of CPython, IronPython on .Net and Mono, and PyPy.

I wish Jython was able to keep up, and making more of an impact. Jim Hugunin started IronPython to prove that .NET was a worse design for dynamic languages than JVM. Did he in fact prove the opposite? Will the JVM improve?

Question:

> Don't forget that if you use threads on a multi-core processor, then IronPython (unencumbered by the GIL) will almost certainly whoop CPython for performance.

Do we have test results on this? Concurrent processing is the most important place where I feel Python is a bit behind the curve, but it is understandable because only now are people starting to really come to grips with making algorithms and designs that take advantage of concurrent processing. I wish Python was the place where:

1) You could use message-passing and shared-nothing as the easy default for concurrent processing

2) You could easily have a thread "watch over" a system of reliant resources to prevent dead-locks.

3) If shared-nothing wasn't going to cut it for performance reasons, that you could easily and precisely define and enforce what state was shared between concurrent threads.
manuelg | 07/04/22 - 8:06 pm | #