On 02/12/16 09:02 PM, Reid Barton wrote:
btw, just recent experience on ARM64 (X-gene board):
bootstrapping 7.10.1 with 7.6.x took: ~120 minutes
bootstrapping 8.0.1 RC2 with 7.10.1 took: ~446 minutes
both run as: ./configure; time make -j8
It would be interesting to have the t
Hi,
Am Freitag, den 12.02.2016, 14:04 -0500 schrieb Richard Eisenberg:
> Ideally, there would be a way to run a portion of the testsuite and
> have the testsuite tool aggregate performance characteristics and
> report.
if you run the test suite with
$ VERBOSE=4
you get the detailed stats for eve
Richard Eisenberg writes:
> Hi devs,
>
> I have a few ideas for tweaks to improve compiler performance. (For
> example, reversing the order of comparisons in a short-circuiting
> comparison operation.) I don't have a particular test case with a
> profile that tells me where the smoking gun is. Bu
You could tweak the function `checkStats` in `testsuite/driver/testlib.py`
a bit, to not only report failures.
Maybe also disable the following check, if you're doing this from a debug
build:
# Compiler performance numbers change when debugging is on, making the
results
# useless and conf
On Feb 12, 2016, at 3:28 PM, Simon Peyton Jones wrote:
> cd testsuite/tests/perf; make
But that tells me only about failures. What if I have a tweak that makes an
average 1% improvement over lots of files? That would be a nice improvement,
but we don't have an easy way to collect this info, I
cd testsuite/tests/perf; make
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Richard
| Eisenberg
| Sent: 12 February 2016 19:04
| To: ghc-devs@haskell.org developers
| Subject: quick performance measurements
|
| Hi devs,
|
| I have a few ideas f
On Tue, Feb 9, 2016 at 11:20 AM, Karel Gardas
wrote:
> On 01/28/16 11:34 PM, Ben Gamari wrote:
>
>> Joachim Breitner writes:
>>
>> Hi Oleg,
>>>
>>> Am Freitag, den 29.01.2016, 00:22 +0200 schrieb Oleg Grenrus:
>>>
Is the same compiler used to build HEAD and 7.10,1?
>>>
>>> Good call. I
Hi devs,
I have a few ideas for tweaks to improve compiler performance. (For example,
reversing the order of comparisons in a short-circuiting comparison operation.)
I don't have a particular test case with a profile that tells me where the
smoking gun is. But I'd like to try these easy tweaks
Hi Janek,
Am Freitag, den 12.02.2016, 08:36 +0100 schrieb Jan Stolarek:
> Joachim, what do I need to do to have my wip/ branch picked up by the
> performance dashboard? I'm
> thinking about branch wip/js-hoopl-cleanup, which was pushed
> yesterday but still hasn't been
> measured for performance
Ben Gamari writes:
> Simon Peyton Jones writes:
>
>> I’m getting this on a clean HEAD. Is anyone else?
>> Simon
>>
>> Unexpected stat failures:
>>perf/compiler T5030 [stat not good enough] (normal)
>>perf/compiler T9872b [stat not good enough] (normal)
>>perf/compiler T9872c [sta
Simon Peyton Jones writes:
> I’m getting this on a clean HEAD. Is anyone else?
> Simon
>
> Unexpected stat failures:
>perf/compiler T5030 [stat not good enough] (normal)
>perf/compiler T9872b [stat not good enough] (normal)
>perf/compiler T9872c [stat not good enough] (normal)
I
I’m getting this on a clean HEAD. Is anyone else?
Simon
Unexpected stat failures:
perf/compiler T5030 [stat not good enough] (normal)
perf/compiler T9872b [stat not good enough] (normal)
perf/compiler T9872c [stat not good enough] (normal)
_
Hi,
I'm currently trying to understand GHC's implementation of Template
Haskell and I've had the following two questions when reading upon
deSugar/DsMeta.hs and deSugar/dsExpr.hs (disclaimer: I'm a complete
newbie to GHC and do not know pretty much anything about its internals;
so please excuse s
13 matches
Mail list logo
