Re: Size of crosscompiled exectuable
On 01/26/2013 09:24 AM, Nathan Hüsken wrote: On 01/25/2013 05:45 PM, Simon Marlow wrote: On 25/01/13 16:35, Simon Marlow wrote: On 25/01/13 15:51, Stephen Paul Weber wrote: Somebody claiming to be Simon Marlow wrote: On 25/01/13 13:58, Nathan Hüsken wrote: A simple hello world application has 1Mb in by 64 bit ubunut machine. When I stript it, is has about 750kb. When I build a cross compiler for android (arm), the executable has a asize of about 10MB, stripped about 5MB. That is huge, five times the size on my linux sysem. Not sure what you mean by five times the size on my linux system. What is 5 times larger than what? He's saying that the size of the android executable (made by his cross compiler) is five time the sive of the equivalent Ubuntu executable (made by, I assume, his system's GHC). Yes, exactly. Sorry for my bad phrasing. The problem is not the size, but the size ratio. Ah, I see. Yes, my executables are a similar size. I'm not sure why, I'll try to look into it. It's just the lack of SPLIT_OBJS. Also, unregisterised accounts for a factor of 1.5 or so. What exactly does SPLIT_OBJS do? Is there a chance to get it working for cross platform? There must be a lot of unused code in the exectuable. Is there no way to remove it? 5 Mb is rather large for an android app. Maybe it would help to pass parameters like -adce or -globaldce to opt (from llvm). But I can not figure out how I can tell ghc to pass these parameters. Someone knows? Regards, Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Size of crosscompiled exectuable
To pass to opt use '-optlo', e.g., $ ghc -fllvm -optlo-adce ... Its documented in the GHC userguide. Cheers, David On 26 January 2013 02:07, Nathan Hüsken nathan.hues...@posteo.de wrote: On 01/26/2013 09:24 AM, Nathan Hüsken wrote: On 01/25/2013 05:45 PM, Simon Marlow wrote: On 25/01/13 16:35, Simon Marlow wrote: On 25/01/13 15:51, Stephen Paul Weber wrote: Somebody claiming to be Simon Marlow wrote: On 25/01/13 13:58, Nathan Hüsken wrote: A simple hello world application has 1Mb in by 64 bit ubunut machine. When I stript it, is has about 750kb. When I build a cross compiler for android (arm), the executable has a asize of about 10MB, stripped about 5MB. That is huge, five times the size on my linux sysem. Not sure what you mean by five times the size on my linux system. What is 5 times larger than what? He's saying that the size of the android executable (made by his cross compiler) is five time the sive of the equivalent Ubuntu executable (made by, I assume, his system's GHC). Yes, exactly. Sorry for my bad phrasing. The problem is not the size, but the size ratio. Ah, I see. Yes, my executables are a similar size. I'm not sure why, I'll try to look into it. It's just the lack of SPLIT_OBJS. Also, unregisterised accounts for a factor of 1.5 or so. What exactly does SPLIT_OBJS do? Is there a chance to get it working for cross platform? There must be a lot of unused code in the exectuable. Is there no way to remove it? 5 Mb is rather large for an android app. Maybe it would help to pass parameters like -adce or -globaldce to opt (from llvm). But I can not figure out how I can tell ghc to pass these parameters. Someone knows? Regards, Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Extended periods of waking up thread %d on cap %d
Ben Gamari bgamari.f...@gmail.com writes: Recently I've been benchmarking my concurrent Gibbs sampler[1] on a largish multicore machine. I've been using GHC HEAD due to various GC-related fixes that are present. One thing that I've noticed in looking over the event logs is that there are large durations (tens of milliseconds) when HECs appear to be constantly bombarded with wake-ups from other capabilities. In these periods, the eventlog will be filled with blocks of messages such as this snippet from one benchmark run[2] (long repeated blocks marked with ellipses, a few irrelevant messages have been omitted yet not marked, see eventlog for full log), 28.320958sHEC 7: running thread 293 I should note that this brings up what might be a related (perhaps more significant from a performance perspective) issue. Notice that around 28.320s in eventlog [2], the benchmark began a new iteration (with a corresponding lull in the CPU activity shown in the log). At this point, a new batch of worker threads were created. Strangely, it seems that the newly created threads begin execution in two groups: While HECs 0 and 2 through 16 begin immediately, HECs 1 and 17 through 23 all only begin at around 28.40s, after the waking up thread 284 on cap 7 storm subsides. Given this coincidence, it seems that these two issues may be related. Thoughts? Cheers, - Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
Now, the question is: does QNX use the same ABI as Linux on ARM? See ARM EABI notes in includes/stg/MachRegs.h Karel On 01/24/13 11:59 PM, Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: On 01/24/2013 07:26 PM, Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: Can you run it in gdb and loock what the backtrace looks like? Did you compile with -debug? I remember I got a stack trace with gdb like this (when doing remote debugging) and got it cleaned up by loading the exectuable with file. Maybe you have to do something like that to? $ ntoarm-gdb --core=Main.core Main ... copyright and such ... [New pid 14336138 tid 1] warning: .dynamic section for /home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libEGL.so.1 is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for /home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libGLESv2.so.1 is not at the expected address (wrong library or version mismatch?) Program terminated with signal 11, Segmentation fault. #0 0x08402000 in ?? () (gdb) bt #0 0x08402000 in ?? () #1 0x082de978 in stg_ap_p_fast () #2 0x082de978 in stg_ap_p_fast () Backtrace stopped: previous frame identical to this frame (corrupt stack?) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: data kinds
On Fri, Jan 25, 2013 at 7:19 AM, Ross Paterson r...@soi.city.ac.uk wrote: GHC implements data kinds by promoting data declarations of a certain restricted form, but I wonder if it would be better to have a special syntax for kind definitions, say data kind Nat = Zero | Succ Nat This is exactly the syntax jhc uses for user defined kinds. John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: data kinds
Hello, I think that it'd be really useful to be able to just declare a `kind` without having to promote a datatype. When we discussed this last time (summarized by the link Pedro sent, I think) it came up that it might be nice to also have kind synonyms, which would be analogous to type synonyms, but one level up. The natural syntax for that would be to have a type kind declaration, but this seems a bit confusing... John, did you implement kind synonyms in jhc, and if so what syntax did you use? -Iavor On Sat, Jan 26, 2013 at 6:11 PM, John Meacham j...@repetae.net wrote: On Fri, Jan 25, 2013 at 7:19 AM, Ross Paterson r...@soi.city.ac.ukwrote: GHC implements data kinds by promoting data declarations of a certain restricted form, but I wonder if it would be better to have a special syntax for kind definitions, say data kind Nat = Zero | Succ Nat This is exactly the syntax jhc uses for user defined kinds. John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users