GNU bug report logs - #38322
GCC optimize levels makes huge impact on performance

Previous Next

Package: grep;

Reported by: Balázs Vinarz <vinibali1 <at> gmail.com>

Date: Fri, 22 Nov 2019 17:05:02 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Balázs Vinarz <vinibali1 <at> gmail.com>
Subject: bug#38322: closed (Re: bug#38322: GCC optimize levels makes huge
 impact on performance)
Date: Thu, 02 Jan 2020 10:09:02 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#38322: GCC optimize levels makes huge impact on performance

which was filed against the grep package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 38322 <at> debbugs.gnu.org.

-- 
38322: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38322
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Balázs Vinarz <vinibali1 <at> gmail.com>
Cc: 38322-done <at> debbugs.gnu.org
Subject: Re: bug#38322: GCC optimize levels makes huge impact on performance
Date: Thu, 2 Jan 2020 02:08:27 -0800
On 11/22/19 5:52 PM, Paul Eggert wrote:
> If we do want to tune grep for set-like operations, that suggests doing some
> surgery to its internals rather than merely fiddling with -O flags.

Since I last wrote, some of that surgery has been done by another grep
contributor, and a simple 'grep -f file1 file2' benchmark that I just now tried
sped up from 47 seconds (for grep 3.1) to 2.3 seconds (for the next version of
grep). So this algorithmic change should far outweigh any GCC optimization level
change.

Anyway, the topic seems to have died down so I'm closing the bug report.

[Message part 3 (message/rfc822, inline)]
From: Balázs Vinarz <vinibali1 <at> gmail.com>
To: bug-grep <at> gnu.org
Subject: GCC optimize levels makes huge impact on performance
Date: Fri, 22 Nov 2019 18:00:29 +0200
Hello there!

Today I was working on two bigger, plain text, csv-like database files
(file1: ~175k lines and 15MB, file2: ~ 168k lines and 14MB). I just
searched for lines, using grep -f $file2 $file1. I was so surprised
when I realized the search was running for minutes already without a
single line at the standard output. I decided to have a try with
custom compiled binaries, because in my mind the size optimized
binaries are the fastest.
In the end grep (3.1) was running for:
- 4m50s if I used the one was coming from Ubuntu,
- 4m29s in case of custom recompiled with GCC7.4 and CFLAGS="O2" and
- 3m17s in case of custom recompiled with GCC7.4 and CFLAGS="Os".
I repeated the runs multiple times, I would say it's accurate. The
files were located on tmpfs.
Binary sizes are: 215K for Ubuntu, 184K for O2 and 150K for Os.
CPU: Intel I5-8350U
OS: Ubuntu 18.04.3 LTS
Would you mind change the default optimize level on the make
configuration? Did somebody ever measured the benefits using different
GCC optimalization levels?
I know that this is a special use case, but the improvement is huge.
I'm looking forward for your feedback.

Best regards



This bug report was last modified 5 years and 137 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.