Live data from Hacker News

What's worked in Computer Science: 1999 vs. 2015 (2015)

danluu.com

81–90 of 155 posts

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#81
post #56
post #43

Earlier quoted context omitted.

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.

I code in C# and use a ton of LINQ when writing business logic. It's FP-ish enough to avoid logic mistakes. The mediator design pattern, which is kind of bringing another FP paradigm to the OO world, also features heavily.

C# LINQ, being a round-about implementation of do-notation, is a pretty advanced FP feature, and beyond most mainstream languages. C# is certainly a step up over Java etc.

However, most developers wouldn’t understand, say, a result monad implemented via LINQ, so you’re still fighting the ecosystem somewhat.

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#82

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.

Definitely agree that mainstream languages are adopting functional features, but records aren't a functional feature. Records are basic data modeling and something that has been around since the beginning of programming languages, whether procedural or functional. It's one of the bare minimums of having a type system, and Java didn't have this due to the misguided belief that "everything is an object". I think record…

Java records are object-oriented construct

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#83

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…

A 20,000 gate minimal RISC-V RV32E controller CPU isn't going to use μops. In 2024, RISC-V has turned that 2015 No into an unqualified Yes even if the microarchitecture of more complex OOO RISC-V systems resemble the microarchitectures of similarly complex x86 and ARM CPUs.

I have made a few of those RISC-V CPUs. The minute the "M" instruction set shows up (with division), a macro/micro-op split becomes worth it if you want to minimize gate count or maximize speed.

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#84
post #66
post #51

Earlier quoted context omitted.

I still have to agree with Dan. "If there's any threat to x86, it's ARM, and it's their business model that's a threat, not their ISA."

I would have believed this before the M1, but now I think fixed-width instructions are great for parallel decode, so there's a real threat now which is attributable to RISC.

Fixed-width decode only one of the ideas of "RISC," but not the main one. I would argue that modern ARM is almost as much of a CISC-y abomination as was x86 in 1999. ARM has a lot of instructions that do multiple things and are very non-RISC.

POWER is probably the most RISC-y architecture in use at the high end right now, but it still looks like CISC to the people who originally came up with that idea.

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#85
post #53

Earlier quoted context omitted.

You are not quite right about pipelined design being faster. At least, not without substantial effort. 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, origin…

Interesting. An R2000 did run programs faster than a 80386, right? This was a few years before my time. From a quick google now, it looks like the R2000 was about 3x better than the 80386 at Dhrystone MIPS/MHz. I guess an accurate comparison of how the R2000 and 80386 spent they gate budget and what they got in return would involve a lot of detail. I remember my compsci professor giving us the computer architecture c…

My point is that you cannot get design much faster in terms of clock frequency by just pipelining. Pipeline unrolls state machine and overlaps different executions of the state machines. But the bottleneck, which is addition, is there in all designs and you need additional effort to break it.

(also MIPS has [i]ntelocked [p]ipeline [s]tages - that "IPS" in MIPS; I implemented it, I know - exception in execution should inform other stages about failure)

By the 1997 Intel has already bought Elbrus II design team, lead by Pentkovski [1]. That Pentkovski guy made Elbrus 2 a superscalar CPU with a stack machine front-end. E.g., Elbrus 2 executed stack operations in a superscalar fashion. You can entertain yourself by figuring out how complex or simple can that be.

[1] https://en.wikipedia.org/wiki/Vladimir_Pentkovski

So at the time your professor complained about Intel's inferior architecture being faster, that inferior architecture implementation has a translation unit inside it to translate x86 opcodes into superscalar-ready uops.

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#86
post #53

Earlier quoted context omitted.

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…

You are not quite right about pipelined design being faster. At least, not without substantial effort. 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, origin…

It's not apples-to-apples to compare raw clock rates between semiconductor processes; Intel's 386 was intially fabbed on 1.5μ then shrunk to 1.0μ process (Intel CHMOS III and IV), whereas MIPS R2000 was 2.0μ, fabless and relied on Sierra, Toshiba, then in 1987 LSI, IDT and other licensees [0][1].

Back in the 1980s/90s/2000s, Intel was consistently a process generation or two ahead of competitors. That was one of their main sources of advantage.

Just imagine if MIPS had been able to fab on Intel process.

[0]: https://www.righto.com/2023/10/intel-386-die-versions.html

[1]: https://en.wikipedia.org/wiki/R2000_microprocessor

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#87
post #86
post #53

Earlier quoted context omitted.

You are not quite right about pipelined design being faster. At least, not without substantial effort. 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, origin…

It's not apples-to-apples to compare raw clock rates between semiconductor processes; Intel's 386 was intially fabbed on 1.5μ then shrunk to 1.0μ process (Intel CHMOS III and IV), whereas MIPS R2000 was 2.0μ, fabless and relied on Sierra, Toshiba, then in 1987 LSI, IDT and other licensees [0][1]. Back in the 1980s/90s/2000s, Intel was consistently a process generation or two ahead of competitors. That was one of thei…

And you are also confirm that in order to have higher clock frequency you need more than just pipelining.

Thank you.

I also think that 1.5x difference in clock speeds cannot be directly attributed to the difference between node size (lambda): difference in lambdas 1.3(3)=2.0/1.5 at the introduction of the 80386 and R2000 is noticeably less than 1.47=12.5/8.5.

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#88

Earlier quoted context omitted.

TS really stands out as amazing. It’s realized a lot of the promise of strong typing.

I agree that TypeScript is quite amazing. And that it's indeed improved the programs created that run in the browser or on `node`. However, I wanted to point out something that I think often gets overlooked when folks talk about TypeScript. I'd argue that TS has realized it for the web programming masses, who usually don't have any computer science education and thus are unaware of computing fundamentals such as type…

https://hypercubed.github.io/joy/joy.html

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#89
> That Intel ceded the low end of the market might seem ironic considering Intel's origins, but they've always been aggressive about moving upmarket

Will see. Intel after 2023 is not like before 2023, when it lost its dominance to AMD and partially to Nvidia and ARM (Apple-M2).

Now lowest end CPUs become RISC-V and ARM pushing to become one of leaders.

x86 is strong, but who knows, how long it could dominate under pressure.

And if we count not desktops but all personal devices, ARM is already won (on just smartphones, now more ARM CPUs than people on Earth, and Data Centers share of ARM CPUs growing).

Only one final thing I could copypaste from "X-files" - "truth is out of there".

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#90

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…

> RISC designs also taken some inspirations from CISC (such as having SIMD/vectorization units)

I think that one went the other way: for example the PlayStation 2 used a MIPS chip with 256-bit SIMD instructions (the TMPR 5900) as well as a dedicated GPU (the so-called “emotion engine”)

Post reply on HN