Re: Prevent optimization from tempering with unsafePerformIO
bbr: > Hello, > > I am writing a compiler from the functional logic language Curry to > Haskell. As the result is a real extension of Haskell, there has to be > SOME side effect involved. Unfortunately, this seems to prevent me from > using any of ghc's optimizations on the resulting code. I have tried for > some time to invoke the no-inline pragmata, but they seem to have no > effect at all. Recently at ICFP, Neil Mitchell told me that there > definitely is a way to avoid this problem. But does anybody know how? > > Thanks for your help! > Bernd Brassel Can you give a specific example of what you have tried to do, and how it failed? Thanks, Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Prevent optimization from tempering with unsafePerformIO
Hi Bernd, > I am writing a compiler from the functional logic language Curry to > Haskell. As the result is a real extension of Haskell, there has to be > SOME side effect involved. Unfortunately, this seems to prevent me from > using any of ghc's optimizations on the resulting code. I have tried for > some time to invoke the no-inline pragmata, but they seem to have no > effect at all. Recently at ICFP, Neil Mitchell told me that there > definitely is a way to avoid this problem. But does anybody know how? It varies by each piece of code, can you post a code fragment that gets optimised in the wrong way? In the particular case I was fighting with previously, GHC was not inlining the unsafe bit, but was floating out the actual computation and turning it into a CAF which was being shared. Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Prevent optimization from tempering with unsafePerformIO
Hello, I am writing a compiler from the functional logic language Curry to Haskell. As the result is a real extension of Haskell, there has to be SOME side effect involved. Unfortunately, this seems to prevent me from using any of ghc's optimizations on the resulting code. I have tried for some time to invoke the no-inline pragmata, but they seem to have no effect at all. Recently at ICFP, Neil Mitchell told me that there definitely is a way to avoid this problem. But does anybody know how? Thanks for your help! Bernd Brassel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Prevent optimization from tempering with unsafePerformIO
Hello, I am writing a compiler from the functional logic language Curry to Haskell. As the result is a real extension of Haskell, there has to be SOME side effect involved. Unfortunately, this seems to prevent me from using any of ghc's optimizations on the resulting code. I have tried for some time to invoke the no-inline pragmata, but they seem to have no effect at all. Recently at ICFP, Neil Mitchell told me that there definitely is a way to avoid this problem. But does anybody know how? Thanks for your help! Bernd Brassel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC benchmarks
Ketil Malde wrote: Simon Marlow <[EMAIL PROTECTED]> writes: Not so much code size, but data size (heap size, to be more precise). Of course. There was some talk about storing tags in pointers for 6.8, I couldn't find the reference, but I wonder if that would help my situation? Unfortunately not, the pointer-tagging optimisation doesn't affect space usage, only runtime. It would be interesting to know how much time is spent in the GC - run the program with +RTS -sstderr. MUT time decreases a bit (131 to 127s) for x86_64, but GC time increases a lot (98 to 179s). Right - GC time doubled, which is what we'd expect to see when the resident data size doubles. The decrease in MUT time is probably due to the extra registers available, but MUT time would also be affected by the increase in data size, because the cache hit rate should be lower. On the whole, I think these results are to be expected. There isn't much we can do to improve things in the short term, I'm afraid. Improvements in the pipeline will hopefully enable us to make better use of the extra registers on x86_64, and perhaps parallel GC in the future will get that GC time down again. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
