- Glasgow-haskell-users

RE: Hardware STG?
by Simon Peyton-Jones 28 Aug '02

28 Aug '02

Think carefully first! Lots of people tried this in the 80's. To beat generic (but high-investment) microprocessors you need to find a factor or 10 or so improvement in the basic architecture, and that is hard to find. The STG machine is designed to be ok for stock hardware, but it's not specialised for stock hardware, so there's no reason it's a bad base for specialised hardware. No, Tcode is very old. We use some different byte-code for the GHCi byte code, but it is designed for easy compilation rather than fast execution. For fast execution we compile to native code, or to C, or (soon I hope) C--. Simon | -----Original Message----- | From: MR K P SCHUPKE [mailto:k.schupke@ic.ac.uk] | Sent: 21 August 2002 16:32 | To: glasgow-haskell-users | Subject: Hardware STG? | | | Hi, | I am looking into starting a project on special hardware to run | haskell - (or perhapse any | lazy functional hardware)... If I go ahead the project will | result in an | open VHDL implementation. I would like to ask a couple of questions. | | Is there any point in doing this as the STG-machine is | designed to | make running haskell | efficient on standard hardware? | | is TCode and the byte code used by GHCi the same? | | finally, does anyone know of any implementations that | have already | been attempted, | and how successful were they? Any general comments on how | worthwhile this might | be? | | Regards, | Keean Schupke | Department of Electrical & Electronic Engineering, | Imperial College London. | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

2 1

Re: Question about error message
by Paulo Sequeira 27 Aug '02

27 Aug '02

Seth, I'm really bad in optimization issues. To be honest, I have almost no serious experience using Haskell, so I have never faced the task to build an application for which it was crucial optimization either in space or time. On the other hand, I have assimilated the idea that you can't put Haskell programs compete with analogous versions in C++ in space/time usage. I think that if you try to convince someone that programming in Haskell is better than doing it in C++ based these metrics, you lost before starting. Haskell's beauty is somewhere else. Try to find mundane problems in which Haskell can do better than others solving them. For example, I participated in some parts of the design and implementation an n-tier system using, among other things, Visual Basic. When we came to write the code for the data access components in the data services tier, we discovered that much of the work was repetitive and boring: just look at the stored procs' signatures and map them into VB procedures. It was clear that what we needed was an utility that could process some database metadata and produced VB code. I you were considering implementing it yourself, which language would you choose? (Certainly, I wouldn't pick VB ;) ) Good luck. Paulo. ----- Original Message ----- From: Seth Kurtzberg <seth(a)cql.com> To: Paulo Sequeira <otro_paulo(a)hotmail.com> Sent: Monday, August 26, 2002 9:32 AM Subject: Re: Question about error message > Paulo, > > Yes you are correct. I actually found another way to do it which is similar > but not quite as good; I'll paste it in below. The program doesn't do > anything useful; I was trying to use it to compare execution times for a > compiled Haskell program to a compiled C program. By the time I stopped > optimizing it it runs in about 1.5 seconds, so it isn't of much use as a > performance test, but I learned a lot coding it. The C++ version is running > about 30 times faster, but I suspect that a lot of that difference is startup > time and I'll need longer running times to make a valid comparison. Also, > the actual printing of the results, which is really irrelevant (to the > situation where I'm trying to convince one of my clients to use Haskell), > probably takes a lot of the running time. I'm going to change this to just > dump the binary results to a file and see what that does to the running > times. > > If you happen to see any obvious way to get this to run faster, let me know. > > Thanks again for your time and efforts. > > import System > import IO > import Data.List > > solutionString (a,b,c,d,e,f,g,h,i,j) = > concat["sum=", (show (a+d+e)), > ", values= ", > (show a), ", ", > (show d), ", ", > (show e), ", ", > (show b), ", ", > (show f), ", ", > (show g), ", ", > (show c), ", ", > (show h), ", ", > (show i), ", ", > (show j), "\n" ] > > validCorner x y z = > cornerSum >= 6 && cornerSum <= 48 && ((cornerSum `mod` 6) == 0) > where cornerSum = (x+y+z)*2 > > solutionList = > [(a, b, c, d, e, f, g, h, i, j) | > a <- [0..9], > b <- [0..9], b /= a, > c <- [0..9], c /= b, c /= a, > (validCorner a b c), > d <- [0..9], d /= a, d /= b, d /= c, > e <- [0..9], e < d, e /= c, e /= b, e /= a, > f <- [0..9], f /= e, f /= d, f /= c, f /= b, f /= a, > g <- [0..9], f < g, g /= e, g /= d, g /= c, g /= b, g /= a, > h <- [0..9], h /= g, h /= f, h /= e, h /= d, h /= c, h /= b, h /= a, > i <- [0..9], h < i, i /= g, i /= f, i /= e, i /= d, i /= c, i /= b, i /= > a, > j <- [0..9], i < j, j /= h, j /= g, j /= f, j /= e, j /= d, j /= c, j /= > b, j /= a, > (a+d+e+b) == (a+f+g+c), > (a+d+e+b) == (b+c+h+i+j) ] > > main = > (putStr . concat . map solutionString) solutionList > > > On Sunday 25 August 2002 22:38, you wrote: > > Seth, > > > > At last, I can have some time to view your question with care. I'm replying > > to you, and not the list, because I'm not sure to be understanding exactly > > what is it that you need; this way, we will avoid introducing some noise > > into the list by posting "Is this what you asked?" mails. Later, we can > > post a message that summarizes the dialogue and the answer. > > > > ----- Original Message ----- > > From: Seth Kurtzberg <seth(a)cql.com> > > Sent: Tuesday, August 20, 2002 1:45 AM > > > > > ... > > > > > > I was trying to follow the basic pattern for coding a recursive function, > > > where you give a pattern for, say, f (x:[]), and you then give a pattern > > > > for > > > > > (x:xs) where xs is then used as the argument for a recursive call (as in > > > "f xs"). > > > > I'm not sure if this is intentional, but there is a case missing here: f [] > > In case you want to, you can rewrite displaySolutions to cope whith it this > > way: > > > > displaySolutions [] = return () -- the "do nothing" > > displaySolutions (x:xs) = displayOneSolution x >> displaySolutions xs > > > > or > > > > displaySolutions [] = return () -- the "do nothing" > > displaySolutions (x:xs) = do displayOneSolution x; displaySolutions xs > > > > > The following is how I now understand it; let me know if this is > > > > fundamentally > > > > > incorrect (and thanks for taking the time to read it). > > > > > > ... > > > > > > The problem is that the examples I was looking at use something like > > > (some calculation with x) * f xs, or + f xs, or some variation where "f > > > xs" is > > > > used > > > > > within a single expression. > > > > This pattern looks like the one foldr captures. Indeed, you can rewrite > > displaySolutions in this way. > > > > displaySolutions xs = foldr ((>>) . displayOneSolution) (return ()) xs > > > > > I see, now, that you need the combinator if > > > there is more than one expression, and that this is not related to > > > whether the expression uses monads. > > > > > > So, is there a way to code this without resorting to the combinator? I > > > > could > > > > > have "displayOneSolution" return "displaySolutions", and then do this (I > > > think): > > > > > > (displayOneSolution x) xs > > > > > > but that would just move the combinator out of displaySolutions and into > > > displayOneSolution. Or am I looking for something that doesn't exist; > > > > that > > > > > is, the combinator is the best way to code this pattern? > > > > What I understand is that you have a list of solutions you want to display, > > one after another. For this, you should traverse the list, one element > > after another, applying the displayOneSolution function in order to build > > an action that do precisely what the name implies. > > > > This can be viewed as having a sequence of actions (display solutions) to > > be performed, one after another. Declaratively, you can understand this as > > having a list of actions that you combine using a sequencing operator. The > > end result is that you have a compound action that is the sequencing of the > > simpler actions of displaing a solution. > > > > If I'm correct in all this, then the answer is that you cannot avoid the > > use of the combinator: it is the part that allows you to sequence the > > actions. Anyway, it seems that displaySolutions has a pattern that is > > captured by sequence_; so, if you ask me, I would code it this way: > > > > displaySolutions xs = sequence_ (map displayOneSolution xs) > > > > which can be transformed also into > > > > displaySolutions = sequence_ . (map displayOneSolution) > > > > Well, we didn't have to use the combinator after all (it is used in > > sequence_). > > > > I tend to choose the second form, although I'm not sure if it is clear and > > easily understandable. What do you think? > > > > Paulo. > > -- > ----------------------------------- > Seth Kurtzberg > M. I. S. Corp. > 1-480-661-1849 >

1 0

RE: genprimopcode segfaulting in Gentoo ebuild
by Simon Marlow 23 Aug '02

23 Aug '02

> I have just received a bug report for the Gentoo Linux ebuild of GHC > 5.04 whose cause I cannot find. Recall that Gentoo builds all packages > from sources. > > The build processes stops when genprimopcode segfaults during the last > stage of the build (GHC 5.04 building itself). > > Anyone interested please look at > > http://bugs.gentoo.org/show_bug.cgi?id=6352 > > for the complete Bugzilla entry which has all available details, > including an strace of the segfaulting genprimopcode. I'm afraid nothing springs to mind - but I do recall that genprimopcode is perhaps the first Haskell binary to be executed in a bootstrapped tree, so it could be just that the stage 2 compiler is building consistently broken binaries. That should be easy to verify. The next stage is to try to debug it. Compile up the runtime system (in the compiler tree that is generating broken code) with the debugging options (see mk/config.mk for details). Compile up something that crashes, investigate with gdb, and we'll take it from there. Cheers, Simon

1 0

RE: --without-happy
by Simon Marlow 23 Aug '02

23 Aug '02

> One more thing: > > The GHC source distribution contains the Happy-generated parsers. This > means that to build from a source tarball, Happy is not required. > Unfortunately the configure script checks for it and aborts > if it's not > found. > > To counter the problem in the Gentoo ebuilds, I apply the > attached patch > to the source. I think it would be a good idea to incorporate this or > something similar (ideally, configure should be able to detect the > prebuilt-parsers and skip the check). I believe this was fixed in 5.04. The configure script now checks for the existence of the pre-generated parser before complaining about a missing Happy. Cheers, Simon

1 0

RE: gcc 3
by Simon Marlow 23 Aug '02

23 Aug '02

> can anybody say something about support for gcc 3 as a > backend to GHC? I > heard from Ralf (see Cc) that it currently does not work. What is the > cause of this, and will it be fixed? The reason it's coming up is that > Gentoo Linux is slowly moving towards a release with GCC 3.2 as its > default compiler. A parallel install of GCC 2 will be supported, but > depending on it would of course not be as nice as one would like. > > Also, I assume the old 4.08 .hc files from which we're bootstrapping > can't be compiled by GCC 3 either. Will you produce a new set once the > compiler supports GCC 3? I guess I could try to produce one myself > otherwise, though. GCC 3 works fine with GHC on x86. On Sparc, we had a couple of problems that were sorted out post-5.04 and the fixes will be in 5.04.1. None of this affects .hc files themselves - any problems are generally confined to the Evil Mangler(TM). So although the 4.08 .hc files should still work fine, you might need to back-port some of the fixes to the mangler into 4.08 in order to bootstrap. Cheers, Simon

1 0

--without-happy
by Sven Moritz Hallberg 22 Aug '02

22 Aug '02

One more thing: The GHC source distribution contains the Happy-generated parsers. This means that to build from a source tarball, Happy is not required. Unfortunately the configure script checks for it and aborts if it's not found. To counter the problem in the Gentoo ebuilds, I apply the attached patch to the source. I think it would be a good idea to incorporate this or something similar (ideally, configure should be able to detect the prebuilt-parsers and skip the check). Thanks for your time, Sven Moritz PS: The patch command should be patch -d /path/to/ghc-5.04/ -p 1 < without-happy-patch

1 0

gcc 3
by Sven Moritz Hallberg 22 Aug '02

22 Aug '02

Hi, can anybody say something about support for gcc 3 as a backend to GHC? I heard from Ralf (see Cc) that it currently does not work. What is the cause of this, and will it be fixed? The reason it's coming up is that Gentoo Linux is slowly moving towards a release with GCC 3.2 as its default compiler. A parallel install of GCC 2 will be supported, but depending on it would of course not be as nice as one would like. Also, I assume the old 4.08 .hc files from which we're bootstrapping can't be compiled by GCC 3 either. Will you produce a new set once the compiler supports GCC 3? I guess I could try to produce one myself otherwise, though. Thanks, Sven Moritz PS: If you would like to mention GHC 5.04's availability in Gentoo, you now finally can. The new ebuild has been tested and unmasked in the official distribution.

1 0

HDirect for GHC 5.04
by Paul Moore 22 Aug '02

22 Aug '02

Is there a version of HDirect available for GHC 5.04? Ideally a binary distribution, but if source is available with step-by-step instructions on building and installing it (I'm most definitely *not* an expert in such things!), then that would do as well. My reason for wanting this is to be able to try driving COM components from Haskell, as described in the "Calling Hell From Heaven And Heaven >From Hell" document. I assume HDirect is the best way of doing this? I looked through recent posts on the list, and couldn't see any information on this... Thanks for any help, Paul Moore. PS A long while back, I played with HaskellScript. Looking at the site, it hasn't been updated in a long while. Is HaskellScript dead, and if so is there anything which covers the same functionality for GHC (particularly the COM libraries etc - I'm not that bothered about the WSH support). Or is that what HDirect covers?

2 6

Hardware STG?
by MR K P SCHUPKE 21 Aug '02

21 Aug '02

Hi, I am looking into starting a project on special hardware to run haskell - (or perhapse any lazy functional hardware)... If I go ahead the project will result in an open VHDL implementation. I would like to ask a couple of questions. Is there any point in doing this as the STG-machine is designed to make running haskell efficient on standard hardware? is TCode and the byte code used by GHCi the same? finally, does anyone know of any implementations that have already been attempted, and how successful were they? Any general comments on how worthwhile this might be? Regards, Keean Schupke Department of Electrical & Electronic Engineering, Imperial College London.

1 0

genprimopcode segfaulting in Gentoo ebuild
by Sven Moritz Hallberg 21 Aug '02

21 Aug '02

Hi, I have just received a bug report for the Gentoo Linux ebuild of GHC 5.04 whose cause I cannot find. Recall that Gentoo builds all packages from sources. The build processes stops when genprimopcode segfaults during the last stage of the build (GHC 5.04 building itself). Anyone interested please look at http://bugs.gentoo.org/show_bug.cgi?id=6352 for the complete Bugzilla entry which has all available details, including an strace of the segfaulting genprimopcode. Thanks, Sven Moritz Hallberg

1 0