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

91–100 of 204 posts

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

#91

Post by dwohnitmok »

baddox wrote: post #80
Waterluvian wrote: post #77

Earlier quoted context omitted.

Are you suggesting a language where you could hypothetically look at your IDE and it'll tell you via static analysis, "this code block takes x cpu units. On a Y core this is 0.95ns". Never thought about that. That would be so cool.

There are lots of attributes that are provably impossible to statically determine about a computer program. Whether the program halts is the obvious example, but Rice's theorem generalizes this to effectively any attribute of a computer program you would be likely to care about. https://en.wikipedia.org/wiki/Rice%27s_theorem

Rice's Theorem generalizes this to any implementation-independent attribute (i.e. properties of the idealized function on natural natural numbers a program represents). However, certain implementation-specific details such as run time (i.e. performance) are fair game. In particular it is quite simple to at least calculate lower bounds on run time. Simply choose a lower bound and then run the program and see if it halts before then.

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

#92

Post by tonysdg »

mjfl wrote: post #58

It would be nice if low volume foundry costs went down an order of magnitude. I'm in a bio lab right now, but I did CS in college and really enjoyed VLSI. If I want to turn a design into a prototype in my bio lab, it's going to cost hundreds of dollars, but if I want to turn a chip I designed into reality, it's going to cost thousands to tens of thousands of dollars even with specialized low volume foundries like MOS…

Generally speaking, that's where FPGAs excel. You get a good chunk of the speedup that comes with designing your own circuit at a lower cost than actual ASICs (at least for protoyping and low volume batches).

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

#93

Post by chubot »

gone35 wrote: post #39
chubot wrote: post #32

Earlier quoted context omitted.

Yes, a pithier way of saying this is: Software is a gas; it expands to fill its container - Nathan Myhrvold Bad performance isn't really a software design problem; it's an economics problem (ditto for security). You could speed up the browser by 2x now, or reduce it's memory usage by 2x, and websites would be exactly as slow after a few months. I'm not trying to be negative here, just stating an unfortunate systems d…

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

To be clearer, I would say that software is exactly as fast and secure as the market will bear.

There is probably an economics term I can cite to explain this better, like some kind of equilibrium (I appreciate any help explaining this).

But the sibling basically got it half-right -- software developers and designers are always making cost-benefit decisions.

The other half of it is that consumers tend to choose features rather than security. The are ALREADY faster and more secure alternatives to every piece of software you use -- you just don't use them because they don't have the features you want!

People vote with their feet, and what we end up with is not the fastest or most secure situation, because there are tradeoffs.

This applies to developers too -- not just end users. I mean why do people choose Python, PHP, or JavaScript? There are faster languages out there. There are languages that could help you write more secure applications.

But those languages have the features and library ecosystem we want, so we use them.

----

I'm one of those people who laments slow and insecure software. But doing my own open source project has kind of brought home the tradeoffs. I've been working for over 2 years on an open source Unix shell. It's written in Python [1], which is not exactly the right tool for the job. But if I wrote it in C or C++ or Rust, it would take 4 or 6 or 10 years.

So unforunately it is too slow, but there's a tradeoff between being slow and being fast but not existing and nobody using it. (Although I have a plan to fix it, basically outlined in that blog post. Not sure how much effort it will take, but I think less than rewriting from scratch.)

It's an economics problem -- if it doesn't have the features people already use, then they'll have to rewrite their software. Rewriting shell scripts costs a lot of money and it doesn't have a lot of advantages. It's more economical for one person/team to emulate bash in a new shell, than for the entire world to rewrite their scripts.

This recent blog post has the same sentiment buried in there:

https://apenwarr.ca/log/20180914

XHTML didn't succeed because it's more economical for a single browser vendor to make a really complicated parsing algorithm than it is for every single person in the world to change how they write HTML.

It's not like we don't KNOW how to design strict data formats, or we don't KNOW how to make secure software. (e.g. ask yourself why more people aren't using DJB's software.) It's matter of economics -- how much effort are the people making decisions willing to put in, and how much the market rewards them for it.

We can certainly improve the situation by valuing secure and fast software, and that has happened in the past. Windows used to be an utter disaster security-wise, but Microsoft realized that it was more than the market would bear, and they changed their whole attitude toward security.

Although if you want to be cynical, you can also say they made the "right" move to ship first and make things secure later :-(

[1] http://www.oilshell.org/blog/2018/03/04.html

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

#94

Post by bcheung »

It seems like hardware is moving away from RISC and even CISC architectures in favor of lots of different types of silicon for specialized applications (GPU, machine learning, vision, DSP, hashing, encryption, SIMD).

It makes sense from a hardware perspective but it seems software development is not keeping pace. General purpose languages have trouble targeting this kind of hardware.

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

#95

Post by Shelnutt2 »

OldHand2018 wrote: post #85
marcosdumay wrote: post #9

Earlier quoted context omitted.

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

At my previous job we used itanium servers for the secure64 dns platform[1]. It performed well, the logic behind itanium is security not performance (according to secure64) but performance was never an issue. I do know the hardware support for rsa did give nice performance for dnssec signing.

[1] https://secure64.com/dns-products/secure64-platforms/secure-...

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

#96

Post by TheCoelacanth »

baddox wrote: post #80
Waterluvian wrote: post #77

Earlier quoted context omitted.

Are you suggesting a language where you could hypothetically look at your IDE and it'll tell you via static analysis, "this code block takes x cpu units. On a Y core this is 0.95ns". Never thought about that. That would be so cool.

There are lots of attributes that are provably impossible to statically determine about a computer program. Whether the program halts is the obvious example, but Rice's theorem generalizes this to effectively any attribute of a computer program you would be likely to care about. https://en.wikipedia.org/wiki/Rice%27s_theorem

Impossible to prove for any arbitrary program doesn't mean impossible to prove for programs that we actually care about, and it especially doesn't mean impossible to prove for a program where the programmer is intentionally trying to write a program where certain attributes are provable.

Any statically typed language necessarily has to prevent some well-formed programs from being represented. This language would just need to reject programs where it can't prove the attributes that it is suppose to prove in addition to programs that are actually malformed.

It is really ergonomics that prevents a language like this from taking off, not any theoretical concerns. Languages that let you prove a lot of complex properties at compile-time take too much work to use, but they are not impossible to create.

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

#97

Post by chubot »

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.

Not quite.. see my sibling response. It's probably more accurate to say that some people have thrown a lot of time and energy at the problem.

But the market does not value their software; we use slower and less secure alternatives.

Slack is a great example. There are probably 99 other chat services that perform better than Slack. (Apparently it makes fans spin on laptops, which is kind of shocking for a chat app.)

But the market doesn't necessarily care -- it values the features that Slack provides more.

Part of it is a bad network effect. I care about speed, but I might have to use Slack because the people I want to talk to on Slack don't care about speed.

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

#98

Post by platform »

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?

Probably things similar to Automated Code transformations. Eg: http://www.semdesigns.com/Products/Services/LegacyMigration....

they site some numbers by Gartner (from '99, when 2K scare was on everyone's mind)

"...

Cost of doing a manual migration:The Gartner Group notes that the cost for manual code conversion can range from $6 - $26 per LOC and is accomplished at a rate of 160 LOC per day (Gartner Group study "Forecasting the Worldwide IT Services Industry: 1999,1").

An assumption is that the migration is going between two relatively similar languages (e.g., not trying to go from COBOL to full object-oriented Java). Using Gartner's numbers, a million lines of code costs $6-$26 million to migrate.

Time to do a manual migration: Again, using Gartner's numbers, a legacy system with a million lines of code requires some 28+ man-years of labor to convert. With a team of 10, this takes 3 elapsed years if done well. With larger systems, one has larger teams. Larger teams require more interactions, slowing them down further.

A 10 million line application simply doesn't have any practical manual migration due to time frames.

"

Never used their services.

But I do think this will continue to be difficult, yet beneficial option, for the migrations from legacy/less secure software.

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

#99

Post by TheCoelacanth »

tabtab wrote: post #37
chubot wrote: post #32

Earlier quoted context omitted.

Yes, a pithier way of saying this is: Software is a gas; it expands to fill its container - Nathan Myhrvold Bad performance isn't really a software design problem; it's an economics problem (ditto for security). You could speed up the browser by 2x now, or reduce it's memory usage by 2x, and websites would be exactly as slow after a few months. I'm not trying to be negative here, just stating an unfortunate systems d…

I generally agree: it's about weighing trade-offs, and calling software companies "lazy" is perhaps an oversimplification. However, I do believe the speed of light and size of atoms puts an upper limit on the degree you can keep throwing hardware at the problem. We may continue to find tricks such as quantum computing, but I suspect it will get ever tougher. There's a theoretical limit to how small you squeeze data a…

Software companies are lazy in exactly the same way that the entire rest of the economy is lazy. Companies in every industry try to cut costs as much as they can.

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

#100

Post by philipkglass »

OldHand2018 wrote: post #85
marcosdumay wrote: post #9

Earlier quoted context omitted.

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

I used Itanium from 2003-2006 for scientific computing on a big cluster. For that purpose it was much faster than Intel's Xeons of similar vintage. It was also significantly faster than the MIPS and POWER systems we had. Caveats:

- The simulation suite that I used most heavily was developed in-house at the same lab that bought the hardware. It was profiled and tuned specifically for our hardware. The development team was a real software development team with experience writing parallel simulation code since the early 1990s. It wasn't just a bunch of PhD students trying to shove new features into the software to finish their theses.

- There was also close cooperation between the lab, the system vendor (HP), and Intel.

- Other software (like all the packages shipped with RHEL for Itanium) didn't seem particularly fast.

- God help you if you needed to run software that was available only as binary for x86. The x86 emulation was not fast at all.

It was great for numerical code that had been specifically tuned for it. It was pretty good for numerical code that had been tuned for other contemporary machines. Otherwise I didn't see particularly good performance from it. I don't know if it really was a design that was only good for HPC or if (e.g.) it also would have been good for Java/databases, given sufficient software investments.

Maybe it would have been competitive against AMD64, even considering the difficulty of architecture-switching, if it had not been so expensive. But I'm not sure Intel had wiggle room to price Itanium to pressure AMD64 even if they had wanted to; Itaniums were quite big, complicated chips.

Post reply on HN