Re: [myhdl-list] It's a beautiful day (somewhat long response)

[Ben <ben...@gm...>]

On Jun 9, 2011, at 11:32 PM, Jan Decaluwe wrote:

> On 06/09/2011 10:56 PM, Ben wrote:
>> 
>> On Jun 9, 2011, at 1:11 PM, Christopher Felton wrote:
>>> 
>>> The relevant information here is the ~2x increase and ~8x increase
>>> with pypy.
>> 
>> Just to mention my testsuite went from 83.213s to 22.339s. So that's almost a 4x gain.
> 
> Is this a suite that consists of a number of tests? Do you see
> the largest gains with those tests that run for the longest time,
> as can be expected from the JIT compiler?

Yes, those are 23 tests. I just don't really know which one could be big enough to be interesting ... It's been more than a year I looked at that project ...

So I thought I could try to run a big Simulation on the same project ... Knowing that it previously failed with the 1.5 release of pypy (traceback including traceSignal), I downloaded the latest nightly build I could find for my platform (http://buildbot.pypy.org/nightly/trunk/pypy-c-jit-44082-2650f0a670c0-osx64.tar.bz2) unfortunately, it looks like it is something like 800 revisions behind the tip ...

I did not got the traceback with traceSignals though. So I don't really know If I found a new bug, If I get a temporary bug that was present at this moment in time or something else.

Here is my stack trace (it doesn't looks good though):

[bogus _immutable_field_ declaration: <GcPtrFieldDescr pypy.interpreter.pyopcode.FrameBlock.inst_previous 16>]
RPython traceback:
  File "implement.c", line 1656, in entry_point
  File "implement_7.c", line 31942, in PyFrame_execute_frame
  File "implement_18.c", line 51028, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "implement_22.c", line 4090, in portal_1
  File "implement_28.c", line 5233, in handle_bytecode__AccessDirect_None
  File "implement_30.c", line 37827, in dispatch_bytecode__AccessDirect_None
  File "implement_33.c", line 60311, in call_function__AccessDirect_None
  File "implement_7.c", line 31942, in PyFrame_execute_frame
  File "implement_18.c", line 51028, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "implement_22.c", line 4090, in portal_1
  File "implement_28.c", line 5233, in handle_bytecode__AccessDirect_None
  File "implement_30.c", line 37440, in dispatch_bytecode__AccessDirect_None
  File "implement_33.c", line 60311, in call_function__AccessDirect_None
  File "implement_7.c", line 31942, in PyFrame_execute_frame
  File "implement_18.c", line 51028, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "implement_22.c", line 4090, in portal_1
  File "implement_28.c", line 5233, in handle_bytecode__AccessDirect_None
  File "implement_30.c", line 38583, in dispatch_bytecode__AccessDirect_None
  File "implement_33.c", line 60311, in call_function__AccessDirect_None
  File "implement_7.c", line 31942, in PyFrame_execute_frame
  File "implement_18.c", line 51028, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "implement_22.c", line 4090, in portal_1
  File "implement_28.c", line 5233, in handle_bytecode__AccessDirect_None
  File "implement_30.c", line 38476, in dispatch_bytecode__AccessDirect_None
  File "implement_34.c", line 785, in EXEC_STMT__AccessDirect_None
  File "implement_7.c", line 31942, in PyFrame_execute_frame
  File "implement_18.c", line 51028, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "implement_22.c", line 4090, in portal_1
  File "implement_28.c", line 5233, in handle_bytecode__AccessDirect_None
  File "implement_30.c", line 40399, in dispatch_bytecode__AccessDirect_None
  File "implement_34.c", line 8061, in CALL_METHOD__AccessDirect_star_1
  File "implement_7.c", line 31942, in PyFrame_execute_frame
  File "implement_18.c", line 51028, in ll_portal_runner__Unsigned_Bool_pypy_interpreter
  File "implement_22.c", line 4090, in portal_1
  File "implement_28.c", line 5233, in handle_bytecode__AccessDirect_None
  File "implement_33.c", line 53338, in jump_absolute__AccessDirect_None
  File "implement_28.c", line 4715, in maybe_compile_and_run__star_5_1
  File "implement_30.c", line 33036, in compile_and_run_once___pypy_jit_metainterp_jitdr_1
  File "implement_30.c", line 46244, in MetaInterp__compile_and_run_once
  File "implement_34.c", line 26936, in MetaInterp_interpret
  File "implement_37.c", line 6223, in MetaInterp__interpret
  File "implement_39.c", line 40711, in MIFrame_run_one_step
  File "implement_52.c", line 63116, in MIFrame_opimpl_jit_merge_point
  File "implement_57.c", line 46696, in MetaInterp_reached_loop_header
  File "implement_61.c", line 5901, in MetaInterp_compile_bridge
  File "implement_61.c", line 16186, in compile_new_bridge
  File "implement_64.c", line 64874, in optimize_bridge
  File "implement_69.c", line 61909, in _optimize_bridge
  File "implement_76.c", line 10608, in Optimizer_propagate_all_forward
  File "implement_79.c", line 55511, in OptHeap_optimize_SETFIELD_GC
Fatal RPython error: BogusPureField
Abort trap

Jan, where did you reported your bug ?

Pushing it a bit further, i removed the traceSignals ... 

I know have the following trouble: cPython complains with the following traceback: (I had no trouble with the traceSignals though ...)

Traceback (most recent call last):
  File "traceProc.py", line 187, in <module>
    tb = traceBench()#traceSignals(traceBench)
  File "traceProc.py", line 67, in traceBench
    @instance
  File "/Library/Python/2.6/site-packages/myhdl/_instance.py", line 42, in instance
    return _Instantiator(genFunc)
  File "/Library/Python/2.6/site-packages/myhdl/_instance.py", line 49, in __init__
    self.waiter = _inferWaiter(self.gen)
  File "/Library/Python/2.6/site-packages/myhdl/_Waiter.py", line 201, in _inferWaiter
    ast = compiler.parse(s)
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/compiler/transformer.py", line 51, in parse
    return Transformer().parsesuite(buf)
  File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/compiler/transformer.py", line 128, in parsesuite
    return self.transform(parser.suite(text))
  File "<string>", line 25
    print "*-->\t%s\t

Did I found a bug in python2.6 ?

Anyway, further removing those annoying print statements, pypy1.5 get two times **slower** than cPython ...

Not a really conclusive test though ...

Regards
Benoît