Hi, So I'm interested in working on the project on improving numerics performance in GHC proposed on the SoC page here http://hackage.haskell.org/trac/summer-of-code/ticket/13 Since I have a full time job, I'd just like to do this on my own time rather than take up an SoC slot. In that vein, Don Stewart suggested that the first thing to do was check out the most recent ghc code from darcs and build it. Well, I've been getting the same problems as here http://hackage.haskell.org/trac/ghc/ticket/715 and I was wondering if anyone knew of a workaround or if we could figure out an environment set up that *could* build ghc correctly. Thanks, Creighton Hogg
Hello Creighton, Thursday, May 4, 2006, 10:00:55 PM, you wrote:
So I'm interested in working on the project on improving numerics performance in GHC proposed on the SoC page here http://hackage.haskell.org/trac/summer-of-code/ticket/13
which states "GHC's performance for double and float intensive code is not as good as it could be. Find out why and improve it. Requires GHC backend hacking. Must be very Haskell literate or have knowledge of code generators." i can't agree with this statement - source of problem is well known, it's an inefficient STG-to-asm translation. and we know two ways to solve this problem - either translate STG to idiomatic C code, as jhc does and then rely on perfect GCC optimization, or make STG-to-asm translation more efficient. last time it was discussed here in Feb'06 in general, it's too complex problem, otherwise Simons may already work on it, because current ghc-generated code is, say, 3 times slower than it could be. this sort of optimization will change performance for any program, not only numeric-intensive ones. one possible rather simple sub-project may be dealing with "leaf" functions with strict arguments and results - i'm not sure but it's possible that implementing this optimization will make significant shift exactly in numeric intensive code. to decide this, it will be great to see this "numeric intensive code" for beginning -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
| in general, it's too complex problem, otherwise Simons may already work | on it, because current ghc-generated code is, say, 3 times slower than | it could be. Thank you for believing in our expertise, but you should not assume that something we have not done is necessarily very difficult. GHC has a huge surface area these days, so we spend a lot of time just keeping everything working. Then we are researchers too (e.g. Simon M is on the ICFP program committee) -- maintaining GHC isn't even our real job. As a result there are many not-very-hard jobs that we simply do not get around to. (I don't know if this is one of them, though.) So I say an enthusiastic Yes to anyone who's willing to jump in and start helping. We need more people familiar with GHC's innards. Simon
On 5/5/06, Simon Peyton-Jones
| in general, it's too complex problem, otherwise Simons may already work | on it, because current ghc-generated code is, say, 3 times slower than | it could be.
Thank you for believing in our expertise, but you should not assume that something we have not done is necessarily very difficult. GHC has a huge surface area these days, so we spend a lot of time just keeping everything working. Then we are researchers too (e.g. Simon M is on the ICFP program committee) -- maintaining GHC isn't even our real job.
As a result there are many not-very-hard jobs that we simply do not get around to. (I don't know if this is one of them, though.)
So I say an enthusiastic Yes to anyone who's willing to jump in and start helping. We need more people familiar with GHC's innards.
Well I'm going to take you up on that enthusiastic yes. In order to get familiar with GHC's innards, is there anything particular I should begin with? At the moment I'm just reading through the user's guide. Cheers, Creighton Hogg
Hello Creighton, Friday, May 5, 2006, 8:50:18 PM, you wrote:
In order to get familiar with GHC's innards, is there anything particular I should begin with? At the moment I'm just reading through the user's guide.
i suggest you to read discussion i already mentioned. and also papers: http://www.haskell.org/ghc/docs/papers/unboxed-values.ps.gz http://www.haskell.org/ghc/docs/papers/run-time-system.ps.gz http://www.haskell.org/ghc/docs/papers/new-rts.ps.gz http://www.research.microsoft.com/~simonpj/Papers/inlining/inline-jfp.ps.gz ps: Simons will not answer before Monday -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
The most straightforward thing to do is not to build the OpenAL package. I'm sure Sven is working on fixing it, but meanwhile it's entirely inessential. Simply edit the libraries/Makefile. Simon ________________________________ From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Creighton Hogg Sent: 04 May 2006 19:01 To: GHC Users Mailing List Subject: Building head & numerics project Hi, So I'm interested in working on the project on improving numerics performance in GHC proposed on the SoC page here http://hackage.haskell.org/trac/summer-of-code/ticket/13 Since I have a full time job, I'd just like to do this on my own time rather than take up an SoC slot. In that vein, Don Stewart suggested that the first thing to do was check out the most recent ghc code from darcs and build it. Well, I've been getting the same problems as here http://hackage.haskell.org/trac/ghc/ticket/715 and I was wondering if anyone knew of a workaround or if we could figure out an environment set up that *could* build ghc correctly. Thanks, Creighton Hogg
Am Freitag, 5. Mai 2006 09:13 schrieb Simon Peyton-Jones:
The most straightforward thing to do is not to build the OpenAL package. I'm sure Sven is working on fixing it, but meanwhile it's entirely inessential. Simply edit the libraries/Makefile.
I've already fixed the ALUT package, but I'd like to do some more testing before I commit the changes. The OpenAL package will be the next thing I'll have a look at. The problems resulted from unstable specifications, but the good thing is that the specs for both OpenAL and ALUT are quite stable now. Hopefully all the distros out there will follow soon with shiny new stable packages... :-] Editing the Makefile should not be necessary, --disable-openal or --disable-alut (whatever fails) during configurationtime should be enough. Cheers, S.
participants (4)
-
Bulat Ziganshin -
Creighton Hogg -
Simon Peyton-Jones -
Sven Panne