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