Announcement

Collapse
No announcement yet.

Linux x32 ABI Interest Faded In 2013

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by kertoxol View Post
    The right ABI for netbooks, arrived too late.
    It is really the wrong idea for just about anything. Once people associated with the idea realize that the code supporting X32 will,slowly fad away.

    Comment


    • #17
      Originally posted by brad0 View Post
      The netbooks where this mattered were/are using 32-bit processors so you can't use said ABI on those systems. Systems where there are 64-bit processors this isn't an issue. Its work to create an ABI for no real world use and then to have to maintain the compiler/toolchain for something very few people will use.
      This is the case exactly. There is simply no real world benefit that justifies the effort required to support the concept.

      Comment


      • #18
        Why would you waste your time doing this? It helps no one and only complicates the distro.

        Originally posted by s_j_newbury View Post
        At least on the Gentoo front, a major roadblock is getting complete multi-abi coverage so that it's possible to emerge a system with x32, then use LP64 ABI as appropriate for a given application, or of course x86 where there is only a x86 package availability, with all dependencies resolved automatically.

        We were pretty much there with the previous multilib-portage effort, but since that wasn't adopted upstream there's been quite a lot of work modifying ebuilds to integrate support, which is what I've been working on for the last month or so. Since I now have Steam working without any emul-linux-x86 binaries, I'm going to start pushing my changes out to ebuild maintainers, so hopefully this will be landing soon. Once that's done I'm going to have another attempt at bringing up x32 as a fully supported ABI, I probably need to have another look at llvm/clang...

        Comment


        • #19
          Well if counting years in the field adds to credibility, I've been around this stuff since the late seventies. By the way that should have zero impact on credibility.

          Originally posted by macpacheco View Post
          There's no magic about how x32 works exactly.
          The only way that x32 could be slower than regular 32bit or x86_64 is some system calls that require conversion of the pointers passed.
          Honestly I don't care if it is faster or slower, it really isn't a point of value here. It is the idea of supporting yet another ABI for nothing of value.
          Plus this set of pure 32bit, 64bit data/32bit pointer and pure 64bit isn't anything new.
          When it's all said and done, you must get some performance improvement, except for some very rare cases that uses almost no pointers.
          You make an assumption that pointers are a huge issue, they aren't. Sure you can look for and find examples of software that is cluttered with pointers but not all code is so encumbered.
          You don't need benchmarks to show that in average there will be 5-10% performance gains.
          Sure you do! Are we suppose to take your word for it?
          I see way too many people criticize x32, but the way they word their messages, it looks like they don't really understand every (positive) impact x32 will have on performance.
          You have done nothing yourself to indicate a justification for supporting yet another ABI.
          They try to frame x32 as only useful for embedded systems where RAM might be limited, showing they don't really understand (and don't care to understand it correctly).
          People forget that the main issue isn't saving RAM, but improving cache hits by reducing the size of data structures, reducing per function stack usage (also to improve cache hits), and reduce RAM bandwidth usage.
          Supporting another ABI doesn't help one bit as now you have libs competing for that RAM and cache space. It really doesn't matter what the platform is, supporting more than one ABI leads to much wasted memory space often dramatically offsetting any supposed performance gains in real world usage.
          If this x32 thing isn't so great, then please get just one hardcore linux kernel developer or some other developer known to care about performance to say x32 isn't a big deal, please.
          Haven't talked to a kernel developer in years. However how many times have these guys been wrong in the past. A rational goal for anybody doing a 64 bit OS is to make sure all of the software running on that machine is 64 bit. That is your number one goal to assure performance is not compromised by excessive memory usage.
          I'm not a kernel developer, but I'm a performance person that started using computers back in the 8 bit times, and learned assembly before C, while (I'm almost sure) most people saying: "this isn't a big deal, prove me it's useful" are much younger guys that are used to be lazy about performance. Sorry about the prejudice, I would like people give their technical credentials before criticizing.
          Why should anyone do that when responding to the nonsense you have just posted?
          I have 30 years of computer experience, how much do you have ?
          Depending on your experience you just know what will work, what won't, and what needs testing. x32 is one of those cases that I know it will work (be worth it). And I'm yet to see a LOGICAL explanation why it might not work (not be worth it).
          You have offered joint rational to support your point of view so it is pretty pathetic to demand that others offer up what you want to call logical explanations. In simple terms X32 wastes RAM and by doing so screws performance that it supposedly recovers. The concept is the modern work of the snake oil salesman of prior centuries.

          Comment


          • #20
            Originally posted by macpacheco View Post
            I remember running Microsoft C compiler from floppy disks circa 1990. We had small (16/16bit), medium (16 bit code pointers, segmented data pointers, code limited to 64KB, data could use all memory), large models (segmented data and code pointers), that was a hack... Took a few minutes to compile a plain hello world program. medium model had data pointers different size of code pointers, very ugly. And memory segments, that was a PITA.


            Originally posted by macpacheco View Post
            x32 is a plain linear model, pure C/C++ core can be recompiled in many cases with no changes at all. And if changes are needed they are tiny (assuming the code is already compatible with both 32-bit / x86_64, essentially it's the 32-bit #ifdef with 64 timestamps, everything else is the same 32bit code).
            I'm very aware it's a difficult, maybe even lost cause vs just using only x86_64. But it's a lot cause because people decided it's not worth, not because it's difficult to do at all ! It's 99.9% about people wanting to do it, rather than oh it's going to take days of work per package, it's more like minutes of work per package (assuming no __asm code blocks or .S files involved).
            But I don't agree with the it's a hack statement. There's no segmentation involved.
            My problem is with assumption most software doesn't use 64bit(63bits). Once ASR is in place, x32 will interfere with it and reduce the window to 4GiB, no? So, for embedded, sure; but aren't they okay with 32bit anyway? 64bit timestamps are another issue. And more will come, matter of time. I sense its similar hack to offset:segment with 286, instead of just moving to larger register globally. Integer over follows have a funny effect of receiving 2 billions of dollars for no apparent reason , I can imagine an embedded terminal implemented. Not that I am going to hold you off, breaking things is always fun.

            Comment


            • #21
              Originally posted by brosis View Post




              My problem is with assumption most software doesn't use 64bit(63bits). Once ASR is in place, x32 will interfere with it and reduce the window to 4GiB, no? So, for embedded, sure; but aren't they okay with 32bit anyway? 64bit timestamps are another issue. And more will come, matter of time. I sense its similar hack to offset:segment with 286, instead of just moving to larger register globally. Integer over follows have a funny effect of receiving 2 billions of dollars for no apparent reason , I can imagine an embedded terminal implemented. Not that I am going to hold you off, breaking things is always fun.
              Sorry to be an ass, this is aggravating for me.

              Your making assumptions that show me you don't know the basic concepts required to truly understand x32 (and its implications).
              Bottom line, you're mixing things that aren't x32 specific, that apply to both 32bit and x86_64.

              I think you need a recap of what x32 is.
              32bit runs in a older 32bit mode of x86 cpus.
              x86_64 runs in 64bit mode, which expands all registers to 64bits, plus double the general register profile.
              Regardless of the above, gcc / g++ even under 32bit has 64bit integer data types, with a full range of operations. Most operations will generate multiple instructions, but that's only a performance hit, functionality is unaffected (except for atomicity, but that's a direct consequence of multiple instructions).
              x32 is x86_64 with only one difference, 32 bit pointers, every other feature of x86_64 is there.
              But at the C / C++ language level, you're able to do signed / unsigned 64bit integer math in all 3 modes.
              Since x86_64 uses a 64bit timestamp to represent seconds since Jan, 1st 1970, Linus decided x32 would use that same format (avoiding the 2037 time stamp overflow).
              Bottom line, is per the usual, there is a lot of people bashing x32 that just don't really understand how in works (specially under the hood).

              No offense, but if you understood under the hood, you wouldn't be demanding benchmarks, just because there no set backs. It has everything good about 32bit and everything good about x86_64 performance wise. The only hit is that system calls must get 32 bit pointers and convert to 64 bit (a trivial operation, that would only be even measurable on apps that execute very little work of its own between system calls, other benefits overwhelm this hit).

              Like I said, c / c++ code that works properly in both 32bit and x86_64 modes and don't use assembly should run under x32 with almost no source changes, also very tiny build environment changes.


              Why I don't need no stinking x32 benchmarks to know it will be better:
              1 - All pointers that need to be stored in the stack (auto allocation), global (static allocate) variables or data structures benefits from x32 vs x86_64 (with the only exception of register variables, but even then, since there are more registers, you can keep more variables in the cpu's registers), they use half the address space which benefits the L1/L2/L3 caches. There zero chance of this being worse than either 32bit or x86_64, except for system call overhead, which is negligible. There's a significant performance benefit for stack allocated pointers, stack allocated structs (with pointers), pointers passed as function arguments.
              2 - The doubling of the register profile speeds up everything versus 32bit, zero chance of any losses here, cause pointers don't double in size (the downsize of x86_64). Since the C int is still 32bit (in all 3 cases) 32bit variables don't become 64bit. x32 longs are 64 bit like x86_64 (32bit in 32bit).
              3 - All x86_64 special tricks are in x32. The system clock can be read without a system call. Less CPU instructions are used for function calls. Function calls with few parameters use register only calling convention.

              Like I said, even with 30 years of programming experience (half of it doing C level stuff) I wrote very little assembly code. I know this stuff cold because I'm ultra curious and a performance nut.
              If this isn't clear, you don't need benchmarks, you need to learn assembly language and cpu architectures properly.
              It's a pity we don't have a magazine like BYTE was circa 1990, that explained this low level stuff extremely well.

              Comment


              • #22
                macpacheco, just to clear up some confusion on your part:

                x32 is ILP32; this means Int, Long and Pointer are 32 bits long. 64 bit C operations will make use of the full 64 bit registers but code utilising ints and longs will only use 32 bit types, just like with x86-32. Code should never depend on the size of non-explicitly sized types, where it does is a bug and was one of the most common problems encountered as 64 bit systems became more common. Fortunately, this means most such bugs have already been long fixed.

                Comment

                Working...
                X