Hi,
On 2024-07-30 21:59:44 -0500, Nathan Bossart wrote:
> On Tue, Jul 30, 2024 at 07:39:18PM -0700, Andres Freund wrote:
> > We can hide most of the dispatch cost in a static inline function that only
> > does the runtime test if size is large enough - the size is a compile time
> > constant most
On Tue, Jul 30, 2024 at 07:39:18PM -0700, Andres Freund wrote:
> On 2024-06-12 20:09:45 -0500, Nathan Bossart wrote:
>> The idea that's been floating around recently is to build a bunch of
>> different versions of Postgres and to choose one on startup based on what
>> the CPU supports. That seems
Hi,
Reply triggered by https://postgr.es/m/ZqmRYh3iikm1Kh3D%40nathan
On 2024-06-12 20:09:45 -0500, Nathan Bossart wrote:
> This is perhaps only tangentially related, but I've found it really
> difficult to avoid painting ourselves into a corner with this stuff. Let's
> use the SSE 4.2 CRC32C co
Re: To Thomas Munro
> Or Debian might just bump the baseline. PostgreSQL asking for it might
> just be the reason we wanted to hear to make it happen.
Which level would PostgreSQL specifically want? x86-64-v2 or even
x86-64-v3?
Christoph
Hi,
sorry for the delayed reply, I suck at prioritizing things.
Re: Thomas Munro
> OK let me CC Christoph and ask the question this way: hypothetically,
> if RHEL users' PostgreSQL packages became automatically faster than
> Debian users' packages because of default -march choice in the
> toolcha
On Thu, Jun 13, 2024 at 8:15 PM Magnus Hagander wrote:
> Yeah, I think it's completely unreasonable to push this on packagers and
> just say "this is your problem now". If we do that, we can assume the only
> people to get any benefit from these optimizations are those that use a fully
> manag
On Thu, Jun 13, 2024 at 9:41 AM Peter Eisentraut
wrote:
> On 13.06.24 04:00, Nathan Bossart wrote:
> > That's true, but my point is that as soon as we start avoiding function
> > pointers more commonly, it becomes difficult to justify adding them back
> in
> > order to support new instruction set
On 13.06.24 04:00, Nathan Bossart wrote:
That's true, but my point is that as soon as we start avoiding function
pointers more commonly, it becomes difficult to justify adding them back in
order to support new instruction sets. Should we just compile in the SSE
4.2 version, or should we take a c
On Thu, Jun 13, 2024 at 01:20:17PM +1200, Thomas Munro wrote:
> The way I think about it, it's not our place to require anything (I
> mean, we can't literally put -march=XXX into our build files, or if we
> do the Debian et al maintainers will have to remove them by local
> patch because they are i
On Thu, Jun 13, 2024 at 1:09 PM Nathan Bossart wrote:
> Now, let's say we require x86-64-v2. Once we have that, we can avoid the
> function pointer on many more x86 machines. While that sounds great, now
> we have a different problem. If someone wants to add, say, AVX-512 support
> [0], which i
On Thu, Jun 13, 2024 at 11:11:56AM +1200, Thomas Munro wrote:
> David R and I were discussing vectorisation and microarchitectures and
> what you can expect the target microarchitecture to be these days, and
> it seemed like some of our choices are not really very
> forward-looking.
>
> Distros ta
Hi,
David R and I were discussing vectorisation and microarchitectures and
what you can expect the target microarchitecture to be these days, and
it seemed like some of our choices are not really very
forward-looking.
Distros targeting x86-64 traditionally assumed the original AMD64 K8
instructio
12 matches
Mail list logo
