There are a number of dimensions I could mention (and they all get at least links snuck into the article), but one that I feel is underdiscussed is the economic cost of code generation. Assume for the sake of argument that LLM-centric flows will produce fully satisfactory output in the near future (or may already). It just takes a long time to get answers back from AI-coding tools. And the latency is fundamental, given the way that deep-learning models are structured and the way other tools are built on top. Latency will really matter for periodic regeneration of all code relevant to an organization.
My hypothesis is that logic-based methods can also take advantage of highly performance-optimized parallel compute to generate better code (though maybe only in relatively rare but important cases) at orders of magnitude lower cost and latency.
Plausibly, there’s a point where coding models and tools get stable enough to not change often, at which point you can do things like make custom silicon to get the speed and efficiency up.
Absolutely true, but the dataflow graphs of this style of solution are fundamentally slow to execute, because they include long sequential dependency chains, as I’ve written about at more length. Going to custom silicon can improve the constant factors, but I don’t think it’s enough.
There are a number of dimensions I could mention (and they all get at least links snuck into the article), but one that I feel is underdiscussed is the economic cost of code generation. Assume for the sake of argument that LLM-centric flows will produce fully satisfactory output in the near future (or may already). It just takes a long time to get answers back from AI-coding tools. And the latency is fundamental, given the way that deep-learning models are structured and the way other tools are built on top. Latency will really matter for periodic regeneration of all code relevant to an organization.
My hypothesis is that logic-based methods can also take advantage of highly performance-optimized parallel compute to generate better code (though maybe only in relatively rare but important cases) at orders of magnitude lower cost and latency.
Plausibly, there’s a point where coding models and tools get stable enough to not change often, at which point you can do things like make custom silicon to get the speed and efficiency up.
Absolutely true, but the dataflow graphs of this style of solution are fundamentally slow to execute, because they include long sequential dependency chains, as I’ve written about at more length. Going to custom silicon can improve the constant factors, but I don’t think it’s enough.