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

[Christopher F. <chr...@gm...>]

>
>
> >
> > 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.

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?

It sounds like most are busy and this topic will have to be put on the back
burner.

Chris