Yesod updates for GHC 7.8 #834

snoyberg · 2014-04-18T05:40:35Z

Same idea as #832. Pinging @kazu-yamamoto.

hamiltont · 2014-08-11T20:03:05Z

@snoyberg Please rebase onto master, and Travis-CI will verify yesod runs without errors. Thanks!

kazu-yamamoto · 2014-08-12T01:57:07Z

@snoyberg Please see #1000. Note that I removed the "-qa" runtime option since it seems unstable in the real world.

snoyberg · 2014-08-12T11:53:23Z

Alright, I've updated the pull request and changed the RTS flags to match @kazu-yamamoto's.

hamiltont · 2014-08-12T13:34:15Z

@snoyberg looks like yesod failed to turn on properly. See the build details (scroll to the row for yesod) on travis. From a quick look, it's saying cabal install failed. This probably indicates:

the haskell installation isn't working properly. This starts on line 1881 and should end by saying "haskell is isntaled" - if there were errors it will say something like "WARN: haskell may not be installed correctly".
the PATH to cabal is not correct and it can't be accessed
some is actually wrong with your framework
perhpas this is a versioning issue?

If you need to see some additional log file, you can print it out in your stop() fuction by reading it in line by line and calling logfile.write(line + '\n')

msmith-techempower · 2014-08-12T14:53:20Z

GHC 7.8 is not set up properly because apt has not been updated. Regardless, we should update the installation to use the Haskell binary distribution so-as to have a permalink to the correct version (we are trying to move away from using apt on these tests - they add too much day-to-day randomness).

http://www.haskell.org/platform/download/2014.2.0.0/haskell-platform-2014.2.0.0-unknown-linux-x86_64.tar.gz

This should include GHC7.8 and the correct cabal-install (as well as other dependencies). More info

msmith-techempower · 2014-08-12T15:47:31Z

@snoyberg This is completely unrelated to our discussions here, but I am excited to see Haskell's numbers with 7.8. We did some testing with the experimental releases with the new IOManager late in 2013 and saw marked improvement. In addition, there was a thread (somewhere) suggesting that the people testing the IOManager did not have access to any hardware with more than 32 cores, but they thought it should scale linearly past that -- we will put this to the test ;-)

snoyberg · 2014-08-12T15:49:10Z

@msmith-techempower Awesome, I look forward to seeing the results! The work on the IO manager in GHC 7.8 was really exciting, and the fact that it almost magically made all of our code faster was great.

hamiltont · 2014-08-12T15:59:12Z

PS @snoyberg - I know waiting our our main travis queue can be a bit slow given the current number of active pull requests. If you go to travis-ci.org and click "log in with github" you can have travis also monitor your fork. This gets you your own build queue and your own ability to cancel stuff

snoyberg · 2014-08-12T16:00:55Z

Doh, that's obvious in hindsight. I've just activated it, hopefully I'll get a result sooner rather than later. Thanks!

hamiltont · 2014-08-12T17:53:08Z

@snoyberg @msmith-techempower Would you guys let me know if this pull request will also accomplish #834 ? As in, can I close that one once this is merged in?

msmith-techempower · 2014-08-12T17:58:11Z

@hamiltont This is #834; do you mean #832 ?

hamiltont · 2014-08-12T18:04:12Z

Ah no I meant #830 -- seems like a ton of people want some fresh ghc!

msmith-techempower · 2014-08-12T18:05:55Z

Oh, this PR will render #830 superfluous - if this build passes, we can close-without-merging #830.

hamiltont · 2014-08-12T18:06:52Z

perfect, thanks

snoyberg · 2014-08-13T21:09:39Z

Looks like the last commit finally built successfully. Let me know if you want me to rebase these changes into a single commit instead.

msmith-techempower · 2014-08-13T21:10:52Z

~~LGTM!~~

Wait, why does Yesod not have output?

Derp - there are errors in this yesod build AND it returned success... worst case scenario realized.

hamiltont · 2014-08-13T23:53:52Z

there are errors in this yesod build AND it returned success

fixed by merging #1006. @snoyberg please rebase onto master. Fell free to use the chance to cleanup your commit history if you desire :-)

snoyberg · 2014-08-14T04:57:45Z

OK, I've rebased and cleaned up.

msmith-techempower · 2014-08-14T14:25:33Z

Seems cabal install is failing.

snoyberg · 2014-08-20T13:36:18Z

At this point the pull request is failing because of:

INFO:run-ci:parsec-3.1.5 failed during the building phase. The exception was:
INFO:run-ci:ExitFailure 9
INFO:run-ci:This may be due to an out-of-memory condition.

So it's running out of memory while building. I'm not really sure how to proceed from there.

hamiltont · 2014-08-20T14:18:36Z

That's impressive....we've built python (3 versions), multiple ruby
versions, mono, the c++ web toolkit, Perl, and a number of other large
projects without memory issues. My only thoughts are 1) its not really a
memory issue and the exit code is misleading or 2) you've used some
"optimize fully flag" that causes memory consumption to massively spike
during compile

codygman · 2014-09-30T13:47:15Z

@snoyberg @hamiltont I have succesfully solved memory issues by using the gold linker from binutils-gold a couple of times:

http://stackoverflow.com/a/6952759/200916

Also, @snoyberg in b7b328f you made a change to use a single threaded build... I'm not sure if that could cause issues but it is something different.

kazu-yamamoto · 2014-09-30T13:54:26Z

Thanks. Michael and I noticed performance regression of Warp/Yesod. We are tackling this issue now.

kazu-yamamoto · 2014-10-02T05:07:42Z

This regression has been fixed.

msmith-techempower · 2014-10-02T15:16:34Z

Rebasing would be my preference - I like to do as little as possible ^_^

EDIT: MAN, why did it take 40m to run the verification test?

snoyberg · 2014-10-02T15:18:50Z

Because I switched it to single-threaded building to try and eliminate the memory issue.

I'll be in meetings the rest of the evening, I'll try to rebase tonight or tomorrow morning.

msmith-techempower · 2014-10-02T15:19:35Z

@snoyberg Sounds good - thanks for all the hard work on this.

codygman · 2014-10-02T15:54:29Z

@snoyberg if you summarize what needs to be rebased I might be able to do
it for you this afternoon.

On Thu, Oct 2, 2014 at 10:19 AM, Mike Smith notifications@github.com
wrote:

@snoyberg https://github.com/snoyberg Sounds good - thanks for all the
hard work on this.

—
Reply to this email directly or view it on GitHub
#834 (comment)
.

codygman · 2014-10-02T15:55:49Z

@msmith-techempower How long is typical for the verification test? I plan on looking at this and trying to run it locally this afternoon. I read most of the README, should that be all the information relevant to what I'll be working with?

msmith-techempower · 2014-10-02T15:58:25Z

@codygman I think I figured this out - my concern might not be valid since this is the Travis-CI environment that is taking 40m. It must apt-get install ghc/cabal/etc, then install all the dependencies with cabal, then build the webapp... 40m might actually be reasonable in the Travis environment.

codygman · 2014-10-02T16:05:43Z

@msmith-techempower Any idea why the query tests for mysql and mongo threw an exception but still pass and are just marked as warn. Is this on purpose?

Also is the memory issue @snoyberg references with Travis or the TechEmpower environment? I'm guessing the TechEmpower environment since it passed with Travis.

msmith-techempower · 2014-10-02T16:09:19Z

@codygman The errors thrown were for the error cases. Our rules for db suggest that if we query the db url and pass it a value less than 0 or a non-number, it should return an array with a single result; so we are querying /dbs/foo and the code is expecting an integer and returns either an error or a 404 (I forgot and I'm on a call, so I don't want to check).

This is considered a warning at present, but should be fixed up at some point.

As for the memory issue - that is entirely within the Travis-CI environment, but @snoyberg switched to a single-threaded approach to cabal install which seemed to resolve the issue.

Our benchmark machines will, in practice, never run out of memory (our lowest RAM is something absurd like 32GB; the largest is a half-terabyte o.O)

EDIT: oops, round10 spoilers

See: TechEmpower#834 (comment)

snoyberg · 2014-10-02T17:00:37Z

@codygman Thank you for the offer! I just rebased and pushed to a new branch, rebased2, on my repo. The real question is: can we get it building without the last two commits? I push that to a separate branch also (creatively named rebased3). If you happen to notice that either of those fail, or if you have any ideas to better clean up the branch, please let me know (and a PR is certainly welcome to fix anything stupid I've done on those branch).

Here's a Travis build of the rebased3 branch: https://travis-ci.org/snoyberg/FrameworkBenchmarks/builds/36889733. If that works, I think we're golden.

codygman · 2014-10-02T17:36:41Z

@snoyberg No problem. I'm eagerly watching that Travis build. Hopefully I can checkout the branches in 4-4 1/2 hours. I'll give you feedback if I have any.

codygman · 2014-10-02T17:47:35Z

Well that's annoying, it seems to be stuck on a http request to duda.io:

Resolving duda.io (duda.io)... 166.78.104.111

Connecting to duda.io (duda.io)|166.78.104.111|:80... connected.

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.

Retrying.

--2014-10-02 17:34:09-- (try: 2) http://duda.io/releases/duda-client/dudac-0.23.tar.gz

Connecting to duda.io (duda.io)|166.78.104.111|:80... connected.

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.

Retrying.

--2014-10-02 17:36:02-- (try: 3) http://duda.io/releases/duda-client/dudac-0.23.tar.gz

Connecting to duda.io (duda.io)|166.78.104.111|:80... connected.

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.

Retrying.

--2014-10-02 17:37:57-- (try: 4) http://duda.io/releases/duda-client/dudac-0.23.tar.gz

Connecting to duda.io (duda.io)|166.78.104.111|:80... connected.

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.

Retrying.

--2014-10-02 17:39:52-- (try: 5) http://duda.io/releases/duda-client/dudac-0.23.tar.gz

Connecting to duda.io (duda.io)|166.78.104.111|:80... connected.

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.

Retrying.

--2014-10-02 17:41:48-- (try: 6) http://duda.io/releases/duda-client/dudac-0.23.tar.gz

Connecting to duda.io (duda.io)|166.78.104.111|:80... connected.

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.

Retrying.

--2014-10-02 17:43:45-- (try: 7) http://duda.io/releases/duda-client/dudac-0.23.tar.gz

Connecting to duda.io (duda.io)|166.78.104.111|:80... connected.

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.

Retrying.

--2014-10-02 17:45:44-- (try: 8) http://duda.io/releases/duda-client/dudac-0.23.tar.gz

Connecting to duda.io (duda.io)|166.78.104.111|:80... connected.

HTTP request sent, awaiting response...

msmith-techempower · 2014-10-02T17:49:57Z

Seems like duda.io is running on a less-than-performant stack - maybe they should try Haskell.

What is reliant upon duda.io?

codygman · 2014-10-02T18:41:41Z

@msmith-techempower ha. The only problem is that their url was timing out. They just need to limit the number of retries and maybe error if the file doesn't exist.

It looks like they are using fw_get. Maybe an issue could be put in to make fw_get verify the file was retrieved succesfully? Adding a max-retries=10 (instead of 20) could be a saner default.

msmith-techempower · 2014-10-02T18:43:46Z

@codygman This was the subject of an issue we never resolved (I think) - what do we do when one of FrameworkX's requirements 404s/timeouts? You cannot continue... so... uh...

snoyberg · 2014-10-06T09:29:48Z

The most recent commit did pass all tests on Travis:

https://travis-ci.org/snoyberg/FrameworkBenchmarks/builds/37152899

I'd recommend this be merged in.

msmith-techempower · 2014-10-06T14:09:49Z

@snoyberg I agree - this looks good to me. LGTM

Question - does cabal sandbox by default now? IIRC, there was a slight problem with the Haskell framework in the previous round that required nuking a folder in installs before every run, but the latest version of cabal supposedly supports sandboxed installations.

msmith-techempower · 2014-10-06T14:13:26Z

toolset/setup/linux/prerequisites.sh


 # WARNING: DONT PUT A SPACE AFTER ANY BACKSLASH OR APT WILL BREAK
-sudo apt-get -y install \
+sudo apt-get -y install -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" \


Before merging, I would love to know what these extra flags do.

If configuration files are too be updated prefer old if user modifications
exist otherwise prefer updated.
On Oct 6, 2014 9:13 AM, "Mike Smith" notifications@github.com wrote:

In toolset/setup/linux/prerequisites.sh:

WARNING: DONT PUT A SPACE AFTER ANY BACKSLASH OR APT WILL BREAK

-sudo apt-get -y install
+sudo apt-get -y install -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" \

Before merging, I would love to know what these extra flags do.

—
Reply to this email directly or view it on GitHub
https://github.com/TechEmpower/FrameworkBenchmarks/pull/834/files#r18458345
.

Thanks for the quick follow-up; that makes sense to me. I just wanted to make sure that this was appropriate across the board given that it is in the overall prerequisites.sh file.

snoyberg · 2014-10-06T14:16:05Z

Regarding the extra flags, see these comments: #834 (comment). It's present to work around an apt-get problem regarding rsyslog config. AFAIK, it is not Yesod specific.

cabal does not sandbox by default. We could theoretically use sandboxes for these builds, I just generally don't end up using it. I'd say if the lack of sandboxing causes a problem in the future we should revisit.

msmith-techempower · 2014-10-06T14:28:20Z

@snoyberg Regarding the sandboxing, I know from personal experience with the Haskell tests in TFB that we have experienced problems with versions working for snap and not for yesod.

For now, LGTM and if we run into problems when we (finally) get around to fixing snap, then I will sandbox that cabal installation and we will see if it is appropriate then.

Yesod updates for GHC 7.8

snoyberg · 2014-10-06T14:29:55Z

OK, sounds good. For the record, I still think it may be worth revisiting the idea of doing the builds in a separate repo. Given that we have something working right now, I'd just as well let sleeping dogs lie. But if we run into failures in the future, I'd recommend we reconsider that.

@kazu-yamamoto Now might be a good time to update the Warp benchmark to use GHC 7.8. I can take a crack at that if you'd prefer.

snoyberg mentioned this pull request Apr 18, 2014

better runtime options for GHC 7.8. #832

Closed

rehno-lindeque mentioned this pull request May 6, 2014

Install latest GHC (new 7.8 version has much faster IO subsystem) #844

Closed

hamiltont added the update request label Aug 11, 2014

kainsavage mentioned this pull request Sep 30, 2014

Install GHC 7.8.2 instead of 7.6.3 #830

Closed

snoyberg force-pushed the master branch 2 times, most recently from 72a8c9e to 37cc832 Compare October 2, 2014 10:36

snoyberg added 5 commits October 2, 2014 19:53

Work around apt-get issues (c/o @codygman)

42883b1

See: TechEmpower#834 (comment)

GHC 7.8

9e8701c

Clean up Yesod code with stylish-haskell

2c51b12

yesod 1.4 and disable non-raw MongoDB

8364264

Set the LANG environment variable

cb23a7c

Some Yesod (attempted) optimizations

ba6da3c

snoyberg force-pushed the master branch from 7769577 to ba6da3c Compare October 6, 2014 06:51

msmith-techempower reviewed Oct 6, 2014
View reviewed changes

msmith-techempower added a commit that referenced this pull request Oct 6, 2014

Merge pull request #834 from snoyberg/master

a58a65c

Yesod updates for GHC 7.8

msmith-techempower merged commit a58a65c into TechEmpower:master Oct 6, 2014

msmith-techempower mentioned this pull request Oct 7, 2014

fix(Yesod): Resolve dependencies and change executable filename in cabal... #788

Closed

Yesod updates for GHC 7.8 #834

Yesod updates for GHC 7.8 #834

Uh oh!

Conversation

snoyberg commented Apr 18, 2014

Uh oh!

hamiltont commented Aug 11, 2014

Uh oh!

kazu-yamamoto commented Aug 12, 2014

Uh oh!

snoyberg commented Aug 12, 2014

Uh oh!

hamiltont commented Aug 12, 2014

Uh oh!

msmith-techempower commented Aug 12, 2014

Uh oh!

msmith-techempower commented Aug 12, 2014

Uh oh!

snoyberg commented Aug 12, 2014

Uh oh!

hamiltont commented Aug 12, 2014

Uh oh!

snoyberg commented Aug 12, 2014

Uh oh!

hamiltont commented Aug 12, 2014

Uh oh!

msmith-techempower commented Aug 12, 2014

Uh oh!

hamiltont commented Aug 12, 2014

Uh oh!

msmith-techempower commented Aug 12, 2014

Uh oh!

hamiltont commented Aug 12, 2014

Uh oh!

snoyberg commented Aug 13, 2014

Uh oh!

msmith-techempower commented Aug 13, 2014

Uh oh!

hamiltont commented Aug 13, 2014

Uh oh!

snoyberg commented Aug 14, 2014

Uh oh!

msmith-techempower commented Aug 14, 2014

Uh oh!

snoyberg commented Aug 20, 2014

Uh oh!

hamiltont commented Aug 20, 2014

Uh oh!

codygman commented Sep 30, 2014

Uh oh!

kazu-yamamoto commented Sep 30, 2014

Uh oh!

kazu-yamamoto commented Oct 2, 2014

Uh oh!

msmith-techempower commented Oct 2, 2014

Uh oh!

snoyberg commented Oct 2, 2014

Uh oh!

msmith-techempower commented Oct 2, 2014

Uh oh!

codygman commented Oct 2, 2014

Uh oh!

codygman commented Oct 2, 2014

Uh oh!

msmith-techempower commented Oct 2, 2014

Uh oh!

codygman commented Oct 2, 2014

Uh oh!

msmith-techempower commented Oct 2, 2014

Uh oh!

snoyberg commented Oct 2, 2014

Uh oh!

codygman commented Oct 2, 2014

Uh oh!

codygman commented Oct 2, 2014

Uh oh!

msmith-techempower commented Oct 2, 2014

Uh oh!

codygman commented Oct 2, 2014

Uh oh!