Re: [myhdl-list] intbv return types and a fixed-point Object

[Jan D. <ja...@ja...>]

Christopher Felton wrote:
> 
>      >
>      > The change was to the _intbv.py.  All math operations were changed to
>      > return a intbv type versus an int type.
> 
>     Thanks for the work, that really helps.
> 
>     In your example, the peformance hit is around 7%. Not dramatic perhaps,
>     but not negligible either.
> 
>     On the other hand, we would probably get this back easily (and more) if
>     _intbv.py is redone in C, which may make a lot of sense just like
>     Signal.
> 
>     I still hesitate. If the reason is purely esthetics, that doesn't seem
>     enough for the change. But if there is a valid technical reason, I have
>     nothing against it either. What does the community think?
> 
>     Jan
> 
> 
> If such performance improvements were attempted would it be better to 
> focus on the Signal class.  In the profiles I have captured the Signal 
> class consumes much more than intbv.

It is clear that Signal is expensive. I prefer coding styles in which
they are not over-used.

In many cases Signal wraps an intbv object. From you profiles, is it
always clear to what functionality the time should be attributed?

What you gain by a C implementation is very much dependent on the
module. I once rewrote the basic simulation engine in MyHDL in C,
with almost no gain. If you mainly use the Python API in C, there's
little gain. On the other hand, if you can rewrite numeric operations
in C directly instead of with the Python API, the gains can be
very large. For this reason, I expect the potential relative gains
for intbv to much larger than for Signal.

On the other hand, as you mention, numeric operations that mimic
intbv (or int) may be very tricky in C. I wouldn't want to try it!
The best starting point would probably be the Python int module.

> The C implementations get tricky, cross-compile multiple platforms etc. 
>  Before such an effort is undertaken it might make sense to simply 
> define the C interface.  The numpy folks have done something similar. 
>  Defined "ctypes" types.  
> http://www.scipy.org/Cookbook/Ctypes
> http://mentat.za.net/ctpug-numpy/ctypes.html
> 
> If "ctype" types were defined for intbv and Signal that might be enough 
> to start implementing portions in C-code.
> Ctypes might not be as efficient as actually embedding  C code but could 
> be a easier approach.  I don't have much experience in this area others 
> may want to comment.
> 
> Another major bottleneck is how python handles the generators (schedules 
> them)?  Would this be correct?  Is the simulation performance mainly 
> dictated by this?

Python doesn't schedule the generators. The MyHDL  Simulation does,
according to a strict algorithm that mimics what VHDL does. The simulation
engine contains optimizations already. For example, every generator is
inspected before the simulation starts. Depending on its sensitivity lists,
it is wrapped in an appropriate wrapper to mimimize the number of tests
during simulation. This makes sense because many generators are endless
loops that run over and over again.

Jan


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com