On Thu, Jun 23, 2016 at 1:42 PM, John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote:
> On 06/23/2016 05:06 PM, David Miller wrote: > > I think what irks people the most about what happened, is that the > > choosen a path is not the most optimal situation for the target > > platform. > > Why should it be any different for sparc64 than for ppc64el, amd64, > arm64, mips64el and so on? Is SPARC so extremely inefficient with > 64-bit pointers? I don't think so. > > > The most desirable would have been to build the bulk of userland > > binaries as 32-bit with v8+ extensions (perhaps even with -mcpu=xxx > > for some v9 cpu), and then for the specific packages that need it, > > build 64-bit. > > I don't think it makes sense to compile things like dateutils with > 32-bit pointers for performance reasons. Also, I would assume that > modern compilers are able to optimize the code well enough that the > difference between 32-bit and 64-bit pointers isn't too big that > it justifies the effort. Some compilers like Intel's C/C++ compiler > are actually already automatically generating 32-bit code when possible, > the feature is called auto-ilp32 [1]. gcc could possibly adopt a similar > feature in the future. > > Just to adopt a devil's advocate approach here: I could also say that it doesn't make sense to compile dateutils for 64-bit since extended address space is no use. I think the point is that there are advantages both ways: having a single set of 64-bit packages is a lot easier to maintain, but David Miller is correct in saying that a large majority of packages do not benefit from using 64-bit memory model, but all of them pay a "tax", relative to the 32-bit packages in code size, cache usage, etc. Obviously, for stuff like `ls`, I could care less if took 250usec longer due to "64-bitness", but if somehow that caused my builds to take 5 extra minutes, I might get annoyed. It's interesting to see, because from a maintainer standpoint, what you are arguing makes a lot of sense, and from David's kernel developer standpoint, he probably dislikes what he perceives as inefficient usage of the hardware that slows down his workflow. I'm also pretty sure that all of the incredible work you two have been doing to iron out SIGBUS, fix drivers, and many other unspeakable violations of C standards will translate to better code if there ever is more demand for 32-bit SPARC packages. Like you said, it shouldn't be a problem to build / upload (32-bit) sparc packages, and then install them if desired, right? Honestly, I'm just happy to have a working kernel/userland/installer! That's a great base to launch any further operations, so thanks to both of you.
