Hiya, I'm benchmarking GHC vs. JHC vs. LHC vs. UHC and I was wonder if you guys could help me make it more accurate. Many of the JHC tests fails in what seems to be easy-to-fix ways. The benchmark results can be found here: http://darcs.haskell.org/~lemmih/nobench/x86_64/results.html The benchmark source can be found here: http://nobench.seize.it/ -- Cheers, Lemmih
On Sat, Sep 05, 2009 at 12:08:00AM +0200, Lemmih wrote:
I'm benchmarking GHC vs. JHC vs. LHC vs. UHC and I was wonder if you guys could help me make it more accurate. Many of the JHC tests fails in what seems to be easy-to-fix ways.
The benchmark results can be found here: http://darcs.haskell.org/~lemmih/nobench/x86_64/results.html The benchmark source can be found here: http://nobench.seize.it/
What options are you using when compiling? Could you make two columns for jhc, one with -fboehm and one without? I have tested with nobench before and had more succeed, but I have not tried it in a while.. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
On Sat, Sep 5, 2009 at 12:25 AM, John Meacham
On Sat, Sep 05, 2009 at 12:08:00AM +0200, Lemmih wrote:
I'm benchmarking GHC vs. JHC vs. LHC vs. UHC and I was wonder if you guys could help me make it more accurate. Many of the JHC tests fails in what seems to be easy-to-fix ways.
The benchmark results can be found here: http://darcs.haskell.org/~lemmih/nobench/x86_64/results.html The benchmark source can be found here: http://nobench.seize.it/
What options are you using when compiling?
Only -f boehm.
Could you make two columns for jhc, one with -fboehm and one without?
Yep. Will update the benchmark asap. -- Cheers, Lemmih
On Sat, Sep 5, 2009 at 12:34 AM, Lemmih
On Sat, Sep 5, 2009 at 12:25 AM, John Meacham
wrote: On Sat, Sep 05, 2009 at 12:08:00AM +0200, Lemmih wrote:
I'm benchmarking GHC vs. JHC vs. LHC vs. UHC and I was wonder if you guys could help me make it more accurate. Many of the JHC tests fails in what seems to be easy-to-fix ways.
The benchmark results can be found here: http://darcs.haskell.org/~lemmih/nobench/x86_64/results.html The benchmark source can be found here: http://nobench.seize.it/
What options are you using when compiling?
Only -f boehm.
Could you make two columns for jhc, one with -fboehm and one without?
Yep. Will update the benchmark asap.
14/73 without the GC. The complete results will be uploaded in a few hours. -- Cheers, Lemmih
Hmm.. looks like many are failing due to the unpacked poly bug, as shown by regression test 'tests.bugs.UnpackedPoly'. Combined with the newtype unpacking bug pointed out by droundy earlier, I think it is time for me to take a look at unpacked fields. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
On Sat, Sep 5, 2009 at 4:32 AM, John Meacham
Hmm.. looks like many are failing due to the unpacked poly bug, as shown by regression test 'tests.bugs.UnpackedPoly'. Combined with the newtype unpacking bug pointed out by droundy earlier, I think it is time for me to take a look at unpacked fields.
x2n1 is quite interesting. It generated the wrong answer with the GC enabled but works fine without it. -- Cheers, Lemmih
On Sat, Sep 05, 2009 at 12:35:54PM +0200, Lemmih wrote:
On Sat, Sep 5, 2009 at 4:32 AM, John Meacham
wrote: Hmm.. looks like many are failing due to the unpacked poly bug, as shown by regression test 'tests.bugs.UnpackedPoly'. Combined with the newtype unpacking bug pointed out by droundy earlier, I think it is time for me to take a look at unpacked fields.
x2n1 is quite interesting. It generated the wrong answer with the GC enabled but works fine without it.
Yes, I think I am pushing the boehm GC further than it was designed for at times :) My recent patches sent to the list fix a few bugs that were keeping some of the benchmarks from compiling. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
On Sat, Sep 5, 2009 at 1:32 PM, John Meacham
On Sat, Sep 05, 2009 at 12:35:54PM +0200, Lemmih wrote:
On Sat, Sep 5, 2009 at 4:32 AM, John Meacham
wrote: Hmm.. looks like many are failing due to the unpacked poly bug, as shown by regression test 'tests.bugs.UnpackedPoly'. Combined with the newtype unpacking bug pointed out by droundy earlier, I think it is time for me to take a look at unpacked fields.
x2n1 is quite interesting. It generated the wrong answer with the GC enabled but works fine without it.
Yes, I think I am pushing the boehm GC further than it was designed for at times :)
My recent patches sent to the list fix a few bugs that were keeping some of the benchmarks from compiling.
I'm re-running the benchmark now. -- Cheers, Lemmih
On Sat, Sep 5, 2009 at 1:59 PM, Lemmih
On Sat, Sep 5, 2009 at 1:32 PM, John Meacham
wrote: On Sat, Sep 05, 2009 at 12:35:54PM +0200, Lemmih wrote:
On Sat, Sep 5, 2009 at 4:32 AM, John Meacham
wrote: Hmm.. looks like many are failing due to the unpacked poly bug, as shown by regression test 'tests.bugs.UnpackedPoly'. Combined with the newtype unpacking bug pointed out by droundy earlier, I think it is time for me to take a look at unpacked fields.
x2n1 is quite interesting. It generated the wrong answer with the GC enabled but works fine without it.
Yes, I think I am pushing the boehm GC further than it was designed for at times :)
My recent patches sent to the list fix a few bugs that were keeping some of the benchmarks from compiling.
I'm re-running the benchmark now.
18/73 with jhc-0.7.2-17. -- Cheers, Lemmih
On Sat, Sep 05, 2009 at 04:08:33PM +0200, Lemmih wrote:
On Sat, Sep 5, 2009 at 1:59 PM, Lemmih
wrote: On Sat, Sep 5, 2009 at 1:32 PM, John Meacham
wrote: On Sat, Sep 05, 2009 at 12:35:54PM +0200, Lemmih wrote:
On Sat, Sep 5, 2009 at 4:32 AM, John Meacham
wrote: Hmm.. looks like many are failing due to the unpacked poly bug, as shown by regression test 'tests.bugs.UnpackedPoly'. Combined with the newtype unpacking bug pointed out by droundy earlier, I think it is time for me to take a look at unpacked fields.
x2n1 is quite interesting. It generated the wrong answer with the GC enabled but works fine without it.
Yes, I think I am pushing the boehm GC further than it was designed for at times :)
My recent patches sent to the list fix a few bugs that were keeping some of the benchmarks from compiling.
I'm re-running the benchmark now.
18/73 with jhc-0.7.2-17.
Hi, I have been going through the failing cases, the newest patches published should fix several more of the tests, (and hopefully speed up others). My hope is that the work Taral is doing at hunting down the space leaks will allow compilation of ByteString which should help out a signifigant number of the currently broken due to missing bytestring ones as well. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
On Mon, Sep 7, 2009 at 1:22 PM, John Meacham
On Sat, Sep 05, 2009 at 04:08:33PM +0200, Lemmih wrote:
On Sat, Sep 5, 2009 at 1:59 PM, Lemmih
wrote: On Sat, Sep 5, 2009 at 1:32 PM, John Meacham
wrote: On Sat, Sep 05, 2009 at 12:35:54PM +0200, Lemmih wrote:
On Sat, Sep 5, 2009 at 4:32 AM, John Meacham
wrote: Hmm.. looks like many are failing due to the unpacked poly bug, as shown by regression test 'tests.bugs.UnpackedPoly'. Combined with the newtype unpacking bug pointed out by droundy earlier, I think it is time for me to take a look at unpacked fields.
x2n1 is quite interesting. It generated the wrong answer with the GC enabled but works fine without it.
Yes, I think I am pushing the boehm GC further than it was designed for at times :)
My recent patches sent to the list fix a few bugs that were keeping some of the benchmarks from compiling.
I'm re-running the benchmark now.
18/73 with jhc-0.7.2-17.
Hi, I have been going through the failing cases, the newest patches published should fix several more of the tests, (and hopefully speed up others).
My hope is that the work Taral is doing at hunting down the space leaks will allow compilation of ByteString which should help out a signifigant number of the currently broken due to missing bytestring ones as well.
23/73 with jhc 0.7.2-26. I'll take out the nogc version. I feel it distorts the data. -- Cheers, Lemmih
On Mon, Sep 07, 2009 at 03:47:29PM +0200, Lemmih wrote:
Hi, I have been going through the failing cases, the newest patches published should fix several more of the tests, (and hopefully speed up others).
My hope is that the work Taral is doing at hunting down the space leaks will allow compilation of ByteString which should help out a signifigant number of the currently broken due to missing bytestring ones as well.
23/73 with jhc 0.7.2-26. I'll take out the nogc version. I feel it distorts the data.
I'd leave them both in. I don't really consider the boehm one representative, but it is useful for seperating memory errors from other types of errors at run-time, and it brackets jhcs performance over a range of collectors well. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
participants (2)
-
John Meacham -
Lemmih