[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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:


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