Live data from Hacker News

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

danluu.com

101–110 of 155 posts

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

#101
post #38

Earlier quoted context omitted.

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

How so? It looks a lot like a less-rich Java, whose type system has existed for literally decades. In fact, the generics syntax and type erasure was directly influenced by Java.

I haven’t used Java in many years, but TypeScript’s structural types give it a different flavor than I remember from Java. Unlike in Java, most of the types I define aren’t classes or interfaces. It’s just data that has an expected shape.

Check out the design of Zod, for example. I have a bunch of Zod types for the validation of incoming JSON messages. This automatically generates the corresponding TypeScript types through the magic of type inference.

It’s quite easy to create discriminated unions, which are just structs where one field has a fixed value.

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

#102
post #95
post #87

Earlier quoted context omitted.

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-...

My assumption is that speedup is less than lambda's ratio.

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

#103
post #85

Earlier quoted context omitted.

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?

> Addition was not the bottle neck for the 386.

It is a bottleneck for MIPS, SPARC, Alpha and not for 386. How so?

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

#104
post #103

Earlier quoted context omitted.

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?

> Addition was not the bottle neck for the 386. It is a bottleneck for MIPS, SPARC, Alpha and not for 386. How so?

The 386 wastes so many FO4 gate delays on other things. I thought I made that extremely clear?

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

#105
post #15

Do GPUs and TPUs for AI count towards parallelism?

I don't think so, they still tend to fall into the "Lampson further remarks that to do parallel programming, what you need to do is put all your parallelism into a little box and then have a wizard go write the code in that box." statment, for the most part.

[deleted]

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

#106

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…

> classical taxonomy of RISC/CISC dichotomy is basically non-existent nowadays

After digest information about IBM 360, I decided, we lost CISCs. One of most important feature of 360 was customizable microcode, which you could load on system boot and got effectively different hardware (like with FPGA emulators of Amiga's). It was widely used to emulate old hardware, like IBM 1401 or IBM 7xxx series. But I have not seen this feature in 390 documentation, so looks like their 360 emulation become just software (and with achievements of semiconductors in 1990s it looks like adequate, to switch to software emulation).

I must admit, ARM marketed feature of customized microcode, to add new instructions (they have standardized place in instruction set, named "custom coprocessor instructions", so if you have enough money, you could make special ARM with your additional instructions), but it is nothing if compare to 360.

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

#107
post #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 pr…

After digest information about IBM 360, I decided, we lost CISCs. One of most important feature of 360 was customizable microcode, which you could load on system boot and got effectively different hardware (like with FPGA emulators of Amiga's). It was widely used to emulate old hardware, like IBM 1401 or IBM 7xxx series. But I have not seen this feature in 390 documentation, so looks like their 360 emulation become just software (and with achievements of semiconductors in 1990s it looks like adequate, to switch to software emulation).

This was not only feature of 360th, for example Xerox Alto, also have documented feature to alter microcode when need (as I hear, they have special framework to work with it, just like we now work with Assembler when need), and I hear rumors that something similar was shipped with DEC mini-computers, but for micro-computers, this feature practically disappeared.

Even when we have "microcode update" feature in many modern CPUs, but it is usually undocumented feature, to which nobody have access outside CPU manufacturers (only could upload encrypted binary, supplied by manufacturer to fix bugs). As I said, in 360th, this was documented standard feature, you could use if need.

I must admit, ARM marketed feature of customized microcode, to add new instructions (they have standardized place in instruction set, named "custom coprocessor instructions", so if you have enough money, you could make special ARM with your additional instructions, you could even order some additions on die), but it is nothing if compare to 360.

And I could tell from FPGA cooking, not all things implemented in FPGAs as hardware logic pipelines. When speed accepting, many people using in FPGA practically microcode engines (very common thing is 1-bit CPU, which is very similar to CISC microcode engine, and programmed in Assembler, very similar to early 8-bits; some people prefer full-featured CPU, like 8048 or even more).

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

#109
post #61

Earlier quoted context omitted.

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).

The moment you have any database or filesystem or remote-service, the hybridization starts anyway. Sure, technically a single computer's local RAM is being managed with strict guidelines, but that correlates less and less to overall application state and behavior these days.

True, but you can isolate side effects.

Knowing that a small collection of functions is not referentially transparent is better than having to deal with any part of the program potentially changing your state.

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

#110
post #68
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.

Those would be considered basic type systems. For "fancy", you gotta dive deeper into the lambda cube (tho generics I guess in 1999 would be fancy and one step in).

The borrow-checker is pretty fancy.
Post reply on HN