[Haskell-cafe] Re: GHC 6.4.1 x86-64 does not compile
Dusan Kolar wrote: Hello all, I've install universal binary for x86_64 of GHC 6.4.1. The installation was done on AMD dual core machine. Uname for the machine gives: Linux machine name 2.6.16.5 #1 SMP Thu Apr 13 09:08:22 CEST 2006 x86_64 x86_64 x86_64 GNU/Linux While ghci was running some tests well, the ghc ended compilation with a long list of errors starting like this: Chasing modules from: queen-main Compiling QueensDK ( ./QueensDK.hs, ./QueensDK.o ) /tmp/ghc27286.s: Assembler messages: /tmp/ghc27286.s:26: Error: bad register name `%r12' /tmp/ghc27286.s:27: Error: bad register name `%r15' /tmp/ghc27286.s:29: Error: bad register name `%r12)' /tmp/ghc27286.s:30: Error: bad register name `%r12)' /tmp/ghc27286.s:31: Error: bad register name `%r12)' /tmp/ghc27286.s:32: Error: bad register name `%rax' /tmp/ghc27286.s:33: Error: bad register name `%r13)' /tmp/ghc27286.s:34: Error: bad register name `%rbp' /tmp/ghc27286.s:37: Error: bad register name `%rbx)' /tmp/ghc27286.s:38: Error: bad register name `%rbx)' /tmp/ghc27286.s:45: Error: bad register name `%rbp)' /tmp/ghc27286.s:46: Error: bad register name `%r14' /tmp/ghc27286.s:48: Error: bad register name `%rbp)' /tmp/ghc27286.s:49: Error: bad register name `%r13' The list is quite long. I've truncated it. Well, OK, the x386 version is running, but it won't compile GHC-6.4.2 and, moreover, it's not optimized for the HW. ;-) Is there any way out, or what may I be doing wrong way? It appears that somehow the assembler is being used in 32-bit mode, rather than 64-bit. I'm not sure why this happens. Perhaps your machine is set up to use a 32-bit build environment by default, rather than a 64-bit one? The fact that the x86 version works without any special options seems to support that. On my x86_64 box here, I have to give -m32 options to gcc to generate 32-bit code, for example. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Optimizing locking with MVars
Bulat Ziganshin wrote: Wednesday, May 3, 2006, 3:07:19 PM, you wrote: I propose to add INLINE pragmas to withMVar and friends. and to any higher-order function? :) imho, key of this problem is that GHC don't have a way to optimize just the required function with all it's enclosed calls. in old GHC papers there is an inline function that does this (afai understood) but it is no more supported problem is not that withMVar should be inlined in any case of its use. problem is what i need to inline it's use in one concrete place of my concrete library and there is no way to force GHC do this beside of copying it's implementation! i think that GHC should just give more priority to inlining higher-order and dictionaries-dependent functions (afaiu, currently they are weighted by the same rules as ordinary functions) Giving the programmer more control over which call sites are inlined would be a good thing. However, it only improves code size, not performance, compared with just using INLINE. GHC has a complicated heuristic to decide whether to inline a function or not, taking into account whether the arguments look interesting or not. An interesting argument valiue (eg. a function or a constructor) might lead to more transformations when the function is inlined, so the decision is weighted in favour of that. See the inlining paper: http://www.haskell.org/~simonmar/papers/inline.pdf There are definitely cases where GHC doesn't inline and it would be beneficial to do so. I'd just like to point out that the current heuristics weren't arrived at by accident - we did lots of measurements of the effect of different values for the tuning parameters on the nofib benchmark suite, and the result is a reasonable compromise between performance and code size. and the second part of problem is what it can't be decided at the place of withMVar definition whether it should be inlined or not - this depends in the first place on the call site. if this is the code that performed just one time, we should decide on the space basis. if this is the innermost loop, we should inline even largest functions (especially if they are higher-order/polymorphic ones). but the compiler don't know how much times some code fragment will be performed (obviously it's place for future integration between optimizer and profiler...) so, i think, it should generally optimize program on code space and only for procedures marked as OPTIMIZE it should enable all the inlining machinery, trying to make code generated for this procedure (including all the inner calls) as fast as possible. this should allow programmer to just mark speed-critical procedures and will make library writers absolutely free from dancing with INLINE pragmas. annotating code fragments for optimise readly hard would be a good thing, yes. Of course, you can always put those code fragments in a separate module, and compile it with -O2 -funfolding-use-threshold100 -fliberate-case-threshold100 etc. This won't affect Handle I/O unfortunately, because we need block to protect against asynchronous exceptions. i think that it is not accidental that hPutChar/hGetChar is exactly 3 and 2 times slower than their v* analogs. my routines use only one locked MVar and i think that Handle routines used 3 and 2 mvars, respectively. i thought that they call withMVar directly, but it is not the case. but may be great blocks that they are perform inside block operations are still not inlined and therefore suffers from the same problem as withMVar? i guess that adding INLINE pragma to block definition may speed up their execution (in 52/38 ~= 1.4 times), but possibly at the cost of code size. anyway, Handle I/O is already too complicated thing to worry about it's further optimizations :( 'block' is trivial, it is already inlined. block (IO io) = IO $ blockAsyncExceptions# io unblock (IO io) = IO $ unblockAsyncExceptions# io thank, it's sort of critics what i very need. the total checking seems to rather complex problem so i will decline it until working on next release. the good news is what my buffering scheme updates only one unboxed pointer (current read/write position inside buffer) on all operations that can be performed using only buffer contents, so it seems that i don't need to use block to protect such operations until routine realizes that there is need to switch to other buffer. btw, i've changed default buffer size to 4kb in next version i will work on this problem. i think that it should be described as some contract between library authors (including authors of 3rd-party streams and transformers) and users, in this form: if stream operation abandoned because of asynchronous interrupt, internal bug or error in input data: - it should leave stream in coherent state (f.e., it should not leave vIsEOF=True and vTell=0 for non-empty-file) - it should not have side-effects, f.e. changing position if whole operation (such as vShow) don't have
[Haskell-cafe] Dynamically stackable monads
Hello,I was wondering if it's possible to stack a runtime-known amount ofmonads on top of each other. Let me illustrate. Assume I have a monadthat can consume data and expects as starting parameter an action of the
underlying monad to use this data (call it produce at the lower levelmonad).Now one could imagine stacking one of these consumers on top of theother, as can be seen below. However I can not choose at runtime how
many I want to stack. Is there any solution for this?Regards,Christophe{-# OPTIONS_GHC -fglasgow-exts #-}
module Main whereimport Control.Monadimport Control.Monad.Identityimport Control.Monad.Stateimport Control.Monad.Transdata Action e m = Action { produce :: e - m ()}newtype SequencerT e m a = SequencerT (StateT (Action e m) m a)
deriving (Functor, Monad, MonadIO)newtype Sequencer e a = Sequencer (SequencerT e Identity a) deriving (Functor, Monad, MonadSequencer e)instance MonadTrans (SequencerT e) where lift = SequencerT . lift
class Monad m = MonadSequencer e m | m - e where consume :: e - m ()instance Monad m = MonadSequencer e (SequencerT e m) where consume x = SequencerT $ do s - get
lift . (produce s) $ xevalSequencerT (SequencerT s) action =""> evalStateT s actionevalSequencer (Sequencer s) inputs action =""> evalSequencerT s actionrunSequencerT (SequencerT s) action =
""> runStateT s actionrunSequencer (Sequencer s) action =""> runSequencerT s actionmain :: IO () = evalSequencerT (evalSequencerT (consume 1 consume 2 consume 3) (Action{produce = \x - if x 1 then consume x else liftIO . print $ (A ++ show x)}))
(Action{produce = print . (B ++) . show })--Christophe PoucetPh.D. StudentPhone:+32 16 28 87 20E-mail: ---
IMEC vzw – Register of Legal Entities Leuven VAT BE 0425.260.668 – Kapeldreef 75, B-3001 Leuven, Belgium – www.imec.be
*DISCLAIMER*This e-mail and/or its attachments may contain confidential information. It is intended solely for the intended addressee(s).Any
use of the information contained herein by other persons is prohibited.
IMEC vzw does not accept any liability for the contents of this e-mail
and/or its attachments.**
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] NewBinary/ BinMem and IO monad
just add unsafePerformIO: great idea! In my case I can also use unsafeInterleaveIO or lazyness, can't I? Marc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] NewBinary/ BinMem and IO monad
On Sat, May 06, 2006 at 12:39:46AM +0200, Marc Weber wrote: just add unsafePerformIO: great idea! In my case I can also use unsafeInterleaveIO or lazyness, can't I? Of cause I can't. unsafePerformIO is of type IO a - IO a. Sorry for posting before thinking ;) Marc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Porting GHC to OSX86?
Hi All, Does anyone know if there's been any headway on this? If there's not a port available, where do I go about finding the hc files? Could I compile on a windows or linux x86 box and use the generated hc files to bootstrap? Cheers, Scott On 22/03/2006, at 7:09 AM, Deling Ren wrote: Hi there, Has anyone made any attempt to port GHC to Mac OS X on x86? Wolfgang Thaller’s binary package runs over Rosetta but slow (not surprising). It can not be used to compile a native version either (I got some errors related to machine registers). I tried to do a bootstrap but can't find the .HC files mentioned in the manual. They don't seem to be on the download page of GHC. Any ideas? Thanks. Deling___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
