6 ms·

> Machine -> Asm -> C -> Python -> LLM (Human language) Something that you neglected to mention is, with every abstraction layer up to Python, everything is pr

by sdesol 2y ago

> Machine -> Asm -> C -> Python -> LLM (Human language) Something that you neglected to mention is, with every abstraction layer up to Python, everything is predictable and repeatable. With LLMs, we can give the exact same instructions, and not be guaranteed the same code.

12345hn6789 2y ago
assuming you have full control over which compiler youre using for each step ;) What's to say LLMs will not have a "compiler" interface in the future that will reign in their variance
- sdesol 2y ago
  > assuming you have full control over which compiler youre using for each step ;) With existing tools, we know if we need to do something, we can. The issue with LLMs, is they are very much black boxes. > What's to say LLMs will not have a "compiler" interface in the future that will reign in their variance Honestly, having a compiler interface for LLMs isn't a bad idea...for some use cases. What I don't see us being able to do is use natural language to build complex apps in a deterministic manner. Solving this problem would require turning LLMs into deterministic machines, which I don't believe will be an easy task, given how LLMs work today. I'm a strong believer in that LLMs will change how we develop and create software development tools. In the past, you would need Google and Microsoft level of funding to integrate natural language into a tool, but with LLMs, we can easily have LLMs parse input and have it map to deterministic functions in days.
theptip 2y ago
I’m not sure why that matters here. Users want code that solves their business need. In general most don’t care about repeatability if someone else tries to solve their problem. The question that matters is: can businesses solve their problems cheaper for the same quality, or at lower quality while beating the previous Pareto-optimal cost/quality frontier.
- thesz 2y ago
  Recognizable repetition can be abstracted, reducing code base and its (running) support cost. The question that matters is: will businesses crumble due to overproduction of same (or lower) quality code sooner or later.
  - chii 2y ago
    > The question that matters is: will businesses crumble due to overproduction of same (or lower) quality code sooner or later. but why doesn't that happen today? Cheap code can be had by hiring in cheap locations (outsourced for example). The reality is that customers are the ultimate arbiters, and if it satisfies them, the business will not collapse. And i have not seen a single customer demonstrate that they care about the quality of the code base behind the product they enjoy paying for.
    - sdesol 2y ago
      > Cheap code can be had by hiring in cheap locations (outsourced for example). If you outsource and like what you get, you would assume the place you outsourced to can help provide continued support. What assurance do you have with LLMs? A working solution doesn't mean it can be easily maintained and/or evolved. > And i have not seen a single customer demonstrate that they care about the quality of the code base behind the product they enjoy paying for. That is true, but they will complain if bugs cannot be fixed and features are added. It is true that customers don't care, and they shouldn't, until it does matter, of course. The challenge with software development isn't necessarily with the first iteration, but rather it is with continued support. Where I think LLMs can really shine is in providing domain experts (those who understand the problem) with a better way to demonstrate their needs.
    - OvbiousError 2y ago
      It is happening. There is a lot of bad software out there. Terrible to use, but still functional enough that it keeps selling. The question is how much crap you can pile on top of that already bad code before it falls apart.
    - 2y ago
CamperBob2 2y ago
With LLMs, we can give the exact same instructions, and not be guaranteed the same code. That's something we'll have to give up and get over. See also: understanding how the underlying code actually works. You don't need to know assembly to use a high-level programming language (although it certainly doesn't hurt), and you won't need to know a high-level programming language to write the functional specs in English that the code generator model uses. I say bring it on. 50+ years was long enough to keep doing things the same way.
omgwtfbyobbq 2y ago
Aren't some models deterministic with temperature set to 0?
zurn 2y ago
> > Machine -> Asm -> C -> Python -> LLM (Human language) > Something that you neglected to mention is, with every abstraction layer up to Python, everything is predictable and repeatable. As long as you consider C and dragons flying out of your nose predictable. (Insert similar quip about hardware)
jsjohnst 2y ago
> With LLMs, we can give the exact same instructions, and not be guaranteed the same code. Set temperature appropriately, that problem is then solved, no?
- sdesol 2y ago
  No, it is much more involved and not all providers allow the necessary tweakings. This means you will need to use local models (with hardware caveats) which will require us to ask: - Are local models good enough? - What are we giving up for deterministic behaviour? For example, will it be much more difficult to write prompts. Will the output be nonsensical and more.
compumetrika 2y ago
LLMs use pseudo-random numbers. You can set the seed and get exactly the same output with the same model and input.
- blibble 2y ago
  you won't because floating point arithmetic isn't associative and the GPU scheduler isn't deterministic
  - threeducks 2y ago
    You can set PyTorch to deterministic mode with a small performance penalty: https://pytorch.org/docs/stable/notes/randomness.html#avoiding-nondeterministic-algorithms https://pytorch.org/docs/stable/notes/randomness.html#avoidi... Unfortunately, this is only deterministic on the same hardware, but there is no reason why one couldn't write reasonably efficient LLM kernels. It just has not been a priority. Nevertheless, I still agree with the main point that it is difficult to get LLMs to produce the same output reliably. A small change in the context might trigger all kinds of changes in the generated code.
zajio1am 2y ago
There is no reason to assume that say C compiler generates the same machine code for the same source code. AFAIK, a C compiler that chooses randomly between multiple C-semantically equivalent sequences of instructions is a valid C compiler.
SkyBelow 2y ago
Even compiling code isn't deterministic given different compilers and different items installed on a machine can influence the final resulting code, right? Ideally they shouldn't have any noticeable impact, but in edge cases it might, which is why you compile your code once during a build step and then deploy the same compiled code to different environments instead of compiling it per environment.

by sdesol 2y ago

12345hn6789 2y ago

assuming you have full control over which compiler youre using for each step ;) What's to say LLMs will not have a "compiler" interface in the future that will reign in their variance

sdesol 2y ago
> assuming you have full control over which compiler youre using for each step ;) With existing tools, we know if we need to do something, we can. The issue with LLMs, is they are very much black boxes. > What's to say LLMs will not have a "compiler" interface in the future that will reign in their variance Honestly, having a compiler interface for LLMs isn't a bad idea...for some use cases. What I don't see us being able to do is use natural language to build complex apps in a deterministic manner. Solving this problem would require turning LLMs into deterministic machines, which I don't believe will be an easy task, given how LLMs work today. I'm a strong believer in that LLMs will change how we develop and create software development tools. In the past, you would need Google and Microsoft level of funding to integrate natural language into a tool, but with LLMs, we can easily have LLMs parse input and have it map to deterministic functions in days.

theptip 2y ago

I’m not sure why that matters here. Users want code that solves their business need. In general most don’t care about repeatability if someone else tries to solve their problem. The question that matters is: can businesses solve their problems cheaper for the same quality, or at lower quality while beating the previous Pareto-optimal cost/quality frontier.

thesz 2y ago
Recognizable repetition can be abstracted, reducing code base and its (running) support cost. The question that matters is: will businesses crumble due to overproduction of same (or lower) quality code sooner or later.
- chii 2y ago
  > The question that matters is: will businesses crumble due to overproduction of same (or lower) quality code sooner or later. but why doesn't that happen today? Cheap code can be had by hiring in cheap locations (outsourced for example). The reality is that customers are the ultimate arbiters, and if it satisfies them, the business will not collapse. And i have not seen a single customer demonstrate that they care about the quality of the code base behind the product they enjoy paying for.
  - sdesol 2y ago
    > Cheap code can be had by hiring in cheap locations (outsourced for example). If you outsource and like what you get, you would assume the place you outsourced to can help provide continued support. What assurance do you have with LLMs? A working solution doesn't mean it can be easily maintained and/or evolved. > And i have not seen a single customer demonstrate that they care about the quality of the code base behind the product they enjoy paying for. That is true, but they will complain if bugs cannot be fixed and features are added. It is true that customers don't care, and they shouldn't, until it does matter, of course. The challenge with software development isn't necessarily with the first iteration, but rather it is with continued support. Where I think LLMs can really shine is in providing domain experts (those who understand the problem) with a better way to demonstrate their needs.
  - OvbiousError 2y ago
    It is happening. There is a lot of bad software out there. Terrible to use, but still functional enough that it keeps selling. The question is how much crap you can pile on top of that already bad code before it falls apart.
  - 2y ago

CamperBob2 2y ago

With LLMs, we can give the exact same instructions, and not be guaranteed the same code. That's something we'll have to give up and get over. See also: understanding how the underlying code actually works. You don't need to know assembly to use a high-level programming language (although it certainly doesn't hurt), and you won't need to know a high-level programming language to write the functional specs in English that the code generator model uses. I say bring it on. 50+ years was long enough to keep doing things the same way.

omgwtfbyobbq 2y ago

Aren't some models deterministic with temperature set to 0?

zurn 2y ago

> > Machine -> Asm -> C -> Python -> LLM (Human language) > Something that you neglected to mention is, with every abstraction layer up to Python, everything is predictable and repeatable. As long as you consider C and dragons flying out of your nose predictable. (Insert similar quip about hardware)

jsjohnst 2y ago

> With LLMs, we can give the exact same instructions, and not be guaranteed the same code. Set temperature appropriately, that problem is then solved, no?

sdesol 2y ago
No, it is much more involved and not all providers allow the necessary tweakings. This means you will need to use local models (with hardware caveats) which will require us to ask: - Are local models good enough? - What are we giving up for deterministic behaviour? For example, will it be much more difficult to write prompts. Will the output be nonsensical and more.

compumetrika 2y ago

LLMs use pseudo-random numbers. You can set the seed and get exactly the same output with the same model and input.

blibble 2y ago
you won't because floating point arithmetic isn't associative and the GPU scheduler isn't deterministic
- threeducks 2y ago
  You can set PyTorch to deterministic mode with a small performance penalty: https://pytorch.org/docs/stable/notes/randomness.html#avoiding-nondeterministic-algorithms https://pytorch.org/docs/stable/notes/randomness.html#avoidi... Unfortunately, this is only deterministic on the same hardware, but there is no reason why one couldn't write reasonably efficient LLM kernels. It just has not been a priority. Nevertheless, I still agree with the main point that it is difficult to get LLMs to produce the same output reliably. A small change in the context might trigger all kinds of changes in the generated code.

zajio1am 2y ago

There is no reason to assume that say C compiler generates the same machine code for the same source code. AFAIK, a C compiler that chooses randomly between multiple C-semantically equivalent sequences of instructions is a valid C compiler.

SkyBelow 2y ago

Even compiling code isn't deterministic given different compilers and different items installed on a machine can influence the final resulting code, right? Ideally they shouldn't have any noticeable impact, but in edge cases it might, which is why you compile your code once during a build step and then deploy the same compiled code to different environments instead of compiling it per environment.