Re: suggestion: add a .ehs file type
Wolfgang Jeltsch [EMAIL PROTECTED] writes: It made me discover that I use more language extensions than I thought I was using. I think, it’s a good thing if you have to be clear about what extensions you use and what you don’t use. What if someone wants to compile your code with a different compiler which doesn’t support all of GHC’s extensions? And - re the Hackage library rank - the next logical step is to analyse the actual extension usage before deciding what goes into Haskell'. (Not that it should be the sole deciding factor, of course.) Wolfgang Jeltsch [EMAIL PROTECTED] writes: I don’t think so. For example, if you don’t use rank-2 polymorphism and similar things, forall is a perfect name for a type variable. Without implicit parameters, you can use (?) as an operator regardless of spacing. And, I think, some constructs (list comprehensions?) have a different meaning with Template Haskell. Most of unintended usages would probably end up as errors, though. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
6.8.0.x, 64 bits, and memory profiling
Hi, I'm using heap profiling on AMD64, and I am getting some slightly strange results. Running the profiling, 'top' shows about 600Mb in use, but the resulting profile shows ~80Mb. Rerunning with -M200M results in an out-of-memory error. Could it be that the profile is calculated incorrectly for 64bit systems? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC benchmarks
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? 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). i686 version: 94,088,199,152 bytes allocated in the heap 22,294,740,756 bytes copied during GC (scavenged) 2,264,823,784 bytes copied during GC (not scavenged) 124,747,644 bytes maximum residency (4138 sample(s)) 179962 collections in generation 0 ( 67.33s) 4138 collections in generation 1 ( 30.92s) 248 Mb total memory in use INIT time0.00s ( 0.00s elapsed) MUT time 131.53s (133.03s elapsed) GCtime 98.25s (100.13s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time 229.78s (233.16s elapsed) %GC time 42.8% (42.9% elapsed) Alloc rate715,345,865 bytes per MUT second Productivity 57.2% of total user, 56.4% of total elapsed x86_64 version: 173,790,326,352 bytes allocated in the heap 59,874,348,560 bytes copied during GC (scavenged) 5,424,298,832 bytes copied during GC (not scavenged) 247,477,744 bytes maximum residency (9856 sample(s)) 331264 collections in generation 0 (111.51s) 9856 collections in generation 1 ( 67.80s) 582 Mb total memory in use INIT time0.00s ( 0.00s elapsed) MUT time 127.20s (127.76s elapsed) GCtime 179.32s (179.63s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time 306.52s (307.39s elapsed) %GC time 58.5% (58.4% elapsed) Alloc rate1,366,233,874 bytes per MUT second Productivity 41.5% of total user, 41.4% of total elapsed I've also added results from the 64 bit ghc-6.8.20071011 binary snapshot, which shows some nice improvements, with one benchmark improving by 30%(!). 151,807,589,712 bytes allocated in the heap 50,687,462,360 bytes copied during GC (scavenged) 4,472,003,520 bytes copied during GC (not scavenged) 256,532,480 bytes maximum residency (6805 sample(s)) 289342 collections in generation 0 ( 89.30s) 6805 collections in generation 1 ( 60.26s) 602 Mb total memory in use INIT time0.00s ( 0.00s elapsed) MUT time 83.79s ( 84.36s elapsed) GCtime 149.57s (151.10s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time 233.35s (235.47s elapsed) %GC time 64.1% (64.2% elapsed) Alloc rate1,811,779,785 bytes per MUT second Productivity 35.9% of total user, 35.6% of total elapsed I'll add some more benchmarks And I did. Below is a bit more detail from the log. The rc hash counts traverse a bytestring, hashing fixed-size words into Integers. As you can see, I haven't yet gotten the SPECIALIZE pragma to work correctly :-). The global alignment is the previous test, performing global (Needleman-Wunsch) alignment on pairs of sequences of length 100 (short) or 1000 (long), implementing the dynamic programming matrix as a list of lists. Start:Fri Oct 12 08:48:36 CEST 2007 Linux nmd 2.6.20-16-generic #2 SMP Fri Aug 31 00:55:27 UTC 2007 i686 GNU/Linux ghc 6.6 --- Sequence bench --- rc hash counts int (8) . OK, passed 10 tests, CPU time: 34.526157s rc hash counts int (16) . OK, passed 10 tests, CPU time: 34.746172s rc hash counts (16) . OK, passed 10 tests, CPU time: 34.642164s rc hash counts (32) . OK, passed 10 tests, CPU time: 35.378212s Sequence bench totals, CPU time: 139.292705s, wall clock: 139 secs --- Alignment bench --- global alignment, short . OK, passed 10 tests, CPU time: 2.696168s global alignment, long .. OK, passed 10 tests, CPU time: 90.481655s Alignment bench totals, CPU time: 93.177823s, wall clock: 94 secs Total for all tests, CPU time: 232.474528s, wall clock: 233 secs End:Fri Oct 12 08:52:29 CEST 2007 Start:Fri Oct 12 09:52:33 CEST 2007 Linux nmd.imr.no 2.6.22-13-generic #1 SMP Thu Oct 4 17:52:26 GMT 2007 x86_64 GNU/Linux ghc 6.6.1 --- Sequence bench --- rc hash counts int (8) . OK, passed 10 tests, CPU time: 36.634289s rc hash counts int (16) . OK, passed 10 tests, CPU time: 36.590286s rc hash counts (16) . OK, passed 10 tests, CPU time: 36.946309s rc hash counts (32) . OK, passed 10 tests, CPU time: 37.402338s Sequence bench totals, CPU time: 147.577222s, wall clock: 148 secs --- Alignment
Re: GHC benchmarks
Ketil Malde [EMAIL PROTECTED] writes: I've also added results from the 64 bit ghc-6.8.20071011 binary snapshot, which shows some nice improvements, with one benchmark improving by 30%(!). One difference between these runs is that the ByteString library, on which this particular benchmark depends heavily, got upgraded from fps-0.7 to bytestring-0.9. I initially thought some of the performance increase could be due to that, but after some contortions, I find that 6.6.1 with bytestring-0.9 gives me slightly worse results(!) (I haven't yet entirely convinced myself that I got this properly set up, but at least ghci lets me :m Data.ByteString.Lazy.Internals, which I believe is a new addition) Here are the numbers: --- Sequence bench --- rc hash counts int (8) . OK, passed 10 tests, CPU time: 38.778423s rc hash counts int (16) . OK, passed 10 tests, CPU time: 38.522408s rc hash counts (16) . OK, passed 10 tests, CPU time: 38.694418s rc hash counts (32) . OK, passed 10 tests, CPU time: 39.170448s Sequence bench totals, CPU time: 155.165697s, wall clock: 155 secs --- Alignment bench --- global alignment, short . OK, passed 10 tests, CPU time: 3.492218s global alignment, long .. OK, passed 10 tests, CPU time: 152.497531s Alignment bench totals, CPU time: 155.989749s, wall clock: 156 secs Total for all tests, CPU time: 311.155446s, wall clock: 311 secs -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC benchmarks
Hi, I've recently implemented some benchmarks for my library, and while I expected a slowdown for 64-bit code, I'm a bit bit surprised by the results. In summary: with 64 bit ghc 6.6.1, my benchmark runs in ~160 seconds with 32 bit ghc 6.6, it runs in ~ 95 seconds Most of the time is traversing a list of elements, doing a few numerical calculations. Presumably this is due to increased code size due to 8-byte pointers? I'll add some more benchmarks, but just wondered whether this was to be expeced, and, if so, whether I perhaps should be running a 32 bit version of GHC? I tried to Google for other benchmark results, but couldn't find any. Are there any particular GHC options I should use for compiling 64-bit code? I'll install 6.8 RSN, perhaps that will improve things? Oh, and if anybody wants to play with it, it should be possible to install Data.Binary and HXT, and then: darcs get http://malde.org/~ketil/bio cd bio make bench -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc 6.6 Debian packages
On Thu, 2007-07-05 at 12:11 -0400, Matthew Danish wrote: On Thu, Jul 05, 2007 at 11:15:03AM +0200, Christian Maeder wrote: Is there no way to provide all the extra libs in one debian package for ghc? It may be possible to create a package which depends on all normal extras but that seems counter-productive. Au contraire - I think that is a great way to go about it, and it is how a lot of things get done. Meta-packages include desktop environments (e.g. KDE and Gnome) and the Linux kernel (e.g. linux-generic). -k ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 2-days old in Haskell
On Fri, 2007-06-01 at 16:00 +0200, TOPE KAREM wrote: I opened a notepad and type this program: main = putStrLn Hello, Word! I saved this file as hello.hs in the same directory GHCi 6.6.1 was installed. You can store it anywhere, as long as GHC is in your search path. When I tried to compile it as instucted on the webpage ( $ ghc -o hello hello.hs), I got this error message. interactive: 1:0: parse error on input '$' please what am I doing wrong. Several things :-) You don't usually compile from within GHCi, but rather from a system command prompt. And: the dollar sign is the typical Unix command prompt, you're not supposed to type it in. Generally, you're better off using the make option to ghc, type ghc --make hello.hs instead. -k ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: isSpace is too slow
On Sun, 2007-05-20 at 16:59 +0100, Duncan Coutts wrote: isSpace c = c == ' ' || c == '\t'|| c == '\n'|| c == '\r'|| c == '\f'|| c == '\v'|| c == '\xa0' || iswspace (fromIntegral (ord c)) /= 0 iswspace does a generic lookup in the unicode property database I think. So there's little hope of beating iswspace unless your input contains a lot of spaces, I guess - for all non-space, we call iswspace, which presumably repeats the tests for ASCII space. Wouldn't something along these lines be more efficient? isSpace :: Char - Bool isSpace = isSp . ord isSp c | c = 13= c = 8 -- \b..\r | c = 127 = c == 32 -- ' ' | c = 255 = c == 0xa0 -- nbsp | otherwise = iswspace(..) A quick test shows about a factor two improvement on /usr/share/dict/words, but that will of course only trig the first match. -k ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Feature proposal: ghc --full-flag-help ?
Simon Peyton-Jones [EMAIL PROTECTED] writes: Suppose ghc --full-flag-help simply printed the URL http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html Or suppose it did 'system(man ghc)'? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: find module of `fromJust Nothing'
Serge D. Mechveliani wrote: On Mon, Nov 13, 2006 at 12:17:07PM +, Simon Peyton-Jones wrote: The Maybe.fromJust: Nothing comes from the library code itself. The Nat1 part is simply the name of the binary. It give no clue to who called fromJust. I do not understand the whole idea. First, the same problem is for many functions: head, tail, and others. I often end up using CPP to #define replacements for these, using the __LINE__ and __FILE__ macros to identify the source of the error. -k ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Benchmarking GHC
Neil Mitchell [EMAIL PROTECTED] writes: I want to benchmark GHC vs some other Haskell compilers, what flags should I use? [...] I guess the answer is -O2 -fvia-C? I tend to use -O2, but haven't really tested it against plain -O. From what I've seen -fvia-C is sometimes faster, sometimes slower, I tend to cross my fingers and hope the compiler uses sensible defaults on the current architecture. One thing that IME makes a difference is -funbox-strict-fields. It's probably better to use pragmas for this, though. Another thing to consider is garbage collection RTS flags, those can sometimes make a big difference. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Packages in GHC 6.6
Bulat Ziganshin [EMAIL PROTECTED] writes: 1. Simon suggests that there is a core GHC distribution. it should be GHC _compiler_ itself and contains only libraries whose implementation are closely tied to compiler version [...] 2. For windows-like OSes where users prefer to see larger monolithic installations we should include more libraries in standard distribution. I'd like to see this (an extra-libs) package to be more than just a bandaid for package management deficiency. A standard library install could encourage the use of those libraries, and perhaps also work as a recommendation of specific libraries. I'd certainly encourage (virtual) Debian/RPM-packages that depend on the standard package bundle, so that it is easy to get the standard libraries for a default installation, and to get coherent installations on different machines. I suggested to exclude from list above graphics/sound I'd prefer to include libraries if they are stable, useful, and provide unique functionality. I'm a bit ambivalent of including libraries with overlapping functionality - while I expect opposing this to be futile, I do think it is better to focus effort on a single standard implementation. Oh, and while this is currently a GHC issue, it would be nice if other systems supported the same set of libraries. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why is there no splitBy in the list module?
Marc Weber [EMAIL PROTECTED] writes: There is already lines. Why not generalise it to take an additional parameter '\n' and call it split or splitBy? There are some cases where you want to split a list not on '\n'. Indeed, and in e.g. ByteString and MissingH, there are more functions of this kind. I find that I've needed split/break type functions of various kinds, and the standard functions don't seem to be too consistently named. I think it would be nice to have an orthogonal product of predicate types: () a a-Bool [a]-Bool (of increasing generality) and result types: ([a],[a]) and [[a]] (split one - split all). -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: package lang
Doaitse Swierstra [EMAIL PROTECTED] writes: but when i try to compile lhs2TeX I get the following error message: /usr/local/bin/ghc -O -package lang --make -o lhs2TeX Main.lhs [..] Did you try without the '-package lang'? I think 'ghc --make' is rather effective at automatically determining which packages to include. (Also, I'm not sure why you include all the source files together with --make, since --make tracks down dependent modules and compile them automatically.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Packages and modules
Simon Peyton-Jones [EMAIL PROTECTED] writes: Brian Hulley wrote: | import A.B.C( T1 ) from foo | import A.B.C( T2 ) from bar | type S = A.B.C.T1 - A.B.C.T2 | I'd suggest that the above should give a compiler error that A.B.C is | ambiguous (as a qualifier), rather than allowing T1 to disambiguate it, But that's inconsistent with Haskell 98. FWIW, I agree with Brian that this is not good practice. If it can't be forbidden, I would suggest that compilers emit a warning about it. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Packages and modules
Brian Hulley [EMAIL PROTECTED] writes: because if the suggested syntax is used, import directives come in two flavours: ones that use from to import from a different package and ones that don't use from and therefore must refer to the current package. What is the current package? My impression was that from would only be needed when there was ambiguity. (And if I wanted to type myself to death, I'd be using Java :-) If you *have* to specify package, this makes things a lot less flexible (e.g., moving a module from one package to another will break code) Would 'base' be the current package in most cases? That would encourage cramming even more stuff into base¹, and I suspect the overloaded 'base' is half the reason we're discussing all this extra syntactical baggage. (E.g. experimenting with a newer version of Don's FPS, I basically need to replace 'base'. With the features being discussed, I could get by rewriting the import statements in all my fps-using code, which would be an improvement. It'd be much safer and better to have a compiler option, of course, but I guess that will only work for complete packages.) Anyway (and like you say) I think the workaround using qualification or hiding is more than sufficient, I consider recycling names from imported modules for local variables questionable as best, and would rather it wasn't encouraged. 3) Syntax: I liked Ian Lynagh's suggestion of using from to start either a single import directive or a block of import directives http://www.haskell.org//pipermail/haskell-cafe/2006-June/016338.html eg (modified to use quotes): from base import Predude hiding(length) import Control.Exception import qualified Data.List as List Would this make 'from' a reserved word? I think this is only useful if you require the module to be declared, and thus not worth an extra keyword (and code breakage) if non-ambigous modules can still be imported. Anyway, I'd just like to say that I'm really happy about the way GHC and Cabal currently works - 'ghc --make' takes care of package imports, and Cabal is simple enough that most of my code gets Cabalized these days. -k ¹ What *is* the advantage of stuffing everything and the kitchen sink into base, btw? -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [GHC] #710: library reorganisation
Bulat Ziganshin [EMAIL PROTECTED] writes: sorry for repetition, but ByteString library in its current state still don't replaces PackedString in functionality, because it don't support full Unicode range of chars What would be required for it to replace PackedString? (If that is a goal?) If I understand correctly, PS is an array of Word32, and ByteString is (obviously) an array of Word8. Would it be sufficient if there was a 'Char' interface supporting all of Unicode (the obvious candidate encoding being UTF-8), or must it support UCS-2 and UCS-4 directly? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [GHC] #710: library reorganisation
Bulat Ziganshin [EMAIL PROTECTED] writes: IMHO, because PackedString is anyway abstract and DON'T support any way to see it's internal representation, any implementation that supports full unicode range, would be enough. Perhaps I'm misrepresenting FPS here, but from my POV, the representation is very much the issue. I see the typical use for FPS to be a case where you have some data (files, network buffers, whatever), which is, essentially, a string of bytes. The Char interface(s) to FPS is, in theory, encoding agnostic, but in practice, it will be limited by the underlying encoding. IMO, that is okay, as long as the interesting encodings are supported. Note that ByteString.UTF8 is *not* going to be a replacement for the other encoding-specific modules, since that would mean you would have to do an (expensive) conversion of non-UTF8 data. The current scheme allows you to work with a universal Unicode interface (based on Char), but keeping the data in its 'native' representation. The question is how to extend this to muliti-byte fixed encodings (UCS-2 and UCS-4), and variable encodings (UTF-8, UTF-16, UTF-32, Shift-JIS, and why not Quoted-Printable?). I feel confident it can be done, but it is likely to involve some policy decisions and trade offs. -k PS: I implemented another single-byte encoding, Windows-1252. This builds everything from a charset table, and while currently not too efficient, should make it very easy to add other single-byte encodings. As usual: darcs get http://www.ii.uib.no/~ketil/src/fps-i18n -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: getrlimit -M
Simon Marlow [EMAIL PROTECTED] writes: John Meacham wrote: perhaps if -M is not otherwise set, 'getrlimit(RLIMIT_AS,..)' could be called and the maximum heap size set to just under that Of course, it is commonly set to 'unlimited' anyway. Perhaps I should limit it; OTOH, the value must be less than 2Gb (signed int), which will soon be on the small side for a modern workstation. For my programs, I've found that setting -M to 80% of physical tends to work well. Beyond that, I get thrashing and lousy performance. (Perhaps programs mmap'ing large files etc can work well beyond physical memory? I'd be interested to hear others' experiences.) Quite often, I find the program will run equally well with smaller heap (presumably GC'ing harder?). I think it would be a good default to at least try as hard as possible to keep heap smaller than physical RAM. (Caveat: I'm on a Linux system which doesn't work wery well with heap sizes at the moment, so my observations may not apply.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc releasing memory during compilation
Simon Marlow [EMAIL PROTECTED] writes: So it used more than double the amount of memory. Is it reproducible? I expect that the -M value might be exceeeded by a small amount sometimes, but double is surprising. Yes. That is, I was running multiple instances on different CentOS computers, all of them went way over the specified amount. Instances on Rock Linux/AMD64 stayed below. This is using the same executable, statically linked. However, when I specify low bounds, it runs out of heap as expected. Please supply the source, it saves time trying to reproduce. $ darcs get http://www.ii.uib.no/~ketil/bioinformatics/repos/rbr $ cd rbr/src; make rbr_s # - _s for the statically linked version $ wget http://www.ii.uib.no/~ketil/tmp/rbrdata.seq $ ./rbr_s rbrdata.seq +RTS -MxM For x=400 or 800, this grows apprarently without bounds, for x=100, it terminates with heap exhaustion. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc releasing memory during compilation
I think I complained earlier about '+RTS -MxxxM' not being respected, but was unable to reproduce the issue. I just saw this again, my process was, I thought, limited to 800M heap, but, just before I gave up and killed the process, 'top' told me: 18580 ketil 18 0 1762m 945m 256 D 3.0 93.5 33:52.81 rbr So it used more than double the amount of memory. However, running the same executable with the same -M option on a different computer, it stayed firmly at 32139 ketil 25 0 779M 779M 872 R99.8 9.9 16:17 0 rbr Apparently, there is some subtle difference between the two systems that causes the RTS's heap limitation to fail. The uname -a on the two systems say: -M works: Linux ... 2.4.21-32.0.1.ELsmp #1 SMP Wed May 25 13:51:11 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux -M fails: Linux ... 2.6.9-22.EL #1 Sat Oct 8 17:48:27 CDT 2005 i686 i686 i386 GNU/Linux Let me know if there's any other information I can supply. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc releasing memory during compilation
Ketil Malde [EMAIL PROTECTED] writes: 18580 ketil 18 0 1762m 945m 256 D 3.0 93.5 33:52.81 rbr So it used more than double the amount of memory. I can provide the source, but perhaps I should mention that the program basically just builds a large Map Int Int. No tricky FFI, arrays or anything, at least not explicitly in my code. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal: Improved error message of Error in array index
Tomasz Zielonka wrote:
On Tue, Nov 08, 2005 at 02:43:47PM +, Malcolm Wallace wrote:
Of course, there is the old stand-by C pre-processor trick:
#define superError(s) error (s++\nin file ++__FILE__ \
++ at line ++__LINE__)
There is a nice trick I saw in darcs' code to make this even more
Haskellish:
#define superError (\s - error (s++\nin file ++ __FILE__ \
++ at line ++ show (__LINE__ :: Int)))
so you can simply write:
superError message
Don't you also need to define head as a CPP macro (otherwise you'll
just get the location of head,
and I'm sure you know where to find that already)?
#define head (\xs - case xs of { (x:_) - x ; _ - superError head:
empty list})
Unfortunately, I don't think CPP will play nicely with operators like ! :-(
There really should be a better way to do this, head: empty list,
read: no parse etc is high on my list of Haskell annoyances.
-k
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal: Improved error message of Error in array index
Simon Marlow wrote: Hmm yes, this is indeed rather unhelpful. I can explain why it happens, though. The compiler has lifted out the error case into a top-level binding: x = error Error in array index Would the compiler be less agressive with this if I turn off optimization? I usually use optimization with profiling as well, but could of course turn it off if it would result in more useful stack backtraces. -k ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Profiling and Data.HashTable
Jan-Willem Maessen [EMAIL PROTECTED] writes: The practical upshot is that, for a hash table with (say) 24 entries, the GC must scan an additional 1000 pointers and discover that each one is []. Would a smaller default size help? In my case, I just wanted HTs for very sparse tables. [Curious: what (if anything) is being used to test Data.HashTable? I'd be willing to undertake very small amounts of fiddling if I could be sure I wasn't slowing down something which mattered.] I'd be happy to test it (or provide my test code). My program isn't too beautiful at the moment, but is tunable to distribute the word counts over an arbitrary number of hash tables. BTW, could one cheat by introducing a write barrier manually in some way? Perhaps by (unsafe?) thaw'ing and freeze'ing the arrays when they are modified? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Profiling and Data.HashTable
Hi all, I have a program that uses hash tables to store word counts. It can use few, large hash tables, or many small ones. The problem is that it uses an inordinate amount of time in the latter case, and profiling/-sstderr shows it is GC that is causing it (accounting for up to 99% of the time(!)) Is there any reason to expect this behavior? Heap profiling shows that each hash table seems to incur a memory overhead of approx 5K, but apart from that, I'm not able to find any leaks or unexpected space consumption. Suggestions? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to make Data.Set.Set a Functor
Lajos Nagy [EMAIL PROTECTED] writes: On the other hand, it seems intuitively natural to make Set an instance of fmap. Indeed. While I generally like the overloaded, qualified names, I find it annoying when, like 'map', they clash with Prelude imports. Which means that, in a module using Data.Set, I must either use it all qualified, or import it twice (qualified and hiding map), or explicitly import Prelude hiding map. (Better solutions wanted!) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to use Data.Set.Set
Christian Maeder [EMAIL PROTECTED] writes: I think, you should import qualified Data.Set as Set only and use Set.map rather than the deprecated mapSet (most other names from Data.Set make more sense with the Set. prefix) I can do this of course, but I think it would be nice to be able to use it unqualified in modules that only uses Sets (and doesn't use e.g. Maps or List.(null|map)). If I always have to qualify it, what is the advantage of Set.map instead of mapSet? (Oh, right, I can import qualified List as Set -- but then I still have to change member to elem etc etc.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Default name of target executable
Simon Marlow [EMAIL PROTECTED] writes: I'm slightly inclined not to make this change, but I could be swayed if there was enough interest in it. What I'm seeing so far is not overwhelming support for the change. Simon PJ is in favour, though. a.out is tradition, of course, but OTOH, I don't think anybody actually depends on it. Could it perhaps be made optional, either through a config file (.ghc?) or an environment variable, or some such? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Default name of target executable
Tomasz Zielonka [EMAIL PROTECTED] writes: Because of this long syntax and comand-line completion I've even once lost the source code. I forgot to remove the .hs at the end of line: $ ghc --make Prog -o Prog.hs If you want, I can tell you about this great version control system I'm using :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Profiling and analysing space usage
Alistair Bayley [EMAIL PROTECTED] writes: I'm no expert, but since nobody else seems to have answered: - is my analysis of the space usage correct i.e. allocation in the loop function is very short-lived and nothing to worry about? IME, that would be the typical case. - is there anything I can do to reduce the memory usage, or is it already minimal, assuming that I'm happy with the size of the STArrays? I realise I could use, say, PackedStrings Slightly more general, you could use unboxed STUArrays. Still limited to a few built-in data types, and strict. E.g. a STUArray Int Word8 would only take up one byte per element, an STArray would store a (4 byte) pointer in each cell, pointing either to a Word8 value, or to a lazy thunk for computing it. At least as far as I understand it. (Manuel's paper notwithstanding, I still have the feeling that *UArrays should be *StrictArrays, and unboxing should be left as a compiler optimization (which then could apply to arbitrary element types, as long as they were strict.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: (no subject)
Amit rohatgi [EMAIL PROTECTED] writes: I want to install DARSC and for that i need GHC .. What architecture? Isn't there a pre-packaged binary version available that you can use? I dont have any old version of Ghc already on the comp so i need the *.hc files from any version 6-?-? to compile ghc. Again, can't you get a binary version for your architecture? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HOME: getEnv: does not exist
Malcolm Wallace [EMAIL PROTECTED] writes: I think runghc is acting like GHCi, and trying to read the file $HOME/.ghci on startup. I toyed with this, and it seems like runghc is forking off a ghc process, which then tries to read .ghci (and possibly .inputrc) from the $HOME directory. Unfortunately, while runghc apparently parses -ignore-dot-ghci (i.e. it refuses illegal options), it later on seems to treat it's a source file to run. As far as I can tell. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
seeking array advice
Hi, I'm about to rework an old program, and I am pondering what data structure to use. Basically, I want to store an index of fixed-length words (q-grams) with positions, i.e. given a word, I can quickly find its position in the data. The data set may be large (gigabytes would be nice), and I also want the option of storing a sparse set of the words in the data (i.e. every other word, every third, etc). I *think* I want to use a Map from words to positions, words packed to fit in Int(32|64|eger) (depending on word size), and positions as Int(32|64). I've used a similar approach with FiniteMaps previously, and it worked nicely, but for smaller data sets. However: Using a 'Map key [pos]' will eat a lot of space for the lists. 'Map key (UArray Int pos)' will be more efficient, but every insertion and deletion will destroy and create a new array -- and I would like the Map to live outside a monad (does there even exist an (IO|ST)Map?) I've considered lists of small(ish -- cache line compatible, probably) arrays. Another possibility is a suffix array, and a Map from words to regions in it. How will a hashtable work in this setting? Any thoughts? -kzm PS: it seems from a recent thread in comp.lang.functional (see [EMAIL PROTECTED]) that array performance has improved in GHC6.4. Impressively so. -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: hyperlinks in Haddock docs
Simon Marlow [EMAIL PROTECTED] writes: There are some problems with the existing approach. It doesn't cope well with instances: instances might refer to types/classes not below the current module in the hierarchy. Also you might import an entity from a hidden module, but actually want to hyperlink to another module Thoughts? Better ideas? If it turns out to be difficult to determine where to link, one option could be to link to a separate table on the same page, listing the candidates? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: hyperlinks in Haddock docs
Simon Marlow [EMAIL PROTECTED] writes: Hmm, I'm not sure that would be practical. Lots of entities are exported from more than one place, especially Prelude entities. You'd have a table on almost every single page listing Bool, Maybe, Int, etc. But surely in many cases, it would be possible to determine which link is relevant, and go directy? I was under the impression that there were some difficult cases (you mentioned type classes) that tended to mess things up -- I would of course only advocate the indirect approach if it's difficult to do it directly. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem with DB and Char size
Santoemma Enrico [EMAIL PROTECTED] writes: The problem is: Oracle ODBC driver expects, at least under Windows, UCS-2 strings. Then, if the DB is set to UTF-8, it converts the string into UTF-8. I'm using HSQL to access ODBC. Isn't UCS-2 the old 16-bit Unicode representation? So that converting from ASCII simply involves interspersing zero-bytes? And converting from a String (of Unicode codepoints from a subset of UCS-2), can be done with a divMod operation. So if you can generate the correct string of bytes this way, withCString should work, shouldn't it? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [ ghc-Feature Requests-1104381 ] Add wxHaskell link to homepage
Simon Marlow [EMAIL PROTECTED] writes: It's intentional, but it can be easily turned off. Do people want to see feature-requests, task-list entries and so forth on this mailing list, or should they be confined to, say, [EMAIL PROTECTED] I would vote to put them in a separate list. At least in the current form, it looks like an anonymous message with various URLs and auto-generated text, and not like something I expect from a -users mailing list. Alternatively, they could perhaps be formatted to resemble a more normal e-mail? IMHO, anyway. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [ ghc-Feature Requests-1104381 ] Add wxHaskell link to homepage
I seem to be getting messages from Sourceforge from this mailing list. Is that an intended use for ghc-users? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: posting
Kenny Chamber [EMAIL PROTECTED] writes: How long after posting should it take for a message to appear on the list? It should be pretty fast, but some lists moderate posts by non-subscribers. Could this be your problem? For timing, we could look at your headers: Date: Thu, 16 Dec 2004 07:33:39 +0300 From: Kenny Chamber [EMAIL PROTECTED] You sent it today, at 07:33:39 +0300 (4:33 UTC). Early bird, huh? Received: from [195.190.104.65] (spb-195-190-104-65.sovintel.ru [195.190.104.65] (may be forged)) (authenticated bits=0) by mail2.hqhost.net (8.12.11/8.12.11) with ESMTP id iBG4Xgt8098072 for [EMAIL PROTECTED]; Thu, 16 Dec 2004 04:33:44 GMT 5 seconds later, it is at mail2.hqhost.net, presumably your outgoing mail server. Received: from mail2.hqhost.net (mail2.hqhost.net [64.237.37.220]) by www.haskell.org (Postfix) with ESMTP id 1DD51368816 for [EMAIL PROTECTED]; Wed, 15 Dec 2004 23:21:54 -0500 (EST) www.haskell.org gets it the day before, but is on the American east coast. I make it 4:21 UTC, though, so one of you isn't running NTP like he or she should. Delivery-date: Thu, 16 Dec 2004 05:33:52 +0100 I don't know who adds this. Received: from haskell.cs.yale.edu (localhost.localdomain [127.0.0.1]) by www.haskell.org (Postfix) with ESMTP id 50D48368835; Wed, 15 Dec 2004 23:21:56 -0500 (EST) Received: from bugs.haskell.org ([128.36.229.215]:53008 helo=www.haskell.org) (So - what's *really* the name of this computer?) by eik.ii.uib.no with esmtp (Exim 4.30) id 1CenKp-0002qk-8z for [EMAIL PROTECTED]; Thu, 16 Dec 2004 05:33:51 +0100 Ends up in my inbox at 05:33:51, subtract one hour if you want UTC. The full trip done in twelwe seconds. If we trust the timestamps to have that good resolution. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Double - CDouble, realToFrac doesn't work
With GHCi, I get: Prelude Ratio toRational (1.0/0) :: Ratio Integer 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 % 1 My personal gut feeling is that converting a NaN/Inf/etc to a fraction should be an error (although I see the point of being able to convert a e.g. Float to a Double and preserve such special values). Is it possible to provide a conversion function in the Floating or RealFloat class instead? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: constant space `minimum'
Serge D. Mechveliani [EMAIL PROTECTED] writes:
The library functions like minimum, maximum, should perform in a
constant space: probably, it is easy to write them his way.
I haven't given it much thought, but it seems that the rather obvious:
Prelude minimum [1..10^6]
*** Exception: stack overflow
Prelude :i minimum
-- minimum is a variable
minimum :: forall a. (Ord a) = [a] - a
Prelude let { mini m (x:xs) = if m = x then mini m xs else mini x
xs; mini m [] = m}
Prelude let minimum' (x:xs) = mini x xs
Prelude minimum' [1..10^6]
1
does the trick (unlike the foldr version, which presumably is used by
the Prelude). No?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC and MPTCs
Hi, I recently tried to do the following code: class VertexState s v where new_point :: s - v - v - v next_state :: s - s -- interleave :: (VertexState s a) = s - [a] - [a] - [a] interleave s (t:ts) (b:bs) = new_point s t b : interleave (next_state s) bs (t:ts) interleave _ [] [b] = [] Firstly, GHC doesn't deal all too gracefully with this if the type signature is uncommented, it tells me: Could not deduce (VertexState s v) from the context (VertexState s a) arising from use of `next_state' at Grid.lhs:25 Probable fix: Add (VertexState s v) to the type signature(s) for `interleave' Unfortunately, doing the probable fix just results in a new request for (VertexState s v1), and so on. I suppose the real problem is that GHC can't decide from next_state that it is supposed to use exactly this instance of VertexState, is there a good way to do that without adding an explicit dummy parameter of type v? (I really would like to be able to have instances with the same s but different v's, which I think adding functional deps would make difficult.) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and MPTCs
MR K P SCHUPKE [EMAIL PROTECTED] writes: Try type annotations: [slightly edited to keep the different s's differentiated] new_point (s0::s) t b : interleave (next_state s0::s) bs (t:ts) Hmm...I get: Inferred type is less polymorphic than expected Quantified type variable `s' escapes It is mentioned in the environment: s0 :: s (bound at Grid.lhs:25) When checking the type signature of the expression: s0 :: forall s. s -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Parallel
Simon Marlow [EMAIL PROTECTED] writes: For the GPH project, go here: http://www.macs.hw.ac.uk/~dsg/gph/ There's also a bit of information in: http://www.haskell.org/communities/05-2004/html/report.html#gph -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Compiling data
Hi, I've recently tried to compile some data into my program, and suddenly I realize why people tend to complain about the speed of GHC. For a benchmark, I'd like to include a bit of data in the form of a list of integer matrices (i.e. [[[Int]]]). While I have about 1 of them, sized about twenty square, even 100 of them takes extremely long to compile. Is there a trick to make this faster? (For short lists (1-8 matrices), time seems to scale linarly, but the 100-matrix took much longer than expected from a simple extrapolation) Also, it takes a long time before any error is produced, it'd be nice if syntactical problems were reported as quickly as possible (perhaps they are?) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compiling data
Christian Maeder [EMAIL PROTECTED] writes: We have put a large list in double quotes and used read to convert the large literal string (too big for hugs, though) into the needed list. This reduced compile time drastically, but I don't know how the runtime changed. (Also errors can only occur at runtime.) Yes, that seemed to do the trick! Don't think there was much of a runtime cost, certainly less than the previous compile cost. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: checking for a working System.Console.Readline
| readline Since you mention readline - I have a rather tiny nit to pick: ghci happily completes filenames starting with ~ (indicating home directory), but file operations typically don't grok it. As I said, hardly an earth shattering show stopper, but a small wart that might be easy to remove? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: sizeFM type
David Roundy [EMAIL PROTECTED] writes: I'd say that rather than returning an Integer, we'd be better off just using a 64 bit Int on 64 platforms. | 7.19.2. GHC's interpretation of undefined behaviour in Haskell 98 | | This section documents GHC's take on various issues that are left | undefined or implementation specific in Haskell 98. | | Sized integral types | |In GHC the Int type follows the size of an address on the host |architecture; in other words it holds 32 bits on a 32-bit |machine, and 64-bits on a 64-bit machine. Looks like a reasonable way to go about it. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: turn off let floating
Bernard James POPE [EMAIL PROTECTED] writes: Note each program was compiled with ghc 6.2 with -O2 on debian linux. : main = print $ loop 1 0 Isn't this going to be optimized away to a constant with -O2? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Haskell profiling and performance
Hi, Am I doing something wrong, or did profiling performance drop an order of magnitude with GHC 6.2? When I compile my program with '-prof -auto-all', it takes about ten times as long to run as it does without. I use -O2 in both cases, and run without any run-time profiling options switched on. (The reported time, OTOH, seems about right) I though that previously profiling-compiling programs would only have marginal effects, and only running with heap profiling on would really slow things down. If this is a recent 'feature' and not just my brain getting its wires crossed again, is there any way to alleviate this (downgrade to x.y, build CVS HEAD, whatever)? (GHC 6.2 on Linux, tested with RPM package and Gentoo binary distribution) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haskell performance
Sébastien Pierre [EMAIL PROTECTED] writes: I am currently evaluating different languages for implementing an application which will have to manipulate large graphs representing the structure of programs and their evolution. Speed is in fact a crucial criterium for the language choice. In my experience, Haskell is slow on a couple of accounts. First, I have problems getting IO to run at anything resembling C speeds. I've messed around with array IO and whatnot, but there still seems to be an order of magnitude or two. I don't know how to fix this, there have been a few remarks that indicate people can solve it, but there are still unanswered requests. If you figure it out, please let me know. Second, GHC tends to gobble a lot of memory. I think (somebody correct me if I'm wrong) a data structure like data Foo = Bar Bool Bool Bool will typically use four machine words (16 bytes) in addition to the data contents itself. You can improve things if you can make the data structure stricter, or if you can store things in UArrays instead of lists, and so on. I'd love to have a compiler that was, aggressively packing my data structures, but in the meantime, I'll just hide behind an abstract interface, and store things directly in Word datatypes. Related to this, some algorithms are slower when implemented in Haskell due to boxing and more indirection. For complex data structures (like your graph stuff probably needs), you will need much of this anyway, and implementing this in C is going to be error-prone and time consuming, and of course equally slow. Third (fourth?), Haskell is often too lazy by default, a bit of strictness will often help speed things up tremendously. Be prepared to spend a lot of time profiling time and memory to squeeze the last drop of performance from your program. For now, the (somewhat unpleasing) conclusion I came with is that a Java (app core), Python (proto, UI) plus some interfaced C++ libs would be OK... I think these are extraordinary choices if, as you say, speed is the most important factor. I would recommend Haskell for speed of development and correctness of implementation, but (probably) C for speed. You can of course combine the two with the FFI, but I don't know how trivial it is to pass Haskell graph structures to C and back. What do you Haskell-experts Oh, did I mention that I'm not an expert? I just play one on mailing lists :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haskell performance
MR K P SCHUPKE [EMAIL PROTECTED] writes: To do the equivalent of the C you could use: http://www.haskell.org/~simonmar/io/System.IO.html Is this documented anywhere? How do I use this? The Haddoc documentation is a bit sparse. This seems quite different from the System.IO module installed with GHC 6.2, what's the relationship? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haskell performance
Simon Marlow [EMAIL PROTECTED] writes: http://www.haskell.org/~simonmar/io/System.IO.html The difference is that the System.IO that comes with GHC is actually implemented, rather than just documented :-) Ah. Drat. You know, it really looks good, and I really could use efficient file access, but I'm afraid I really need an implementation, too. :-) (to clarify, that link above is a half-baked design for a System.IO replacement. The discussion was taking place on [EMAIL PROTECTED] a while back, but has stalled). Okay. What's really bothering me is that I can't find any good indication of what to do to get IO faster. Do I need to FFI the whole thing and have a C library give me large chunks? Or can I get by with hGet/PutArray? If so, what sizes should they be? Should I use memory mapped files? I'm willing to put in some work, accept some kluges, and so on, but I can't really blindly try all possible combinations with my fingers crossed. Some people seem to manage to speed things up, but I can't seem to find anything *specific* anywhere. E.g. when I posted a snippet to do readFile¹ in somewhat larger chunks a while ago, I was hoping somebody would say, hey, that's just stupid, what you need to do instead is... or point me to TFM, but unfortunately only silence ensued, and left me a sadder but none the wiser man... -kzm ¹ Message-ID: [EMAIL PROTECTED], on [EMAIL PROTECTED] -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Stack space overflow after optimization
Christian Maeder [EMAIL PROTECTED] writes: Stack space overflow: current size 1048576 bytes. Use `+RTS -Ksize' to increase it. only when translated with -O. Is it possible that the next release of ghc uses a higher stack size at least when the -O flag is set? (Only to reduce the likelyhood that our users need to supply RTS flags.) Also, profiling seems to increase stack usage. Perhaps the 1M limit is overly conservative? Maybe it is even possible to add a ghc flag that allows to set the default Ksize of the generated programs. Someone told me to link in an additional header file, but maybe you can supply a more convienent solution. It's fairly simple; you just need to define the approprate constant in a C file, compile and link it with your program proper. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: optimization question
John Meacham [EMAIL PROTECTED] writes: The reason I ask is I am writing someting which will generate large case statements [over strings] and want to know if I should bother pre-optimizing it to [search tries]¹ I've no idea what compilers do, but one quick-and-dirty way to optimize this could perhaps be to insert the strings into a FiniteMap, and use lookupFMWithDefault(?) to get the resulting value? -kzm ¹ I think this is an accurate representation of your question? -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to write this correct...
[EMAIL PROTECTED] (Hans Nikolaus Beck) writes: type GLVertex = (GLfloat,GLfloat,GLfloat) toVertex :: GLVertex - Vertex3 GLfloat toVertex :: (a,a,a) - Vertex3 a Yes this works (the first variant). Thanks ! But I must say that I have problems to understand The problem is that you tried to tell the compiler that toVertex would return a parametrised type, namely 'Vertex3 a', but that the compiler sees that toVertex, when given a 'GLVertex' always will produce 'Vertex3 GLfloat'. the class mechanism in its full extend Classes doesn't have anything to do with this. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: detecting memory size?
Joachim Durchholz [EMAIL PROTECTED] writes: What I really want is the amount of memory my application can allocate and excercise lively without causing thrashing. On my Linux computer, that amounts more or less to the installed, physical RAM, minus a bit, so I'll settle for that. :-) An easier way would be to make this a configuration option at installation time - the justification being that users probably have a better idea of how much RAM should be allowed to the program. Actually, there is currently a parameter to use at run-time. The problem is that it is a time/space trade-off; if this parameter is set too conservatively, the program will be unnecessarily slow, if too liberal, the program will thrash, giving you on average about 5% CPU. In this case, it's better to crash early with OOM. (And the optimal setting depends on the data -- not just data size.) So the point of this excercise is to attempt to automatically determine a reasonable default. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
detecting memory size?
Hi, Is it possible to detect memory (i.e. RAM, not virtual memory) size from inside a Haskell program (so that I can keep my program from growing too large with consequent thrashing)? And if so, to what degree of portability? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: detecting memory size?
Glynn Clements [EMAIL PROTECTED] writes: What do you mean by memory size? How much RAM is installed in the system? The amount which the process is currently using? The amount which the OS might be willing to allocate to your process at any given point in time? Something else? My aplogies for being unclear! What I really want is the amount of memory my application can allocate and excercise lively without causing thrashing. On my Linux computer, that amounts more or less to the installed, physical RAM, minus a bit, so I'll settle for that. :-) (After browsing various information, it seems I'm after the minimum of physical RAM and getrlimit(RLIMIT_DATA)). On Linux, you can read /proc/* (e.g. /proc/meminfo) with readFile, getrusage() is relatively portable across Unix variants Perhaps the best approach would be to use getrusage(), and try to decrease memory use if/when there is a lot of page faults happening? BTW, I've started looking into this after a similar problem was mentioned on the darcs list[0]. -kzm [0] http://www.abridgegame.org/pipermail/darcs-users/2004/001022.html -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: detecting memory size?
Glynn Clements [EMAIL PROTECTED] writes: IIRC, getrlimit(RLIMIT_DATA) doesn't mean much on Linux, as it doesn't include memory which is added using mmap(..., MAP_ANON), which is used by glibc's malloc(). Also, getrlimit(RLIMIT_RSS) is probably more relevant for your purposes. I also got a reply from David Roundy (the author of darcs); he is using sysconf(3), which apparently is fairly portable, and suffices to at least obtain the amount of physical memory. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Talking with the compiler
[EMAIL PROTECTED] (Hans Nikolaus Beck) writes: in order to build a programming environement, it would be nice to ask the GHC about symbols etc found in a given Haskell program. I suppose a programming environment could talk to GHCi (which provides commands like :type, :info, :browse to explore the currently defined symbols)? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Working character by character in Haskell
Simon Marlow [EMAIL PROTECTED] writes: Well, in Haskell each character of the string takes 20 bytes: 12 bytes for the list cell, and 8 bytes for the character itself Why does a list cell consume as much as 12 bytes? Two pointers (data and next) and a 32-bit tag field, perhaps? And a 64-bit minimum allocation quatnity, accounting for the 8-byte character? Isn't it possible to optimize this, e.g. by embedding small data directly in the cons cell? 21 bits for a Unicode character should leave enough bits for tagging, shouldn't it? (Since I'm halfway planning to use Haskell next Spring to process long lists of data with a small set of values (for instance: data Base = A | C | G | T ) I'm curious about the performance.) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UniCode
Dylan Thurston [EMAIL PROTECTED] writes: Right. In Unicode, the concept of a character is not really so useful; After reading a bit about it, I'm certainly confused. Unicode/ISO-10646 contains a lot of things that aren'r really one character, e.g. ligatures. most functions that traditionally operate on characters (e.g., uppercase or display-width) fundamentally need to operate on strings. (This is due to properties of particular languages, not any design flaw of Unicode.) I think an argument could be put forward that Unicode is trying to be more than just a character set. At least at first glance, it seems to try to be both a character set and a glyph map, and incorporate things like transliteration between character sets (or subsets, now that Unicode contains them all), directionality of script, and so on. toUpper, toLower - Not OK. There are cases where upper casing a character yields two characters. I though title case was supposed to handle this. I'm probably confused, though. etc. Any program using this library is bound to get confused on Unicode strings. Even before Unicode, there is much functionality missing; for instance, I don't see any way to compare strings using a localized order. And you can't really use list functions like length on strings, since one item can be two characters (Lj, ij, fi) and several items can compose one character (combining characters). And map (==) can't compare two Strings since, e.g. in the presence of combining characters. How are other systems handling this? It may be that Unicode isn't flawed, but it's certainly extremely complex. I guess I'll have to delve a bit deeper into it. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UniCode
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] writes: Fri, 5 Oct 2001 02:29:51 -0700 (PDT), Krasimir Angelov [EMAIL PROTECTED] pisze: Why Char is 32 bit. UniCode characters is 16 bit. No, Unicode characters have 21 bits (range U+..10). We've been through all this, of course, but here's a quote: Unicode originally implied that the encoding was UCS-2 and it initially didn't make any provisions for characters outside the BMP (U+ to U+). When it became clear that more than 64k characters would be needed for certain special applications (historic alphabets and ideographs, mathematical and musical typesetting, etc.), Unicode was turned into a sort of 21-bit character set with possible code points in the range U- to U-0010. The 2×1024 surrogate characters (U+D800 to U+DFFF) were introduced into the BMP to allow 1024×1024 non-BMP characters to be represented as a sequence of two 16-bit surrogate characters. This way UTF-16 was born, which represents the extended 21-bit Unicode in a way backwards compatible with UCS-2. The term UTF-32 was introduced in Unicode to mean a 4-byte encoding of the extended 21-bit Unicode. UTF-32 is the exact same thing as UCS-4, except that by definition UTF-32 is never used to represent characters above U-0010, while UCS-4 can cover all 231 code positions up to U-7FFF. from a/the Unicode FAQ at http://www.cl.cam.ac.uk/~mgk25/unicode.html Does Haskell's support of Unicode mean UTF-32, or full UCS-4? Recent messages seem to indicate the former, but I don't see any reason against the latter. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: enormous executable
Julian Seward (Intl Vendor) [EMAIL PROTECTED] writes: On Linux and probably most Unixes, the text and data segments of the executable are loaded page-by-page into memory on demand. So having a lot of unused junk in the executable doesn't necessarily increase the memory used, either real memory or swap space. (Surely not swap, since code is just paged from the executable image :-) Surely the executable itself is only linked with the functions that are actually used by the program? Or are you talking about working set? I'd expect a GUI library to have considerable initialization etc. code, which is used relatively rarely. In that case, the waste is mostly disk space, which is abundant these days. My thought was, however, that the GUI toolkit is probably used by multiple other (non-haskell) programs, and could be usefully shared. I think it's basically harmless providing you're only running one instance of the program on the machine. Uh, multiple instances would share the executable in memory, if I understand things correctly. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GC options. Reply
Simon Marlow [EMAIL PROTECTED] writes: Ok, I've done the following: - disabled the maximum heap - RTS options are taken from the GHCRTS environment variable in addition to the command line (the command line has precedence). (I haven't followed this debate closely, so I may be missing out on something, but:) Perhaps it could be possible to embed a default in the executable as well, through a command line option to the compiler/linker? You know, for the occasional program that actually requires more heap than one is comfortable declaring in GHCRTS, but one is too lazy to write a shell wrapper for? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Run time error message
Hi I've compiled a program with GHC, but when I run it, it runs to partial completion (i.e. I get some correct-looking output) and terminates with: Fail: Prelude.(!!): index too large Great. Is there any way I can work out where, exactly, the !! failed? I only use it with constants (0..3) in my own code, so the culprit's probably hidden in some library function. Could it be trigged by (++) or putStr, perhaps? Please Cc: me any replies, as I'm not on this list. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
