Re: Compiling large source files
Gunther should first check if he thinks this is the same issue as http://hackage.haskell.org/trac/ghc/ticket/2002 (looks similar to me) If it is, he could just add comments there. Simon Peyton-Jones wrote: Gunther Could you make a Trac bug report for this, and attach your source file? It'd help if you could first check that things are still bad with GHC 6.10.4. Another useful thing would be to provide data on whether the behaviour is non-linear. Eg try with 1k, 2k, 4k, 8k, etc elements in your list and see how it behaves. Providing reproducible and well-characterised bug reports greatly increases the likelihood that we'll fix it! Thanks Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Günther Schmidt | Sent: 03 August 2009 22:09 | To: Thomas DuBuisson | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Compiling large source files | | Hi Thomas, | | yes, a source file with a single literal list with 85k elements. | | | Günther | | | Am 03.08.2009, 22:20 Uhr, schrieb Thomas DuBuisson | thomas.dubuis...@gmail.com: | | Can you define very large and compiler? I know an old version of | GHC (6.6?) would eat lots of memory when there were absurd numbers of | let statements. | | Thomas | | 2009/8/3 Günther Schmidt red...@fedoms.com: | Hi all, | | I'm having trouble compiling very large source files, the compiler eats | 2GB | and then dies. Is there a way around it? | | Günther | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | | | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: gcc version for GHC 6.10.4 under Sparc/Solaris
Duncan Coutts wrote: I should also note that there is a GHC 6.10.4 binary for Sparc/Linux that is now included with Gentoo. It's got all features turned on except for split objects (which fails due to mixing ld -r and --relax flags). In particular it's a registerised via-C build with ghci, TH and profiling working. Does compiling using gcc-4.3.x work if -fvia-C is added? It's a distro package not a generic relocatable GHC binary tarball so there's no point putting it on the ghc download page, but it's there nevertheless if people want it (look for the gentoo ghc ebuild). I've found http://packages.gentoo.org/package/dev-lang/ghc Where are ebuilds or downloadable binaries? Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: What is the mutator?
Say you are implementing a network server, for example -- you don't want to have big spikes in the request latency due to GC. We think concurrent GC is unlikely to be practical in the Haskell setting, due to the extra synchronisation needed in the mutator. -- Simon Marlow It is perfectly possible to do real-time concurrent garbage collection for Haskell, in an incremental fashion that guarantees a small maximum bound on each packet of GC work. The tradeoff is that the percentage of time devoted to GC in total is much greater, and the mutator must do more work to co-operate with the GC. In other words, the program runs slower. This tradeoff is the same for all real-time garbage collection schemes as far as I am aware, in any language - either you can have responsiveness, or you can have better overall application speed, but you cannot have both. So I wonder, to what degree is GC latency controllable in Haskell? It seems that, pending further research, we can not hope for concurrent GC. There have been several papers on real-time GC in Haskell (including one of my own). There is no technical problem, only performance worries. This is what I think Simon means by unlikely to be practical. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: use gtar and not tar under solaris
Matthias Kilian wrote: However, to create an archive, you can use something like $ pax -wf foo.tar directory Do you think gtar --format=posix would be different from pax? The only question is, if we should create archives using the ustar, posix/pax, or gnu format. ustar seems to be the least common denominator. Does ustar have any disadvantages? Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: use gtar and not tar under solaris
Christian Maeder wrote: Matthias Kilian wrote: However, to create an archive, you can use something like $ pax -wf foo.tar directory Do you think gtar --format=posix would be different from pax? The only question is, if we should create archives using the ustar, posix/pax, or gnu format. ustar seems to be the least common denominator. Does ustar have any disadvantages? My plain tar command under solaris cannot handle the pax files, too. So ustar archives should be created (at least under solaris). But I don't know why the ustar format can handle long file names, whereas the gnu format creates a @LongLink file and pax a PaxHeader file (when unpacked with tar). Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
FFI: Problem with Signal Handler Interruptions
Apologies for re-posting this subject here since I had sent already a message to haskell-café 3 days ago, but I just learned about this mailing list and it seems more appropriate to ask this question here I guess. I already got a reply from Simon Marlow but I posted some further (so far unanswered) questions. The thread starts here: http://www.haskell.org//pipermail/haskell-cafe/2009-August/064880.html. Basically my remaining questions are: 1. How can one safely perform a blocking wait on a system call via FFI when compiling with -threaded and avoid signal interruptions which cause the call to return with EINTR? 2. Could 1. be achieved by blocking SIGVTALRM in the thread doing the call? For details please cf. the original maling list thread. Many thanks, Levi ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI: Problem with Signal Handler Interruptions
Hello Levi, Friday, August 7, 2009, 6:48:42 PM, you wrote: 1. How can one safely perform a blocking wait on a system call via FFI when compiling with -threaded i think you should use forkOS to create OS thread dedicated to Haskell thread and avoid signal interruptions which cause the call to return with EINTR? don't know, but may be you can retry on this retcode or disable EINTR in one specific OS thread -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: gcc version for GHC 6.10.4 under Sparc/Solaris
On Thu, Aug 06, 2009 at 10:04:19AM +0200, Christian Maeder wrote: Hi Ian, could you add a note on the download page that GCC version 4.3.x is not suited for: Done! Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: What is the mutator?
2009/08/07 Malcolm Wallace malcolm.wall...@cs.york.ac.uk: There have been several papers on real-time GC in Haskell (including one of my own). There is no technical problem, only performance worries. This is what I think Simon means by unlikely to be practical. So I guess there is no right answer here -- a realistic solution would offer two GC options, maybe set by an option to the RTS or on a per-thread level. I guess your work was specifically on garbage collection of functional languages in embedded systems? An incremental garbage collector for embedded real-time systems ftp://ftp.cs.york.ac.uk/pub/malcolm/rtgc.html Also there is the Non-stop Haskell paper. Non-stop Haskell http://research.microsoft.com/en-us/um/people/simonpj/Papers/inc-gc.htm Both of these papers are from some time ago; the most recent thing I can find is: Exploring the Barrier to Entry - Incremental Generational Garbage Collection for Haskell -- Jason Dusek ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
What would be required to make a LLVM backend for GHC
Hi all, I've been talking to one of the LLVM developers, who's working on an operating system called AuroraUX, which, among other things, is trying to use LLVM as much as possible in the system (using clang as the default compiler, compiler-rt [libgcc replacement from the LLVM team], etc.). He would like to know exactly what would need to be implemented in LLVM to allow ghc to be ported to LLVM, and he would do his best to get these features implemented. I know the LLVM guys are quite open to suggestions, and want to get people using it as much as possible, so if we can let them know what we need, hopefully they can help make life easier for us. Thanks, Alex Mason ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
