8.2 and earlier build times
I did a build time test with hackage.haskell.org/package/bloodhound today. I tested 8.2 (RC), 8.0, 7.10, and 7.8. I used Bloodhound in part because it has very few but very large modules which is sort of a pathological case for GHC right now. I first built the deps and library with each compilers and then reran the build once or twice until the results stabilized. The build re-built the V5/Types module and the examples depending on that module. I triggered a build by adding/removing newline characters in the V5/Types module. I've pushed the build targets / stack.yamls to the git repository: https://github.com/bitemyapp/bloodhound Here are the results: 8.2 build: 126.37s user 2.26s system 101% cpu 2:07.16 total 8.0 build: 147.44s user 2.24s system 100% cpu 2:28.93 total 7.10 build: 163.38s user 2.14s system 100% cpu 2:44.64 total 7.8 build: 129.12s user 2.30s system 101% cpu 2:10.09 total Please let me know if you have any questions. -- Chris Allen Currently working on http://haskellbook.com
Very interesting, that would suggest there is some improvement in build times. I want to test out compile times with each of those compilers on our pathological worst case dependency amazonka ( https://github.com/brendanhay/amazonka) and a library we've built on top of it mismi ( https://github.com/ambiata/mismi) today. The code in both have a lot of derivings for data types which seems to be one of the slowest parts. I'm not that conversant with stack as a tool but were these compile times with optimisations on / off? On Wed, May 17, 2017 at 4:08 AM, Christopher Allen <cma@bitemyapp.com> wrote:
I did a build time test with hackage.haskell.org/package/bloodhound today.
I tested 8.2 (RC), 8.0, 7.10, and 7.8. I used Bloodhound in part because it has very few but very large modules which is sort of a pathological case for GHC right now.
I first built the deps and library with each compilers and then reran the build once or twice until the results stabilized. The build re-built the V5/Types module and the examples depending on that module. I triggered a build by adding/removing newline characters in the V5/Types module.
I've pushed the build targets / stack.yamls to the git repository: https://github.com/bitemyapp/bloodhound
Here are the results:
8.2 build: 126.37s user 2.26s system 101% cpu 2:07.16 total
8.0 build: 147.44s user 2.24s system 100% cpu 2:28.93 total
7.10 build: 163.38s user 2.14s system 100% cpu 2:44.64 total
7.8 build: 129.12s user 2.30s system 101% cpu 2:10.09 total
Please let me know if you have any questions.
-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
That's great news! Faster than GHC 7.8! We should advertise this :-). Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Christopher Allen | Sent: 16 May 2017 19:09 | To: ghc-devs@haskell.org | Subject: 8.2 and earlier build times | | I did a build time test with hackage.haskell.org/package/bloodhound | today. | | I tested 8.2 (RC), 8.0, 7.10, and 7.8. I used Bloodhound in part | because it has very few but very large modules which is sort of a | pathological case for GHC right now. | | I first built the deps and library with each compilers and then reran | the build once or twice until the results stabilized. The build re- | built the V5/Types module and the examples depending on that module. I | triggered a build by adding/removing newline characters in the | V5/Types module. | | I've pushed the build targets / stack.yamls to the git repository: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.com%2Fbitemyapp%2Fbloodhound&data=02%7C01%7Csimonpj%40microsoft.com% | 7Cc4d32126857a47dd4dd008d49c86aa7c%7C72f988bf86f141af91ab2d7cd011db47% | 7C1%7C0%7C636305549597208612&sdata=kcqWLIARzF8xwaYwZgJ6vOkex1%2FtD53cB | %2BJlYcdnq2o%3D&reserved=0 | | | Here are the results: | | | 8.2 build: | 126.37s user 2.26s system 101% cpu 2:07.16 total | | 8.0 build: | 147.44s user 2.24s system 100% cpu 2:28.93 total | | 7.10 build: | 163.38s user 2.14s system 100% cpu 2:44.64 total | | 7.8 build: | 129.12s user 2.30s system 101% cpu 2:10.09 total | | | Please let me know if you have any questions. | | -- | Chris Allen | Currently working on | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskel | lbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7Cc4d32126857a47dd4dd | 008d49c86aa7c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63630554959 | 7208612&sdata=vVpn%2FeGOPMspkvoj9SRl2nvc1CIpE0lZbnXYhyTu%2B9Y%3D&reser | ved=0 | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cc4d32126857a47dd4dd008d4 | 9c86aa7c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363055495972086 | 12&sdata=G7cskVvK6Gp7mGLxGbSFPHm4MAQqav69A8PftobVsLE%3D&reserved=0
On Wed, May 17, 2017 at 10:56 AM, Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> wrote:
That's great news! Faster than GHC 7.8! We should advertise this :-).
However, not everything is back to 7.8 levels when looking at the time-dimension, e.g. for regex-tdfa-1.2.2 (with reasonably similar versions of dependencies): GHC 7.8.4: <<ghc: 71340383624 bytes, 1821 GCs, 159844888/430161152 avg/max bytes residency (23 samples), 1221M in use, 0.00 INIT (0.00 elapsed), 41.12 MUT (45.55 elapsed), 16.85 GC (16.85 elapsed) :ghc>> GHC 7.10.3: <<ghc: 68219940408 bytes, 2275 GCs, 135800561/334469832 avg/max bytes residency (30 samples), 934M in use, 0.001 INIT (0.001 elapsed), 41.251 MUT (45.513 elapsed), 18.519 GC (18.520 elapsed) :ghc>> GHC 8.0.2: <<ghc: 89544610040 bytes, 2301 GCs, 189183965/391103872 avg/max bytes residency (29 samples), 1075M in use, 0.001 INIT (0.001 elapsed), 55.747 MUT (61.520 elapsed), 23.276 GC (23.278 elapsed) :ghc>> GHC 8.2.1: <<ghc: 115210990008 bytes, 6383 GCs, 116487828/234031864 avg/max bytes residency (77 samples), 670M in use, 0.001 INIT (0.000 elapsed), 64.154 MUT (68.262 elapsed), 37.114 GC (37.077 elapsed) :ghc>> So GHC 8.2.1 seems to have traded memory-in-use (significantly less than 7.8) for compile-time (significantly more than 7.8).
Herbert Valerio Riedel <hvriedel@gmail.com> writes:
On Wed, May 17, 2017 at 10:56 AM, Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> wrote:
That's great news! Faster than GHC 7.8! We should advertise this :-).
However, not everything is back to 7.8 levels when looking at the time-dimension, e.g. for regex-tdfa-1.2.2 (with reasonably similar versions of dependencies):
Interesting. I tried comparing build times of regex-tdfa-1.1.8 with GHC 8.0.2 and 8.2.1, yet was unable to reproduce this. Rather 8.2 was significantly faster than 8.0.2 (although not in the profiled build, it seems), 8.0.2: real 2m4.403s user 0m2.233s sys 4m49.319s normal build: <<ghc: 91089022760 bytes, 3544 GCs, 254983314/623313256 avg/max bytes residency (29 samples), 1777M in use, 0.000 INIT (0.001 elapsed), 0.277 MUT (49.941 elapsed), 0.972 GC (28.395 elapsed) :ghc>> profiled build: <<ghc: 53822322480 bytes, 2813 GCs, 152915198/391707624 avg/max bytes residency (24 samples), 1059M in use, 0.000 INIT (0.000 elapsed), 0.177 MUT (29.445 elapsed), 0.527 GC (15.834 elapsed) :ghc>> 8.2.1-rc2: real 1m37.004s user 0m1.690s sys 4m22.921s normal build: <<ghc: 74407995376 bytes, 2547 GCs, 188938069/574558856 avg/max bytes residency (29 samples), 1524M in use, 0.001 INIT (0.001 elapsed), 66.810 MUT (33.696 elapsed), 79.093 GC (21.746 elapsed) :ghc>> profiled build: <<ghc: 55111218888 bytes, 2272 GCs, 149652372/540904144 avg/max bytes residency (26 samples), 1336M in use, 0.001 INIT (0.001 elapsed), 51.072 MUT (25.140 elapsed), 58.298 GC (16.143 elapsed) :ghc>> My methodology was roughly, $ cabal unpack regex-tdfa-1.1.8 $ cd regex-tdfa-1.1.8 $ use_component ghc 8.0.2 $ cabal configure ; time cabal build --ghc-options='-fforce-recomp -v +RTS -t -RTS' >| 8.0.2 2>&1 $ use_component ghc 8.2.1-rc2 $ cabal configure ; time cabal build --ghc-options='-fforce-recomp -v +RTS -t -RTS' >| 8.2.1 2>&1 The "normal" and "profiled" build metrics are the +RTS -t lines extract from Cabal's profiled and unprofiled GHC invocations. I believe the RTS timings for 8.0.2 are broken due to a (fixed) RTS bug, although I can't come up with a reference at the moment. Herbert, did these timings come from a VPS? Cheers, - Ben
Ben Gamari <ben@smart-cactus.org> writes: snip
The "normal" and "profiled" build metrics are the +RTS -t lines extract from Cabal's profiled and unprofiled GHC invocations. I believe the RTS timings for 8.0.2 are broken due to a (fixed) RTS bug, although I can't come up with a reference at the moment.
I tried this again with regex-tdfa-1.2.2 and indeed I was able to reproduce Herbert's result, 8.0.2 normal: <<ghc: 91199006664 bytes, 3573 GCs, 260839393/610327968 avg/max bytes residency (30 samples), 1687M in use, 0.000 INIT (0.001 elapsed), 0.319 MUT (49.441 elapsed), 0.858 GC (30.681 elapsed) :ghc>> profiled: <<ghc: 73210356144 bytes, 3333 GCs, 225266643/599801320 avg/max bytes residency (26 samples), 1731M in use, 0.000 INIT (0.001 elapsed), 0.352 MUT (39.318 elapsed), 0.685 GC (21.644 elapsed) :ghc>> 8.2.1-rc2: normal: <<ghc: 90928069104 bytes, 3655 GCs, 256129517/594585536 avg/max bytes residency (29 samples), 1691M in use, 0.000 INIT (0.001 elapsed), 1.137 MUT (84.652 elapsed), 0.941 GC (47.811 elapsed) :ghc>> profiled: <<ghc: 73010065480 bytes, 3228 GCs, 225992177/578697488 avg/max bytes residency (27 samples), 1649M in use, 0.000 INIT (0.001 elapsed), 0.318 MUT (53.871 elapsed), 0.728 GC (32.681 elapsed) :ghc>> We'll need to look at what is going on here as this is a pretty significant regression. Cheers, - Ben
| We'll need to look at what is going on here as this is a pretty | significant regression. Make a ticket with repro instructions? s | -----Original Message----- | From: Ben Gamari [mailto:ben@smart-cactus.org] | Sent: 20 May 2017 18:20 | To: Herbert Valerio Riedel <hvriedel@gmail.com>; Simon Peyton Jones | <simonpj@microsoft.com> | Cc: ghc-devs@haskell.org | Subject: Re: 8.2 and earlier build times | | Ben Gamari <ben@smart-cactus.org> writes: | | snip | > | > The "normal" and "profiled" build metrics are the +RTS -t lines | > extract from Cabal's profiled and unprofiled GHC invocations. I | > believe the RTS timings for 8.0.2 are broken due to a (fixed) RTS | bug, | > although I can't come up with a reference at the moment. | > | > | I tried this again with regex-tdfa-1.2.2 and indeed I was able to | reproduce Herbert's result, | | | 8.0.2 | normal: <<ghc: 91199006664 bytes, 3573 GCs, 260839393/610327968 | avg/max bytes residency (30 samples), 1687M in use, 0.000 INIT (0.001 | elapsed), 0.319 MUT (49.441 elapsed), 0.858 GC (30.681 elapsed) :ghc>> | profiled: <<ghc: 73210356144 bytes, 3333 GCs, 225266643/599801320 | avg/max bytes residency (26 samples), 1731M in use, 0.000 INIT (0.001 | elapsed), 0.352 MUT (39.318 elapsed), 0.685 GC (21.644 elapsed) :ghc>> | | 8.2.1-rc2: | normal: <<ghc: 90928069104 bytes, 3655 GCs, 256129517/594585536 | avg/max bytes residency (29 samples), 1691M in use, 0.000 INIT (0.001 | elapsed), 1.137 MUT (84.652 elapsed), 0.941 GC (47.811 elapsed) :ghc>> | profiled: <<ghc: 73010065480 bytes, 3228 GCs, 225992177/578697488 | avg/max bytes residency (27 samples), 1649M in use, 0.000 INIT (0.001 | elapsed), 0.318 MUT (53.871 elapsed), 0.728 GC (32.681 elapsed) :ghc>> | | We'll need to look at what is going on here as this is a pretty | significant regression. | | Cheers, | | - Ben
Simon Peyton Jones <simonpj@microsoft.com> writes:
| We'll need to look at what is going on here as this is a pretty | significant regression.
Make a ticket with repro instructions?
participants (5)
-
Ben Gamari -
Christopher Allen -
Herbert Valerio Riedel -
Simon Peyton Jones -
Tim McGilchrist