Live data from Hacker News

David Patterson Says It’s Time for New Computer Architectures and Languages

spectrum.ieee.org

151–160 of 204 posts

Re: David Patterson Says It’s Time for New Computer Architectures and Languages

#151

Earlier quoted context omitted.

People still have to throw their computers out because other hardware still advances, software also advances, and companies decide not to support older hardware in their new software. The wastefulness really doesn't end.

They don't have to throw them out as often, though.

ionno... did people actually throw out their computers more often before? I'm honestly skeptical that people threw out their computers every 18 months just because their friend had a faster computer as was claimed here. I feel like people are very quick to buy new computers now. And not just that, but now we're having this problem with phones too.

Re: David Patterson Says It’s Time for New Computer Architectures and Languages

#152
post #2

It's really hard. Remember the Itanium and the Cell. You can build it, but they may not come. GPUs, though. Those have turned out to be very successful, they can be parallelized as much as you're willing to pay for, and they're good for some non-graphics tasks. Much of machine learning is a simple repetitive computation running at low precision. Special purpose hardware can do that very well. So what's the next usefu…

The Cell was way ahead of its time. Its security architecture capabilities was almost perfect, but they've screwed up the implementation and they failed to provide good programming tools. And, it was very very expensive.

Re: David Patterson Says It’s Time for New Computer Architectures and Languages

#153

I want a language where you can express time and constraints on time within the language and the type system. I want to be able to guarantee program correctness, pre-calculate fine-grained energy usage, optimize for energy/power-saving mode usage, interface with asynchronous signals, and whatnot -- all with respect to program execution at the ISA-level within some hard real-time constraints. Compilers make optimizati…

This is already possible to a degree within existing type systems - here’s a small experiment tracking execution time of list comprehensions on the type level in Purescript [0].

[0] https://twitter.com/pkamenarsky/status/961666713900249088?s=...

Re: David Patterson Says It’s Time for New Computer Architectures and Languages

#154
post #143
post #2

It's really hard. Remember the Itanium and the Cell. You can build it, but they may not come. GPUs, though. Those have turned out to be very successful, they can be parallelized as much as you're willing to pay for, and they're good for some non-graphics tasks. Much of machine learning is a simple repetitive computation running at low precision. Special purpose hardware can do that very well. So what's the next usefu…

Itanium only failed because Intel had agreements in place that allowed AMD to build x86 compatible CPUs, and they were clever to come up with AMD64. If it wasn't for that AMD stunt we would all be using Itaniums by now.

In other words, Itanium only failed because there was competition.

Re: David Patterson Says It’s Time for New Computer Architectures and Languages

#155
post #14

Earlier quoted context omitted.

Representing memory hierarchy in a somewhat-HLL was the goal of the programming language Sequoia, presented in the paper 'Sequoia: Programming the Memory Hierarchy' [1][2] from Stanford University. Abstract: "We present Sequoia, a programming language designed to facilitate the development of memory hierarchy aware parallel programs that remain portable across modern machines featuring different memory hierarchy conf…

(Disclaimer: I work on Legion) Sequoia has been largely superseded by its spiritual successor Legion [1], another programming system by Alex Aiken. Legion doesn't focus so much on low-level memory hierarchies, but it does a very, very good job of scaling to very large machines, and taking advantage of heterogeneous processors such as GPUs. It is also incomparably better at working with dynamic programs, whereas Sequo…

How does Legion differ from languages like Halide which separate scheduling from the algorithm?

How much of this could get handled by PGO (profile guided optimization) to observe locality and access patterns?

Do you think AI has a place in directing scheduling given enough semantic information so that "bad hypothesis" can get pruned?

Does it rely on a static description of machine (latencies and bandwidth) or does it evolve over time? Can it handle things that are dynamic but are thought of as static like memory bandwidth in a cloud environment?

How does Legion compare to cache oblivious techniques?

Are there changes at the processor level that could fuse operations given the existence of data in the cache, much like hyperthreading can do a context switch on a cache miss.

Do we need to modify what constitutes a Basic Block? Is modern hardware too low level?

Have you read the "Collapsing Towers of Interpreters" paper and do you think it applies to your work?

Re: David Patterson Says It’s Time for New Computer Architectures and Languages

#156
post #3

What's happening with that Mill Arch? Is it moving forward outside of them publishing papers? It seemed promising.

I believe end of next month there will be another Talk where the Mill designers will talk about Spectre and Meltdown attacks in relation to Mill (though the spoiler would be that the talk mentions the point "and why Mill is immune" so I guess it'll be a very fun talk).

I do hope a lot that Mill will succeed, it's an incredibly promising architecture.

Re: David Patterson Says It’s Time for New Computer Architectures and Languages

#157
post #2

It's really hard. Remember the Itanium and the Cell. You can build it, but they may not come. GPUs, though. Those have turned out to be very successful, they can be parallelized as much as you're willing to pay for, and they're good for some non-graphics tasks. Much of machine learning is a simple repetitive computation running at low precision. Special purpose hardware can do that very well. So what's the next usefu…

>It's really hard. Remember the Itanium and the Cell. You can build it, but they may not come.

I think the problem with those is that they failed to build anything compelling -- not that people didn't come.

Re: David Patterson Says It’s Time for New Computer Architectures and Languages

#158

Well, there are some interesting new languages out there already: https://julialang.org/ In fact Moore’s law must have been the reason why Python is what it is today: “Who cares if it’s slow, tomorrow’s computers will be faster!”

Who cares if it’s slow, tomorrow’s computers will be faster!

Well, that’s a misrepresentation of history, the Python ethos has always been to drop into C for performance critical sections. That’s why NumPy won, and why Numba is highly competitive with Julia, and you can keep your existing code.

Re: David Patterson Says It’s Time for New Computer Architectures and Languages

#159
post #143

Earlier quoted context omitted.

Itanium only failed because Intel had agreements in place that allowed AMD to build x86 compatible CPUs, and they were clever to come up with AMD64. If it wasn't for that AMD stunt we would all be using Itaniums by now.

In other words, Itanium only failed because there was competition.

No, Itanium failed because Intel made the error to allow other companies to compete on the x86 space with their patents cross licensing deal.

Competition from other architectures was always there.

Re: David Patterson Says It’s Time for New Computer Architectures and Languages

#160
The author makes it sound as if there have been no material changes to programming languages recently but unless you've been hiding under a rock you will know that this is not true.

He compares Python to C. Come on, please. It would have been more relevant to speak about the LLVM project and how that enables architects to build more expressive languages which can still make use of 30 years of optimization wisdom (most of which was built when CPU's were much slower)

What about mentioning languages like Rust which are designed for high concurrency and zero overhead which let developers write software with the safety of python but the performance of C.

What about mentioning that some old languages, like c++, have evolved though new language features AND guidelines into much more effective languages to guide us into the future of concurrent programming (the easiest way to enjoy the speedups of yesteryear)

Post reply on HN