Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

spectrum.ieee.org

Post reply on HN
Print view View original

61–70 of 204 posts

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

#61

Post by StillBored »

How about instead of inventing new languages we just pick a couple and tell people that if care at all about performance not to use the rest.

I would start by throwing away all the interpreted/GC'ed languages because even after decades of massive effort they are frequently lucky if they even manage to keep up with unoptimized C.. But that really isn't the problem, the problem is that they cannot be debugged for performance without directly hacking the GC/interpreter. At least in C when you discover your data structures are being trashed by insufficient cache associativity (for example), you can actually fix the code.

Put another way, up front people need to know that if they write in python/Java/etc to save themselves a bit of engineering effort and its anything more than throwaway low volume code, the effort to optimize or rewrite it will dwarf any savings they might have gotten by choosing python.

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

#62

Post by luma »

Varcht wrote: post #59
luma wrote: post #57

Only tangentially related to the article but... I'm left to wonder about the photograph selected. His left hand appears to be on a stack of 20-year old HP 9000s (maybe rp3440, pre-grey box?), and standing across from a rack full of ancient 4U systems mounted into 2-post relay racks. The white blanking panels are early 2000's-era HP kit, and in the background are racks full of tower systems stacked vertically. Is this…

Per the exif data embeded in the image "Date Time Digitized: May 1, 2006, 9:10:59 PM, Creator: Peg Skorpinski photo".

That would certainly explain it! After posting my comment it occurred to me that having Dr Patterson pose next to a PA-RISC system was probably intentional, given his history.

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

#63

Post by mark_l_watson »

A little off topic, but I greatly admire generalists: Dr. Patterson (along with Dr. Fox) taught a good Coursera course on agile web development with Ruby and Rails. Quite a departure for an originator of RISC architectures!

I think Dr. Patterson makes a great point on there being plenty of headroom in the increase in software efficiency.

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

#64

Post by Retra »

saagarjha wrote: post #42
gone35 wrote: post #39

Earlier quoted context omitted.

Bad performance isn't really a software design problem; it's an economics problem (ditto for security). Why do you say so?

It means that people haven't thrown enough {time, energy, money} at the problem.

I think the idea is that people stop optimizing for speed as soon as it gets "fast enough", and what "fast enough" means doesn't change at all if you make better tools and machines.

Faster machines and tools only really matters to people who are trying to do things that are currently never fast enough to put into production.

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

#65

Post by mtinkerhess »

StillBored wrote: post #61

How about instead of inventing new languages we just pick a couple and tell people that if care at all about performance not to use the rest. I would start by throwing away all the interpreted/GC'ed languages because even after decades of massive effort they are frequently lucky if they even manage to keep up with unoptimized C.. But that really isn't the problem, the problem is that they cannot be debugged for perfo…

For a lot of problems performance really isn't the problem. In many, many cases the engineering cost to optimize C++ to get a benefit over Java / C# will be way more expensive than just paying for more servers. Even in game dev where milliseconds matter C# is very common.

Personally I agree about dynamically typed languages not being great for large projects but that's more about maintainability than perf.

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

#66

Post by api »

Here's something that seems shockingly under-explored to me: languages that incorporate relational data structures natively.

We have SQL of course, but SQL is not a general purpose language and is (intentionally) often not Turing-complete.

I'm imagining something like Go, Ruby, JavaScript, or Rust with native tables, queries, and other SQL-ish relational data structures.

The long term goal would be to kill the age-old impedance mismatch problem and eliminate CRUD code. Toward this long term end the language runtime or standard library could actually contain a full database engine with replication/clustering support.

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

#67

Post by mitchty »

austincummings wrote: post #51
so_tired wrote: post #43

Earlier quoted context omitted.

Do u see more pitches for source-code level solutions ? i.e. analyzing and modifying the huge legacy of existing code base ? This is a very difficult area of course (both financially and technologically). But the pay off can be very large. Imagine a vmware-like transformation at the source code level.

> Imagine a vmware-like transformation at the source code level. I'm not sure what you mean by this, but I'm interested. Could you explain?

Sounds like as400 bytecode maybe?

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

#68

Post by gerritsg »

StillBored wrote: post #61

How about instead of inventing new languages we just pick a couple and tell people that if care at all about performance not to use the rest. I would start by throwing away all the interpreted/GC'ed languages because even after decades of massive effort they are frequently lucky if they even manage to keep up with unoptimized C.. But that really isn't the problem, the problem is that they cannot be debugged for perfo…

So would Rust be one of the languages you'd advocate including in the chosen few? Does Rust's approach to memory management put it more in the C group in terms of debugging for performance?

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

#69

Post by gsnedders »

saidajigumi wrote: post #29
snaky wrote: post #10

Earlier quoted context omitted.

> Remember the Itanium Well, why not. > Q: I feel like deja vu - at Hot Chips, Intel introduced VLIW-concept Itanium that pushed complexity onto the compiler. I see traces of that here. What are you doing to avoid the Itanium traps? How will you avoid IP from Intel? > A: Itanium was in-order VLIW, hope people will build compiler to get perf. We came from opposite direction - we use dynamic scheduling. We are not VLIW…

That captures a lot of my take on Itanium at the time: despite being "VLIW" it took on what at the time was a vast amount of CPU controller complexity without an obvious design win or clear high-performance compilation model. As an outsider, it felt like an extremum of Intel's flavor of design hubris. It's interesting to compare the Itanium's approach to a VLIW contemporary from TI: the C6x VLIW DSP ISA. The C6x ISA…

What was the controller complexity of the Itanium you're referring to?

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

#70

Post by Senderman »

philipkglass wrote: post #7

Are there languages that have first-class support for representing/optimizing memory hierarchy characteristics? Optimizing C compilers, for example, may have extensions to force specific alignments: https://software.intel.com/en-us/articles/coding-for-perform... But I'm not aware of languages where e.g. declaring alignments is part of the base language. Awareness of L1, L2, L3 cache characteristics, plus NUMA nodes,…

Assembly typically requires you to declare your own alignments. There are some higher-level assemblers, with macros and things, but you're right, there's rarely an abstract language offering low-level memory specification.

I also dislike the tendency to only expose the abstract view, although I think that trend is due to the difficulties involved in designing a language and compiler whose job is to output code for multiple architectures. Well, at least I hope that's why, because I don't know why you'd choose to offer less control in your language otherwise.

Post reply on HN