Re: Assembler errors when compiling nofib benchmarks with -optc-g
On 02/11/2009 21:49, Henry DeYoung wrote:
On Mon, November 2, 2009 9:09 am, Simon Marlow wrote:
On 31/10/2009 18:27, Henry DeYoung wrote:
We've decided to use oprofile to sample cache misses recorded by the
performance counters. To get reasonable information out of oprofile,
I'd
like to compile the nofib benchmarks via C with export of debugging
symbols.
As a first step toward this, I've changed the NoFibHcOpts variable in
nofib/mk/boilerplate.mk to be:
NoFibHcOpts = -O -fvia-C -pgmc gcc -optc-g
That won't work, I'm afraid. The Evil Mangler script that
post-processes the .s file output by gcc does not understand the debug
annotations added by gcc's -g flag.
The best you can do with oprofile is get assembly-level profiling. It's
not too bad actually; I've used it in the past myself, although oprofile
itself I found to be a bit flaky - for some reason it seems to stop
counting randomly on my laptop.
You might have better luck using the new performance counter support
("performance events") in Linux 2.6.31. I've not been able to test it
yet myself because apparently it doesn't support the CPU in my laptop, but
I plan to find another machine to try it on soon.
So now I'm using
NoFibHcOpts = -O -keep-s-files -opta-g
which seems to work fine. You mentioned that assembly-level profiling is
the best you can do with oprofile (in particular). Is there another
profiler that would allow source-level (in Haskell or the generated C
code) profiling, or is this as good as it gets for any profiler since GHC
doesn't seem to export debugging symbols at the source level?
This is as good as it gets, yes.
Also, based on what you've heard, would you recommend the Linux 2.6.31
performance counter tools over the PAPI library? (I see that there is
PAPI support in the GHC runtime:
http://hackage.haskell.org/trac/ghc/wiki/PAPI)
The main difficulty with PAPI is that it is so hard to get it working.
You need a patched kernel, and then building and installing PAPI itself
is not at all easy. If I was going to install it on a new machine, I'd
set aside a day to do it.
The new Linux performance events infrastructure will be in the default
kernel that comes with most distributions - Ubuntu Karmic includes it
for example. That makes it a lot more attractive for me. Also it has
support for annotating source (or assembly) with profiling results, like
oprofile. I don't think PAPI has that, but I could be wrong. On the
other hand, PAPI has an API for saving/restoring sets of counters, which
is what we use in GHC's RTS for separating the GC counters from the
mutator. I hope I'll be able to do that with perf events, but I don't
know yet.
Thanks so much for all your help!
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Assembler errors when compiling nofib benchmarks with -optc-g
On Mon, November 2, 2009 9:09 am, Simon Marlow wrote:
> On 31/10/2009 18:27, Henry DeYoung wrote:
>
>> We've decided to use oprofile to sample cache misses recorded by the
>> performance counters. To get reasonable information out of oprofile,
>> I'd
>> like to compile the nofib benchmarks via C with export of debugging
>> symbols.
>>
>> As a first step toward this, I've changed the NoFibHcOpts variable in
>> nofib/mk/boilerplate.mk to be:
>>
>> NoFibHcOpts = -O -fvia-C -pgmc gcc -optc-g
>>
>
> That won't work, I'm afraid. The Evil Mangler script that
> post-processes the .s file output by gcc does not understand the debug
> annotations added by gcc's -g flag.
>
> The best you can do with oprofile is get assembly-level profiling. It's
> not too bad actually; I've used it in the past myself, although oprofile
> itself I found to be a bit flaky - for some reason it seems to stop
> counting randomly on my laptop.
>
> You might have better luck using the new performance counter support
> ("performance events") in Linux 2.6.31. I've not been able to test it
> yet myself because apparently it doesn't support the CPU in my laptop, but
> I plan to find another machine to try it on soon.
So now I'm using
NoFibHcOpts = -O -keep-s-files -opta-g
which seems to work fine. You mentioned that assembly-level profiling is
the best you can do with oprofile (in particular). Is there another
profiler that would allow source-level (in Haskell or the generated C
code) profiling, or is this as good as it gets for any profiler since GHC
doesn't seem to export debugging symbols at the source level?
Also, based on what you've heard, would you recommend the Linux 2.6.31
performance counter tools over the PAPI library? (I see that there is
PAPI support in the GHC runtime:
http://hackage.haskell.org/trac/ghc/wiki/PAPI)
Thanks so much for all your help!
Henry
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Assembler errors when compiling nofib benchmarks with -optc-g
On 31/10/2009 18:27, Henry DeYoung wrote:
Hi,
I am working with another grad student on a course project on cache
behavior of GHC programs. The first part of this project is to reproduce
some of the measurements from Nethercote and Mycroft's "The Cache Behavior
of Large Lazy Functional Programs on Stock Hardware".
We've decided to use oprofile to sample cache misses recorded by the
performance counters. To get reasonable information out of oprofile, I'd
like to compile the nofib benchmarks via C with export of debugging
symbols.
As a first step toward this, I've changed the NoFibHcOpts variable in
nofib/mk/boilerplate.mk to be:
NoFibHcOpts = -O -fvia-C -pgmc gcc -optc-g
That won't work, I'm afraid. The Evil Mangler script that
post-processes the .s file output by gcc does not understand the debug
annotations added by gcc's -g flag.
The best you can do with oprofile is get assembly-level profiling. It's
not too bad actually; I've used it in the past myself, although oprofile
itself I found to be a bit flaky - for some reason it seems to stop
counting randomly on my laptop.
You might have better luck using the new performance counter support
("performance events") in Linux 2.6.31. I've not been able to test it
yet myself because apparently it doesn't support the CPU in my laptop,
but I plan to find another machine to try it on soon.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Assembler errors when compiling nofib benchmarks with -optc-g
Hi guys, I am new on this nofib library, could you tell me where can I download it? Thanks, Guilherme Kely de Melo Oliveira 2009/10/31 Henry DeYoung > Hi, > > I am working with another grad student on a course project on cache > behavior of GHC programs. The first part of this project is to reproduce > some of the measurements from Nethercote and Mycroft's "The Cache Behavior > of Large Lazy Functional Programs on Stock Hardware". > > We've decided to use oprofile to sample cache misses recorded by the > performance counters. To get reasonable information out of oprofile, I'd > like to compile the nofib benchmarks via C with export of debugging > symbols. > > As a first step toward this, I've changed the NoFibHcOpts variable in > nofib/mk/boilerplate.mk to be: > >NoFibHcOpts = -O -fvia-C -pgmc gcc -optc-g > > However, when I do make in the nofib/real/compress directory, for example, > I get the following error message: > > ==nofib== compress: time to compile BinConv follows... > /usr0/software/ghc-6.10.1/inplace/bin/ghc-stage2 -H32m -O -O -fvia-C -pgmc > gcc -optc-g -Rghc-timing -H32m -hisuf hi -c BinCon > v.hs -o BinConv.o > < samples), 33M in use, 0.00 INIT (0.00 elapsed), 0.14 > MUT (1.25 elapsed), 0.10 GC (0.12 elapsed) :ghc>> > 1.27user 0.12system 0:01.39elapsed 100%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (0major+21251minor)pagefaults 0swaps > ==nofib== compress: size of BinConv.o follows... > textdata bss dec hex filename > 6677 192 868771add BinConv.o > ==nofib== compress: time to compile BinTest follows... > /usr0/software/ghc-6.10.1/inplace/bin/ghc-stage2 -H32m -O -O -fvia-C -pgmc > gcc -optc-g -Rghc-timing -H32m -hisuf hi -c BinTes > t.hs -o BinTest.o > /tmp/ghc14909_0/ghc14909_0.s: Assembler messages: > > /tmp/ghc14909_0/ghc14909_0.s:54:0: Error: unassigned file number 1 > > /tmp/ghc14909_0/ghc14909_0.s:54:0: > Error: junk at end of line, first unrecognized character is `0' > > /tmp/ghc14909_0/ghc14909_0.s:56:0: Error: unassigned file number 1 > > /tmp/ghc14909_0/ghc14909_0.s:56:0: > Error: junk at end of line, first unrecognized character is `0' > > /tmp/ghc14909_0/ghc14909_0.s:57:0: Error: unassigned file number 1 > > /tmp/ghc14909_0/ghc14909_0.s:57:0: > Error: junk at end of line, first unrecognized character is `0' > > /tmp/ghc14909_0/ghc14909_0.s:61:0: Error: unassigned file number 1 > > /tmp/ghc14909_0/ghc14909_0.s:61:0: > Error: junk at end of line, first unrecognized character is `0' > > etc... > > Curiously, if I remove the -optc-g flag, but still use -fvia-C and -pgmc > gcc, everything works fine. > > Do you have any ideas what might be causing these errors? Is there a fix > or workaround to get the C compiler to export debugging symbols? > > > Second, it appears that a make with -fvia-C -pgmc gcc removes the C source > after it has been compiled. Is there a way to preserve this source so > that it can be annotated line by line using oprofile? > > > I apologize if these questions are rudimentary; this is my first > experience with GHC and nofib. Also, if these questions should be > directed toward a different mailing list, please let me know. > > Thanks for any help you can give with this! > > Henry > > > > ___ > 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
Assembler errors when compiling nofib benchmarks with -optc-g
Hi, I am working with another grad student on a course project on cache behavior of GHC programs. The first part of this project is to reproduce some of the measurements from Nethercote and Mycroft's "The Cache Behavior of Large Lazy Functional Programs on Stock Hardware". We've decided to use oprofile to sample cache misses recorded by the performance counters. To get reasonable information out of oprofile, I'd like to compile the nofib benchmarks via C with export of debugging symbols. As a first step toward this, I've changed the NoFibHcOpts variable in nofib/mk/boilerplate.mk to be: NoFibHcOpts = -O -fvia-C -pgmc gcc -optc-g However, when I do make in the nofib/real/compress directory, for example, I get the following error message: ==nofib== compress: time to compile BinConv follows... /usr0/software/ghc-6.10.1/inplace/bin/ghc-stage2 -H32m -O -O -fvia-C -pgmc gcc -optc-g -Rghc-timing -H32m -hisuf hi -c BinCon v.hs -o BinConv.o <> 1.27user 0.12system 0:01.39elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+21251minor)pagefaults 0swaps ==nofib== compress: size of BinConv.o follows... textdata bss dec hex filename 6677 192 868771add BinConv.o ==nofib== compress: time to compile BinTest follows... /usr0/software/ghc-6.10.1/inplace/bin/ghc-stage2 -H32m -O -O -fvia-C -pgmc gcc -optc-g -Rghc-timing -H32m -hisuf hi -c BinTes t.hs -o BinTest.o /tmp/ghc14909_0/ghc14909_0.s: Assembler messages: /tmp/ghc14909_0/ghc14909_0.s:54:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:54:0: Error: junk at end of line, first unrecognized character is `0' /tmp/ghc14909_0/ghc14909_0.s:56:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:56:0: Error: junk at end of line, first unrecognized character is `0' /tmp/ghc14909_0/ghc14909_0.s:57:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:57:0: Error: junk at end of line, first unrecognized character is `0' /tmp/ghc14909_0/ghc14909_0.s:61:0: Error: unassigned file number 1 /tmp/ghc14909_0/ghc14909_0.s:61:0: Error: junk at end of line, first unrecognized character is `0' etc... Curiously, if I remove the -optc-g flag, but still use -fvia-C and -pgmc gcc, everything works fine. Do you have any ideas what might be causing these errors? Is there a fix or workaround to get the C compiler to export debugging symbols? Second, it appears that a make with -fvia-C -pgmc gcc removes the C source after it has been compiled. Is there a way to preserve this source so that it can be annotated line by line using oprofile? I apologize if these questions are rudimentary; this is my first experience with GHC and nofib. Also, if these questions should be directed toward a different mailing list, please let me know. Thanks for any help you can give with this! Henry ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
