es in the context of application-specific benchmarks.
Yaron.
From: Sasha Krassovsky
Sent: Wednesday, July 20, 2022 5:55 PM
To: dev@arrow.apache.org
Subject: Re: [C++] Moving from -O3 to -O2 optimization level in release builds
I’d +1 on this - in my past experience
ol for selecting the best optimization flags for Arrow
modules in the context of application-specific benchmarks.
Yaron.
From: Sasha Krassovsky
Sent: Wednesday, July 20, 2022 5:55 PM
To: dev@arrow.apache.org
Subject: Re: [C++] Moving from -O3 to -O2 optimizat
tify a switch to -O2. In the longer-term, I'd
> suggest making a bisection tool for selecting the best optimization flags for
> Arrow modules in the context of application-specific benchmarks.
>
>
> Yaron.
>
> From: Sasha Krassovsky
&g
n flags for Arrow
modules in the context of application-specific benchmarks.
Yaron.
From: Sasha Krassovsky
Sent: Wednesday, July 20, 2022 5:55 PM
To: dev@arrow.apache.org
Subject: Re: [C++] Moving from -O3 to -O2 optimization level in release builds
I’d +1 on th
I’d +1 on this - in my past experience I’ve mostly seen -O2. It would make
sense to default to -O2 and only enable -O3 on source files selectively that
can be demonstrated to benefit from it (if anyone actually spends the time to
look into it).
Sasha
> On Jul 20, 2022, at 2:10 PM, Wes McKinney
hi all,
Antoine and I were digging into a weird issue where gcc in -O3
generated ~40KB of optimized code for a function which was less than
2KB in -O2, and where a "leaner" implementation (in PR 13654) was yet
faster and smaller. You can see some of the discussion at
https://github.com/apache/arr
