6 ms·

I am excited to see if this evolutionary bottleneck will take us beyond the von neumann architecture. The article implies we will get even more specialized har

I am excited to see if this evolutionary bottleneck will take us beyond the von neumann architecture. The article implies we will get even more specialized hardware that will speed up common categories of algorithms like gpus asics and FPGAs have been used. I wonder what kinds of performance gains could be had from a merge sort asic for example. I think the real interesting thing will be if new architectures beyond von neumann will allow us to think outside the box and break out into new algorithmic territory that is not obvious from our current perspective. It's very hard for us to throw away our toolchain towers of Babel but I think the departure has already begun when you look at bitcoin mining and gpgpu programming.

creshal 11y ago
> The article implies we will get even more specialized hardware that will speed up common categories of algorithms like gpus asics and FPGAs have been used. Which is actually bad, because it entrenches existing solutions and makes it harder to switch to new, better algorithms. Just look at cryptography: Now that AES is hardware accelerated in desktop CPUs, ChaCha has been bumped down to "that one algorithm for mobile users with shitty CPUs" with little to no chance of gaining significant traction on other markets until Intel decides to add hardware acceleration for it, too.
- gnarbarian 11y ago
  Sure but OpenGL/OpenCL is a good counter example. We have an open standard tailored to a specialized style of architecture that is supported across vendors, competitive with closed/proprietary alternatives and beats the hell out of anything we could run on a CPU.
  - creshal 11y ago
    OpenGL, really? The graphics API that is to terribly unsuited to modern hardware that it spawned several replacement APIs (Apple Metal, Khronos Vulkan, DirectX 12, …) and that has been more in the way of than helping programmers for at least a decade before? OpenGL is the perfect caution tale on what not to do when trying to make a hardware acceleration API.
    - gnarbarian 11y ago
      Vulkan is next. Opengl dominated for quite a while. 10 years? after it beat glide. The hardware has changed enough to warrant a new standard which is where the gpgpu language explosion is coming from.
      - douche 11y ago
        OpenGL dominated? Not anywhere where people had better alternatives. Windows/XBox had DirectX, other console makers had their own proprietary libraries.
        Chyzwar 11y ago
        What do you think is used on mobile.
        creshal 11y ago
        DirectX on Windows Phone, Metal on iOS; and mobile GPU vendors are one of the driving forces behind Vulkan, as OpenGL (ES) is just too shitty to keep using.
    - pjc50 11y ago
      I think this has been unfairly downvoted. It doesn't match accelerator hardware well, it's something of a historic path dependency because it was the only open API, and the one used by 3DFX for their "miniGL" drivers.
- hacknat 11y ago
  The vast majority of mainstream AES implementations don't take advantage of the hardware (yet).
nostrademons 11y ago
I think it's more likely that software development practices will change to recover a lot of the speed that's been lost. Not dramatically - certainly not a new architecture - but in lots of little ways. There's a lot of low-hanging performance fruit in programming language design, compiler implementation, technology choice, and application design. For the most part, nobody takes it because it doesn't make economic sense. With Moore's Law, just wait a couple years and your shitty implementation is good enough. It's possible for a skilled engineer to write code that is much more efficient. You have to compromise in other ways, like developer time or feature set. Up till now, those compromises have not been worth it, because somebody will beat you to market and make you irrelevant. In a world where "fast as an initial prototype" is not "fast enough", however, you could see firms actually start to compete on performance. I predict that even without hardware changes, we'll see a bit of a maturation of the software industry, where people look at what folks actually do with their computers and then work to make that actually perform well. Possibly not for a few years, though.
- noir_lord 11y ago
  > There's a lot of low-hanging performance fruit in programming language design. Indeed but there is also huge scope for applying known techniques to existing languages, PHP7 for example is twice as fast as 5.6 (in the real world, I've seen this) with about half the memory usage. The interesting thing is that anyone using PHP who goes to 7 gets that performance upgrade at essentially zero-cost.
  - tempodox 11y ago
    That surely looks like a no-brainer for PHP users. I know folks who have hard-coded dependencies on PHP 5.3(!) you wouldn't dare to have nightmares about.
    - noir_lord 11y ago
      Indeed, if you have a modern codebase on 5.6 then moving to 7 is very straightforward. In anything I'd written in the last 2 years I didn't have to change any code at all, just upgrade, run unit tests, do some sanity checks and deploy. Performance increases was immediately noticeable on both response times and server loads. One of the easiest wins I've ever had :).

creshal 11y ago

> The article implies we will get even more specialized hardware that will speed up common categories of algorithms like gpus asics and FPGAs have been used. Which is actually bad, because it entrenches existing solutions and makes it harder to switch to new, better algorithms. Just look at cryptography: Now that AES is hardware accelerated in desktop CPUs, ChaCha has been bumped down to "that one algorithm for mobile users with shitty CPUs" with little to no chance of gaining significant traction on other markets until Intel decides to add hardware acceleration for it, too.

gnarbarian 11y ago
Sure but OpenGL/OpenCL is a good counter example. We have an open standard tailored to a specialized style of architecture that is supported across vendors, competitive with closed/proprietary alternatives and beats the hell out of anything we could run on a CPU.
- creshal 11y ago
  OpenGL, really? The graphics API that is to terribly unsuited to modern hardware that it spawned several replacement APIs (Apple Metal, Khronos Vulkan, DirectX 12, …) and that has been more in the way of than helping programmers for at least a decade before? OpenGL is the perfect caution tale on what not to do when trying to make a hardware acceleration API.
  - gnarbarian 11y ago
    Vulkan is next. Opengl dominated for quite a while. 10 years? after it beat glide. The hardware has changed enough to warrant a new standard which is where the gpgpu language explosion is coming from.
    - douche 11y ago
      OpenGL dominated? Not anywhere where people had better alternatives. Windows/XBox had DirectX, other console makers had their own proprietary libraries.
      - Chyzwar 11y ago
        What do you think is used on mobile.
        creshal 11y ago
        DirectX on Windows Phone, Metal on iOS; and mobile GPU vendors are one of the driving forces behind Vulkan, as OpenGL (ES) is just too shitty to keep using.
  - pjc50 11y ago
    I think this has been unfairly downvoted. It doesn't match accelerator hardware well, it's something of a historic path dependency because it was the only open API, and the one used by 3DFX for their "miniGL" drivers.
hacknat 11y ago
The vast majority of mainstream AES implementations don't take advantage of the hardware (yet).

nostrademons 11y ago

I think it's more likely that software development practices will change to recover a lot of the speed that's been lost. Not dramatically - certainly not a new architecture - but in lots of little ways. There's a lot of low-hanging performance fruit in programming language design, compiler implementation, technology choice, and application design. For the most part, nobody takes it because it doesn't make economic sense. With Moore's Law, just wait a couple years and your shitty implementation is good enough. It's possible for a skilled engineer to write code that is much more efficient. You have to compromise in other ways, like developer time or feature set. Up till now, those compromises have not been worth it, because somebody will beat you to market and make you irrelevant. In a world where "fast as an initial prototype" is not "fast enough", however, you could see firms actually start to compete on performance. I predict that even without hardware changes, we'll see a bit of a maturation of the software industry, where people look at what folks actually do with their computers and then work to make that actually perform well. Possibly not for a few years, though.

noir_lord 11y ago
> There's a lot of low-hanging performance fruit in programming language design. Indeed but there is also huge scope for applying known techniques to existing languages, PHP7 for example is twice as fast as 5.6 (in the real world, I've seen this) with about half the memory usage. The interesting thing is that anyone using PHP who goes to 7 gets that performance upgrade at essentially zero-cost.
- tempodox 11y ago
  That surely looks like a no-brainer for PHP users. I know folks who have hard-coded dependencies on PHP 5.3(!) you wouldn't dare to have nightmares about.
  - noir_lord 11y ago
    Indeed, if you have a modern codebase on 5.6 then moving to 7 is very straightforward. In anything I'd written in the last 2 years I didn't have to change any code at all, just upgrade, run unit tests, do some sanity checks and deploy. Performance increases was immediately noticeable on both response times and server loads. One of the easiest wins I've ever had :).