Re: [myhdl-list] It's a beautiful day (somewhat long response)
Brought to you by:
jandecaluwe
Menu
▾
▴
Re: [myhdl-list] It's a beautiful day (somewhat long response)
|
From: Jan D. <ja...@ja...> - 2011-06-10 11:23:47
|
Sounds like we are changing too many things at the same time :-) 1. I wouldn't worry about non up-to-date nightly builds. PyPy is in heavy test-driven development. 2. The bug I found could easily be described in words, which I did on the irc channel. Armin Rigo fixed it before I could enter it into the bug tracker :-) 3. there is no way I can explain that things would work with traceSignals but not without. However, in your stack trace I notice a reference to the old, deprecated compiler package. Seems a really old version of MyHDL. Since 0.7, we use the supported ast package. Perhaps the deprecated compiler package was changed in 2.6 - but if so we will not fix related problems in MyHDL. Jan On 06/10/2011 12:46 AM, Ben wrote: > > 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 > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev -- 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 |
