I've been investigating the performance of some word frequency counting code I wrote, and I came across this stackoverflow thread http://stackoverflow.com/questions/3058529/curious-about-the-hashtable-probl... Dons shows simple benchmarks for HashTable and IntMap, but I can't reproduce the "after the fix" performance of the HashTable code, I am very confused as to what version of ghc actually has the fix. In the post Don writes "With GHC 6.10.2, before the fix, inserting 10M ints:" and then "With GHC 6.13, after the fix:", is this a typo, shouldn't it read 6.10.3? Since there is no 6.13 version of ghc yet? If it should be 6.10.3, and I'm running v 6.12.1, why does the HashTable code in Don's post take 22 seconds to run on my machine (compiled ghc --make -O2) and the IntMap version takes only 5.8s? How can one find out what release the fix for ticket #650 was released into? I've tried the release notes but I can't seem to spot it, and google doesn't either. The ticket has "Milestone: 6.12.2" but that is struck-through, though the comments would suggest this made it into r 6.12.2, I can't spot anything in the release notes for that version either. Can someone help clarify which version the fix will be/is in and how one should figure this out in general for other issues? Thanks Tom
On Sunday 10 October 2010 13:01:59, Tom Doris wrote:
I've been investigating the performance of some word frequency counting code I wrote, and I came across this stackoverflow thread http://stackoverflow.com/questions/3058529/curious-about-the-hashtable-p roblemwhere Dons shows simple benchmarks for HashTable and IntMap, but I can't reproduce the "after the fix" performance of the HashTable code, I am very confused as to what version of ghc actually has the fix.
In the post Don writes "With GHC 6.10.2, before the fix, inserting 10M ints:" and then "With GHC 6.13, after the fix:", is this a typo, shouldn't it read 6.10.3? Since there is no 6.13 version of ghc yet?
And there never will be. GHC's versioning scheme for releases is series.even-branch-number.patchlevel Odd numbers in second place indicate the development branch (aka HEAD). So 6.13 was the development branch after 6.12 was released. Originally, a 6.14 release was planned, but there have been so significant changes that the next release (due in a few weeks, probably end of October) will be the first of the 7 series (and HEAD is now 7.1, no longer 6.13).
If it should be 6.10.3, and I'm running v 6.12.1, why does the HashTable code in Don's post take 22 seconds to run on my machine (compiled ghc --make -O2) and the IntMap version takes only 5.8s? How can one find out what release the fix for ticket #650 was released into? I've tried the release notes but I can't seem to spot it, and google doesn't either. The ticket has "Milestone: 6.12.2" but that is struck-through, though the comments would suggest this made it into r 6.12.2, I can't spot anything in the release notes for that version either.
Not sure what goes in the release notes, nor whether the fix was in 6.12.2. But the patch was merged nine months ago, it should be in 6.12.2 (but if you upgrade within the 6.12 series, choose 6.12.3, there were some bugs in 6.12.2 iirc). However, if it's not pressing, consider waiting for the release of GHC 7.
Can someone help clarify which version the fix will be/is in and how one should figure this out in general for other issues?
In general, ask or test. But if you found a ticket for the issue, if it's closed with a merge, any release later than a few eeeks after the merge should contain the fix (unless it's explicitly stated that the patch will not go to the stable branch).
Thanks Tom
Thanks for the clarification. I installed 6.12.3 and can reproduce the
benchmark timings now.
On 10 October 2010 13:10, Daniel Fischer
On Sunday 10 October 2010 13:01:59, Tom Doris wrote:
I've been investigating the performance of some word frequency counting code I wrote, and I came across this stackoverflow thread http://stackoverflow.com/questions/3058529/curious-about-the-hashtable-p roblemwhere Dons shows simple benchmarks for HashTable and IntMap, but I can't reproduce the "after the fix" performance of the HashTable code, I am very confused as to what version of ghc actually has the fix.
In the post Don writes "With GHC 6.10.2, before the fix, inserting 10M ints:" and then "With GHC 6.13, after the fix:", is this a typo, shouldn't it read 6.10.3? Since there is no 6.13 version of ghc yet?
And there never will be. GHC's versioning scheme for releases is
series.even-branch-number.patchlevel
Odd numbers in second place indicate the development branch (aka HEAD).
So 6.13 was the development branch after 6.12 was released. Originally, a 6.14 release was planned, but there have been so significant changes that the next release (due in a few weeks, probably end of October) will be the first of the 7 series (and HEAD is now 7.1, no longer 6.13).
If it should be 6.10.3, and I'm running v 6.12.1, why does the HashTable code in Don's post take 22 seconds to run on my machine (compiled ghc --make -O2) and the IntMap version takes only 5.8s? How can one find out what release the fix for ticket #650 was released into? I've tried the release notes but I can't seem to spot it, and google doesn't either. The ticket has "Milestone: 6.12.2" but that is struck-through, though the comments would suggest this made it into r 6.12.2, I can't spot anything in the release notes for that version either.
Not sure what goes in the release notes, nor whether the fix was in 6.12.2. But the patch was merged nine months ago, it should be in 6.12.2 (but if you upgrade within the 6.12 series, choose 6.12.3, there were some bugs in 6.12.2 iirc). However, if it's not pressing, consider waiting for the release of GHC 7.
Can someone help clarify which version the fix will be/is in and how one should figure this out in general for other issues?
In general, ask or test. But if you found a ticket for the issue, if it's closed with a merge, any release later than a few eeeks after the merge should contain the fix (unless it's explicitly stated that the patch will not go to the stable branch).
Thanks Tom
participants (2)
-
Daniel Fischer -
Tom Doris