Thread: Is *fast* 32-bit support still important?
Hello hackers, I would like your help to collectively try to answer these three questions: 1. Who are the current users of 32-bit PostgreSQL? 2. Among these users, how many are upgrading to new major versions? 3. For how many of these users is performance critical? This came up during ongoing work on optimizing numeric_mul [1]. To me, it's non-obvious whether introducing `#if SIZEOF_DATUM < 8` with separate 32-bit and 64-bit code paths is worthwhile to maintain performance for both. Knowing more about $subject can hopefully help us reason about how much additional code complication is justifiable for *fast* 32-bit support. I checked the archives but only found a discussion on *dropping* 32-bit support [2], which is a different topic. Thanks for input! /Joel [1] https://postgr.es/m/9d8a4a42-c354-41f3-bbf3-199e1957db97@app.fastmail.com [2] https://postgr.es/m/0a71b43129fb447988f152941e1dbcb3@nidsa.net
On 29/07/2024 23:40, Joel Jacobson wrote: > To me, it's non-obvious whether introducing `#if SIZEOF_DATUM < 8` with > separate 32-bit and 64-bit code paths is worthwhile to maintain performance > for both. > > Knowing more about $subject can hopefully help us reason about how much > additional code complication is justifiable for *fast* 32-bit support. IMO I don't think it's worth adding extra code for fast 32-bit support anymore. However, I'd still be wary of *regressing* performance on 32-bit systems. So if you're adding a new fast path to a function, it's OK to make it 64-bit only, and fall back to the old slower code on 32-bit systems. But -1 on *removing* existing 32-bit fast path code, or rewriting things in a way that makes an existing function significantly slower than before on 32-bit systems. This isn't black or white though. It depends on how big a gain or regression we're talking about, and how complex the extra code would be. -- Heikki Linnakangas Neon (https://neon.tech)
Hi Joel, Here are my two cents. > 1. Who are the current users of 32-bit PostgreSQL? Pretty much any embedded system that uses just a few GB of memory may win from using a 32-bit processor (not necessarily in terms of performance, maybe in terms of price). Think of WiFi-routers, smart TVs, 3D printers, etc. Generally speaking it's hard to give an exact answer due to lack of "telemetry" in PostgreSQL. > 2. Among these users, how many are upgrading to new major versions? I would guess it very much depends on the product and manufacturer. I wouldn't assume though that users of 32-bit systems don't do major upgrades. (Not to mention that it's beneficial for us to test the code on 32-bit systems.) > 3. For how many of these users is performance critical? Depends on how you define performance. Performance of a single OLTP query is important. The performance of the upgrade procedure is probably not that important. The ability of processing a lot of data is probably also not extremely important, at least I wouldn't expect a lot of data and/or fast storage devices on 32-bit systems. -- Best regards, Aleksander Alekseev
On Tue, Jul 30, 2024, at 09:25, Heikki Linnakangas wrote: > On 29/07/2024 23:40, Joel Jacobson wrote: >> To me, it's non-obvious whether introducing `#if SIZEOF_DATUM < 8` with >> separate 32-bit and 64-bit code paths is worthwhile to maintain performance >> for both. >> >> Knowing more about $subject can hopefully help us reason about how much >> additional code complication is justifiable for *fast* 32-bit support. > > IMO I don't think it's worth adding extra code for fast 32-bit support > anymore. However, I'd still be wary of *regressing* performance on > 32-bit systems. > > So if you're adding a new fast path to a function, it's OK to make it > 64-bit only, and fall back to the old slower code on 32-bit systems. But > -1 on *removing* existing 32-bit fast path code, or rewriting things in > a way that makes an existing function significantly slower than before > on 32-bit systems. > > This isn't black or white though. It depends on how big a gain or > regression we're talking about, and how complex the extra code would be. Thanks for input. I still haven't got any reports from real users of 32-bit PostgreSQL, so my comments below are based on the assumption that such users exist and have high performance needs. I agree that it's not a black or white decision since quantifying complexity is inherently challenging. However, perhaps it would be possible to say something about lower and upper bounds on 32-bit slowdown? - Below a certain percentage slowdown, extra 32-bit code optimization is definitively unnecessary. - Above a certain percentage slowdown, extra 32-bit code optimization is definitively necessary. In the range between these bounds, I guess the decision should depend on the specific added code complexity required? It's also the question what percentage we're reasoning about here. Is it the time spent in the function, or is it the total execution time? /Joel
On Tue, Jul 30, 2024, at 11:06, Aleksander Alekseev wrote: > Hi Joel, > > Here are my two cents. > >> 1. Who are the current users of 32-bit PostgreSQL? > > Pretty much any embedded system that uses just a few GB of memory may > win from using a 32-bit processor (not necessarily in terms of > performance, maybe in terms of price). Think of WiFi-routers, smart > TVs, 3D printers, etc. Thanks for feedback! Do we know of any such products or users? I found an OS that runs on many 32-bit chips, FreeRTOS, that seems quite popular. Couldn't find anything about PostgreSQL and FreeRTOS though. I've posted a question on their forum. [1] Let's wait and see if we hear from any real user. I see one i386 and i686 build farm animals runs Debian. Perhaps it makes sense to try to reach out to the Debian community, and see if they know of any PostgreSQL users on 32-bit? > Generally speaking it's hard to give an exact answer due to lack of > "telemetry" in PostgreSQL. Could we add a text message that is displayed to a user, when compiling PostgreSQL on a 32-bit platform? ***** NOTICE: You are compiling PostgreSQL on a 32-bit platform. We are interested in learning about your use case. Please contact us with details about how you are using PostgreSQL on this platform. Thank you! Contact: pgsql-hackers@postgresql.org Subject: Report from 32-bit user ***** /Joel
Hi, > > Pretty much any embedded system that uses just a few GB of memory may > > win from using a 32-bit processor (not necessarily in terms of > > performance, maybe in terms of price). Think of WiFi-routers, smart > > TVs, 3D printers, etc. > > Thanks for feedback! > > Do we know of any such products or users? > > I found an OS that runs on many 32-bit chips, FreeRTOS, that seems quite popular. > Couldn't find anything about PostgreSQL and FreeRTOS though. > I've posted a question on their forum. [1] Let's wait and see if we hear from any real user. I'm not extremely familiar with FreeRTOS but my humble understanding is that it's very different from what we would typically call an "operating system". If I'm not wrong, basically this is a framework that adds multitasking to STM32 microcontrollers. This is not exactly a target hardware for PostgreSQL (although running PostgreSQL on STM32 MCUs could be a fun project for someone looking for a challenging task.) > I see one i386 and i686 build farm animals runs Debian. > Perhaps it makes sense to try to reach out to the Debian community, > and see if they know of any PostgreSQL users on 32-bit? > > > Generally speaking it's hard to give an exact answer due to lack of > > "telemetry" in PostgreSQL. > > Could we add a text message that is displayed to a user, > when compiling PostgreSQL on a 32-bit platform? What would be actionable items depending on the results? Option A: someone claims to use PostgreSQL on 32-bit hardware. Option B: no one admits that they use PostgreSQL on 32-bit hardware (but maybe someone actually does and/or will in the future). Regardless of the results you can't drop the support of 32-bit software (until it gets as difficult and pointless as with AIX that was dropped recently) and it will not tell you how slow the 32-bit version of PostgreSQL can be. If there are no actionable items why create a poll? -- Best regards, Aleksander Alekseev
On Mon, Aug 5, 2024, at 14:24, Aleksander Alekseev wrote: >> Could we add a text message that is displayed to a user, >> when compiling PostgreSQL on a 32-bit platform? > > What would be actionable items depending on the results? Option A: > someone claims to use PostgreSQL on 32-bit hardware. Option B: no one > admits that they use PostgreSQL on 32-bit hardware (but maybe someone > actually does and/or will in the future). Regardless of the results > you can't drop the support of 32-bit software (until it gets as > difficult and pointless as with AIX that was dropped recently) and it > will not tell you how slow the 32-bit version of PostgreSQL can be. > > If there are no actionable items why create a poll? Never suggested *dropping* 32-bit support; that's a different question. However, if we were to receive input from 32-bit PostgreSQL users explaining why they need *high performance*, then I imagine that could affect how we feel about 32-bit optimizations. Right now, there doesn't seem to be a consensus on whether we should optimize for 32-bit or not. On the one hand, we have commit 5e1f3b9 that says: "While it adds some space on 32-bit machines, we aren't optimizing for that case anymore." On the other hand, we have the ongoing work on optimizing numeric_mul, where a patch is suggested with extra code to optimize for 32-bit. I agree, however, that the absence of any comments from such a poll would not give us any more information. /Joel
On Mon, Jul 29, 2024 at 4:41 PM Joel Jacobson <joel@compiler.org> wrote: > To me, it's non-obvious whether introducing `#if SIZEOF_DATUM < 8` with > separate 32-bit and 64-bit code paths is worthwhile to maintain performance > for both. I feel like it's probably mostly up to the patch author. Reviewers and/or the eventual committer might propose to reverse whatever decision the patch author made, but personally, I wouldn't bounce a patch for either having or not having separate code paths, unless there was some particular reason to believe that whatever decision the patch author made was likely to cause a problem. One generally difficult thing about working in the PostgreSQL community is that we have pretty limited formal decision-making structures. A consensus on the list is valid only until the issue is relitigated, which can happen at any time and for any reason. With infrequent exceptions such as RMT or core pronouncements, a previous consensus doesn't bind people who weren't participants in the previous discussion, or even people who were. Everybody is free to change their mind at any time. For that reason, I often find it more helpful to approach questions like this from a pragmatic standpoint: rather than asking "what is the policy about X?" I find it better to ask "If I do X, what is probably going to happen?" What I think is: if you write a patch that caters mostly to 64-bit systems, probably nobody will notice or care that the 32-bit performance is not great, because there just aren't that many 32-bit users left out there. I think it's been a very long time since we got a complaint about 32-bit performance, or a patch to improve 32-bit performance, but we get other kinds of performance-optimizing patches all the time, for all sorts of things. Perhaps that's because we haven't yet done anything too terrible to 32-bit performance, but it's probably also that if you're running a 32-bit system in 2024, you're probably not expecting it to come under serious load. You likely care more about getting the job done with limited machine resources than anything else. And you likely expect it to be slow. I don't actually know how much we'd have to regress 32-bit performance before users started to show up and complain about it, and I'm certainly not recommending that we do so gratuitously. At the same time, evidence that people are displeased with our current 32-bit performance or that they care about improving our 32-bit performance is very thin on the ground, AFAIK. If at some point people do start showing up to complain, then we'll know we've gone too far and we can back off -- with the benefit of knowing what people are actually unhappy about at that point, vs. what we think they might be unhappy about. And on the other hand, if you take the opposite approach and write a patch that includes a separate code path for 32-bit systems, as long as it works and doesn't look terribly ugly, I bet nobody's going to waste time demanding that you rip it out. So I would just do whatever you feel like doing and then defend your choice in the comments and/or commit message. -- Robert Haas EDB: http://www.enterprisedb.com