ghc-6.6.1 win32 msi available
In case anyone's interested, http://www.galois.com/~sof/msi/ghc-6-6-1.msi contains a Windows installer for 6.6.1; most (all?) libraries/ are in there; no C++ bits (sorry.) enjoy --sigbjorn [And, if it's your preference, a ghc-6-6-1.zip is also available from that same dir.] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
problems using ghc-6.6.1 (due to fgl-5.4.1)
I wrote: > Dear Hets- and GHC-Developers, > we have a problem using ghc-6.6.1. The created hets binary runs a > couple > of times slower than the one created using ghc-6.6. This problem is gone when I install and use fgl-5.3 (where "hiding (indices)" needs to be deleted in Data.Graph.Inductive.Monad.IOArray). I strongly suspect the new functions context1l' and context4l' in Data.Graph.Inductive.Graph (fgl-5.4.1) to be the reason for our drastic slow down. In fgl-5.3 the functions fst4 and fth4 have been used instead. A cyclic edge (an edge from and to the very same node) was only returned as ingoing edge and not as outgoing one. (a design decision documented elsewhere). I think, the change in fgl-5.4.1 now returns a cyclic edge also as outgoing edge (and possibly twice as ingoing one). Our application heavily uses in- and outgoing edges that may be cyclic. Christian P.S. ghc-6.6.1/libraries/fgl/Setup.hs does not compile with ghc-6.6.1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
Hi So I want to know "What version of MinGW do you use?" and "Is your MinGW has C++ files?" None, I don't have it installed. I took the binaries straight from the GHC 6.6.1 .tar.bz on haskell.org, I guess Ian would know how they build that. I think these tasks are easy, and they don't become bottleneck to release installer. As before, its not something I have any power over. GHC 6.6's installer (MSI) has three Installation Mode, Typical, Custom, Complete. These mode doesn't work GHC 6.6's one, but some other installer uses these Installation Mode, to suport install options. I'll add that, its not overly hard, but I want something functional, robust and now. For the next version you'll have options over what to install. Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
SMP question
Some days ago I sent an email to the list asking about the reason why I couldn't run my programs with the "-Nx" RTS option even if I compiled them with -threaded. AH! by the way, the architecture is ia64 (Itanium). Today I realized that when I ./configure, a preprocessor variable called "NOSMP" is defined and it disallows the multiple OS threads (the -Nx option). Looking a bit deeper I figured out that there's no Itanium version for the functions xchg (exchange), cas (compare-and-swap) and write_barrier in the header file SMP.h (includes/SMP.h) so there's no way that the holy -N option is available. My question is: is it enough to implement xchg, cas and write_barrier for ia64 to make multiple OSthreads available on ia64? If not, what else should be implemented/changed? Regards. Cristian Perfumo ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: problems using ghc-6.6.1
You seem to be generating 8x the garbage with the 6.6.1 version which could account for the 2x slowdown. On May 8, 2007, at 2:19 PM, Christian Maeder wrote: ghc-6.6.1: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 1979.05 secs (39581 ticks @ 50 ms) total alloc = 167,752,167,576 bytes (excludes profiling overheads) -- http://wagerlabs.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
problems using ghc-6.6.1
Dear Hets- and GHC-Developers, we have a problem using ghc-6.6.1. The created hets binary runs a couple of times slower than the one created using ghc-6.6. (see below) What might be the cause for this? Cheers Christian ghc-6.6.1: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 1979.05 secs (39581 ticks @ 50 ms) total alloc = 167,752,167,576 bytes (excludes profiling overheads) COST CENTREMODULE %time %alloc selectProofBasis Proofs.EdgeUtils 82.8 86.1 sl_signCASL.Sublogic 5.33.7 compInclusion Logic.Grothendieck 3.23.2 getAllPathsOfTypesBetween Proofs.EdgeUtils 1.51.6 isSubOpMap CASL.Sign 1.20.9 primCoerce Logic.Coerce 0.81.1 ghc-6.6: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 215.25 secs (4305 ticks @ 50 ms) total alloc = 20,691,103,008 bytes (excludes profiling overheads) COST CENTREMODULE %time %alloc selectProofBasis Proofs.EdgeUtils 73.1 79.6 sl_signCASL.Sublogic 6.84.2 compInclusion Logic.Grothendieck 3.73.8 getAllPathsOfTypesBetween Proofs.EdgeUtils 2.83.1 isSubOpMap CASL.Sign 1.61.1 sublogics_join CASL.Sublogic 1.51.1 primCoerce Logic.Coerce 1.31.4 isSameTranslation Proofs.Local 1.20.9 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
On Tue, 08 May 2007 19:04:33 +0900, Neil Mitchell <[EMAIL PROTECTED]> wrote: >> You forgot to include GLUT and readline packages. >> I think you can't build these packages, so you don't include it. > > I have built an installer for the binary package produced by the GHC > Team, including whatever they included, and excluding whatever they > excluded. If the GHC Team change their build so these are built, I > will happily include whatever they tell me. It's wrong about buildable packages and C++ files. First, "make binary-dist" includes these packages in binary distribution if you can build theirs. GHC 6.4 and GHC 6.6.1 or above installers include theirs. And if you can build OpenAL and ALUT, you can include these packages to your installer. Second, I can include C++ files (except header files) in binary by "make binary-dist" command with MinGW-4.1.1. http://www.haskell.org/pipermail/glasgow-haskell-users/2007-April/012410.html http://www.haskell.org/pipermail/glasgow-haskell-users/2007-April/012413.html So I want to know "What version of MinGW do you use?" and "Is your MinGW has C++ files?" If you don't find C++ files in your MinGW directory, I think you probably choice not to install C++/g++ things. So if you find your MinGW doesn't include C++ files, you must install these files first. And then you try to use "make binary-dist" command and make installer again. >> There is no C++ files in your installer. >> But if anyone want to build C++ source code by GHC, he disappoint >> about that. > > As before, what goes in the package is someone elses choice. This > installer is intended as something quick to get a working installer > out the door. I'd like to think about beefing it up, offering extra > options (possibly C++ support) in the next version (i.e. 6.8, 6.6.2) So above tasks will be complete just checking and correcting your build enviornment. An lack is C++ header files, but you can fix this problem by changing to comment out or remove dist/prep-bin-dist-mingw's below line. rm -rf include/mingw/c++/ || echo "c++/ not there" I think these tasks are easy, and they don't become bottleneck to release installer. >> And can you add Installation Mode to your installer? > > There is already a silent install mode, /SILENT or /VERYSILENT do > something - but I have no idea what. Is that what you meant by > Installation Mode? GHC 6.6's installer (MSI) has three Installation Mode, Typical, Custom, Complete. These mode doesn't work GHC 6.6's one, but some other installer uses these Installation Mode, to suport install options. I want to say that. But that is difficult task, so I wait that for the next version. Best Regards, -- shelarcy http://page.freett.com/shelarcy/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why do we have stack overflows?
Simon Marlow wrote: I'm more than happy to change the defaults, if there's some agreement on what the defaults should be. The current choice is somewhat historical - we used to have a bound on both heap size and stack size, but the heap size bound was removed because we felt that on balance it made life easier for more people, at the expense of a bit more pain when you write a leaky program. Well in the light of what Stefan says about exponentially increasing stack size I'm not sure increasing (or removing) the default is the answer. Going from 16M to 32M to 64M stacks is bit drastic. It seems to me going up in sane sized linear increments would be better. But since we also want to avoid frequent copying of an already oversized stack I guess some linked list representation is what's needed. In fact I'd think what Stefan suggests or something very similar would be the way to go. But I have no idea how much work that would be. But to give programs best possible chance of running successfully then I think an (optional) overall limit on total memory use would be preferable (better than trying to guess how much stack space will be needed in advance). Regards -- Adrian Hey ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 Windows installer, test version
Hi You forgot to include GLUT and readline packages. I think you can't build these packages, so you don't include it. I have built an installer for the binary package produced by the GHC Team, including whatever they included, and excluding whatever they excluded. If the GHC Team change their build so these are built, I will happily include whatever they tell me. And can you add Installation Mode to your installer? There is already a silent install mode, /SILENT or /VERYSILENT do something - but I have no idea what. Is that what you meant by Installation Mode? There is no C++ files in your installer. But if anyone want to build C++ source code by GHC, he disappoint about that. As before, what goes in the package is someone elses choice. This installer is intended as something quick to get a working installer out the door. I'd like to think about beefing it up, offering extra options (possibly C++ support) in the next version (i.e. 6.8, 6.6.2) So I think we will become happy, if adding Installation Mode and maintain that on GHC's darcs repository. I'm still not entirely sure what you mean by this? Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why do we have stack overflows?
Adrian Hey wrote: John Meacham wrote: I believe it is because a stack cannot be garbage collected, and must be traversed as roots for every garbage collection. I don't think there are any issues with a huge stack per se, but it does not play nice with garbage collection so may hurt your performance and memory usage in unforeseen ways. I'm still not convinced :-( I also don't believe it's in anybodys interest to have programs failing for no good reason. A good reason to fail is if overall memory demands are getting stupid. Failing because the stack has grown beyond some arbitrary (and typically small) size seems bad to me. I know that this is to a certain extent this is controllable using RTS options, but this is no use to me as a library writer tying to chose between stackGobbler and heapGobbler. The stuff should "just work" and not be dependent on the right RTS incantations being used when the final program is run. I'm more than happy to change the defaults, if there's some agreement on what the defaults should be. The current choice is somewhat historical - we used to have a bound on both heap size and stack size, but the heap size bound was removed because we felt that on balance it made life easier for more people, at the expense of a bit more pain when you write a leaky program. Also, it used to be the case that the OOM killer could be a bit unpredictable, killing vital system processes instead of the leaky Haskell program. I'm not sure if this is still true for current OS incarnations. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why do we have stack overflows?
Stefan O'Rear wrote: On Thu, May 03, 2007 at 05:36:45PM -0700, Brandon Michael Moore wrote: On Thu, May 03, 2007 at 04:59:58PM -0700, John Meacham wrote: I believe it is because a stack cannot be garbage collected, and must be traversed as roots for every garbage collection. I don't think there are any issues with a huge stack per se, but it does not play nice with garbage collection so may hurt your performance and memory usage in unforeseen ways. Isn't it just the top of the stack that has to be treadted as a root? (maybe you need to walk the stack to find exception handlers and so on.) Maybe it shouldn't be so much worse than a heap. The Chicken Scheme system allocates everything on the C stack, and runs some sort of compacting collector when it is about to fill. GHC uses a simple exponential-backoff algorithm for handling stacks. When the stack pointer passes the stack limit, the thread yields to the scheduler, where the stack size is doubled, and the old stack is moved. Perhaps instead we could modify the algorithm such that up to 16K stack size the behaivor is the same, but use linked lists for larger? 1. Allocate a new chunk, of size 16KB. 2. Copy the topmost 1KB of stack to the new block. This decreases storage efficiency slightly (but not much in time - memcpy is several times faster than anything the current ghc code generator can generate), but it avoids a nasty corner case (stack size fluctuating across 0 mod 16K) by acting as a form of hysteresis. 3. Create a special frame at the bottom of the new stack chunk that returns into a stack underflow handler, thus avoiding the need for yet another conditional. GHC in the distant past (pre-4.0) had linked stack chunks, but we discarded the idea when the RTS was rewritten, mainly for simplicity. It was before my time, so I don't know all the war stories, but I think it turned out to be hairy enough to avoid it in the redesign. At least it would require separate TSO and STACK objects, the underflow frame, code to avoid performance degradation at the boundary (e.g. as you say, copy the top 1k of stack to the new chunk), stack walking gets more complicated (several places in the RTS do this). My impression is that the performance of stack growth isn't usually a limiting factor, so I'm not sure it's worth adding this complexity. Benchmarks can be convincing, though... Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
