Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upUpdates to Yesod and WAI #1086
Conversation
snoyberg
added some commits
Oct 7, 2014
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
msmith-techempower
Oct 7, 2014
Member
@snoyberg Looks like Travis is content with this; is it ready to be merged?
Related: in #832 I discussed some preliminary results when twiddling with the dials. The best results we saw were with +RTS -N -qg2; changing -N to specify the thread count might have slightly lowered the results, but I don't recall and I didn't say that specifically in that post.
|
@snoyberg Looks like Travis is content with this; is it ready to be merged? Related: in #832 I discussed some preliminary results when twiddling with the dials. The best results we saw were with |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
snoyberg
Oct 7, 2014
Contributor
@msmith-techempower The only thing to be careful about is the explicit core count. Can I leave it to your discretion whether that commit gets merged in or not? Otherwise, this is definitely good to go.
|
@msmith-techempower The only thing to be careful about is the explicit core count. Can I leave it to your discretion whether that commit gets merged in or not? Otherwise, this is definitely good to go. |
snoyberg commentedOct 7, 2014
This brings WAI forward to use GHC 7.8, just like Yesod does now. It also introduces some performance enhancements to the Yesod implementation, and reduces the library dependencies in Yesod to get faster compile times (it originally used the yesod package, when in reality just yesod-core was necessary).
One possibly contentious change is: 062e4f9. @kazu-yamamoto and I discussed this, and weren't completely certain if the thread count passed in should be treated as a hard limit on the number of machine cores to use or not. This commit changes it so that the benchmarks will use exactly the number of threads specified, regardless of the number of cores actually available. The previous behavior was to use all cores reported available by the OS.