Hacker News Reader

Comment by eli_gottlieb | Hacker News Reader

>If you develop a compiler that, say, parallelizes the hell out of code, you'll have a group of massive companies breaking down your door and throwing money at you.

I speak with some fair knowledge of compilers, PLs, runtime systems, and OSs when I say: massive companies will also throw money at me if I can turn lead into gold.

A compiler cannot transform an inherently stateful, sequential program into an inherently parallel program that can be easily parallelized-the-hell-out-of. This is why there has been actual interest in shifting over to functional programming among those who need lots and lots of concurrency.

There do exist systems that will, for example, guarantee the determinism of threaded applications -- making them more predictable and debuggable. But DThreads still won't take a fold and turn it into a map.

View on HN

Proebsting has shown that compilers double performance about every 18 years - http://research.microsoft.com/en-us/um/people/toddpro/

Given enough time and memory more things are possible. Heck you could probably add speculative execution to many programs for more speedup. You are right in that the easy stuff has already been done, but that doesn't mean the hard stuff can't be done - just that it is hard. The good news is that people are prepared to pay for hard stuff.

1) See my other post, where I list out how you would build a Sufficiently Smart Compiler for parallelizing preexisting code.

2) You've gone into the research world, which concedes my original point about it not being a viable business ;-).

WRT to 1) you left out profiled feedback which would help with some of the analysis choices. Something else that can be done is to compile multiple versions of things and makes choices/switch things around according to circumstances at runtime (as pretty much every modern JIT does). We also still have a "waste not" mentality which is why I mentioned speculative execution which inherently wastes CPU in order to get quicker answers.

2) Not really. You've used current thinking to define your business model. Think disruptive instead. And worst case you'd end up spending Ycombinator money and end up with a better CV.

Some thoughts: It is possible now for a compiler to chew through terabytes of open source code to build up an information bank. Internal representation of code can be centrally submitted to see if anything matches and provides more compilation hints. Runtime profiling could submit back big O information. An organisation could run all the possibilities Seti-at-home style. ie rather than the compiler having to make more intelligent choices, it can just try all the choices.

1) OK, I concede this one, certainly we can use profiling to get an idea of what a given function's performance curve looks like. We just need some notion of how to vary the size of the inputs in a controlled way when profiling, and then we need to look at the curve and decide what kind of curve we're seeing, and then we need to actually run the statistical software to calculate the precise terms of the curve.

To my knowledge, the middle step is actually the hardest. I'm no statistician, but do we have math/software that can look at a curve and distinguish a logarithmic function with little error in the data from a linear function with lots of error in the data?

>2) Not really. You've used current thinking to define your business model. Think disruptive instead. And worst case you'd end up spending Ycombinator money and end up with a better CV.

The man-years here are the dominant cost. A SSC falls outside the start-up business model of releasing a "Minimum Viable Product" and all that jazz. You can't build a minimum SSC without building most of the whole thing.

That doesn't mean I wouldn't take someone's money to do it, but I'd be asking for a research-project budget, not an equity investment that has to be "ramen profitable".

Besides, I prefer home-made vegetable curry to ramen any day ;-).

See slide 6 of this IBM presentation http://webdocs.cs.ualberta.ca/~amaral/IBM-Stoodley-talks/Uof... (warning: pdf). Note how little compilers cost relative to other ways of improving performance.

You are still thinking "cathedral" as the project structure. I think "bazaar" is a better approach - try all the things, fling stuff against the wall and see what sticks. Use the terabytes of existing code to learn. I see the latter like spoken language translation. The approach used to be coming up with rules from experts which is very expensive. Nowadays they use statistical approaches which relies on having lots of data, uses humungous amounts of machine time to build the translation, but uses very few (expensive) people.

A YC startup doesn't have to be profitable or even come up with a MVP - it has to show there is merit to what they doing and some probability of success in the long run.

Another example from a favoured database - MongoDB. Rather than trying to come up with optimal query plans they try all pertinent ones concurrently. Whichever finishes first is noted and used in the future. Its performance results continue to be monitored and if they start diverging all are tried again.

This means not having to guess big O correctly, or access patterns or other stuff in advance. It is possible to add future optimisations and not worry about current ones since they just won't be used work inapplicable workloads.

>A YC startup doesn't have to be profitable or even come up with a MVP - it has to show there is merit to what they doing and some probability of success in the long run.

Then what's the point of a YC startup? Doesn't have to make a profit, doesn't have to build a product... basically, sounds like it doesn't have to build a company.

His page at Microsoft Research is gone, and Google Cache has got it the same day you posted this. I wonder what happened to him. Can anybody link to that research?

http://webcache.googleusercontent.com/search?hl=en&q=cac...

http://i.imgur.com/wGqku.png

Reply on news.ycombinator.com