Re: [creduce-dev] halfempty algorithm for creduce?

[Nico Weber <thakis@chromium.org>]

Thanks for sharing the data and the test scripts!

The inputs we usually use with creduce are 2-4MB (basically what clang writes when it hits an assert -- it's a single cpp file with all .h files inlined via -frewrite-includes -E), so orders of magnitude larger. I'd expect the speedup to be much larger. If so, I suppose I could run halfempty first and then creduce second.

Thanks to your reply and went and looked at the default value for --n, and apparently it's 4 (https://github.com/csmith-project/creduce/blob/a1aa2a3601addc4d8d22c203c1ddecdbdde3df6e/creduce/creduce_utils.pm#L151), which means I'm using only 10% of my cores when running creduce. I wasn't aware of that, so thanks for making me look it up. Maybe just passing --n 48 will make things much faster already.

I'll do a comparison of my last bisect and will report numbers.

On Fri, Jun 14, 2019 at 2:38 AM Vegard Nossum <vegard.nossum@gmail.com> wrote:

I did a creduce vs. halfempty benchmark at some point. These were my results:

"""
Same input (739 bytes C++), ~same test script, 1 vs 32 threads (on 32 cores).

Halfempty speedup = ~2.7 (-63%),
creduce speedup = ~8.7 (-89%).

at 32 cores the two programs were within 8 seconds of each other (!),
whereas on 1 core, halfempty took 7m27 and creduce took 22m57

The final file sizes were:

460 bytes for halfempty,
317 for c-reduce
"""

File dump from back then at:
https://gist.github.com/vegard/e79b96cefffbfb753da17c4646132fab


Vegard

On Thu, 13 Jun 2019 at 22:57, Nico Weber <thakis@chromium.org> wrote:
>
> Hi,
>
> creduce often takes more than an hour to run, with most cores being idle. https://github.com/googleprojectzero/halfempty is an approach to doing delta debugging in parallel. Could that approach be implemented in creduce as well?
>
> Thanks,
> Nico