- Glasgow-haskell-users

RE: package treating
by Simon Marlow 22 Oct '03

22 Oct '03

> Now, does the package > > Package {name = "docon", > import_dirs = ["$(e)"], > source_dirs = [], > library_dirs = ["$(e)"], > hs_libraries = ["HSdocon"], > extra_libraries = [], > include_dirs = [], > c_includes = [], > package_deps = ["data"], > extra_ghc_opts = [$(extraPackageOpts)], > extra_cc_opts = [], > extra_ld_opts = [] > } > e = .../source/export > extraPackageOpts = such and such complier flags > > > specify of what it is intended? > In particular, what should be package_deps = [ ?? ] > ? package_deps should be a list of packages on which this package depends. More precisely, for every module M imported by a module in your package, if M is from another package P, you should include P in package_deps. That is, package_deps doesn't need to be transitively closed. Cheers, Simon

1 0

Re: package treating
by Serge D. Mechveliani 22 Oct '03

22 Oct '03

On Tue, Oct 21, 2003 at 02:03:03PM +0100, Simon Marlow wrote: > > > I presumed that, as the ghci > > command loads all usable libraries, then > > > > ghci -package-conf myPackage.conf -package myPackage > > > > will load all that `ghci' loads + > > what is specified in myPackage.conf. > > > > But, probably, this is not (should not be?) so: the option > > > > -package-conf myPackage.conf > > > > fully replaces the configuration, and the package search is done > > only according to what is specified in > > myPackage.conf > > , right? > No, packages are loaded on a demand-driven basis. Packages must have > correct dependencies specified, so that GHC can ensure that they are > loaded in dependency order. The -package-conf flag does not cause the > configuration to be "fully replaced". It is hard to understand how do they work. In my real practice, the project creates a package docon which refers to the .a, .o libraries in $(e)/ that are build earlier by `making' the project (.o library appears a bit later, at the stage of creating the package by ghc-pkg ... -u -g ). The project imports and re-exports Data.FiniteMap, (maybe, Data.Set,) and all the Standard library modules. The package should work both as ghci $dOpts UserModule and as ghc $dOpts --make UserModule with dOpts = -package-conf docon.conf -package docon Now, does the package Package {name = "docon", import_dirs = ["$(e)"], source_dirs = [], library_dirs = ["$(e)"], hs_libraries = ["HSdocon"], extra_libraries = [], include_dirs = [], c_includes = [], package_deps = ["data"], extra_ghc_opts = [$(extraPackageOpts)], extra_cc_opts = [], extra_ld_opts = [] } e = .../source/export extraPackageOpts = such and such complier flags specify of what it is intended? In particular, what should be package_deps = [ ?? ] ? Thank you in advance for the advice, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

ghci & TclHaskell
by Volker Stolz 22 Oct '03

22 Oct '03

ghci doesn't automatically pick up libtcl & libtk, although they're in package.conf. LD_PRELOADing them works fine [plain ghc works as well]. Is this a feature? Tracing shows that libt{cl,k}83.so *are* opened. Changing the order in extra_libraries or moving them to extra_ld_opts doesn't help, either. > ghci -package TclHaskell ... Loading package TclHaskell ... linking ... /usr/local/lib/ghc-6.0.1//HSTclHaskell_cbits.o: unknown symbol `Tcl_AppendResult' ghc-6.0.1: panic! (the `impossible' happened, GHC version 6.0.1): can't load package `TclHaskell' > LD_PRELOAD=/usr/local/lib/libtcl83.so:/usr/local/lib/libtk83.so ghci -package TclHaskell ... Loading package TclHaskell ... linking ... done. Prelude> [Not that that's any useful, but conclusion about the above might be relevant for other packages. Skipping Main ( philos.hs, ./philos.o ) Ok, modules loaded: Main, ConcurrentDebug, CHD_ConcurrentSampleVar, CHD_Label, CHD_ConcurrentQSemN, CHD_ConcurrentQSem, CHD_ConcurrentCVar, CHD_ConcurrentMain, CHD_ConcurrentChannel, CHD_ConcurrentMVar, CHD_DebugMsgChan, CHD_BaseTypes, CHD_BaseFunctions, CHD_GuiConfigWindow, CHD_Enviroment, PriorDoubleChannel. Prelude Main> main No compiled code for Tcl ] Package.conf: Package {name = "TclHaskell", auto = False, import_dirs = ["/usr/local/lib/ghc-6.0.1/imports/tclhaskell/"], source_dirs = [], library_dirs = ["/usr/local/lib/ghc-6.0.1/"], hs_libraries = ["HSTclHaskell"], extra_libraries = ["tcl83", "tk83", "HSTclHaskell_cbits" ], include_dirs = ["/usr/local/lib/ghc-6.0.1/include"], c_includes = [], package_deps = ["rts", "lang", "concurrent", "data"], extra_ghc_opts = ["-fglasgow-exts", "-fvia-C"], extra_cc_opts = [], extra_ld_opts = ["-L/usr/local/lib", "-lncurses"], framework_dirs = [], extra_frameworks = []}] -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME

1 0

Re: GHC and gcc 3.3.1
by Jost Berthold 21 Oct '03

21 Oct '03

We have built GHC 6.2 for RedHat 9 in our department without problems (well... I checked out the sources approx. 2 weeks ago) using gcc-3.3.1 and a snapshot of ghc-6.1(20030829, rebuilt using binary ghc-6.1.20030803 and manually linking in a dummy __ctype_b). I only had problems because of the changed library (ghc fails when linking) and because I could not install an rpm on the machine. Now the build got through without problems, and it seems the compiler does what it should... Jost > Date: 21 Oct 2003 01:42:25 +0200 > From: Peter Simons <simons(a)cryp.to> > To: glasgow-haskell-users(a)haskell.org > Subject: GHC and gcc 3.3.1 > > Just curious: Has anyone successfully compiled GHC with gcc > 3.3.1 on Linux/x86? I'm having trouble here with both GHC > 6.0 and GHC-current. Is that just me? > > Peter

1 0

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

21 Oct '03

Well, i found the reason why it did work with haskell and not with C. It was simply that for haskell i provided an arch via -optc-march=pentium3 and did not the same with C++ (... i should have read the sse option documentation). Thanks for the hint about strictness on large data structures. Regards, Andreas |---------+---------------------------> | | Michael Weber | | | <michaelw@foldr.| | | org> | | | | | | 21.10.2003 12:55| | | | |---------+---------------------------> >-------------------------------------------------------------------------------------------------------------------| | | | An: Andreas.Schroeder(a)gillardon.de | | Kopie: | | Thema: Re: Faster, GHC, and floating point. | >-------------------------------------------------------------------------------------------------------------------| On Tue, Oct 21, 2003 at 12:03:34PM +0200, Andreas.Schroeder(a)gillardon.de wrote: > > Can't tell you, SSE is disabled by cygwin when i try -mfpmath=sse i get the > message If you compare one language with SSE enabled and another one without, this is like comparing apples and oranges, no? It's rather meaningless when trying to decide how good Haskell performs compared to C++. And I have no doubt your C++ colleagues will point you to it... ;) > Oh, and btw, using MinGW yields the same message for C/C++. > For haskell actually, it _makes_ a difference. Don't ask me why and how. It would be good to find out what is going on there before comparing values. BTW: my personal experience is that with bigger datastructure it gets worse for Haskell rather than better. Closures and copying add a lot of overhead and you really have to keep on eye on strictness. Cheers, Michael

1 0

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

21 Oct '03

Yes, i got SSE to work with C++ with -march=pentium3 and -mfpmath=sse Well, don't make a difference for C++. It is still stuck at 140ms. But i must say that the speedup could be below the time resolution of my PC + Test. It is assumable that the improvement is similar to Haskell (about 4%) |---------+-----------------------------------------> | | Michael Weber | | | <michaelw(a)foldr.org> | | | Gesendet von: | | | glasgow-haskell-users-bounces@| | | haskell.org | | | | | | | | | 21.10.2003 11:47 | | | | |---------+-----------------------------------------> >-------------------------------------------------------------------------------------------------------------------| | | | An: Andreas.Schroeder(a)gillardon.de | | Kopie: glasgow-haskell-users(a)haskell.org | | Thema: Re: Faster, GHC, and floating point. | >-------------------------------------------------------------------------------------------------------------------| * Andreas.Schroeder(a)gillardon.de [2003-10-21T11:39+0200]: > Now, Haskell takes 4.57 the time of C++ (cygwin gnu C++ with -O2). Did you add the SSE options etc. to the C++ program as well when comparing Haskell vs. C++? What is the SSE speedup of C++ vs. C++/with SSE? Cheers, Michael _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

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

21 Oct '03

> > You put the blame on me for the bad performance of my code, > > I didn't mean to give that impression, sorry. Optimising Haskell code > is a delicate art which requires experience and sometimes a deep > knowledge of GHC's optimiser. This is a real problem, and we readily > accept that. I just wanted to say that i am aware that i am not (yet) a Haskell pro. I don't really feel blamed. I apologize for the formulation :-) Regards, Andreas Schroeder

1 0

RE: Faster, GHC, and floating point.
by Simon Marlow 21 Oct '03

21 Oct '03

> > really performance-critical code. Also this will tell you > whether your > > performance problems are due to strictness/boxing or > something else. It > > should be possible to obtain the same performance as C++ > (or better). > > Are you shure about this? And why are you shure? One can never be 100% sure, but your application is numerical and experience suggests that numerical code can often be optimised to yield code similar or better in performance than C. The pseudoknot benchmark (a while ago now) was a good example. > You put the blame on me for the bad performance of my code, I didn't mean to give that impression, sorry. Optimising Haskell code is a delicate art which requires experience and sometimes a deep knowledge of GHC's optimiser. This is a real problem, and we readily accept that. Cheers, Simon

1 0

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

21 Oct '03

Hi Simon, > really performance-critical code. Also this will tell you whether your > performance problems are due to strictness/boxing or something else. It > should be possible to obtain the same performance as C++ (or better). Are you shure about this? And why are you shure? You put the blame on me for the bad performance of my code, and i can let this hold - i don't think that i am a haskell performance expert (though i am learning a lot through you people - thanks a lot). But i want to know if it is just _theoretically_ possible or really easily feasible. See, i know of some C++ hackers who will eventually have to change to Haskell. This will get hard for them, and i don't know if they can get into complex performance issues right from the start :-) But i guess the C++ / Haskell comparison will look far better for Haskell when changing to computations with large data structures. All i can tell by now is that Haskell works fine for me while C++ is ... hard to program. Regards, Andreas Schroeder

1 0

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

21 Oct '03

Can't tell you, SSE is disabled by cygwin when i try -mfpmath=sse i get the message c++ AIBD.cpp Main.cpp -O2 -mfpmath=sse -o AIBD.exe cc1plus: warning: SSE instruction set disabled, using 387 arithmetics and the program it takes obviously the same time. Oh, and btw, using MinGW yields the same message for C/C++. For haskell actually, it _makes_ a difference. Don't ask me why and how. |---------+---------------------------> | | Michael Weber | | | <michaelw@foldr.| | | org> | | | | | | 21.10.2003 11:47| | | | |---------+---------------------------> >-------------------------------------------------------------------------------------------------------------------| | | | An: Andreas.Schroeder(a)gillardon.de | | Kopie: glasgow-haskell-users(a)haskell.org | | Thema: Re: Faster, GHC, and floating point. | >-------------------------------------------------------------------------------------------------------------------| * Andreas.Schroeder(a)gillardon.de [2003-10-21T11:39+0200]: > Now, Haskell takes 4.57 the time of C++ (cygwin gnu C++ with -O2). Did you add the SSE options etc. to the C++ program as well when comparing Haskell vs. C++? What is the SSE speedup of C++ vs. C++/with SSE? Cheers, Michael

1 0