3 ms·

Well…Suppose I wrote an optimizer which could—-perhaps as some kind of return-value optimization, determine that we didn’t even need to construct such an object

by rhelz 3y ago

Well…Suppose I wrote an optimizer which could—-perhaps as some kind of return-value optimization, determine that we didn’t even need to construct such an object, but we instead could just pass along the values to the caller? If I never had to create the virtual table, would it be a violation of the spec if I didn’t do it? We are so good at handling ambiguity that we don’t even notice its existence most of the time. But specs, especially specs which specify the semantics of an expression—are infinitely ambiguous as to how to that expression is actually calculated. Ideally, the spec, for c++ or another language is deliberately made ambiguous, just because it leaves room for creative interpretations—-also known as “optimizations”.

jiggawatts 3y ago
> If I never had to create the virtual table, would it be a violation of the spec if I didn’t do it? Generally: no. Most such specs have a phrase along the lines of “externally observable effect”. In other words, the compiler can do anything as long as the programmer or external systems can’t tell that anything is different. Processors do this all the time, reordering instruction execution but then arranging things so that it’s impossible to tell that this occurred.
- rhelz 3y ago
  Yup. Its an interesting example of deliberate ambiguity, and how useful it can be. This is why I don't like using "ambiguous" as a term of abuse. Ambiguity isn't inherently bad. Languages are ambiguous for a reason.
  - jiggawatts 3y ago
    But this can be unambiguously defined! Externally observable effects can have specific meanings.
    - rhelz 3y ago
      I didn't quite understand that point, can you rephrase? I mean, yeah, things like specs for computer languages do define a space for ambiguity, but that space is ambiguous just the same.
      - jiggawatts 3y ago
        Let's say you wrote this code: a = 2 * b + c * d; writeToDisk(a) e = b + b - a; sendToNetwork(e) Naively, you would expect the compiler to emit CPU instructions that perform the computations left-to-right, top-to-bottom. In pseudocode assembly: mul 2, b -> a mul c, d -> reg1 add a, reg1 -> a push a call writeToDisk mov b -> reg1 add b, reg1 -> reg1 sub a, reg -> e push e call sendToNetwork The externally observable effects may be considered to be the function calls. If you're dealing with I/O devices then it would be some similar specific hardware event such as writing to a GPIO register. It should be immediately obvious that the compiler can compute 2*b just once, cache it in a register, and use it to compute both 'a' and 'e', even though the formulas are different and interspersed with function calls. Similarly, it can noticed that e has a 2b-2b in its overall formula and hence eliminate some computations entirely. As long as the inputs to the functions don't change and the order of their calls aren't modified, "all is fine" and the compiler is free to do this. In fact, modern compilers can completely eliminate function calls, inlining them if they perform pure computations or have no side-effects! This is done to such a point that it makes benchmarking challenging: merely timing some computations will often take 0 time unless the result of the computation is written to the console or some similarly externally-visible destination. Compilers are allowed to this even for abstractions like virtual functions or interfaces. The JVM does this regularly. If it notices there's only a single implementation of an interface, it'll inline it, possibly eliminating the call entirely if it turns out to be a no-op.
        rhelz 3y ago
        Ok, thanks for clarifying. But again, we are so used to dealing with ambiguity that we don't even notice it. It looks like the inputs/outputs are really nailed down....but still, it is ambiguous in countless ways. For example, you can type the input/output to these functions in any font or size you want. You don't have to use ASCII. The results on the screen can be glowing green phosphorus, red phosphorus, or a glorious retina display. etc etc. Wherever the specs end, the ambiguity begins.
- InitialLastName 3y ago
  For your latter point I find branch prediction to be even more egregious (from a computational ambiguity perspective). The processor is executing code just in case it discovers that it needs to have executed it.

by rhelz 3y ago

jiggawatts 3y ago

> If I never had to create the virtual table, would it be a violation of the spec if I didn’t do it? Generally: no. Most such specs have a phrase along the lines of “externally observable effect”. In other words, the compiler can do anything as long as the programmer or external systems can’t tell that anything is different. Processors do this all the time, reordering instruction execution but then arranging things so that it’s impossible to tell that this occurred.

rhelz 3y ago
Yup. Its an interesting example of deliberate ambiguity, and how useful it can be. This is why I don't like using "ambiguous" as a term of abuse. Ambiguity isn't inherently bad. Languages are ambiguous for a reason.
- jiggawatts 3y ago
  But this can be unambiguously defined! Externally observable effects can have specific meanings.
  - rhelz 3y ago
    I didn't quite understand that point, can you rephrase? I mean, yeah, things like specs for computer languages do define a space for ambiguity, but that space is ambiguous just the same.
    - jiggawatts 3y ago
      Let's say you wrote this code: a = 2 * b + c * d; writeToDisk(a) e = b + b - a; sendToNetwork(e) Naively, you would expect the compiler to emit CPU instructions that perform the computations left-to-right, top-to-bottom. In pseudocode assembly: mul 2, b -> a mul c, d -> reg1 add a, reg1 -> a push a call writeToDisk mov b -> reg1 add b, reg1 -> reg1 sub a, reg -> e push e call sendToNetwork The externally observable effects may be considered to be the function calls. If you're dealing with I/O devices then it would be some similar specific hardware event such as writing to a GPIO register. It should be immediately obvious that the compiler can compute 2*b just once, cache it in a register, and use it to compute both 'a' and 'e', even though the formulas are different and interspersed with function calls. Similarly, it can noticed that e has a 2b-2b in its overall formula and hence eliminate some computations entirely. As long as the inputs to the functions don't change and the order of their calls aren't modified, "all is fine" and the compiler is free to do this. In fact, modern compilers can completely eliminate function calls, inlining them if they perform pure computations or have no side-effects! This is done to such a point that it makes benchmarking challenging: merely timing some computations will often take 0 time unless the result of the computation is written to the console or some similarly externally-visible destination. Compilers are allowed to this even for abstractions like virtual functions or interfaces. The JVM does this regularly. If it notices there's only a single implementation of an interface, it'll inline it, possibly eliminating the call entirely if it turns out to be a no-op.
      - rhelz 3y ago
        Ok, thanks for clarifying. But again, we are so used to dealing with ambiguity that we don't even notice it. It looks like the inputs/outputs are really nailed down....but still, it is ambiguous in countless ways. For example, you can type the input/output to these functions in any font or size you want. You don't have to use ASCII. The results on the screen can be glowing green phosphorus, red phosphorus, or a glorious retina display. etc etc. Wherever the specs end, the ambiguity begins.
InitialLastName 3y ago
For your latter point I find branch prediction to be even more egregious (from a computational ambiguity perspective). The processor is executing code just in case it discovers that it needs to have executed it.