On Thu, 09 Aug 2012 11:36:06 -0500, Jon Elson wrote: > Michael Haberler wrote: >> 4. interpreter: I'd say the current *structure* had its day (NB: I >> dont mean cradek's work) and it would be fair to reconsider whether >> C++ is actually needed or one could go to, say, a Python-based >> interpreter to start with; if C++ were the decision, I would consider >> Joseph Coffland's OpenSCAM interpreter code as an alternative to port >> to. >> > My only concern would be that a Python interpreter might be slower > than > the c++, but I > don't know enough about it to know whether that could be true. We > would > not want to > make any changes that significantly slow the block execution rate.
For some rough numbers... Straight comparison between 100% Python to C is about a 5x to 10x execution speed reduction. If you offload a lot of the numerical computation to C and use the Python bindings and nice high scale stuff (like numpy), it is a 3x slow down. The comparison between C/C++ is complicated because you can fine tune it down to be about the same, but if you muck it up and do full object copies instead of reference/pointer copies I once saw it as bad as a 100x slowdown (I fixed that pretty darn quick...) Other than that Python is nice for development and portability, but at the cost of speed. And before we get to far down the speed wagon discussions -- define just how much speed you have to have instead of demanding that it always be as fast as it can be. EBo -- ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
