51–60 of 155 posts
Fascinating about how ARM has made tremendous strides in the “high end” market since 2015. I would argue that I would categorize RISC as a “yes” with its absolute dominance on mobile and now moving into data center not to mention all the embedded use cases.
Do GPUs and TPUs for AI count towards parallelism?
I would like to suggest that the classical taxonomy of RISC/CISC dichotomy is basically non-existent nowadays -- namely because both sides have influenced each other. It is well known that CISC has taken a lot of inspirations from RISC designs (such as having a lot more registers in x64), and RISC designs also taken some inspirations from CISC (such as having SIMD/vectorization units). In other words, the line betwee…
Yep. RISC was interesting when gate budgets for CPU pipelines were seriously limited. It was interesting because before RISC the industry had been merrily spending the gate budget increase on adding lots of use-specific instructions. The RISC people pointed out that if you removed support for all the fancy instructions you had enough gate budget for the ALU to be nicely pipelined, and then you could wind up the clock…
https://en.wikipedia.org/wiki/R2000_microprocessor
"The R2000 is a 32-bit microprocessor chip set developed by MIPS Computer Systems that implemented the MIPS I instruction set architecture (ISA)..."
"The R2000 was available in 8.3, 12.5 and 15 MHz grades..."
https://en.wikipedia.org/wiki/I386
"The Intel 386, originally released as 80386 and later renamed i386, is a 32-bit microprocessor introduced in 1985..."
"Max. CPU clock rate: 12.5 MHz to 40 MHz"
As you can see, 80386 was released a year earlier than R2000 and was about 1.5 times faster than MIPS implementation from the start.
The critical path is, usually, in addition/subtraction, which should be complete in one cycle in both 80386 and in R2000. To pipeline addition you need a superpipelined CPU, one that has several stages for computation. Even seemingly simple computation of condition codes can make clock cycle 10% longer (SPARC vs MIPS) if your CPU is just simply pipelined.
BTW, some Pentiums did computed 32-bit addition in two cycles, all in name of higher clock frequencies.
I'd say that " pure Functional programming" has become a no. But "Functional programming approach" has been subsumed into existing programming languages, e.g. records in Java. You get most of the benefit of FP while keeping all of the other good stuf from an imperative language.
Neural networks: 1999 - No 2015 - Not really 2024 - Yes?
I'd say 2005 to 2010 is probably more probably more appropriate for not really. By 2015, neural networks were already a really hot research topic. Just off the top of my head, the seq2seq paper was published in 2014 and U-Net and ResNet were published in 2015.
The resurgence you're noting are papers with a 10 year tail before them (hell, most of the deep concepts were initiated decades before but lacked both the data sources and efficient hardware to really work them out).
This stuff has a long and deeply connected history.
I'd say that " pure Functional programming" has become a no. But "Functional programming approach" has been subsumed into existing programming languages, e.g. records in Java. You get most of the benefit of FP while keeping all of the other good stuf from an imperative language.
What mainstream languages have a good suite of FP features though? If you try to write mostly pure code in Java I’m afraid you’re in for a bad time, despite the (big!) improvements of records and lambdas. Minimum viable FP starts at OCaml, F#, Scala and Closure, yet none of these are mainstream.
Yes Maybe Firefox Reader Mode CSS
The days of square monitors and wall-to-wall text have been over for a while.
Fascinating about how ARM has made tremendous strides in the “high end” market since 2015. I would argue that I would categorize RISC as a “yes” with its absolute dominance on mobile and now moving into data center not to mention all the embedded use cases.
At the moment, x86 is mainly hanging on in legacy spaces because of backward compatibility. Everything new is RISC including Apple's newer Macs. Windows computers still run on x86 because people buy Windows to run legacy code. Playstation and Xbox run on x86 because that makes porting games from Windows more convenient. My view, even when I was studying RISC V in grad school around 6 years ago, was that RISC is clear…
x86 platforms also tend to let you run your own code, and are associated with 'proper computers/proper operating systems' where you have full access to your own device.
The vast majority of non-x86 devices are of the 'locked down and dumbed-down' variety. Content consumption devices built around monopolistic App Stores and touch-centric UIs. They tend to be entirely non-upgradable and, increasingly, actively repair-resistant, too.
The market for a 'real computer' may be shrinking, but it's premature to call them 'legacy devices'.
(It'd be nice if serious ARM-based PCs became more of an option though, not just little devices like the Pi, or glued-in-battery Apple products, but fully-upgradeable replacements for a high-end x86 workstation or gaming PC)
I would like to suggest that the classical taxonomy of RISC/CISC dichotomy is basically non-existent nowadays -- namely because both sides have influenced each other. It is well known that CISC has taken a lot of inspirations from RISC designs (such as having a lot more registers in x64), and RISC designs also taken some inspirations from CISC (such as having SIMD/vectorization units). In other words, the line betwee…
Yep. RISC was interesting when gate budgets for CPU pipelines were seriously limited. It was interesting because before RISC the industry had been merrily spending the gate budget increase on adding lots of use-specific instructions. The RISC people pointed out that if you removed support for all the fancy instructions you had enough gate budget for the ALU to be nicely pipelined, and then you could wind up the clock…
I'd say that " pure Functional programming" has become a no. But "Functional programming approach" has been subsumed into existing programming languages, e.g. records in Java. You get most of the benefit of FP while keeping all of the other good stuf from an imperative language.
Hybrid languages are sub-optimal in a lot of ways. One of the joys of functional programming are the guarantees that imperative languages can't offer (primarily immutability).