Re: IMCROSS and ghc
Duncan Coutts wrote: On Wed, 2008-12-10 at 11:19 -0800, John Meacham wrote: I was wondering if anyone has gotten ghc to work with IMCROSS[1]. I'm Cross is a way to build native windows and mac osx apps on linux. quite convinient for making distribution packages for those other platforms or if you want to use linux's toolset during your build. basically, IMCROSS installs a couple new gccs with names like /usr/local/bin/i386-mingw-gcc and so forth, is there some way to get ghc to use said non-native compiler as its back end? It seems that ghc will also need to build the libraries with different #define's as well to reflect the target windows or mac environment. It sounds like you would need to set ghc up as a cross-compiler. I'm told that this there is a fair bit of work required to get ghc to support cross-compilation. I expect Ian or Simon could provide more details on what would need doing if you're interested in pursuing it. Right - the stage 1 compiler has to be a cross-compiler, running on the host system and generating binaries for the target system. Bits of the infrastructure are in place (i.e. we make some attempt to use the right _HOST_ARCH vs. TARGET_ARCH #defines), but we've never actually done real cross-compilation with GHC so I imagine there will be various things to fix. The build system probably assumes that host==target in lots of places. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Malcolm Wallace wrote: Had you deprecated the non-threaded RTS, we would probably have no problems described in ticket #2848 :-/ I think you'll have to deprecate it anyway, because it will be more and more difficult to maintain two versions of code, we may conduct small survey on amount of usage of old RTS (i mean ask this in haskell-cafe) For the only application I tried, using the threaded RTS imposes a 100% performance penalty - i.e. computation time doubles, compared to the non-threaded RTS. This was with ghc-6.8.2, and maybe the overhead has improved since then? This is a guess, but I wonder if this program is concurrent, and does a lot of communication between the main thread and other threads? The main thread is a bound thread, which means that communication between the main thread and any other thread is much more expensive than communication between unbound threads, because it involves full OS-level context switches. In a concurrent program, don't use the main thread to do any real work, do a forkIO and wait for the child to complete. Certainly a 2x performance overhead for the threaded RTS is not something we normally see. There will be an overhead for MVars and STM, but even then I'd consider 2x to be deeply suspicious. For most programs, the overhead should be close to zero. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: IMCROSS and ghc
basically, IMCROSS installs a couple new gccs with names like /usr/local/bin/i386-mingw-gcc and so forth, is there some way to get ghc to use said non-native compiler as its back end? I don't know about IMCROSS specifically, but earlier this year Sylvain Nahas adapted the build system of nhc98 to allow it to become a cross-compiler. At configure time, you simply give some additional arguments to point to the C cross-compilation toolchain, e.g. ./configure --target=i386-mingw --hostcc=i386-mingw-gcc --hoststrip=... --endian=-DLOW_BYTE_FIRST --ccoption=... --ldoption=... Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Brian B wrote: Hi Bulat, My contribution to the survey: I've used forkProcess to daemonize a ghc program inside the haskell fuse bindings: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse http://code.haskell.org/hfuse/System/Fuse.hsc If removing the non-threaded RTS would break forkProcess entirely, these bindings would have to do something different. The issue: users of the FUSE C api will get daemonized using daemon(2); it'd be nice if GHC fuse programs could behave similarly. forkProcess should work with the threaded RTS, as long as you don't enable multiple cores with +RTS -Nn. However, forking is a pretty tricky operation in a multi-threaded environment, and that's where the difficulty comes from. Cheers, Simon Thanks, Brian Bloniarz Hello Tomasz, Saturday, December 6, 2008, 10:52:39 PM, you wrote: Had you deprecated the non-threaded RTS, we would probably have no problems described in ticket #2848 :-/ I think you'll have to deprecate it anyway, because it will be more and more difficult to maintain two versions of code, especially if one of them will be much less used and tested. we may conduct small survey on amount of usage of old RTS (i mean ask this in haskell-cafe) -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Connect to the next generation of MSN Messenger Get it now! http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-ussource=wlmailtagline ___ 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: ghci and ghc -threaded broken with pipes forking
John Goerzen wrote: Brian B wrote: Hi Bulat, My contribution to the survey: I've used forkProcess to daemonize a ghc program inside the haskell fuse bindings: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse http://code.haskell.org/hfuse/System/Fuse.hsc If removing the non-threaded RTS would break forkProcess entirely, these bindings would have to do something different. The issue: users of the FUSE C api will get daemonized using daemon(2); it'd be nice if GHC fuse programs could behave similarly. I also use forkProcess extensively: in HSH, for instance, which is used by hpodder, twidge, and a host of other tools. Removing the ability to use forkProcess removes the ability to write a Unix shell in Haskell, or to do anything shell-like, or anything even mildly advanced involving piping, file descriptors, and the like. I would see it as a significant regression. Have you tried those apps with the threaded RTS? I'd be interested to know whether they work as expected. I'm not suggesting we remove the non-threaded RTS, however perhaps there's an argument for making -threaded the default. After all, that's what you get with GHCi by default right now. Maintaining both versions of the RTS is certainly a burden, but I think it's one we have to carry, since there are still reasons to want both. The System.Process calls, last I checked (in 6.8.x) were both too buggy to use for complex tasks, and too inadequate for some (though the adequacy has been improving.) If there's bugginess we need to get it fixed - please report those bugs! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Simon Marlow wrote: John Goerzen wrote: Brian B wrote: Hi Bulat, My contribution to the survey: I've used forkProcess to daemonize a ghc program inside the haskell fuse bindings: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse http://code.haskell.org/hfuse/System/Fuse.hsc If removing the non-threaded RTS would break forkProcess entirely, these bindings would have to do something different. The issue: users of the FUSE C api will get daemonized using daemon(2); it'd be nice if GHC fuse programs could behave similarly. I also use forkProcess extensively: in HSH, for instance, which is used by hpodder, twidge, and a host of other tools. Removing the ability to use forkProcess removes the ability to write a Unix shell in Haskell, or to do anything shell-like, or anything even mildly advanced involving piping, file descriptors, and the like. I would see it as a significant regression. Have you tried those apps with the threaded RTS? I'd be interested to know whether they work as expected. I have, and it didn't work well. But it's been awhile, and I can't tell you anymore what version of GHC or what exactly the problem was. I was most certainly 6.8 or older. Once 6.10 hits Debian, I could test again there. But see below... I'm not suggesting we remove the non-threaded RTS, however perhaps there's an argument for making -threaded the default. After all, that's what you get with GHCi by default right now. That's probably an OK solution. I would also add: does the threaded RTS support all platforms? For instance, GHC runs on my Alpha and on AIX, unregisterised. ghci doesn't run there, but GHC does. If you drop the non-threaded RTS, does that mean that GHC doesn't work there at all? The System.Process calls, last I checked (in 6.8.x) were both too buggy to use for complex tasks, and too inadequate for some (though the adequacy has been improving.) If there's bugginess we need to get it fixed - please report those bugs! Already done: http://hackage.haskell.org/trac/ghc/ticket/1780 (still open since Nov 2007) There was also a thread here regarding problems with the threaded RTS: http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg11573.html Not sure if that has been fixed, or was an error on my part, but see your reply at: http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg11585.html I admit I haven't had the chance to reread that whole thread, so my apologies if this is a red herring. -- John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Simon Marlow wrote: I would also add: does the threaded RTS support all platforms? For instance, GHC runs on my Alpha and on AIX, unregisterised. ghci doesn't run there, but GHC does. If you drop the non-threaded RTS, does that mean that GHC doesn't work there at all? If those platforms support threads, there's no reason why the threaded RTS shouldn't work there. Also, GHCi should work on all platforms (even unregisterised) these days, including the FFI if there's support in libffi for that platform. That's very good to hear. http://hackage.haskell.org/trac/ghc/ticket/1780 (still open since Nov 2007) That one is closed - fixed in 6.8.3 I think. Oops, my mistake. I'll look into it again. http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg11585.html I did make a ticket for that: http://hackage.haskell.org/trac/ghc/ticket/1185 #1 way to tell you are a Haskell geek: * milestone changed from _|_ to 6.10.2. grin Thanks, Simon. -- John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
