"Coyoteboy" <co*********@hotmail.com> writes:
Ive read a few comments, the usual about it being slower,sometimes vastly
slower than a C++ written item but I was wondering if its 'slow'
incomparison with what I need. I'm looking at taking two arrays of 12 bytes
over an ethernet connection, comparing them, recieving correction data
(single byte) from another module over a pipe at approximately 900Hz and
using all these with a fairly complex set of algorithms to generate a new
set of 12 byte data. This has to be done in a very short time, preferably
the same rate of throughput as the 900Hz. Am i asking too much of Python? I
find C++/MFC fairly complex and python looked like a great alternative if it
hadnt been 'flagged' as slow.
Cheers
J
There is no way to tell from this info. This is a real-time problem.
If you assume 1GHZ CPU, 10 clks/instruction, 10000 instructions/event
then you require 0.001 sec/event. 900Hz event rate means you only
have 0.0011 sec/event available, which is the same order of magnitude.
Chances are, variation in the event rate or in the OS response time
would violate this small safety factor, even if the assumptions were
dead on.
So you need a faster machine or fewer instructions. Some instructions
will be used in the OS and interface stack, no matter what language
you use. Some will be used in your "fairly complex set of
algorithms". You may have used up your 10000 instructions without
getting around to Python. Even assembler might be too slow.
If you did implement in Python and found it was too slow by a moderate
factor (e.g., you could only handle 500Hz event rate), then you can
stay in python to explore alternative implementations. E.g., multiple
processors in parallel, more efficient algorithms, ctypes or pyrex to
speed up the python.
In terms of the overall project notion-to-delivery duration,
implementing in Python might be the right first step on your way to an
assembler implementation.
--
Harry George
PLM Engineering Architecture
