Live data from Hacker News

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

danluu.com

91–100 of 155 posts

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

#91

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…

Is there something about RISC that is still makes it better than CISC when it comes to per-watt performance? Seems like nobody has any success making an x86 processor that's as power efficient as ARM or RISC.

> Is there something about RISC that is still makes it better than CISC when it comes to per-watt performance?

CLASSIC CISC was micro-coded (for example, IBM S/360 have feature, you could make your custom microcode for compatibility with your inherited equipment, like IBM-1401 machines or IBM-7XXX series, or for other purposes), and RISC was with pipeline from birth.

Second thing, as I understand, many CISC existed as multiple chips board or even as multiple boards, so have great losses on wires, but RISC appear in 1990s as one die immediately (only external cache added as additional IC), but I could mistake on this.

> nobody has any success making an x86 processor that's as power efficient as ARM or RISC

Rumors said, Intel Atom (essentially CMOS version of Pentium first generations) was very good in mobiles, but ARM far succeed it on software support of huge number of power saving features (modern ARM SOC allows to turn off near any part of chip any time and OS support this), and because of lack of software support, smartphones with Intel have poor time on battery.

More or less official info said, that Intel made bad power conversion circuit, so Atom consumes too much in mode between deep sleep and full speed, but I don't believe them, as this is too obvious mistake for hardware developer.

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

#92
post #19

Earlier quoted context omitted.

I think the battle between RISC and CISC is overshadowed by the battle between non-x86 and x86. On average are new designs more RISC than CISC? I don't know but that's different from numbers of chips of a certain type sold. RISC showed what you could do with a clean sheet and the battle has really been about whether we can afford the cost of changing to a new instruction set just because it's better by a bit.

>> by the battle between non-x86 and x86. 68000 -> PowerPC -> x86 -> arm Apple has been through 4 architectures in 30 years. Given enough money and tyranny (as in "were doing this" kind of leadership, vs committee) its apparently not that terrible.

And rumors said, they even considered IBM RS-6000, but pushed to make simplified PowerPC, and IBM had not very good times, so agreed.

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

#93
post #77

Earlier quoted context omitted.

On the other hand, the banking infrastructure in many countries wouldn't work without COBOL, scientific research wouldn't work without MATLAB, and healthcare wouldn't work without MUMPS. Many languages and paradigms, good and bad, end up entrenched within an industry.

> COBOL > MATLAB > MUMPS One of each uglier than the one before. But: Is there something we can learn from these examples? Are there good reasons for these languages being adopted? And are the Racket designers with their approach of "a language to define interoperable DSLs" up to something?

I think programming languages are more like spoken languages than we give them credit for. Their design is more intentional, but the processes by which they spread, compete, and evolve is similarly difficult to pin down.

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

#94
post #2

The phone networks and basic infrastructure for the internet in many countries wouldn’t work without Erlang. Which is functional… but maybe that doesn’t count?

On the other hand, the banking infrastructure in many countries wouldn't work without COBOL, scientific research wouldn't work without MATLAB, and healthcare wouldn't work without MUMPS. Many languages and paradigms, good and bad, end up entrenched within an industry.

You forget FORTRAN (was very popular for scientific computing, and nearest neighbor with COBOL in S/360 environment) :)))

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

#95
post #87
post #86

Earlier quoted context omitted.

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.

Smaller transistors are faster, but the relationship between clock frequency and 1/feature size isn't necessarily linear like you're assuming.

https://cs.stackexchange.com/questions/27875/moores-law-and-...

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

#96
post #19

Earlier quoted context omitted.

I think the battle between RISC and CISC is overshadowed by the battle between non-x86 and x86. On average are new designs more RISC than CISC? I don't know but that's different from numbers of chips of a certain type sold. RISC showed what you could do with a clean sheet and the battle has really been about whether we can afford the cost of changing to a new instruction set just because it's better by a bit.

>> by the battle between non-x86 and x86. 68000 -> PowerPC -> x86 -> arm Apple has been through 4 architectures in 30 years. Given enough money and tyranny (as in "were doing this" kind of leadership, vs committee) its apparently not that terrible.

Add the transition to "32-bit clean" on 68K (and some trouble with caches) + 32-to-64-bit transitions on PPC and x86.

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

#97
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…

And the R2000 was implemented in 2µm and the (early) 386 was implemented in 1.5µm. Double-metal for both. Didn't bother to look up die size.

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

#98

Earlier quoted context omitted.

> Apple's M chips have made RISC is a clear yes now. ARM is not a pure RISC architecture (even though its instruction set is somewhat inspired by those ideas behind RISC that stood the test of time).

What counts as "pure RISC"?

Good question. Now things are complicated. When all beginning, CISC CPUs was not one chip but board or even cabinet (like IBM S/360), and they featured customizable microcode, so you could even load different microcode on different CPUs in system.

As I know, very powerful feature of S/360 series was to supply custom microcode to make machine compatible with older IBM hardware, like 1401 series or 7xxx series (or to make your own architecture if you wish and if you have enough money).

I have not hear about customizable microcode in RISC (to be honest, I hear, it exists in ARM, but it is rare used option, if compare with IBM 360).

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

#99
post #85

Earlier quoted context omitted.

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…

Addition was not the bottle neck for the 386. It had a FO4 delay of 80+ per clock. An adder is much faster.

Maybe you meant that it was (one, just one!, of many of) the bottle neck(s) in an optimized implementation?

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

#100
post #9

> Fancy type systems We are taking steps to this direction. By adding optional typing to dynamic languages Python and JavaScript/TypeScript. And then type checker tools and local programming style guides are making using these maybe less optional, and more mandatory.

Sum types have definitely been making a big splash. I'd also look at how C++ has added concepts and Go has added generics. Local type inference is also commonplace too, even Java has it.

Even C23 has it.
Post reply on HN