5 ms·

I hope they converge towards the middle and stay there until ARM takes over completely (which it will, within the next decade or so). I'm waiting for Threadripp

by 0xbear 9y ago

I hope they converge towards the middle and stay there until ARM takes over completely (which it will, within the next decade or so). I'm waiting for Threadripper and for AMD to address Linux-related problems with Ryzen (GCC crashes, general stability, etc), but we did build a couple of boxes with Ryzen at work to benchmark and optimize software for, and they hold their own against Intel performance wise, in spite of narrower SIMD.

cptskippy 9y ago
I don't see your hope for AMD or your prediction about ARM happening. I think it's much more likely that Intel will continue to produce backward compatible x86 chips and start producing a variant that eschews backwards compatibility in favor of performance by dropping legacy x86 features either gradually or entirely.
- 0xbear 9y ago
  I bet you also don't see the impending cloud price wars which will make the current cost structures unsustainable. And you also don't see that it is vital for cloud providers to avoid a single vendor situation with the most expensive line item in their capex. For the first time in a very long time, you can compile your software with "-march-native" on Skylake and then just run it (with AVX2 and FMA!) on an AMD chip without it giving you "invalid instruction". Apple is a good canary for what's to come. Their most recent stuff is overtaking Intel's Core M. It's not even a question that e.g. iPhone 8 will leave it in the dust. Servers can't be that far behind, since x86 is no longer competitive either per dollar or in performance per watt. Meanwhile there's an uptick of interest in beefy ARM cores as well, in HPC and elsewhere. For Google it would be very little effort to migrate parts of their backend to ARM: they've been requiring their software to be compileable on ARM and PPCle for years. And no one would even know what they use.
- iamnotlarry 9y ago
  Congratulations, cptskippy. You just predicted 2001. Intel and HP combined lost to amd64. This time around, Intel will have to take on more than just AMD. You think eschewing backwards compatibility will work better this time?
  - yuhong 9y ago
    It would not be the same as IA-64. My idea would be to ditch the segment registers and act if the segment base is always zero except FS and GS for example, with a new way to handle interrupts etc of course. As a side note, I am thinking that in such a proposal only up to SSE2 should be mandatory, as these are the Intel patents most likely to expire soon. We should also choose either SYSENTER or SYSCALL for 32-bit system calls and make it the same for all x86 vendors (I am thinking of assuming that all OSes are 64-bit and only running user mode programs in 32-bit).
    - geezerjay 9y ago
      If your feature wish list doesn't translate into relevant performance boosts, you're wishing for a whole new stack of problems and challenges that buy you nothing at all. The parent poster was right: you just predicted 2001. Intel and HP combined lost to amd64 because they'd bet on a redesign which failed to provide any meaningful gains. Backward compatibility is there to avoid problems, and nowadays it's highly unlikely that performance gains from new products will be more than marginal.
      - yuhong 9y ago
        IA-64 had plenty of other problems which did not help either. This proposal would make x86 more like a normal "RISC" processor instead without breaking user mode and hopefully not even driver compatibility. Main benefit would be to get rid of a lot of microcode for example.
        geezerjay 9y ago
        IA-64 had its own problems, but your proposal would have its own problems as well. Breaking backward compatibility is all about creating problems, and you failed to point out any gain as a trade-off for all that pain. Getting rid of microcode only causes problems for the potential clients and developers, and for what?
        9y ago

by 0xbear 9y ago

cptskippy 9y ago

I don't see your hope for AMD or your prediction about ARM happening. I think it's much more likely that Intel will continue to produce backward compatible x86 chips and start producing a variant that eschews backwards compatibility in favor of performance by dropping legacy x86 features either gradually or entirely.

0xbear 9y ago
I bet you also don't see the impending cloud price wars which will make the current cost structures unsustainable. And you also don't see that it is vital for cloud providers to avoid a single vendor situation with the most expensive line item in their capex. For the first time in a very long time, you can compile your software with "-march-native" on Skylake and then just run it (with AVX2 and FMA!) on an AMD chip without it giving you "invalid instruction". Apple is a good canary for what's to come. Their most recent stuff is overtaking Intel's Core M. It's not even a question that e.g. iPhone 8 will leave it in the dust. Servers can't be that far behind, since x86 is no longer competitive either per dollar or in performance per watt. Meanwhile there's an uptick of interest in beefy ARM cores as well, in HPC and elsewhere. For Google it would be very little effort to migrate parts of their backend to ARM: they've been requiring their software to be compileable on ARM and PPCle for years. And no one would even know what they use.
iamnotlarry 9y ago
Congratulations, cptskippy. You just predicted 2001. Intel and HP combined lost to amd64. This time around, Intel will have to take on more than just AMD. You think eschewing backwards compatibility will work better this time?
- yuhong 9y ago
  It would not be the same as IA-64. My idea would be to ditch the segment registers and act if the segment base is always zero except FS and GS for example, with a new way to handle interrupts etc of course. As a side note, I am thinking that in such a proposal only up to SSE2 should be mandatory, as these are the Intel patents most likely to expire soon. We should also choose either SYSENTER or SYSCALL for 32-bit system calls and make it the same for all x86 vendors (I am thinking of assuming that all OSes are 64-bit and only running user mode programs in 32-bit).
  - geezerjay 9y ago
    If your feature wish list doesn't translate into relevant performance boosts, you're wishing for a whole new stack of problems and challenges that buy you nothing at all. The parent poster was right: you just predicted 2001. Intel and HP combined lost to amd64 because they'd bet on a redesign which failed to provide any meaningful gains. Backward compatibility is there to avoid problems, and nowadays it's highly unlikely that performance gains from new products will be more than marginal.
    - yuhong 9y ago
      IA-64 had plenty of other problems which did not help either. This proposal would make x86 more like a normal "RISC" processor instead without breaking user mode and hopefully not even driver compatibility. Main benefit would be to get rid of a lot of microcode for example.
      - geezerjay 9y ago
        IA-64 had its own problems, but your proposal would have its own problems as well. Breaking backward compatibility is all about creating problems, and you failed to point out any gain as a trade-off for all that pain. Getting rid of microcode only causes problems for the potential clients and developers, and for what?
        9y ago