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

81–90 of 204 posts

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

#81

Post by solotronics »

Senderman wrote: post #70
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 mu…

probably a dumb question but if you exposed the low level memory manipulation wouldn't you just end up with something like assembly?

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

#82

Post by romwell »

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…

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

Yeah right, let's just burn down the Web.

The biggest performance hog on my machine isn't Python code.

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

#83

Post by klodolph »

solotronics wrote: post #81
Senderman wrote: post #70

Earlier quoted context omitted.

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 mu…

probably a dumb question but if you exposed the low level memory manipulation wouldn't you just end up with something like assembly?

Low-level memory work, if you care about things like data locations and exact layout of memory, is possible in practice with C. There are cases where you can run into aliasing problems, but controlling the actual memory layout is no problem at all. (There are some limitations.)

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

#84

Post by CMCDragonkai »

api wrote: post #66

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-ol…

There's a bunch of relational algebra systems in Haskell, and one in Ruby that gives better first class control over these structures. However the fact that SQL engines all use SQL as text to communicate results in marshalling cost. However there are also languages that have embedded database such as K+.

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

#85

Post by OldHand2018 »

marcosdumay wrote: post #9
Animats wrote: 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…

Well, past experiences are not that useful right now. I don't think the Itanium or the Cell were great architectures, but it's clear that their most obvious failure mode (mainstream architectures improving faster than them) isn't a showstopper anymore. For some guess on the next big thing, I would imagine that stuff that avoid the need of memory coherence have nice odds.

Does anyone else have real-world Itanium experience? We've got a couple 5+ year old HP Integrity servers running OpenVMS on Itanium at work that we use to batch process large ASCII vendor files in an ETL process written in C. They certainly don't embarrass themselves. We'll be connecting them to a new Pure Storage SAN in a few months and the IT guys are really excited to see what happens to performance.

I take the same exact C code, compile it with Visual Studio, and then run the same ASCII files locally on my 7th-gen 4c/8t i7 desktop and am not seeing any improvement. That's about the best I can do as far as benchmarking goes.

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

#86

Post by StillBored »

gerritsg wrote: post #68
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?

I wasn't really trying to pick/choose a language. Although I did pick on python a bit, because I just spent a few days wading through a gigantic "python shell script" that would have literally been 1/100th as many lines written in bash because every third line was calling some shell utility or doing the equivalent of 1 line sed calls in 4-8 line python functions.

The point is that we literally have dozens and dozens of languages active on any given machine with absolutely massive frameworks duplicating functionality. Here is a few hundred meg ruby runtime, with a few hundred meg node.js runtime, with a few hundred meg python2 runtime (and another for python3), with a few hundred meg perl runtime, etc, etc, etc. Its insane because in most cases you can't even statically bind the whole thing into a single .jar like file.

Not only is the cognitive load incredible, but the code quality in most of them is horrendous. Then there is the issue, that most of these language runtimes have for most purposes have zero documentation outside of the actual code.

Then when someone says "what language should I choose" they are presented with a whole bunch of square pegs to pound into their round hole. If your going to work with a square peg, it should probably be one well understood and polished enough to actually have documentation for more than the 100 most common functions being called.

What I'm trying to say is that we don't need yet another over-hyped language, and we should probably try to kill a few more of them off. Object Pascal is a better language than probably 1/2 the ones on common use, but its pretty much dead. Inventing another language that is _worse_ than object pascal is just stupid.

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

#87

Post by adrianratnapala »

amckinlay wrote: post #71

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…

When I was a student in the late '90s, folks at the Uni wanted to that stuff with Ada. I suspect that some limited-but-useful version of this does exist by now in niche sub-branches of safety-critical embedded programming. (Though the commercially used onces are likely to be static analysers for C as they are to be an ADA compiler).

I mean it's nice for compilers to count instructions, but that is far more likely to work on some "primitive" embedded CPU than it is to work on the modern spectre-pipelined goliath CPUs that we use in personal computers and datacentres.

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

#88

Post by adrianratnapala »

munificent wrote: post #79
amckinlay wrote: post #71

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…

Part of the reason most languages obscure this is because it's a moving target. If a language let you say, "this chunk of code here should run in 7 cycles", what happens when a new optimization finds a way to reduce that, or a new architecture comes up where that operation gets slower but lots of others get faster? I'm not arguing against your desire, just explaining that it's not unreasonable that we're where we are…

This is actually why you want the compiler to track it.

You write an algorithm that seems reasonable. And you encode timing constraints into the thing. Now you re-target to a different machine, and the compiler re-checks those constraints. A much cheaper way of dealing with weird timing bugs than doing a post-mortem of why the fuel valves didn't quite close on the day of the rocket test.

But this only works if the CPU is knowable to the compiler. Which is why it is only even remotely feasible in the embedded world (where it is also the most useful).

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

#89

Post by crb002 »

snaky wrote: post #31
crb002 wrote: post #19

Earlier quoted context omitted.

Massive parallel prefix and reduction operations in RAM. Start with just the MPI standard reduction ops. 1000x faster than Von Neuman bottleneck.

> Massive parallel prefix and reduction operations in RAM Sounds similar to Micron Automata Processor.

Micron's processor in memory doesn't have near the same bandwidth as a processor in memory array geared to doing parallel prefix.

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

#90

Post by bcheung »

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,…

There's bit fields in C++.

https://en.cppreference.com/w/cpp/language/bit_field

If you don't need the full precision or range of a 64-bit integer you can pack multiple of them together to get multiple integers transferred in a single cache line read. Compressing in this manner also means you are more likely to get a cache hit.

Post reply on HN