June 2005 - Glasgow-haskell-users

RE: Int64 and efficiency
by Simon Marlow 06 Jun '05

06 Jun '05

On 06 June 2005 12:44, Ketil Malde wrote: > Recently, Marcin 'Qrczak' Kowalczyk posted a micro-benchmark on > comp.lang.functional, illustrating performance with statically typed > Int and Integer, and Kogut's dynamically typed automatically-promoted > numbers. (Int is fastest, Kogut second, and Integer quite a bit > slower). > > For fun, I tried to use Int64, but to my surprise it is a lot slower > than the others. Marcin suggested I look at stg and hc output (which > I did without getting much wiser) and made some guesses as to what the > reasons were. > > I'm curious whether this is typical, and if so, whether there is a > theoretical reason why Int64 is so slow? (I would have expected a > factor of 2-4 worse than Int, but in reality it was about 35x slower) > > (Code attached, replace MyInt as appropriate.) In theory, you're right. I haven't investigated your example, but my guess is that some inlining isn't happening - maybe some missing INLINE pragmas somewhere. You might be able to shed more light by comparing the -ddump-stg output for the Int version with the Int64 version. Oh, also the Int64 operations are currently performed by foreign calls, rather than primitives, IIRC. That will affect speed, but not by a huge amount. Cheers, Simon

1 0

Int64 and efficiency
by Ketil Malde 06 Jun '05

06 Jun '05

Hi, Recently, Marcin 'Qrczak' Kowalczyk posted a micro-benchmark on comp.lang.functional, illustrating performance with statically typed Int and Integer, and Kogut's dynamically typed automatically-promoted numbers. (Int is fastest, Kogut second, and Integer quite a bit slower). For fun, I tried to use Int64, but to my surprise it is a lot slower than the others. Marcin suggested I look at stg and hc output (which I did without getting much wiser) and made some guesses as to what the reasons were. I'm curious whether this is typical, and if so, whether there is a theoretical reason why Int64 is so slow? (I would have expected a factor of 2-4 worse than Int, but in reality it was about 35x slower) (Code attached, replace MyInt as appropriate.) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

qualified re-export of Data.Set
by Serge D. Mechveliani 06 Jun '05

06 Jun '05

Dear GHC developers, Please, how to re-export (qualified) Data.Set, Data.Map ? In ghc-6.2.2, I used only ------------------------------------------- {-# OPTIONS -fno-warn-duplicate-exports #-} module Reexport (module Data.Set, ...) ... import Data.Set ------------------- module Main import Reexport ------------------------------------------ For ghc-6.4, I need qualified import of Data.Set, Data.Map and need to re-export it. I am trying --------------------------------------------------------------------- module Reexport (module Set, f, g) where import qualified Data.Set as Set f :: Bool f = True g :: Set.Set Bool g = Set.singleton f -------------------------- module Main import Reexport main = putStr $ shows v "\n" where v = Set.singleton f -- g --------------------------------------------------------------------- Now, v = g works. And v = Set.singleton f reports Main.hs:3:40: Not in scope: `Set.singleton' I wonder, how the needed thing can be arranged. With kind regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

RE: FFI questions
by Simon Marlow 06 Jun '05

06 Jun '05

On 06 June 2005 09:04, Gary Morris wrote: > --- begin: AccuTime.hs > > module AccuTime where > > import Foreign.C.Types > > foreign import stdcall unsafe "accutime.h accuticks" c_accuticks :: > IO CULLong > > accuticks :: IO Integer > accuticks = do ull <- c_accuticks > return (fromIntegral ull) > > --- end > > And then, after passing the correct -L and -l flags to ghci, attempted > to load that module. Unfortunately, I got: > > ___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 6.4, for Haskell > 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \____/\/ /_/\____/|_| Type :? for help. > > Loading package base-1.0 ... linking ... done. > Loading object (dynamic) AccuTime ... done > final link ... done > Prelude> :l AccuTime.hs > Compiling AccuTime ( AccuTime.hs, interpreted ) > ghc.exe: panic! (the `impossible' happened, GHC version 6.4): > ByteCodeFFI.mkMarshalCode_wrk(x86) L_ > > Please report it as a compiler bug to > glasgow-haskell-bugs(a)haskell.org, > or http://sourceforge.net/projects/ghc/. Yes, unfortunately it seems that long-long results from foreign functions aren't supported by GHCi (on x86) right now. Workaround is to compile the module instead of interpreting it. Cheers, Simon

1 0

FFI questions
by Gary Morris 06 Jun '05

06 Jun '05

Hello everyone, Apologies in advance if I'm asking an incredibly simple question, but I'm using GHC 6.4 on Windows XP SP2. I was recently playing with implementing the Kocher attack on RSA in Haskell, and along the way I needed a reasonable way to time operations -- the built-in Windows functions don't do such a good job. I wrote a very simple function that uses the rdtsc instruction: --- begin: AccuTime.c #include <windows.h> __declspec(dllexport) ULONGLONG accuticks() { LARGE_INTEGER i; ULONG lo, hi; __asm { rdtsc mov hi, edx mov lo, eax } i.HighPart = hi; i.LowPart = lo; return i.QuadPart; } --- end --- begin: AccuTime.h #ifndef __accutime_h #define __acutime_h #include <windows.h> ULONGLONG accuticks(); #endif /* __accutime_h */ --- end and compiled it to AccuTime.dll. I then attempted to piece together the file I'd need to import this function into Haskell: --- begin: AccuTime.hs module AccuTime where import Foreign.C.Types foreign import stdcall unsafe "accutime.h accuticks" c_accuticks :: IO CULLong accuticks :: IO Integer accuticks = do ull <- c_accuticks return (fromIntegral ull) --- end And then, after passing the correct -L and -l flags to ghci, attempted to load that module. Unfortunately, I got: ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Loading object (dynamic) AccuTime ... done final link ... done Prelude> :l AccuTime.hs Compiling AccuTime ( AccuTime.hs, interpreted ) ghc.exe: panic! (the `impossible' happened, GHC version 6.4): ByteCodeFFI.mkMarshalCode_wrk(x86) L_ Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, or http://sourceforge.net/projects/ghc/. > At this point, I'm quite confused. Does anyone else know what I'm doing to cause this panic? Thanks, /g

1 0

RE: using the Intel compiler (icc)
by Simon Marlow 05 Jun '05

05 Jun '05

There's a command line switch to change the C compiler: -pgmc icc. But I doubt whether you could use icc as the back-end for GHC without quite a lot of work, because the mangler is quite picky. Linking object files created by icc into a ghc-compiled program should work fine, though. Automatic vectorisation of loops won't help GHC (the code we generate doesn't have any loops). Cheers, Simon On 05 June 2005 19:17, Keean Schupke wrote: > Yes, thats exactly what I mean. Can I switch the compiler to use with > a command line switch? ICC is compatible with GCC and can use the same > libraries. The main advantage is the automatic vectorisation of loops, > to use SSE / MMX. > > Keean. > > Seth Kurtzberg wrote: > >> Keean Schupke wrote: >> >>> Is it possible to get GCC to use the intel C compiler (ICC) instead >>> of gcc? >>> >>> >> Do you mean is it possible to get /GHC/ to use /ICC/? Otherwise I >> don't understand the question. > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Set, Map libraries
by Serge D. Mechveliani 05 Jun '05

05 Jun '05

Dear GHC team, I am looking into the .html docs on the libraries of Map and Set. Here follow the questions and notices. 1. elems :: Set a -> [a] setToList :: Set a -> [a] These two look like synonyms, but have different comments. Am I missing something? 2. size :: Set a -> Int -- O(1) ... And for large sets, the user needs to program genericSize :: Set a -> Integer genericSize = genericLength . Data.Set.elems ? Is this possible to make it O(1) too? 3. Data.Map has lookup and findWithDefault. According to name correspondence, a natural name for the latter would be lookupWithDefault - ? 4. Data.Set.intersection. In old library, it was `intersect' -- if I recall correct. So, it is natural to include `intersect' to the `Obsolete' list. 5. Name resolution. ./Prelude0.hs:254:28: Ambiguous occurrence `null' It could refer to either `Data.Set.null', imported from Data.Set at ./Prelude0.hs:50:48-51 or `GHC.List.null', imported from Prelude at ./Prelude0 Could the compiler detect where null applies to list and where to Set ? For this is visible from the types in the user program. 6. My module applies Data.Set.null (s :: Set a), and null (xs :: [a]). Why ghc reports of the clash with GHC.List.null ? Is GHC.List same as old List library module? Should I write import GHC.List (genericLength, null) instead of import List (genericLength) ? With kind regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

11 14

recompilation check in 6.4
by Serge D. Mechveliani 05 Jun '05

05 Jun '05

People, who knows, please, how to fix re-compilation in ghc-6.4 ? Porting my program dm from 6.2.2 to 6.4, I see that the 6.4 system re-compiles many modules when re-processing the Makefile to build dm. For example, let Foo.hs from dm contain an error "value v not in scope". Running make dm for the first time compiles all the modules before Foo in 50 seconds. Then, I fix an error in Foo.hs and repeat "make dm". The options are set so that ghc-6.2.2 gets to Foo.hs in less than 1 second when doing this repeated `make'. It does consider each module before Foo and each time decides that there is no need in recompilation. It keeps on going this way: -------- Considering whether compilation is required for Prelude0: Skipping Prelude0 ( ./Prelude0.hs, /foo/source/export/Prelude0.o ) -------- and so on, by the scheme "Considering ..XX -- {Checking usages .. --} Skipping XX". The compiler applies this way: -------------------- /foo/ghc/6.2.2/inst/bin/ghc -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances -fno-warn-overlapping-patterns -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports -idemotest -odir /home/mechvel/dm/1.02/dm/source/export -hidir /home/mechvel/dm/1.02/dm/source/export -ddump-hi-diffs --make DExport -package-name dm -------------------- Now, when ghc-6.4 does such a repeated `make', it re-compiles all the `previous' modules under the above options: --------- Chasing modules from: DExport Source file changed or recompilation check turned off Compiling Prelude0 ( ./Prelude0.hs, /.../source/export/Prelude0.o ) Interface file unchanged ... --------- (And when setting to Foo a _syntax_ error, 6.4 finds this error without compiling `previous' modules). Something has changed in 6.4, maybe, the default for the recompilation check, I do not know. 6.2.2 did what was intended in Makefile. Who knows, please, how to fix this recompilation point in 6.4 ? Thank you in advance for explanation. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

docs on Set, Map
by Serge D. Mechveliani 04 Jun '05

04 Jun '05

Dear GHC developers, ghc-6.4 documentation specifies about Map.insertWith " insertWith :: Ord k => (a -> a -> a) -> k -> a -> Map k a -> Map k a O(log n). Insert with a combining function. " This description is not sufficient. For example, in insertWith (\ a1 a2 -> a1) k a3 mp the doc does not tell what value overrides on the key overlap, a3 or the one in mp. The usage of the GHC library for Set and Map will become much easier if you fix this documentation point on all updating functions for Set and Map which use a combining function. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Set & Int
by Serge D. Mechveliani 04 Jun '05

04 Jun '05

Date: Thu, 02 Jun 2005 10:29:03 -0400 People discussed the Map implementation in GHC: data Set a = Tip | Bin {-# UNPACK #-} !Size a !(Set a) !(Set a) type Size = Int ... I do not think that these strict fields can do a real harm, because they effect only a single level of data construction. And even if it was a strict language, operating with large sets would be all right. Still, I would prefer to remove `!' and UNPACK, in order to preserve a pure language. But what I really do not understand is: why not `Integer'? What difficulties may cause the design with size :: Set a -> Natural type Natural = Integer What will be the difference? With each insert envokation, recomputing size costs O(log n), the next call for size costs O(1). Right? Everything looks like for `Int' -- except that `Int' is a bug. "v :: Int" is a bug, if v can occur large. For example, we could imagine (there may appear, there may exist) a machine capable to process in a real time the number of cells much greater than maximal_Int. This depends on hardware architecture specifics. For such sets sS, size sS :: Int returns incorrect result. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0