4 ms·

Warning: link auto-plays video with sound. Edit/addition: AVX-512 in Skylake is pretty exciting. 32 FLOPS per clock cycle per core is amazing. Also good to se

by vardump 12y ago

Warning: link auto-plays video with sound. Edit/addition: AVX-512 in Skylake is pretty exciting. 32 FLOPS per clock cycle per core is amazing. Also good to see 64 or 128 MB of eDRAM being included in more configurations. It should also somewhat help with algorithms with larger working sets, not just with graphics. Integration is also interesting, latency between GPU and CPU should be low. This may open chances for better integration and sharing of work between those units. 1 Gbps ethernet starts to be a limitation, it's barely enough for current internet connections in some parts of the world. Nearly any SSD can do sustained 5 Gbps, most new mechanical disks push 2 Gbps. It's time for 10GBASE-T to be a standard, with power saving option to function at lower speeds. Nowadays even low end hardware such as $80 Asus etc. wifi-router with USB 3.0 can push 500 Mbps+ at file serving.

bhouston 12y ago
It is hard to get mainstream usage of CPU extensions until they are on the large majority of chips because creating multiple code paths is a pain. Thus while AVX-512 is nice, I do not expect to see usage of it outside video codecs until at least 3 years from now, and it likely won't be widely used until 5-7 years from now. This problem is compounded by the slow upgrade cycles of PCs now that their performance doesn't drastically increase per generation.
- vardump 12y ago
  It's worse than that. It's still problematic to even assume SSE4.2, not to mention AVX2, which would help significantly. Virtualization is making the problem worse, because hypervisors set CPUID bits to lowest common denominator within a vMotion / teleportation domain. I think (specialized) JITting is the answer for that. Generate code on the fly. I've been lately playing around with JITted [de]serializers, etc. I think it might be possible to have an order of magnitude gains in JSON, XML, msgpack, etc. processing. Even *printf can be much, much faster. If the format specifier is static, first run just generates code just for that specifier. Subsequent invocations can be about 10-20x faster versus normal style format string scanner. Edit: When I say JIT, I'm not talking about JVM or any other mainstream implementation specifically, but the concept in general. Which means just-in-time generation of (optimal) machine specific code.
  - bhouston 12y ago
    I guess the other solution is to use OpenCL and write all kernels in that language. Then it should JIT into AVX-512 if it is available.
    - vardump 12y ago
      It might be acceptable for some subset of "embarrassingly parallel" problems. For other problems, writing OpenCL code that even approaches hardware potential is very hard. We might need other intermediary languages than it. Currently LLVM is a better fit than OpenCL in general. If you want the last 50% of performance, hand coding seems to be unfortunately the only way. Very little code needs to be that fast, though.
  - tormeh 12y ago
    JIT and AOT on-device is the future, I agree. How good are the JVMs at taking advantage of new instructions?
    - bhouston 12y ago
      My understanding is that JVMs do not generate any advanced instructions from standard Java code. The only time they use these instructions is if they link in hand coded C++ libraries that make use of them. Edit: Stackoverflow answer says that in rare cases the JVM can vectorize simple loops: http://stackoverflow.com/questions/10784951/do-any-jvms-jit-compilers-generate-code-that-uses-vectorized-floating-point-ins http://stackoverflow.com/questions/10784951/do-any-jvms-jit-...
      - vardump 12y ago
        Just take a look at the code they generate, it's easy. In short, they do generate SIMD code, but very rarely take advantage of vectorized execution.
        tormeh 12y ago
        Why aren't the processor manufacturers making their own JITs and AOT compilers? Surely that would be a competitive advantage.
- nly 12y ago
  > creating multiple code paths is a pain GCC added some cool functionality to make this a lot easier recently: https://gcc.gnu.org/wiki/FunctionMultiVersioning https://gcc.gnu.org/wiki/FunctionMultiVersioning
  - innocenat 12y ago
    No it isn't. You are still going to need to maintain multiple code path. Especially with SIMD instruction set like AVX-512 -- to be performant you need to do things with direct assembly anyway.
  - Keyframe 12y ago
    Seems nice, but isn't all that much different from checking support yourself and initializing function pointers to correct functions - more work, but portable.
cmsj 12y ago
+1 on the networking angle, although Intel does have Thunderbolt, which at least gets you 10Gb peer-to-peer networking if your hardware and OS support it. It does seem very weird that 10Gb copper networking has existed since 2006, but hasn't fallen down to prices so low that it naturally replaces gigE. It seems entirely possible at this point, that 802.11ax will be finished before 10GBASE-T becomes widespread outside of server applications.
- bhouston 12y ago
  I as well desire 10GBase-T that is affordable. It seems to be very slow coming. I think the issue is that while there is some business desire for this, the consumer only wants wireless -- thus that is where all the effort is going. Probably to get past 1GB in the next few years, one will deploy a wireless network (although wireless suffers horrible congestion as opposed to switched networks.)

by vardump 12y ago

bhouston 12y ago

It is hard to get mainstream usage of CPU extensions until they are on the large majority of chips because creating multiple code paths is a pain. Thus while AVX-512 is nice, I do not expect to see usage of it outside video codecs until at least 3 years from now, and it likely won't be widely used until 5-7 years from now. This problem is compounded by the slow upgrade cycles of PCs now that their performance doesn't drastically increase per generation.

vardump 12y ago
It's worse than that. It's still problematic to even assume SSE4.2, not to mention AVX2, which would help significantly. Virtualization is making the problem worse, because hypervisors set CPUID bits to lowest common denominator within a vMotion / teleportation domain. I think (specialized) JITting is the answer for that. Generate code on the fly. I've been lately playing around with JITted [de]serializers, etc. I think it might be possible to have an order of magnitude gains in JSON, XML, msgpack, etc. processing. Even *printf can be much, much faster. If the format specifier is static, first run just generates code just for that specifier. Subsequent invocations can be about 10-20x faster versus normal style format string scanner. Edit: When I say JIT, I'm not talking about JVM or any other mainstream implementation specifically, but the concept in general. Which means just-in-time generation of (optimal) machine specific code.
- bhouston 12y ago
  I guess the other solution is to use OpenCL and write all kernels in that language. Then it should JIT into AVX-512 if it is available.
  - vardump 12y ago
    It might be acceptable for some subset of "embarrassingly parallel" problems. For other problems, writing OpenCL code that even approaches hardware potential is very hard. We might need other intermediary languages than it. Currently LLVM is a better fit than OpenCL in general. If you want the last 50% of performance, hand coding seems to be unfortunately the only way. Very little code needs to be that fast, though.
- tormeh 12y ago
  JIT and AOT on-device is the future, I agree. How good are the JVMs at taking advantage of new instructions?
  - bhouston 12y ago
    My understanding is that JVMs do not generate any advanced instructions from standard Java code. The only time they use these instructions is if they link in hand coded C++ libraries that make use of them. Edit: Stackoverflow answer says that in rare cases the JVM can vectorize simple loops: http://stackoverflow.com/questions/10784951/do-any-jvms-jit-compilers-generate-code-that-uses-vectorized-floating-point-ins http://stackoverflow.com/questions/10784951/do-any-jvms-jit-...
    - vardump 12y ago
      Just take a look at the code they generate, it's easy. In short, they do generate SIMD code, but very rarely take advantage of vectorized execution.
      - tormeh 12y ago
        Why aren't the processor manufacturers making their own JITs and AOT compilers? Surely that would be a competitive advantage.
nly 12y ago
> creating multiple code paths is a pain GCC added some cool functionality to make this a lot easier recently: https://gcc.gnu.org/wiki/FunctionMultiVersioning https://gcc.gnu.org/wiki/FunctionMultiVersioning
- innocenat 12y ago
  No it isn't. You are still going to need to maintain multiple code path. Especially with SIMD instruction set like AVX-512 -- to be performant you need to do things with direct assembly anyway.
- Keyframe 12y ago
  Seems nice, but isn't all that much different from checking support yourself and initializing function pointers to correct functions - more work, but portable.

cmsj 12y ago

+1 on the networking angle, although Intel does have Thunderbolt, which at least gets you 10Gb peer-to-peer networking if your hardware and OS support it. It does seem very weird that 10Gb copper networking has existed since 2006, but hasn't fallen down to prices so low that it naturally replaces gigE. It seems entirely possible at this point, that 802.11ax will be finished before 10GBASE-T becomes widespread outside of server applications.

bhouston 12y ago
I as well desire 10GBase-T that is affordable. It seems to be very slow coming. I think the issue is that while there is some business desire for this, the consumer only wants wireless -- thus that is where all the effort is going. Probably to get past 1GB in the next few years, one will deploy a wireless network (although wireless suffers horrible congestion as opposed to switched networks.)