October 2003 - Glasgow-haskell-users

5.02.2
by Serge D. Mechveliani 20 Oct '03

20 Oct '03

In my last posting I wrote erroneousely about the program working stably in ghc-5.04. It is in fact ghc-5.02.2. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

DoCon as GHC test
by Serge D. Mechveliani 20 Oct '03

20 Oct '03

Dear GHC developers, I wonder: why do not you use the DoCon program as the test? For many years, an attempt to build DoCon according to install.txt and to run its test .../demotest/T_ reveals on average a couple of serious bugs in a new GHC version. One does not need to study anything: only download the archive and follow install.txt. Anyway, if the test function crashes, then it, probably, does not worth to release a public version until the bug is fixed -- ? After the release is done public, the users will still find further bugs, but this is a regular process. Though the test is not done specially for debugging GHC, it proves useful for this. It runs first certain simple functionality, then proceeds with more complex. It also prints True, True ..., and where it prints first False or where it crashes, it follows then that the bug had occured before. Generally, the situation is as follows. * docon-2.06 is public, it is for old ghc, maybe, ghc-5.04. * docon-2.07 is used privately, it is intermediate, it runs on ghc-5.04 and does not reveal any serious bug. * docon-2.08 is ready to become public, it is for ghc >= 6.0.1, but needs a reliable ghc release. * As to the implemented computer algebra methods themself, there is no serious progress from docon-2.06. But the porting is good, because a) it is useful for the GHC debugging, b) DoCon has 1-2 users, now and then other people threaten to use it, and this alarms me, c) the last GHC release is always most supported, and often DoCon cannot install for new release without some changes, usually, `system', cosmetic ones. * Sometimes I drop upgrading DoCon to new GHC for an year or two, and this leads to extra unfixed bugs in GHC. * Recently I try a project of CA + Prover based on Term Rewriting and so far implement half of it in Haskell. I tried many scientific programming tools in my life and do not fear any of looking into new ones, but (Glasgow) Haskell occurs hard to quit with. With kind regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: reexport warnings
by Simon Peyton-Jones 20 Oct '03

20 Oct '03

| My application program (called DoCon), | being ported recently to ghc-6.0.1, | needs to provide the user (program) with the following visibility | scope of items: | all the proper DoCon export | + most of Haskell standard library | + FiniteMap, and maybe some others | module DExport | (module DPrelude, module Categs, ... -- DoCon proper export | ... | module Data.FiniteMap, | module Prelude, module List, module Ratio, module Random | ) | | Is this a reasonable way to arrange the thing? Yes, this looks fine to me. | Now, the ghc-6.0.1 compiler reports | | Compiling DExport ... | Warning: `++' is exported by `module Prelude' and `module List' .. | | I think that these overlaps are harmless, and the compiler will still | set the intended definitions for (++), foldr, etc., | without any danger. Correct. You can suppress these warnings with -fno-warn-duplicate-exports | Aslo proper DoCon export fron DExport has many similar overlaps. | I think that it is often useful to be able to import an item from | different modules. Is this reasonable? It's fine. The warning is only saying that either one of the exports would do by itself for (++). Perhaps there should not be a warning when both export specifiers are 'module X'. | Generally, I accept these overlap warnings as useful ones. | But at the installation, such strange numerous warnings on DExport | will frighten the user. | Therefore, Makefile has, probably, to compile the last module | DExport with this kind of messages switched off. Yes, -fno-warn-duplicate-exports should do the job. You can even put it in the file thus: {-# OPTIONS -fno-warn-duplicate-exports #-} Simon

1 0

ghc 6.3 windows (mingw) cannot invoke gcc correctly
by kyra 18 Oct '03

18 Oct '03

Hi, After downgrading a mingw gcc from 3.3.1 to 3.2.3 I've managed to build and install ghc 6.3 compiler. Unfortunately, it cannot compile source files. It seems it incorrectly invokes gcc . "ghc -c -v filt.hs" gives something like this: ghc-6.3 (incorrect): ................... *** Assembler g:\Progs\ghc-6.3\gcc -B"g:\Progs\ghc-6.3\gcc-lib/" -I. -I. -c C:\DOCUME~1\Awson\LOCALS~1\Temp\ghc1252.s -o .\Main.o Failed: g:\Progs\ghc-6.3\gcc -B"g:\Progs\ghc-6.3\gcc-lib/" -I. -I. -c C:\DOCUME~1\Awson\LOCALS~1\Temp\ghc1252.s -o .\Main.orawSystem: does not exist (No such file or directory) ................... ghc-6.0.1 (correct): ................... *** Assembler G:\Progs\ghc-6.0.1\gcc -B"G:\Progs\ghc-6.0.1\gcc-lib/" "-I." "-I." "-c" "C:\DOCUME~1\Awson\LOCALS~1\Temp\ghc812.s" "-o" "filt.o" ................... Meanwhile, ghc-6.3 correctly outputs intermediate .c or .s (when compiling without gcc) files. I'm completely stuck. Regards, Kyra

1 0

Re: GHC with MS .Net 2003 C compiler
by Andreas.Schroeder＠gillardon.de 18 Oct '03

18 Oct '03

Hi all, hi Seth, yes, you're right with the P4 optimizations of the MS .Net Compiler. My tests ran on a P4 1,7 GHz with 1 GB Ram. But anyway, an older C++ compiler (the 6.0 MSVC++ from... 1998?) did also better than Cygwin C++. > I haven't seen your code yet, but I have noticed in the path the Haskell > is much more sensitive (compared to C++ and Java) to coding style. Don't have to tell me, tell my colleages ;-) See, i am just trying to persuade them that using Haskell would save us a LOT of money. (And would let me finally use a language i like - the PL "nice" looks also well, though) Anyway, here comes the code. I am not using "Integer" for performance' sake. (I read about it somewhere...) Basically, this code does an iteration to do some "backward calculation" of interest rate and similar. Btw, i did not start to bother my colleages with logic programming :-) i know that this would work also. module AIBD(aibd, rechneZins, rechneRate, rechneKapital) where import Foreign(unsafePerformIO) type Funktion = Double -> Double data Genauigkeit = Absolut {wert, intervall :: Double} | Intervall Double istOk :: Genauigkeit -> Double -> Double -> Bool istOk (Absolut w i) x _ = abs (x-w) <= i istOk (Intervall i) _ dx = abs dx <= i sekantenVerfahren :: Funktion -> Genauigkeit -> Genauigkeit -> Int -> Double -> Double sekantenVerfahren f gx gy tiefe start = sekantenIter f tiefe gx gy x1 x2 y1 y2 where x1 = start x2 = start + start * 0.1 y1 = f x1 y2 = f x2 sekantenIter _ 0 _ _ _ x2 _ _ = x2 sekantenIter f tiefe gx gy x1 x2 y1 y2 = let x3 = x2 - y2 * (x2 - x1) / (y2 - y1) y3 = f x3 dy = y3 - y2 dx = x3 - x2 in if (istOk gx x3 dx) && (istOk gy y3 dy) then x3 else sekantenIter f (tiefe-1) gx gy x2 x3 y2 y3 foreign import ccall "HAIBDUtil.h caibd" caibd :: Double -> Double -> Double -> Int -> IO Double aibd:: Double -> Double -> Double -> Int -> Double aibd kapital zins rate jahre = unsafePerformIO (caibd kapital zins rate jahre) {- does the same than aibd:: Double -> Double -> Double -> Int -> Double aibd kapital _ _ 0 = kapital aibd kapital zins rate jahre = aibd (kapital + kapital * zins - rate) zins rate (jahre-1) -} rechneZins :: Double -> Double -> Int -> Double rechneZins kapital rate jahre = sekantenVerfahren f (Intervall 0.00001) (Absolut 0 0.001) 100 0.05 where f = \zins -> aibd kapital zins rate jahre rechneRate :: Double -> Double -> Int -> Double rechneRate kapital zins jahre = sekantenVerfahren f (Intervall 0.001) (Absolut 0 0.001) 100 start where start = kapital / (fromIntegral jahre) f = \rate -> aibd kapital zins rate jahre rechneKapital :: Double -> Double -> Int -> Double rechneKapital zins rate jahre = sekantenVerfahren f (Intervall 0.001) (Absolut 0 0.001) 100 start where start = rate * (fromIntegral jahre) f = \kapital -> aibd kapital zins rate jahre

4 5

Re: Faster, GHC, and floating point.
by Andreas.Schroeder＠gillardon.de 17 Oct '03

17 Oct '03

Hi all, Ok, it isn't FTP but HTTP, but here is the link. http://haskell.sourcez.org/performance.zip Regards, Andreas Schroeder

1 0

Re: Faster, GHC, and floating point.
by Andreas.Schroeder＠gillardon.de 17 Oct '03

17 Oct '03

Hi all, using -fexcess-precision improves the runtime from about 180259 ns to 140201 ns on my environment (Intel P3, 700Mhz, 384 MB Ram, Win2k). That makes for me a speedup of 1.29. I tested the other flags, -funbox-strict-fields -fliberate-case-threshold100 but did not see an improvement. Well, pure Haskell has a runtime of 140201 ns as stated above for a test of 9000 calls (thanks to the "sum $ map f [inputlist]" pattern!). If i use the C aibd as foreign call, i get a runtime of 80115 ns That's pretty good (both ghc6.0.1 on MinGW windows env). But if i look at my Java or C++ solution, then Java takes for the same task (JVM 1.4.2_01 client vm) 30000 ns. The resolution of the currenttimemillis is pretty poor in Java. It's neither better in C++, but i guess that's because of my Arch. At home, i got a better timer resolution than that. (wich i was able to lookup through Haskell). The C++ version lies somewhere between 20000 ns and 10000 ns, close to 20000 ns. I guess it's 18000 ns. That's still the difference of 4 to 6 between C++ and Haskell. I will look at the "core source" generated by GHC to look if it is good enough. For interested souls, i will put the C++ code as well as the haskell code on an FTP server. FTP access details will come soon. Currently, i am setting up a second test. While this first study concentrates on "numbers", and does not provide much data structures, the second study i will do concentrates on complex data structures (yup, i will have a GREAT time with C++, since i "only" learned Java, Haskell, SML, MIPS assembler, ProLog, ... at the University) Thanks to all for your great help so far, Andreas Schroeder |---------+-----------------------------------------> | | JP Bernardy <jyp_7(a)yahoo.com> | | | Gesendet von: | | | glasgow-haskell-users-bounces@| | | haskell.org | | | | | | | | | 16.10.2003 12:56 | | | | |---------+-----------------------------------------> >-------------------------------------------------------------------------------------------------------------------| | | | An: glasgow-haskell-users(a)haskell.org | | Kopie: | | Thema: Faster, GHC, and floating point. | >-------------------------------------------------------------------------------------------------------------------| Hi all, > Generally, did you look at http://haskell.org/ghc/docs/latest/html/users_guide/faster.html I have to say that one advice is not perfect... "Don't use Floats: "...There's rarely a speed disadvantage -- "modern machines will use the same floating-point "unit for both. ... Assuming an i386 architecture, the way to get really faster code is 1. Use -fexcess-precision, unless you really need the exact (lesser) precision. Otherwise each intermediate result is spilled in memory. This hurts! 2. Use floats rather than doubles. You won't lose so much precision because all intermediate computations will use 80-bit precision. This saves some memory. Plus, GHC doesn't align on 64 bits, which slows down access to doubles. I've made up a simple benchmark with Andreas' code, using the pure haskell "aibd", with main: tt z = print $ sum $ map (\x -> rechneZins x 0.01 z) $ [1..10000] main = do tt 20 tt 21 ... tt 30 ghc -O2 -fglasgow-exts --make Main.hs, a.out runs in 7.82 secs. with -fexcess-precision, runs in 2.97secs; with Float instead of Double, runs in 2.72secs. This is with gcc 3.3.2, ghc 6.0.1, linux and a pentium4 arch. Just my 2 cents, JP. __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: stg_ap_v_ret porting crash: solved?
by Simon Marlow 16 Oct '03

16 Oct '03

> but > > -------------------------------------------------------------- > ---------- > ===fptools== Recursively making `boot' in base haskell98 > network haskell-src unix ... > PWD = /scratch/users/eden/ghc-6.0.1/libraries > -------------------------------------------------------------- > ---------- > -------------------------------------------------------------- > ---------- > ==fptools== gmake boot -r; > in /scratch/users/eden/ghc-6.0.1/libraries/base > -------------------------------------------------------------- > ---------- > ../../ghc/utils/ghc-pkg/ghc-pkg-inplace --update-package > <package.conf.inplace > /usr/users/eden/scratch/ghc-6.0.1/ghc/driver/package.conf.inpl > ace: parse error in package config file > gmake[1]: *** [../../ghc/driver/stamp-pkg-conf-base] Error 1 > gmake: *** [boot] Error 1 Have you done 'make boot' in ghc/driver? Cheers, Simon

3 6

RULES for SPECIALIZ(E)ations
by Juanma Barranquero 16 Oct '03

16 Oct '03

I'm playing with rules, and I wonder if it is posible to define a rule that will trigger for a specialization of a function. (In the following examples, the functions are not necesarily useful or good-style... :) I have: count :: (Integral b) => (a -> Bool) -> [a] -> b count = count' 0 where count' n _ [] = n count' n f (x:xs) | f x = count' (n+1) f xs | otherwise = count' n f xs with b of class Integral and not an Int because it could posibly be used to count lists with more than maxInt elements (let's say, bytes in a huge file, or records in a long-lived socket connection, or whatever). Ok, if I'm not mistaken I can add: {-# SPECIALIZE count :: (a -> Bool) -> [a] -> Int #-} and have the compiler add an alternate version of count for uses such as: let c :: Int = count even [1..100] Now, to learn about RULES, I defined: {-# RULES "count/generic" forall f g xs. count f (filter g xs) = genericLength (filter (\x -> g x && f x) xs) #-} where I'm forced to use genericLength so the types of the LHS and RHS can match. Then I wondered: as I have an specialization of count which returns Int, wouldn't be possible to do: {-# RULES "count/int" forall f g xs. count f (filter g xs) = length (filter (\x -> g x && f x) xs) -#} Well, the fact is that: testc1 n = count even (filter (\x -> x `mod` 3 > 0) [1..n]) fires "count/generic" all right, but testc2 :: Int -> Int testc2 n = count even (filter (\x -> x `mod` 3 > 0) [1..n]) does not fire "count/int". I suppose I'm being bitten by User's Guide 7.8.2: "If more than one rule matches a call, GHC will choose one arbitrarily to apply." even if a bit later it says: "So a rule only matches if the types match too." Am I understanding right and it's that so? Thanks, /L/e/k/t/u

1 0

Building ghc with mingw ghc 6.0.1 and gcc 3.3.1 problem
by kyra 16 Oct '03

16 Oct '03

Hi, folks! Trying to build either 6.2 or 6.3 ghc with mingw ghc 6.0.1 and gcc 3.3.1, I get multiple "undefined reference to `__module_registered' " errors during a stage2 ghc linking. Is the gcc 3.3 behaviour the case? Regards, Kyra

1 0