9 ms·

Just as expected. Turning back to nineties, it's easy to see that almost all ventures into specialty hardware ended up with mainstream consumer CPUs catching u

• gpderetta 6y ago
  AKA the Wheel of Reincarnation. I do think that GPUs are here to stay for a long time though.
  • mcosta 6y ago
    Yes, but how much until integrated beats separate card in $/performance? Once I bought a separate i387 chip for floating point. Later it was inside the main CPU.
    • gameswithgo 6y ago
      Lots of jobs where a GPU is a factor of 1000x faster so...
    • wongarsu 6y ago
      Both CPU and GPU are in large part limited by power delivery and heat. Putting them both in one chip tends to make both of them worse. I wouldn't count on that reversing any time soon. It is however curious how CPU and GPU become more similar over time, with CPUs getting ever wider SIMD instructions and GPUs becoming better over time with branching code, integer performance, etc.
      • gpderetta 6y ago
        There is some convergence, but CPUs are still latency optimized and GPUs are throughput optimized which makes for vastly different architectures.
      • rbanffy 6y ago
        > Putting them both in one chip tends to make both of them worse. You don’t need to do that for them to share a single memory address space. Putting them together would be useful if sharing caches between them made sense, but it doesn’t.
    • Dylan16807 6y ago
      They integrated it, but you were still buying it. You just saved a couple dollars on packaging. Similarly, an integrated GPU has a meaningful price advantage at low enough price tiers. But GPU price and power budgets have been pretty steady for a long time, so I wouldn't expect a major shift any time soon.
    • monocasa 6y ago
      Interestingly the later separate i487 chip was in fact a full 486 CPU and 487 FPU on one die, and disabled the 486 CPU in the main CPU socket. Integration really means something, even when the product SKUs aren't there yet.
• zelon88 6y ago
  Yup. Controversial opinion incoming, but I actually can't wait for the same thing to happen to ARM. The RISC crowd so quickly forgot the purpose of the RISC architecture. Every time I hear someone tell me how the M1 is so fast compared to x86 I just get this picture in my head of a guy in a 1992 Civic DX with a 2 foot wing revving his engine at the Lambo parked next to him. [1] [1] https://wccftech.com/why-apple-m1-single-core-comparisons-are-fundamentally-flawed-with-benchmarks/ https://wccftech.com/why-apple-m1-single-core-comparisons-ar...
  • deleted 6y ago
    [deleted]
  • mhh__ 6y ago
    I think you're wrong but I upvoted because the article does raise a valid point.
  • JohnJamesRambo 6y ago
    Lol what? Can you explain this view more fully? If anything the x86 currently has the two foot spoiler on it.
    • zelon88 6y ago
      Sure! I'll keep digging. >D RISC = Reduced Instruction Set Computer. Reduced instructions result in (supposedly) reduced complexity per instruction (which has failed over time). While each instruction is "simpler" it takes more instructions to accomplish a task. It would stand to reason that it would take more clock cycles to accomplish the same goal on ARM than x86. [1] ARM processors regularly outperform x86 in terms of instructions per cycle. They have to in order to do the same amount of work. That is literally the whole idea of RISC. Simpler instructions executed quickly. [2] But this is not why they are fundamentally not as capable. The reason for that is the pipeline. Or relative lack of pipe-lining. [3] But again, you are comparing a Civic to a Lambo. You have a 3.5w CPU which, per watt, you have the more efficient processor. But that's not good enough. ARM folks love to stand on the efficiency soapbox and preach about performance. You want to have the flexibility of out-of-order execution but don't want to admit the shortcomings that come with it. You have the best performance per watt but you want best overall performance. Which, if you skew every metric in favor of sliced up processors and non-real world benchmarks then sure... Your phone is almost as fast as an entry level laptop when running native code on a single core. If x86 appears slower than ARM it's only because ARM fans have thrown everything but the kitchen sink into their test bench and found the absolute most favorable conditions possible. Anything but admit that their $1200 cell (which was never designed to be faster than your laptop) is "faster per watt per core per thread" than a $150 x86 processor. [1] https://www.androidauthority.com/arm-vs-x86-key-differences-explained-568718/ https://www.androidauthority.com/arm-vs-x86-key-differences-... [2] https://www.extremetech.com/computing/318020-flaw-current-measurements-x86-versus-apple-m1-performance https://www.extremetech.com/computing/318020-flaw-current-me... [3] http://www.csbio.unc.edu/mcmillan/Comp411F17/Lecture26.pdf http://www.csbio.unc.edu/mcmillan/Comp411F17/Lecture26.pdf
• gumby 6y ago
  > Turning back to nineties And 80s (consider Britton-Lee). And the opposite too: "mainframes are too complicated; we'll write an OS that does all IO in the kernel (e.g. Unix) and run it on minis that don't have channel controllers". Come the 2000s and every disk drive and even keyboard has a processor it it. And edge-vs-core computing in the network... The best part is hardly anyone reads the literature much less history, so if you've lived through a couple of cycles you can see the pendulum starting to swing back and, to mix metaphors, "skate to where the puck will be"
  • Ericson2314 6y ago
    Amen to that. I do welcome the return of "spread out" computing. I agree ease of use is important, but putting everything the CPU microcomputer style makes for a very imperative notion of ease of. Ergonomics without that would be much more elegant.
    • 01100011 6y ago
      Random thought: computing may very well be spread out one day if computational machinery is cheap to build but limited by heat. I could see computers becoming much, much larger, but with a smaller duty cycle for a particular compute element to assist with thermal management. Imagine building structures, like tables, walls, or skyscrapers, out of nothing but doped silicon.
• SatvikBeri 6y ago
  It's interesting because in some ways, GPUs are much less specialized than CPUs – GPGPU programming mostly involves treating the GPU like a huge, dumb collection of very simple processors. I expect effects in the opposite direction as well, i.e. that programming languages get better at using GPUs to do a wider set of workloads. For example, I was recently able to prototype an ETL pipeline with no machine learning or matrix multiplication to a GPU and get a ~10x price/performance improvement, which would have been a lot harder even 5 years ago.
  • lumost 6y ago
    In practice it's pretty tough to make this work. If your ETL can't be turned into just math on a <12GB dataset then you will be contending with streaming data from io -> CPU -> GPU -> CPU efficiently. CPU's are really good at multi-threaded io given an evented runtime these days, but GPUs can only do 1 thing at a time. This means that your application will need to batch data to the GPU. So the real race is between how good you can be at batching vs. parallel dispatch when reading disk from I/O. As parallel dispatch is a more general problem it tends to get more attention.
    • vlovich123 6y ago
      Or avoid shuttling the data back and forth and go with a unified architecture like the M1. Memcpy is terrible and yet we keep trying to build bigger and better pipes to make it faster with diminishing returns.
      • lumost 6y ago
        I strongly suspect that this is Nvidia's next big move. A giant CPU/GPU hybrid with unified memory. Who doesn't want threadripper scale Nvidia/ARM cores?
        • tremon 6y ago
          Yes, unified memory being the key here. FAFAIK GPUs still use a hub-and-spoke model, where all processing is done in the hub but data is stored on the rim. They achieve their speedup by increasing the number of spokes (data channels). You could do better by moving the data processing to the spokes as well, and using the hub only for orchestration and synchronization. At least, it's computationally better. But it won't allow scaling the processing power and memory size independently, so it might require a different commercial model.
• jmartrican 6y ago
  Genuine question here.... why are GPU's still used for graphics in video games? Is this one use case where the CPU will never catch up or has yet to?
  • SatvikBeri 6y ago
    Oversimplifying a bit, CPUs are smart and can do a lot of different things, and a lot of their chip area is devoted to that intelligence. GPUs are "dumb" but their chip area is heavily devoted to absolutely enormous throughput on really big batches. Looking at AWS prices right now, I can pay ~4/hour for 50 4gHz CPU cores or 5,000 1.75 gHz GPU cores. That means the best case scenario for GPUs is ~2,000 times faster. In practice, you'll rarely achieve that, but GPUs can be tremendously faster for extremely parallelizable tasks (which graphics are.)
    • nwah1 6y ago
      True. Of course the need for all that parallel processing can sometimes be replaced with intelligence, such as the new video codecs that leverage machine learning. Maybe CPUs will be better for video if those codecs start to dominate.
    • mewse 6y ago
      Yes.. if you're doing something that is just doing the same calculation on a whole lot of different inputs, then GPUs absolutely eat that for breakfast. In my game, I have a complex procedural generation process that occurs while loading a game. It's not a graphics process, so I originally did it on the CPU. It originally took about three seconds to build the data in parallel across seven background CPU threads on my quad-core processor. But testers who were using low-end dual-core i5s only had one background thread to do that same calculation, and typically reported that the procgen took multiple minutes to complete. After spending a week refactoring the algorithm to do the same calculation on the GPU instead of the CPU (basically by pretending it was a rendering calculation and writing results out into a "texture" that we could read the results from), calculation times dropped from seconds or even minutes to just fractions of a millisecond, even on low-spec machines. The calculation that I previously had to hide behind a loading screen was now quick enough that I could freely do it at runtime without even causing a blip to the frame rate. If you've got a problem that they can handle, GPUs are kind of astonishingly fast; even the (by modern standards) low-end ones.
• IvanAchlaqullah 6y ago
  Reading comments in this thread, it feels like people still can't believe that in some case neural networks can be faster on CPU instead of GPU. In fact, there is already real world use for neural networks that only optimized for CPU: an chess engine. More specifically, chess engine that use NNUE (Efficiently Updated Neural Networks) [1] like Stockfish 12 [2]. It run much faster while consuming less watts compared to GPU, can be run on average CPU, and managed to beat GPU based neural networks! [3] This model (NNUE) already exist far earlier than the model discussed in this thread, yet there is almost no discussion about it on HN nor Reddit's r/MachineLearning [1] https://www.chessprogramming.org/NNUE https://www.chessprogramming.org/NNUE [2] https://www.chessprogramming.org/Stockfish_NNUE https://www.chessprogramming.org/Stockfish_NNUE [3] https://www.chess.com/blog/the_real_greco/evolution-of-a-chess-fish-what-is-nnue-anyway https://www.chess.com/blog/the_real_greco/evolution-of-a-che...
  • ummonk 6y ago
    Was the NNUE trained on the CPU though? It’s intuitive that with the small size of a chessboard and the ability to use incremental update of evaluations, it will be faster to do neural network evaluation on CPU. Training, on the other hand, is typically highly parallelizable, so it would be a big development if we are able to do it faster on CPU.
    • Cybiote 6y ago
      It looks like training is on CPU too: https://github.com/nodchip/Stockfish/blob/master/src/nnue/evaluate_nnue_learner.cpp https://github.com/nodchip/Stockfish/blob/master/src/nnue/ev....
  • nl 6y ago
    NNUE is weird. No one outside the chess/shogi community talks about it because they seem to have a very case of strong not-invented-here syndrome. It's hand-optimised CPU code that doesn't (yet) run on the GPU (which is why it is "faster"). To be fair, they do want to embed it into a consumer friendly application, and the integration for embedding TF or something that can run pytorch models on a GPU without python is non-trivial. If someone ported it to a GPU, it almost certainly would be faster. See http://www.talkchess.com/forum3/viewtopic.php?f=7&t=76986 http://www.talkchess.com/forum3/viewtopic.php?f=7&t=76986 There is a PyTorch port available, but no benchmarks unfortunatly. It does seem to be fairly widely used for training though, which is indicative of the speed gains available.
• crazygringo 6y ago
  > almost all ventures into specialty hardware ended up with mainstream consumer CPUs catching up All except for... 3D rendering, image compositing, video encoding, and video decoding? I'm really struggling to see what you're trying to argue, because we do have multiple meaningful brute-force tasks that most computers today ship with dedicated silicon for. Yes we can do more real-time audio processing I guess, but that's mainly because CPU speeds increased, not because "people learned how things really worked", or am I missing something?
  • aidenn0 6y ago
    Don't forget encryption
• rasz 6y ago
  >Multi-channel audio, and sound effects on CPUs We only got here because Microsoft was afraid of one vendor, Creative, monopolizing positional audio market. This led to killing off audio hardware acceleration in Vista and leveling the playing field.
• _0ffh 6y ago
  Only it's not purely specialty hardware in this case. It's a massively parallel computation subsystem that happens to be also able to generate a video signal. This really makes sense in a way. I once read in a paper that the best thing to have when faced with the task of performing an arbitrary calculation with maximal speed is 1) one core that's a fast as possible (for stuff that must be calculated sequentially) and 2) as many as possible slower cores (for stuff that can be calculated in parallel).
• kolinko 6y ago
  CPUs didn’t swallow GPUs though.
• stjohnswarts 6y ago
  That's not how this works. Dedicated hardware for video games won't be on a general GPU anytimes soon. Neither will those problems that FPGA is solving when the matrices and properties of the calculation are massively parallel and static (or pseudo static require little change). Same with lidar processing or numerous other end uses. Dedicated hardware (in the form of FPGA's and ASICS) is everywhere.