Re: [myhdl-list] newb question
Brought to you by:
jandecaluwe
Menu
▾
▴
Re: [myhdl-list] newb question
|
From: Christopher F. <cf...@uc...> - 2008-02-18 17:43:39
|
On Mon, 18 Feb 2008 17:38:33 +0100
Jan Decaluwe <ja...@ja...> wrote:
> Jan Decaluwe wrote:
>> Christopher L. Felton wrote:
>>
>>
>>>For this test, most people would not simulate this design this way.
>>>
>>>The design has a simple state machine
>>>that controls the inputs to a bank of pwm's (controls the duty
>>>cycle). But the state machine goes to the next
>>>state on the order of 100ms real-time. But since the simulation has
>>>
>>>little logic and the logic switches minimally
>>>it seemed like a good test to profile the MyHDL simulation execution
>>>(most the time spent in the simulation code and not the logic code).
>>
>>
>> This seems to imply that more "typical" code (e.g. with more logic
>> inside generators) could have a relatively larger intbv overhead,
>> and therefore more to gain from intbv optimization.
>>
>> I'll see if I can do a profiling check on my recent designs.
>
> Below you find a profiling output of a recent test plan. I believe
>this
> is quite representative for the code I tend to write.
>
> I used Python 2.5, cProfile, ordered by time (first 20 items).
>
> I use intbv slicing a lot, and you see this takes a considerable
>amount
> of time.
>
> It seems that optimizing intbv would help significantly, but the
>Simulation
Does it make sense to formalize a possible plan for optimization
(quick wiki page)? If different folks attack it in parallel they
would head down a similar path. Define if it needs to be optimized
with C code or not. If so, add ctype type for intbv (like numpy folks
did for arrays). Then attributes etc. can easily be accessible from
C?
> (including Signal) overhead being what it is, we can't expect
>miracles.
>
> (Until the py.py team delivers a Python that is 10 times faster :-))
>
> Jan
>
> ----
>
> Wed Feb 13 18:36:07 2008 runprof
>
> 536613094 function calls (523280085 primitive calls) in
>2643.025 CPU seconds
>
> Ordered by: internal time
>
> ncalls tottime percall cumtime percall
>filename:lineno(function)
> 19119681 257.504 0.000 461.618 0.000
>_intbv.py:148(__setitem__)
> 12 244.692 20.391 2623.724 218.644 _Simulation.py:95(run)
> 27579102 222.675 0.000 390.886 0.000
>_Signal.py:180(_set_next)
> 2092116 144.248 0.000 937.835 0.000 _Waiter.py:184(next)
> 89188746 139.018 0.000 139.018 0.000 {isinstance}
> 25572768 126.633 0.000 126.633 0.000
>_intbv.py:80(_checkBounds)
> 4748554 108.021 0.000 1078.335 0.000 _Waiter.py:152(next)
> 19675183 105.021 0.000 105.021 0.000 _Signal.py:46(purge)
> 41201947/30501215 94.226 0.000 168.693 0.000 {cmp}
> 27633083/26039251 93.698 0.000 248.657 0.000
>_Signal.py:426(__cmp__)
> 10615743 93.432 0.000 140.551 0.000
>_intbv.py:121(__getitem__)
> 28024120 84.658 0.000 107.350 0.000
>_Signal.py:151(_update)
> 668592 76.952 0.000 447.660 0.001 xxx.py:131(xxx)
> 13568864/13268586 75.899 0.000 127.541 0.000
>_intbv.py:428(__cmp__)
> 63303336 75.171 0.000 75.171 0.000 {method 'append' of
>'list' objects}
> 25711177 61.852 0.000 61.852 0.000
>_Signal.py:224(_setNextBool)
> 8153851 43.938 0.000 122.899 0.000
>_Signal.py:284(__getitem__)
> 33114023 38.130 0.000 38.130 0.000 {id}
> 29873445 33.188 0.000 33.188 0.000 {method 'extend' of
>'list' objects}
> 3053592 31.259 0.000 50.400 0.000 _intbv.py:39(__init__)
>
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
> From Python to silicon:
> http://myhdl.jandecaluwe.com
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
|
