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.
2) You've gone into the research world, which concedes my original point about it not being a viable business ;-).
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.
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 ;-).
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.
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.
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.