On Thu, 2012-08-09 at 12:54 -0400, EBo wrote: > 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 -- > I'm back again.
Maybe the cart is creeping ahead of the horse. ... just visualize that! Re' the post by Peter about MW525's being limited to 1.25 KHz cycle rate and this seems to be a trend in intel processors being less and less suited to rt maybe it is time to find a new architecture (sustainable) the suits our needs and then design the system around that. Just my tuppance...again. Dave ps. the above may only apply to the inexpensive processors but that is what we tend to use. > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
