Thread: [myhdl-list] It's a beautiful day
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Jan D. <ja...@ja...> - 2011-06-07 12:16:17
|
A few weeks ago, I posted the following:
> From: Jan Decaluwe <ja...@ja...>
> Newsgroups: gmane.comp.python.myhdl
> Subject: My take on MyHDL weaknesses - and solutions
> Date: Mon, 04 Apr 2011 11:00:23 +0200
> ...
> Solution 2: The PyPy project (future). Python doesn't have
> to be slow: by employing clever JIT techniques, performance
> can be improved drastically e.g. 5-10x. I believe that MyHDL
> is a good candidate for this type of optimization. The day
> this happens would be one of the most important ones in
> MyHDL's history: the performance limitations would for a
> large part go away, and it would be the ultimate validation
> of the concept: benefitting from advances without having to
> do anything yourself :-)
I'm very happy to report that it looks like this day has
arrived now. PyPy 1.5 is compatible with Python 2.7, and
I'm seeing really spectacular speedup factors.
I have documented my findings extensively here:
http://www.myhdl.org/doku.php/performance
Obviously, I would like to create some buzz about this, but
I want to move carefully. First I would like to know if
people with relevant simulations get similar results.
Feedback is therefore very welcome; I think everything needed
to get started is documented on the page mentioned above.
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
|
|
From: Angel E. <ang...@gm...> - 2011-06-07 13:29:03
|
That is fantastic news! I'm pretty sure that the PyPy guys would love to hear about this success story. I believe they have a web page were they track packages that work with PyPy. It would probably be even better if MyHDL was on the Python Package Index (coincidentally named PyPi) since I think there are also some web pages which track the percentage of the packages in there war work with PyPi. Also, think they have a page, http://speed.pypy.org/, where they automatically run benchmarks comparing their performance to CPython's. It would be great if you got them to add a MyHDL benchmark to their list. Since PyPy has quite a lot of mindshare on sites such as HackerNews, reddit/programming, etc, if you manage to get "featured" by them (in their blog, or on their benchmark page, for example) you'd surely get a huge boost to the number of people that know about MyHDL. As for your performance comparison, I wonder if it would make sense to manually write equivalent VHDL and Verilog tests, and compare those to the automatically generated ones (with MyHDL). If the results are similar it would make a really strong case that Verilog and VHDL code generated with MyHDL is as efficient as code directly written in those languages. I know that is a concern to some people when they get introduced to MyHDL so anything that can prove that is not the case would be great. I would say that they only drawback of the PyPy apporach is that, AFAIK, there is currently no stand-alone windows installer. Hopefully that will be addressed by the PyPy guys soon. Cheers, Angel On Tue, Jun 7, 2011 at 2:15 PM, Jan Decaluwe <ja...@ja...> wrote: > A few weeks ago, I posted the following: > >> From: Jan Decaluwe <ja...@ja...> >> Newsgroups: gmane.comp.python.myhdl >> Subject: My take on MyHDL weaknesses - and solutions >> Date: Mon, 04 Apr 2011 11:00:23 +0200 >> ... >> Solution 2: The PyPy project (future). Python doesn't have >> to be slow: by employing clever JIT techniques, performance >> can be improved drastically e.g. 5-10x. I believe that MyHDL >> is a good candidate for this type of optimization. The day >> this happens would be one of the most important ones in >> MyHDL's history: the performance limitations would for a >> large part go away, and it would be the ultimate validation >> of the concept: benefitting from advances without having to >> do anything yourself :-) > > I'm very happy to report that it looks like this day has > arrived now. PyPy 1.5 is compatible with Python 2.7, and > I'm seeing really spectacular speedup factors. > > I have documented my findings extensively here: > > http://www.myhdl.org/doku.php/performance > > Obviously, I would like to create some buzz about this, but > I want to move carefully. First I would like to know if > people with relevant simulations get similar results. > > Feedback is therefore very welcome; I think everything needed > to get started is documented on the page mentioned above. > > 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 > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
|
From: Angel E. <ang...@gm...> - 2011-06-07 13:58:16
|
On Tue, Jun 7, 2011 at 3:28 PM, Angel Ezquerra <ang...@gm...> wrote: > That is fantastic news! > > I'm pretty sure that the PyPy guys would love to hear about this > success story. I believe they have a web page were they track packages > that work with PyPy. It would probably be even better if MyHDL was on > the Python Package Index (coincidentally named PyPi) since I think > there are also some web pages which track the percentage of the > packages in there war work with PyPi. Also, think they have a page, > http://speed.pypy.org/, where they automatically run benchmarks > comparing their performance to CPython's. It would be great if you got > them to add a MyHDL benchmark to their list. > > Since PyPy has quite a lot of mindshare on sites such as HackerNews, > reddit/programming, etc, if you manage to get "featured" by them (in > their blog, or on their benchmark page, for example) you'd surely get > a huge boost to the number of people that know about MyHDL. > > As for your performance comparison, I wonder if it would make sense to > manually write equivalent VHDL and Verilog tests, and compare those to > the automatically generated ones (with MyHDL). If the results are > similar it would make a really strong case that Verilog and VHDL code > generated with MyHDL is as efficient as code directly written in those > languages. I know that is a concern to some people when they get > introduced to MyHDL so anything that can prove that is not the case > would be great. > > I would say that they only drawback of the PyPy apporach is that, > AFAIK, there is currently no stand-alone windows installer. Hopefully > that will be addressed by the PyPy guys soon. > > Cheers, > > Angel > > > On Tue, Jun 7, 2011 at 2:15 PM, Jan Decaluwe <ja...@ja...> wrote: >> A few weeks ago, I posted the following: >> >>> From: Jan Decaluwe <ja...@ja...> >>> Newsgroups: gmane.comp.python.myhdl >>> Subject: My take on MyHDL weaknesses - and solutions >>> Date: Mon, 04 Apr 2011 11:00:23 +0200 >>> ... >>> Solution 2: The PyPy project (future). Python doesn't have >>> to be slow: by employing clever JIT techniques, performance >>> can be improved drastically e.g. 5-10x. I believe that MyHDL >>> is a good candidate for this type of optimization. The day >>> this happens would be one of the most important ones in >>> MyHDL's history: the performance limitations would for a >>> large part go away, and it would be the ultimate validation >>> of the concept: benefitting from advances without having to >>> do anything yourself :-) >> >> I'm very happy to report that it looks like this day has >> arrived now. PyPy 1.5 is compatible with Python 2.7, and >> I'm seeing really spectacular speedup factors. >> >> I have documented my findings extensively here: >> >> http://www.myhdl.org/doku.php/performance >> >> Obviously, I would like to create some buzz about this, but >> I want to move carefully. First I would like to know if >> people with relevant simulations get similar results. >> >> Feedback is therefore very welcome; I think everything needed >> to get started is documented on the page mentioned above. >> >> 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 >> >> >> ------------------------------------------------------------------------------ >> 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 >> _______________________________________________ >> myhdl-list mailing list >> myh...@li... >> https://lists.sourceforge.net/lists/listinfo/myhdl-list >> > Actually it seems there is a beta version of a windows (x32) installer! You can get it from: http://pypy.org/download.html Angel |
|
From: Christopher F. <chr...@gm...> - 2011-06-07 15:03:17
|
It is suppose to be over 100F here today with a heat index of 110F. But seriously, good job! This is exciting news. When I get a chance I will try this on some of my projects and report back. Chris |
|
From: Christopher F. <chr...@gm...> - 2011-06-08 08:45:57
|
On 6/7/11 7:15 AM, Jan Decaluwe wrote: > A few weeks ago, I posted the following: > >> From: Jan Decaluwe<ja...@ja...> >> Newsgroups: gmane.comp.python.myhdl >> Subject: My take on MyHDL weaknesses - and solutions >> Date: Mon, 04 Apr 2011 11:00:23 +0200 >> ... >> Solution 2: The PyPy project (future). Python doesn't have >> to be slow: by employing clever JIT techniques, performance >> can be improved drastically e.g. 5-10x. I believe that MyHDL >> is a good candidate for this type of optimization. The day >> this happens would be one of the most important ones in >> MyHDL's history: the performance limitations would for a >> large part go away, and it would be the ultimate validation >> of the concept: benefitting from advances without having to >> do anything yourself :-) > > I'm very happy to report that it looks like this day has > arrived now. PyPy 1.5 is compatible with Python 2.7, and > I'm seeing really spectacular speedup factors. > > I have documented my findings extensively here: > > http://www.myhdl.org/doku.php/performance > > Obviously, I would like to create some buzz about this, but > I want to move carefully. First I would like to know if > people with relevant simulations get similar results. > > Feedback is therefore very welcome; I think everything needed > to get started is documented on the page mentioned above. > > Jan > The following are some notes at my attempt to use pypy on some of my projects today. Jump to the Chase ================= My experience was mixed. Majority of my projects, simulations, utilize numpy and other packages (matplotlib, etc). Most of these do not work with pypy. Majority of my project simulations failed with pypy. I read there are efforts to get numpy working with pypy. But it is unknown when these would be available. Most of my active projects have some dependency that failed and prevented the simulations from running with pypy. Note: My testbenches utilize numpy and other common Python libraries. The hardware descriptions do *not* use the libraries. Disclaimer ========== I did not set out to run a set of simulations to preform similar task that Jan Decaluwe did in his excellent write-up. But rather test pypy against existing projects (in existing states) and record the results with minimal modifications and effort. Other than getting the *existing* simulations to run no additional work was performed to create a good test suite. Notes on Installing pypy ======================== I usually work on an ancient mac and pypy1.5 is available through macports. Should be easy to install ... ``>> port install pypy`` But, it failed to build and it wasn't clear why, next step try building from the source, binaries not available for my machine. This was confusing. The pypy installing PYPY page_ has instructions where to get the source (tarball or hg). But then jumps to testing the install and not the actual act of installing? .. _page: pypy.org/download.html#install But installing on the Ubuntu box was pretty straight forward. Download the binaries and off you go. The simulations were attempted on an Ubuntu system. Verified pypy worked. Simulations =========== As discussed, the first couple simulations I tried failed because of the unsupported dependencies. Which required some investigation on the failures and possible solutions. At this time there is no solution for the numpy and company other than rewriting the simulations, not to use numpy. The following is the list of my projects I attempted to run with pypy. Most of these are described on the myhdl wiki. 1. Recursive FFT (failed, numpy) 2. GnuRadio Compatible USRP CIC Filter (failed, numpy) 3. Fixed-Point SOS (failed, numpy) 4. USBP (FX2 USB Interface) (failed in myhdl??) All in all, I could not get any of them to run with pypy? Some were expected but some were not. Summary ======= I think pypy is very promising but there are some limitations. I don't know how many others would be affected by the limitations but for me it was fairly severe. But I also need to devote some more time resolving the non-dependency issues and working through those. I look forward to the day more packages are supported by pypy! Chris Felton |
|
From: Angel E. <ang...@gm...> - 2011-06-08 09:07:52
|
On Wed, Jun 8, 2011 at 10:45 AM, Christopher Felton <chr...@gm...> wrote: > On 6/7/11 7:15 AM, Jan Decaluwe wrote: >> A few weeks ago, I posted the following: >> >>> From: Jan Decaluwe<ja...@ja...> >>> Newsgroups: gmane.comp.python.myhdl >>> Subject: My take on MyHDL weaknesses - and solutions >>> Date: Mon, 04 Apr 2011 11:00:23 +0200 >>> ... >>> Solution 2: The PyPy project (future). Python doesn't have >>> to be slow: by employing clever JIT techniques, performance >>> can be improved drastically e.g. 5-10x. I believe that MyHDL >>> is a good candidate for this type of optimization. The day >>> this happens would be one of the most important ones in >>> MyHDL's history: the performance limitations would for a >>> large part go away, and it would be the ultimate validation >>> of the concept: benefitting from advances without having to >>> do anything yourself :-) >> >> I'm very happy to report that it looks like this day has >> arrived now. PyPy 1.5 is compatible with Python 2.7, and >> I'm seeing really spectacular speedup factors. >> >> I have documented my findings extensively here: >> >> http://www.myhdl.org/doku.php/performance >> >> Obviously, I would like to create some buzz about this, but >> I want to move carefully. First I would like to know if >> people with relevant simulations get similar results. >> >> Feedback is therefore very welcome; I think everything needed >> to get started is documented on the page mentioned above. >> >> Jan >> > > The following are some notes at my attempt to use pypy on some of my > projects today. > > Jump to the Chase > ================= > My experience was mixed. Majority of my projects, simulations, utilize > numpy and other packages (matplotlib, etc). Most of these do not work > with pypy. Majority of my project simulations failed with pypy. I read > there are efforts to get numpy working with pypy. But it is unknown > when these would be available. Most of my active projects have some > dependency that failed and prevented the simulations from running with > pypy. > > Note: My testbenches utilize numpy and other common Python libraries. > The hardware descriptions do *not* use the libraries. > > > Disclaimer > ========== > I did not set out to run a set of simulations to preform similar task > that Jan Decaluwe did in his excellent write-up. But rather test pypy > against existing projects (in existing states) and record the results > with minimal modifications and effort. Other than getting the > *existing* simulations to run no additional work was performed to create > a good test suite. > > > Notes on Installing pypy > ======================== > I usually work on an ancient mac and pypy1.5 is available through > macports. Should be easy to install ... > > ``>> port install pypy`` > > But, it failed to build and it wasn't clear why, next step try building > from the source, binaries not available for my machine. This was > confusing. The pypy installing PYPY page_ has instructions where to get > the source (tarball or hg). But then jumps to testing the install and > not the actual act of installing? > > .. _page: pypy.org/download.html#install > > But installing on the Ubuntu box was pretty straight forward. Download > the binaries and off you go. The simulations were attempted on an > Ubuntu system. Verified pypy worked. > > > Simulations > =========== > As discussed, the first couple simulations I tried failed because of the > unsupported dependencies. Which required some investigation on the > failures and possible solutions. At this time there is no solution for > the numpy and company other than rewriting the simulations, not to use > numpy. The following is the list of my projects I attempted to run with > pypy. Most of these are described on the myhdl wiki. > > 1. Recursive FFT (failed, numpy) > 2. GnuRadio Compatible USRP CIC Filter (failed, numpy) > 3. Fixed-Point SOS (failed, numpy) > 4. USBP (FX2 USB Interface) (failed in myhdl??) > > All in all, I could not get any of them to run with pypy? Some were > expected but some were not. > > > Summary > ======= > I think pypy is very promising but there are some limitations. I don't > know how many others would be affected by the limitations but for me it > was fairly severe. But I also need to devote some more time resolving > the non-dependency issues and working through those. I look forward to > the day more packages are supported by pypy! > > Chris Felton Chris, it seems that you are not the only one who'd like to get numpy to work with pypy. Check these two posts on the pypy blog: http://morepypy.blogspot.com/2011/05/numpy-in-pypy-status-and-roadmap.html http://morepypy.blogspot.com/2011/06/report-back-from-our-survey.html In short, they know this is important, they have a plan on how to proceed, they believe they can make numpy even faster than it is, but they don't have many resources allocated to the task (yet?). So I think we can be cautiously optimist that this problem will be solved eventually. In the meantime I'd love to know if your projects work when you remove the numpy stuff. Angel |
|
From: Christopher F. <chr...@gm...> - 2011-06-08 09:14:21
|
On 6/8/11 4:07 AM, Angel Ezquerra wrote: > On Wed, Jun 8, 2011 at 10:45 AM, Christopher Felton > <chr...@gm...> wrote: >> On 6/7/11 7:15 AM, Jan Decaluwe wrote: >>> A few weeks ago, I posted the following: >>> >>>> From: Jan Decaluwe<ja...@ja...> >>>> Newsgroups: gmane.comp.python.myhdl >>>> Subject: My take on MyHDL weaknesses - and solutions >>>> Date: Mon, 04 Apr 2011 11:00:23 +0200 >>>> ... >>>> Solution 2: The PyPy project (future). Python doesn't have >>>> to be slow: by employing clever JIT techniques, performance >>>> can be improved drastically e.g. 5-10x. I believe that MyHDL >>>> is a good candidate for this type of optimization. The day >>>> this happens would be one of the most important ones in >>>> MyHDL's history: the performance limitations would for a >>>> large part go away, and it would be the ultimate validation >>>> of the concept: benefitting from advances without having to >>>> do anything yourself :-) >>> >>> I'm very happy to report that it looks like this day has >>> arrived now. PyPy 1.5 is compatible with Python 2.7, and >>> I'm seeing really spectacular speedup factors. >>> >>> I have documented my findings extensively here: >>> >>> http://www.myhdl.org/doku.php/performance >>> >>> Obviously, I would like to create some buzz about this, but >>> I want to move carefully. First I would like to know if >>> people with relevant simulations get similar results. >>> >>> Feedback is therefore very welcome; I think everything needed >>> to get started is documented on the page mentioned above. >>> >>> Jan >>> >> >> The following are some notes at my attempt to use pypy on some of my >> projects today. >> >> Jump to the Chase >> ================= >> My experience was mixed. Majority of my projects, simulations, utilize >> numpy and other packages (matplotlib, etc). Most of these do not work >> with pypy. Majority of my project simulations failed with pypy. I read >> there are efforts to get numpy working with pypy. But it is unknown >> when these would be available. Most of my active projects have some >> dependency that failed and prevented the simulations from running with >> pypy. >> >> Note: My testbenches utilize numpy and other common Python libraries. >> The hardware descriptions do *not* use the libraries. >> >> >> Disclaimer >> ========== >> I did not set out to run a set of simulations to preform similar task >> that Jan Decaluwe did in his excellent write-up. But rather test pypy >> against existing projects (in existing states) and record the results >> with minimal modifications and effort. Other than getting the >> *existing* simulations to run no additional work was performed to create >> a good test suite. >> >> >> Notes on Installing pypy >> ======================== >> I usually work on an ancient mac and pypy1.5 is available through >> macports. Should be easy to install ... >> >> ``>> port install pypy`` >> >> But, it failed to build and it wasn't clear why, next step try building >> from the source, binaries not available for my machine. This was >> confusing. The pypy installing PYPY page_ has instructions where to get >> the source (tarball or hg). But then jumps to testing the install and >> not the actual act of installing? >> >> .. _page: pypy.org/download.html#install >> >> But installing on the Ubuntu box was pretty straight forward. Download >> the binaries and off you go. The simulations were attempted on an >> Ubuntu system. Verified pypy worked. >> >> >> Simulations >> =========== >> As discussed, the first couple simulations I tried failed because of the >> unsupported dependencies. Which required some investigation on the >> failures and possible solutions. At this time there is no solution for >> the numpy and company other than rewriting the simulations, not to use >> numpy. The following is the list of my projects I attempted to run with >> pypy. Most of these are described on the myhdl wiki. >> >> 1. Recursive FFT (failed, numpy) >> 2. GnuRadio Compatible USRP CIC Filter (failed, numpy) >> 3. Fixed-Point SOS (failed, numpy) >> 4. USBP (FX2 USB Interface) (failed in myhdl??) >> >> All in all, I could not get any of them to run with pypy? Some were >> expected but some were not. >> >> >> Summary >> ======= >> I think pypy is very promising but there are some limitations. I don't >> know how many others would be affected by the limitations but for me it >> was fairly severe. But I also need to devote some more time resolving >> the non-dependency issues and working through those. I look forward to >> the day more packages are supported by pypy! >> >> Chris Felton > > Chris, > > it seems that you are not the only one who'd like to get numpy to work > with pypy. Check these two posts on the pypy blog: > > http://morepypy.blogspot.com/2011/05/numpy-in-pypy-status-and-roadmap.html > http://morepypy.blogspot.com/2011/06/report-back-from-our-survey.html > > In short, they know this is important, they have a plan on how to > proceed, they believe they can make numpy even faster than it is, but > they don't have many resources allocated to the task (yet?). > > So I think we can be cautiously optimist that this problem will be > solved eventually. > > In the meantime I'd love to know if your projects work when you remove > the numpy stuff. > > Angel I imagine I could get them to work without the numpy. I really only use the numerical packages to create the input signals and analyze the output signals. A bunch of it is for analyzing the response, creating psd plots, etc. If I remove a bunch of the post-simulation analysis I should be able to reproduce the signal generation with lists and the basic Python math libs. At that point I could measure the speed improvements with pypy. Thanks for the links! Chris |
|
From: Angel E. <ang...@gm...> - 2011-06-08 10:15:49
|
On Wed, Jun 8, 2011 at 11:13 AM, Christopher Felton <chr...@gm...> wrote: > On 6/8/11 4:07 AM, Angel Ezquerra wrote: >> On Wed, Jun 8, 2011 at 10:45 AM, Christopher Felton >> <chr...@gm...> wrote: >>> On 6/7/11 7:15 AM, Jan Decaluwe wrote: >>>> A few weeks ago, I posted the following: >>>> >>>>> From: Jan Decaluwe<ja...@ja...> >>>>> Newsgroups: gmane.comp.python.myhdl >>>>> Subject: My take on MyHDL weaknesses - and solutions >>>>> Date: Mon, 04 Apr 2011 11:00:23 +0200 >>>>> ... >>>>> Solution 2: The PyPy project (future). Python doesn't have >>>>> to be slow: by employing clever JIT techniques, performance >>>>> can be improved drastically e.g. 5-10x. I believe that MyHDL >>>>> is a good candidate for this type of optimization. The day >>>>> this happens would be one of the most important ones in >>>>> MyHDL's history: the performance limitations would for a >>>>> large part go away, and it would be the ultimate validation >>>>> of the concept: benefitting from advances without having to >>>>> do anything yourself :-) >>>> >>>> I'm very happy to report that it looks like this day has >>>> arrived now. PyPy 1.5 is compatible with Python 2.7, and >>>> I'm seeing really spectacular speedup factors. >>>> >>>> I have documented my findings extensively here: >>>> >>>> http://www.myhdl.org/doku.php/performance >>>> >>>> Obviously, I would like to create some buzz about this, but >>>> I want to move carefully. First I would like to know if >>>> people with relevant simulations get similar results. >>>> >>>> Feedback is therefore very welcome; I think everything needed >>>> to get started is documented on the page mentioned above. >>>> >>>> Jan >>>> >>> >>> The following are some notes at my attempt to use pypy on some of my >>> projects today. >>> >>> Jump to the Chase >>> ================= >>> My experience was mixed. Majority of my projects, simulations, utilize >>> numpy and other packages (matplotlib, etc). Most of these do not work >>> with pypy. Majority of my project simulations failed with pypy. I read >>> there are efforts to get numpy working with pypy. But it is unknown >>> when these would be available. Most of my active projects have some >>> dependency that failed and prevented the simulations from running with >>> pypy. >>> >>> Note: My testbenches utilize numpy and other common Python libraries. >>> The hardware descriptions do *not* use the libraries. >>> >>> >>> Disclaimer >>> ========== >>> I did not set out to run a set of simulations to preform similar task >>> that Jan Decaluwe did in his excellent write-up. But rather test pypy >>> against existing projects (in existing states) and record the results >>> with minimal modifications and effort. Other than getting the >>> *existing* simulations to run no additional work was performed to create >>> a good test suite. >>> >>> >>> Notes on Installing pypy >>> ======================== >>> I usually work on an ancient mac and pypy1.5 is available through >>> macports. Should be easy to install ... >>> >>> ``>> port install pypy`` >>> >>> But, it failed to build and it wasn't clear why, next step try building >>> from the source, binaries not available for my machine. This was >>> confusing. The pypy installing PYPY page_ has instructions where to get >>> the source (tarball or hg). But then jumps to testing the install and >>> not the actual act of installing? >>> >>> .. _page: pypy.org/download.html#install >>> >>> But installing on the Ubuntu box was pretty straight forward. Download >>> the binaries and off you go. The simulations were attempted on an >>> Ubuntu system. Verified pypy worked. >>> >>> >>> Simulations >>> =========== >>> As discussed, the first couple simulations I tried failed because of the >>> unsupported dependencies. Which required some investigation on the >>> failures and possible solutions. At this time there is no solution for >>> the numpy and company other than rewriting the simulations, not to use >>> numpy. The following is the list of my projects I attempted to run with >>> pypy. Most of these are described on the myhdl wiki. >>> >>> 1. Recursive FFT (failed, numpy) >>> 2. GnuRadio Compatible USRP CIC Filter (failed, numpy) >>> 3. Fixed-Point SOS (failed, numpy) >>> 4. USBP (FX2 USB Interface) (failed in myhdl??) >>> >>> All in all, I could not get any of them to run with pypy? Some were >>> expected but some were not. >>> >>> >>> Summary >>> ======= >>> I think pypy is very promising but there are some limitations. I don't >>> know how many others would be affected by the limitations but for me it >>> was fairly severe. But I also need to devote some more time resolving >>> the non-dependency issues and working through those. I look forward to >>> the day more packages are supported by pypy! >>> >>> Chris Felton >> >> Chris, >> >> it seems that you are not the only one who'd like to get numpy to work >> with pypy. Check these two posts on the pypy blog: >> >> http://morepypy.blogspot.com/2011/05/numpy-in-pypy-status-and-roadmap.html >> http://morepypy.blogspot.com/2011/06/report-back-from-our-survey.html >> >> In short, they know this is important, they have a plan on how to >> proceed, they believe they can make numpy even faster than it is, but >> they don't have many resources allocated to the task (yet?). >> >> So I think we can be cautiously optimist that this problem will be >> solved eventually. >> >> In the meantime I'd love to know if your projects work when you remove >> the numpy stuff. >> >> Angel > > I imagine I could get them to work without the numpy. I really only use > the numerical packages to create the input signals and analyze the > output signals. A bunch of it is for analyzing the response, creating > psd plots, etc. If I remove a bunch of the post-simulation analysis I > should be able to reproduce the signal generation with lists and the > basic Python math libs. At that point I could measure the speed > improvements with pypy. > > Thanks for the links! > > Chris > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > Someone posted the following story to the python subreddit: http://www.reddit.com/r/Python/comments/httng/pypy_gives_massive_speed_boost_to_myhdl/ There is already a question asking whether someone uses MyHDL for serious work. I think it is an excellent opportunity to let people now that MyHDL can be used instead of the regular VHDL or Verilog workflow :-) Angel |
|
From: Christopher F. <chr...@gm...> - 2011-06-09 11:12:18
|
<snip> > > > Simulations > =========== > As discussed, the first couple simulations I tried failed because of the > unsupported dependencies. Which required some investigation on the > failures and possible solutions. At this time there is no solution for > the numpy and company other than rewriting the simulations, not to use > numpy. The following is the list of my projects I attempted to run with > pypy. Most of these are described on the myhdl wiki. > > 1. Recursive FFT (failed, numpy) > 2. GnuRadio Compatible USRP CIC Filter (failed, numpy) > 3. Fixed-Point SOS (failed, numpy) > 4. USBP (FX2 USB Interface) (failed in myhdl??) > > All in all, I could not get any of them to run with pypy? Some were > expected but some were not. > > Ok, I *learnt* something since yesterday. First, pypy will not work on my PPC Mac. I should have realized this right away, the JIT is for x86 only (correct?). But the surprising thing is that python is crazy slow on my PPC-Mac (circa 2003). I am running py27 with the latest trunk myhdl. py27 installed with macports (port install) To get another system in the mix I stole my wifes laptop which can run pypy (side note, how quickly things can be setup with MyHDL/Python). Also, my non-numpy simulations, yesterday, were failing. They failed, because I was using the traceSignals (?). When I removed the traceSignals function I was able to run two of the simulations with pypy :) Below is a table of execution times for the different simulations. +---------+---------+----------+-----------+----------+----------+ | | OSX-CPy | OSXi-CPy | OSXi-pypy | Ubu-CPy | Ubu-pypy | +---------+=========+==========+===========+==========+==========+ | rFFT | 10m.52s | 4m.6s | failed* | 4m.36s | failed* | +---------+---------+----------+-----------+----------+----------+ | CIC | tbr | tbr | failed* | tbr | failed* | +---------+---------+----------+-----------+----------+----------+ | USBP | tbr | 4m.30s | 2m.20s | 4m.50s | 2m.28s | +---------+---------+----------+-----------+----------+----------+ | LED | 30m.4s | 15m.15s | 2m.10s | 16m.13s | 1m.59s | +---------+---------+----------+-----------+----------+----------+ * failed due to the numpy dependency System configurations OSX - Dual 2GHz PPC G5, 4.5GiB RAM, OS X 10.5.8 OSXi - 2.26GHz Intel Core 2 Duo, 2GiB RAM, OS X 10.6.7 Ubu - AMD Athlon LE1620 1.7GiB RAM, Ubuntu (natty) The relevant information here is the ~2x increase and ~8x increase with pypy. Hope this is useful. Chris Felton |
|
From: Ben <ben...@gm...> - 2011-06-09 20:56:40
|
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. Great work to all who allowed that to happen ! Benoît |
|
From: Jan D. <ja...@ja...> - 2011-06-09 21:32:39
|
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? 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 |
|
From: Ben <ben...@gm...> - 2011-06-09 22:47:04
|
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 |
|
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 |
|
From: Jan D. <ja...@ja...> - 2011-06-09 16:24:10
|
On 06/09/2011 05:30 PM, Angel Ezquerra wrote: > Jan, any idea why calling traceSignals would fail? Actually yes, for the same reason why conversion doesn't work with PyPy 1.5. The hierarchy extractor reuses the Python profiler, and there is a bug in PyPy with it. I had found that while trying conversion, and reported it. It's fixed in PyPy development. I will add this info to the page on myhdl.org. I see our experiments as a preparation for PyPy 1.5.1 when hopefully everything will work (don't know about numpy) with perhaps some additional speed boost. Also, now that it was worth the trouble, I have rewritten some parts of the Signal handling considerably in 0.8-dev, with a significant speed boost (independent of PyPy) for some simulation. Also worth trying out. 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 |
|
From: Angel E. <ezq...@gm...> - 2011-06-09 15:30:21
|
On Thursday, June 9, 2011, Christopher Felton <chr...@gm...> wrote: > <snip> >> >> >> Simulations >> =========== >> As discussed, the first couple simulations I tried failed because of the >> unsupported dependencies. Which required some investigation on the >> failures and possible solutions. At this time there is no solution for >> the numpy and company other than rewriting the simulations, not to use >> numpy. The following is the list of my projects I attempted to run with >> pypy. Most of these are described on the myhdl wiki. >> >> 1. Recursive FFT (failed, numpy) >> 2. GnuRadio Compatible USRP CIC Filter (failed, numpy) >> 3. Fixed-Point SOS (failed, numpy) >> 4. USBP (FX2 USB Interface) (failed in myhdl??) >> >> All in all, I could not get any of them to run with pypy? Some were >> expected but some were not. >> >> > > Ok, I *learnt* something since yesterday. First, pypy will not work > on my PPC Mac. I should have realized this right away, the JIT is > for x86 only (correct?). But the surprising thing is that python > is crazy slow on my PPC-Mac (circa 2003). I am running py27 with > the latest trunk myhdl. py27 installed with macports (port install) > To get another system in the mix I stole my wifes laptop which can > run pypy (side note, how quickly things can be setup with MyHDL/Python). > > Also, my non-numpy simulations, yesterday, were failing. > They failed, because I was using the traceSignals (?). When I > removed the traceSignals function I was able to run two of the > simulations with pypy :) > > Below is a table of execution times for the different simulations. > > +---------+---------+----------+-----------+----------+----------+ > | | OSX-CPy | OSXi-CPy | OSXi-pypy | Ubu-CPy | Ubu-pypy | > +---------+=========+==========+===========+==========+==========+ > | rFFT | 10m.52s | 4m.6s | failed* | 4m.36s | failed* | > +---------+---------+----------+-----------+----------+----------+ > | CIC | tbr | tbr | failed* | tbr | failed* | > +---------+---------+----------+-----------+----------+----------+ > | USBP | tbr | 4m.30s | 2m.20s | 4m.50s | 2m.28s | > +---------+---------+----------+-----------+----------+----------+ > | LED | 30m.4s | 15m.15s | 2m.10s | 16m.13s | 1m.59s | > +---------+---------+----------+-----------+----------+----------+ > * failed due to the numpy dependency > > System configurations > OSX - Dual 2GHz PPC G5, 4.5GiB RAM, OS X 10.5.8 > OSXi - 2.26GHz Intel Core 2 Duo, 2GiB RAM, OS X 10.6.7 > Ubu - AMD Athlon LE1620 1.7GiB RAM, Ubuntu (natty) > > The relevant information here is the ~2x increase and ~8x increase > with pypy. > > Hope this is useful. > > Chris Felton Awesome, thanks for the info. Sonit seems that when it works the speedup is significant! Jan, any idea why calling traceSignals would fail? Angel |
|
From: Angel E. <ezq...@gm...> - 2011-06-09 16:38:29
|
On Thursday, June 9, 2011, Jan Decaluwe <ja...@ja...> wrote: > On 06/09/2011 05:30 PM, Angel Ezquerra wrote: > >> Jan, any idea why calling traceSignals would fail? > > Actually yes, for the same reason why conversion doesn't > work with PyPy 1.5. The hierarchy extractor reuses the > Python profiler, and there is a bug in PyPy with it. I had found > that while trying conversion, and reported it. It's > fixed in PyPy development. I will add this info to the > page on myhdl.org. > > I see our experiments as a preparation for PyPy 1.5.1 > when hopefully everything will work (don't know about numpy) > with perhaps some additional speed boost. > > Also, now that it was worth the trouble, I have rewritten > some parts of the Signal handling considerably in 0.8-dev, > with a significant speed boost (independent of PyPy) for some > simulation. Also worth trying out. > > Jan Cool! Does that mean that with ploy 1.5.1 both tracesignals and conversion will work? Angel |
|
From: Jan D. <ja...@ja...> - 2011-06-09 19:41:39
|
On 06/09/2011 06:38 PM, Angel Ezquerra wrote: > On Thursday, June 9, 2011, Jan Decaluwe<ja...@ja...> wrote: >> On 06/09/2011 05:30 PM, Angel Ezquerra wrote: >> >>> Jan, any idea why calling traceSignals would fail? >> >> Actually yes, for the same reason why conversion doesn't >> work with PyPy 1.5. The hierarchy extractor reuses the >> Python profiler, and there is a bug in PyPy with it. I had found >> that while trying conversion, and reported it. It's >> fixed in PyPy development. I will add this info to the >> page on myhdl.org. >> >> I see our experiments as a preparation for PyPy 1.5.1 >> when hopefully everything will work (don't know about numpy) >> with perhaps some additional speed boost. >> >> Also, now that it was worth the trouble, I have rewritten >> some parts of the Signal handling considerably in 0.8-dev, >> with a significant speed boost (independent of PyPy) for some >> simulation. Also worth trying out. >> >> Jan > > Cool! > > Does that mean that with ploy 1.5.1 both tracesignals and conversion will work? My working hypothesis is that with PyPy 1.5.1, MyHDL will work exactly as with cPython. Jan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X