5 ms·

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 y

by daeken 15y ago

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. Edit: Also, compilers to move code from mainframes to commodity servers, recompilers to switch architectures (e.g. Rosetta by Transitive), etc are big business. Are they going to make you a billionaire? Probably not. Can you make a couple million and a great ROI? Absolutely.

eli_gottlieb 15y ago
>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.
- rogerbinns 15y ago
  Proebsting has shown that compilers double performance about every 18 years - http://research.microsoft.com/en-us/um/people/toddpro/ 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.
  - eli_gottlieb 15y ago
    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 ;-).
    - rogerbinns 15y ago
      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.
      - eli_gottlieb 15y ago
        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 ;-).
  - ranit8 15y ago
    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=cache%3Ahttp%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Ftoddpro%2F http://webcache.googleusercontent.com/search?hl=en&q=cac... http://i.imgur.com/wGqku.png http://i.imgur.com/wGqku.png
eli_gottlieb 15y ago
OK, my second response is the following (copypasta'd out of the email I just sent to Paul Graham on the very subject of the Sufficiently Smart Compiler being a business prospect... ever): http://marmoach.blogspot.com/2012/03/this-is-why-you-cant-build-sufficiently.html http://marmoach.blogspot.com/2012/03/this-is-why-you-cant-bu...

by daeken 15y ago

eli_gottlieb 15y ago

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

rogerbinns 15y ago
Proebsting has shown that compilers double performance about every 18 years - http://research.microsoft.com/en-us/um/people/toddpro/ 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.
- eli_gottlieb 15y ago
  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 ;-).
  - rogerbinns 15y ago
    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.
    - eli_gottlieb 15y ago
      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 ;-).
- ranit8 15y ago
  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=cache%3Ahttp%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Ftoddpro%2F http://webcache.googleusercontent.com/search?hl=en&q=cac... http://i.imgur.com/wGqku.png http://i.imgur.com/wGqku.png

eli_gottlieb 15y ago

OK, my second response is the following (copypasta'd out of the email I just sent to Paul Graham on the very subject of the Sufficiently Smart Compiler being a business prospect... ever): http://marmoach.blogspot.com/2012/03/this-is-why-you-cant-build-sufficiently.html http://marmoach.blogspot.com/2012/03/this-is-why-you-cant-bu...