On Wed, Feb 07, 2007 at 03:35:50PM -0800, Stefan O'Rear wrote:
On Wed, Feb 07, 2007 at 03:26:42PM -0500, Isaac Dupree wrote:
Stefan O'Rear wrote:
(to change RTS options - turns out I don't have enough RAM to build the libraries without +RTS -c, and even with it's a tight squeeze)
How much RAM is this amount that worked as a "tight squeeze" for you? That is, I'd like some numbers for how much memory jhc needs (One time I tried this and didn't have enough memory on my current computer; I don't remember if I knew to try +RTS -c)
384 MB.
by which I mean Jhc stayed above 5% cpu the whole time. (Jhc's VIRT stayed around 495MB).
also my limited patience has prevented me from seeing the whole-program optimization phase ...
Jhc is unusably (read: untestably if/when I break something) slow on my obsolete computer. My first hacking target will be some kind of -fsymbol-at-a-time use less ram option :)
once the libraries are built, then things go much smoother. I have basically done very little work on optimizing jhc's memory usage other than not doing anything blatently silly (I hope). There is most likely a lot of room for improvement and probably some low-hanging fruit that can be done easily with a little profiling. There are also some obvious things that could be done, like storing the dependency graph in the binary file, so I need not go through everything and calculate free variables again on loading, or having a separate section that doesn't need to be loaded for functions that we know are so big they will never be inlined. coming up with a unified annotation to store strictness,cpr, and eta information and serializing it rather than recalculating it would also be a big win. (I am working on this actually) John -- John Meacham - ⑆repetae.net⑆john⑈