Hacker News Reader

Comment by jabl | Hacker News Reader

Well, most code isn't performance critical. And most which are, aren't bottlenecked by CPU performance but by network/disk. And of those performance critical programs which are CPU/memory bound, certainly a sizeable bunch might require more than 4 GB memory, depending on the input data. Or are you going to keep a X32 version for "normal" use and a separate x86-64 version for large inputs? Or might want to mmap() large files, etc.

So all the hassle of maintaining a separate ABI (toolchains, kernel, libraries etc.), for a modest performance increase for some subset of applications?

Starts to smell pretty niche to me.

View on HN

> Well, most code isn't performance critical.

In principle yes, but it is hard to predict which code will be at some point performance critical and which code will not. In the worst case you chain a lot of alleged "non performance critical" tasks together and in the sum (actually product, performance percentage is multiplicative) your problem becomes a performance problem.

> Or might want to mmap() large files

This is a fringe application that is not covered by my definition of "application that is unlikely to use more than 2GB of memory". Most programs read linear from files.

> So all the hassle of maintaining a separate ABI (toolchains, kernel, libraries etc.), for a modest performance increase for some subset of applications? Starts to smell pretty niche to me.

As far as I see it there is not enough awareness of this feature. So instead of declaring it "niche" that causes "hassles" maybe advertise it more since the hard work (toolchains, kernel, libraries etc.) has already been done. (My personal use case is derivatives market simulations and performance the gain is in the double digits percentage. I'm pretty sure other use cases exists, they just need to found.)

In the end, who defines "hassle", how big is it really, and who defines "niche"? Potentially accelerating 90% + x of code running on your CPU is hardly a niche.

I hope that "potentially accelerating 90%" was an intentional joke? There is a reason why they consider removing support. We've tried to use it and if there was any improvement anywhere at all, it was minimal. There is this misunderstanding that this magically makes code more efficient. It does not work that way. It absolutely negligible compared to a simple optimization in code itself.

I'm wondering whether a webapp environment such as Chrome OS would be that niche (with a couple of commits in their issue tracker to enable x32).

Hardware is typically a price sensitive netbook contrained by RAM and with a low powered x86-64 CPU, so that 13% performance increase might be noticeable.

The software is a design that is inherently multiprocess for security reasons (where every webapp is essentially a browser tab running in its own sandbox).

> I'm wondering whether a webapp environment such as Chrome OS would be that niche

My guess would be no. For a sort-of counter-example, Apple started migrating to a 64-bit environment for their smartphone and tablet systems already back in 2013, and I think 64-bit Android systems are also pretty common nowadays.

And, if they wanted X32 support, I think it would be more than a "couple of commits in their issue tracker"; AFAIU V8 has no X32 support, which would definitely be a non-trivial undertaking. Do you think they would commit to implementing and maintaining V8 X32 support, just to get a modest performance improvement in such a niche market? Also not to mention that for security reasons they might prefer 64-bit anyways (see ASLR).

My opinion is that 32-bit is rapidly dying for anything approaching "general purpose" (including things like smartphones etc.). For embedded system, sure, 32-bit systems are under no threat of extinction; heck neither are 8 or 16-bit microcontrollers under any particular threat. For an example, look at RISC-V; they haven't even bothered to bring up Linux support for the 32-bit variant, RV64GC is the baseline they are targeting. 32-bit RISC-V seems to be targeting microcontrollers or maybe some simple embedded OS's, but not Linux.

What makes it easier to predict what code will never allocate more than 3GB than to predict what might become performance critical? How do the failure modes differ if the prediction is incorrect?

> In the worst case you chain a lot of alleged "non performance critical" tasks together and in the sum (actually product, performance percentage is multiplicative)

Huh? So if I chain together tasks A->B->C, and assuming (optimistically) that X32 completes a task in 90% of the time of X86-64, then the total time of X32 is not .9x(time_A+time_B+time_C) but, what? .9^3(time_A time_B time_C)? I'm lost, can you explain?

> As far as I see it there is not enough awareness of this feature.

Hmm, I'm not sure. Seems it has been discussed extensively all over the place, certainly enough that people interested and able in shaving some (likely) single-digit percentage time of their application, that they have determined is due to mem/cache usage of pointers, ought to be aware.

> the hard work (toolchains, kernel, libraries etc.) has already been done.

That is true, but the point is that there is an ongoing maintenance burden. If almost nobody is using it, is it worth it to keep paying the maintenance cost? Evidently the Linux kernel maintainers are starting to think that nope, not worth it.

> In the end, who defines "hassle", how big is it really

Presumably the people who have to maintain it?

> and who defines "niche"

Number of users, maybe? Did you read the lkml thread? The X32 Debian maintainer popped in, and mentioned that per popcon X32 in Debian has 7 users. Not 7k, 7. Seven. Now there are certainly users who are not enabling popcon, but still. For comparison, for x86-64 popcon reports 172k users. So for every user who thinks X32 is a good idea and what they need, we have 24k users who prefer x86-64 (certainly a large fraction of those implicitly, but still).

> I'm lost, can you explain?

Lets assume Instruction I_n is dependent on I_n-1 is dependent on ... I_1 (I_1->I_2->...->I_n). The Instuction I_i takes t_i amount of time. Lets further assume those Instructions can be pipelined and parallelized hence the number of executions of the full Instruction series is big compared to n. Then the time needed to execute the series is max(t_i). If we have a optimization that modifies all the times to o_i * t_i the new time needed to execute the series is max(o_j * t_j) hence the time ratio saved on the whole series is r = max(o_j * t_j)/max(t_i) and the time saved per execution is then n * r because the time you save to execute the whole series is not dependent on n itself.

> Debian maintainer popped in, and mentioned that per popcon X32 in Debian has 7 users.

In order to do it right you have to distribute X32 versions for packages where it makes sense in your otherwise X86_64 distribution. Then you have increased the performance for everybody and an adoption of 100%.

Reply on news.ycombinator.com