Hacker News Reader

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?

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.

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.

> 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%.