I just looked into IronPython in more detail and you might be right. Sorry about that, I assumed it was layering the existing interpreter on a different thread model. Martin
You are droning on and on about things that are basically obvious ..... why ? The original topic .. long since abandoned has degraded into feces throwing with people arguing over air ...... Performance on multiprocessors is a relative idea and depends completely on the nature of the application, NOT on technical issues which outside of the context of a particular system are largely irrelevant .....
Basically obvious? Almost everyone in this discussion made mistakes and had to revise their opinion, myself included. Threading is subtle. Earlier in this discussion you wrote... "The difference between a hack and a software engineer is that the engineer knows the limits of their design: they know under what conditions it breaks or saturates." Yet now you seem to think that exploring the design limitations of Python is a waste of time. Strange. Martin
Exactly. The design limitations (or advantages) of .Net, Python, or any other of the whole plethora of techologies and platforms are largely irrelevant until you consider them in the context of a particular system .... they are only limitations if your system can not be accomodated within them .... Thus one or the other is really not "better" or "worse" People argue ad nauseum over these topics continuously, then typically when they get to point of actually deciding the best solution they start bringing up "limitations" which may have no real bearing on the system being built ..... Software and hardware vendors know this argument well and they know that if they can appeal to people with technical facts outside of the context of any particular system, then they can instill fear in them regarding a future "limitation" that their system may never hit ... and thus they overbuy and overdesign the system wasting huge amounts of money. .... The discussion sounds as if a bunch of vendors are arguing the merits of their technologies in a sales call .....
<i>People argue ad nauseum over these topics continuously, then typically when they get to point of actually deciding the best solution they start bringing up "limitations" which may have no real bearing on the system being built .....</i> You must have missed where I described exactly how this shortcoming affects my backtest engine in practice and several practical ways to work around it. If anything is a pointless ad nauseum argument, it is you complaining about this discussion. Incidentally, Python I/O operations do release the GIL. So if you need multithreading in order to saturate an I/O interface like the network or hard drive, for example retrieving quotes from a server farm or loading and processing data from a RAID array, even Python threading will give you significant speedup. It still won't let you take advantage of a multiprocessor though. Martin
But when did this become a discussion of the problem with your software design ? Those issues are for you to solve upfront before you build by developing a technology neutral or technology segregated design. If now you are suddenly trying to determine how to move what perhaps should have been a technology neutral design from the outset, then you are already in hot water ....
Not as far as I know - it would be as portable as the .NET framework is, since it depends on it. That currently means mono outside the windows environment. nitro
You didn't get anywhere with your last ad hominim criticism, so you're trying a new one? Sorry, I won't bite. Go fish somewhere else. Martin
Hi prt, You are quite right. Only a few frustrated guys hung up on either 'passe' tools or a splendid tool like C/C++, which is in a sense 'passe' for those using it in many places where Python would let you write 10 times faster without significant speed penalty - if you're smart enough. As I said I use a lot of threading in Python, even in SMP and have never encountered any limitation. If these threading clowns really think they have a point, let them take it up in the Python newsgroup. Over the years a lot has been said about this. They will likely get mauled to pieces. The point of this thread was to show the practical equivalence in speed to C/C++ of Python in scientific computation provided you fall back on the right modules. For speed of development, Python is without competition from C/C++.