5 ms·

To clarify, you cant know what is the most efficient path in Programming. You can modify and time, but you can't know ahead of time.

MaxBarraclough 6y ago
I don't see the point here. It's quite possible to assess the performance of a game-engine.
- marketingPro 6y ago
  Okay I'll explain one more time, maybe a second write will clarify. In Engineering, everything is defined with specifications and based on specifications you can calculate if something will work. If you need something to work at 100 degrees C but it will never get to 110C, you don't buy a material that works at 110C, you find the cheapest material that works at 101C. (Factor of safety aside) You can prove in math your design will work In Programming, unless you are working at switch levels, how could you prove your code is most optimized? It's not going to be. Abstraction has removed the possibility of doing that. The closest thing I've seen to Engineering in the Programming world is Industrial Engineering. This is the way Engineers optimize production environments. You can see this in Programming in various time/load aspects. But industrial engineering is an "After the fact", and as much as I like optimization, it has a reputation of not being Engineering. Hope that makes sense. Science and math vs optimization.
  - MaxBarraclough 6y ago
    > You can prove in math your design will work It's possible, but extremely labour-intensive, to mathematically prove the correctness of a program. I mentioned this in my previous comment. > In Programming, unless you are working at switch levels, how could you prove your code is most optimized? 'Most optimised' is an entirely different problem than 'your design will work'. Complexity theory lets us do something like this, but at a more abstract level, rather than at the level of real-world performance on a particular machine. As you say, real-world code is almost guaranteed not to be perfectly optimal in terms of performance. We really never need to aim for this though. Market forces push for high correctness and performance, to varying degrees across different different problem domains. Performance matters in game-engines and for high-frequency trading, and in those applications, the software engineers put in great effort to optimise their systems, using fewer abstractions. Sometimes the software engineering challenge may be a life-critical hard-real-time system, such as in medicine or aviation. Software engineers are able to deliver such systems. It's not of great concern that these systems aren't perfectly optimal in terms of their performance, provided the programs give the right outputs and always meet their deadlines. The generation of perfectly optimised code has been researched, branded superoptimisation, [0] but it's little more than an academic curiosity. I doubt it will ever be possible to scale it up to be practical for large programs. (I'm not sure if/how they deal with the way most modern processors are terribly complex and don't have easily predictable performance.) > Abstraction has removed the possibility of doing that. It's very often a sound decision to trade off on performance in order to gain on some other dimension, such as development velocity, or maintainability, or indeed correctness, given the project's resource constraints. As tools improve, the Pareto frontier advances, and we get a little closer to being able to 'have it all'. An example of this might be the use of Rust for web development work, which can apparently greatly improve performance (or greatly reduce the computational resources needed). It can bring the performance of C++, while retaining many of the advantages of safer, higher-level languages like Java and C#. Whether it does this well enough to really grain traction, we'll have to wait and see, but I think it's a good example. > The closest thing I've seen to Engineering in the Programming world is Industrial Engineering. Industrial engineering is an entirely different discipline than software engineering. For examples of 'proper software engineering', the obvious candidates are avionics (as discussed in the article I linked above), and development methodologies involving formal methods, such as with the Tokeneer project. [1][2] [0] https://en.wikipedia.org/wiki/Superoptimization https://en.wikipedia.org/wiki/Superoptimization [1] https://blog.adacore.com/tokeneer-fully-verifed-with-spark-2014 https://blog.adacore.com/tokeneer-fully-verifed-with-spark-2... [2] [Huge PDF] http://www.adacore.com/uploads/downloads/Tokeneer_Report.pdf http://www.adacore.com/uploads/downloads/Tokeneer_Report.pdf
    - marketingPro 6y ago
      We may be talking past each other as your points aren't relevant to Engineering. I'm going to highlight this- Engineering is Science and math vs Programming which is optimization.
      - MaxBarraclough 6y ago
        Software engineering is an optimisation problem in the same sense that other engineering fields are optimisation problems. There are tradeoffs to be made on many dimensions, just like in any engineering discipline. Again, mathematical tools can be used to prove the correctness of programs.
        marketingPro 6y ago
        I think you are missing the science and math aspect of this. This isn't a contest. Physicians make lots of money by following tradition and practicing medicine as an art. There is huge debate that Physicians could lose their monopoly powers if medical is a science.
        MaxBarraclough 6y ago
        This is vague. Please clarify your point. What aspect are you talking about?
        marketingPro 6y ago
        I recommend reviewing the scientific method. Not that you don't already know the scientific method. But there is a huge difference between science and tradition/authority/art and it's good to realize what is required for something to be science. (And it's not You, people often confuse science with authority/art/tradition)
- AnimalMuppet 6y ago
  I suspect that marketingPro meant that you can't know what is the most efficient path for writing that game engine.
IggleSniggle 6y ago
If you are writing in an assembly language ie for a specific hardware architecture, why couldn’t you know the most efficient path ahead of time?

MaxBarraclough 6y ago

I don't see the point here. It's quite possible to assess the performance of a game-engine.

marketingPro 6y ago
Okay I'll explain one more time, maybe a second write will clarify. In Engineering, everything is defined with specifications and based on specifications you can calculate if something will work. If you need something to work at 100 degrees C but it will never get to 110C, you don't buy a material that works at 110C, you find the cheapest material that works at 101C. (Factor of safety aside) You can prove in math your design will work In Programming, unless you are working at switch levels, how could you prove your code is most optimized? It's not going to be. Abstraction has removed the possibility of doing that. The closest thing I've seen to Engineering in the Programming world is Industrial Engineering. This is the way Engineers optimize production environments. You can see this in Programming in various time/load aspects. But industrial engineering is an "After the fact", and as much as I like optimization, it has a reputation of not being Engineering. Hope that makes sense. Science and math vs optimization.
- MaxBarraclough 6y ago
  > You can prove in math your design will work It's possible, but extremely labour-intensive, to mathematically prove the correctness of a program. I mentioned this in my previous comment. > In Programming, unless you are working at switch levels, how could you prove your code is most optimized? 'Most optimised' is an entirely different problem than 'your design will work'. Complexity theory lets us do something like this, but at a more abstract level, rather than at the level of real-world performance on a particular machine. As you say, real-world code is almost guaranteed not to be perfectly optimal in terms of performance. We really never need to aim for this though. Market forces push for high correctness and performance, to varying degrees across different different problem domains. Performance matters in game-engines and for high-frequency trading, and in those applications, the software engineers put in great effort to optimise their systems, using fewer abstractions. Sometimes the software engineering challenge may be a life-critical hard-real-time system, such as in medicine or aviation. Software engineers are able to deliver such systems. It's not of great concern that these systems aren't perfectly optimal in terms of their performance, provided the programs give the right outputs and always meet their deadlines. The generation of perfectly optimised code has been researched, branded superoptimisation, [0] but it's little more than an academic curiosity. I doubt it will ever be possible to scale it up to be practical for large programs. (I'm not sure if/how they deal with the way most modern processors are terribly complex and don't have easily predictable performance.) > Abstraction has removed the possibility of doing that. It's very often a sound decision to trade off on performance in order to gain on some other dimension, such as development velocity, or maintainability, or indeed correctness, given the project's resource constraints. As tools improve, the Pareto frontier advances, and we get a little closer to being able to 'have it all'. An example of this might be the use of Rust for web development work, which can apparently greatly improve performance (or greatly reduce the computational resources needed). It can bring the performance of C++, while retaining many of the advantages of safer, higher-level languages like Java and C#. Whether it does this well enough to really grain traction, we'll have to wait and see, but I think it's a good example. > The closest thing I've seen to Engineering in the Programming world is Industrial Engineering. Industrial engineering is an entirely different discipline than software engineering. For examples of 'proper software engineering', the obvious candidates are avionics (as discussed in the article I linked above), and development methodologies involving formal methods, such as with the Tokeneer project. [1][2] [0] https://en.wikipedia.org/wiki/Superoptimization https://en.wikipedia.org/wiki/Superoptimization [1] https://blog.adacore.com/tokeneer-fully-verifed-with-spark-2014 https://blog.adacore.com/tokeneer-fully-verifed-with-spark-2... [2] [Huge PDF] http://www.adacore.com/uploads/downloads/Tokeneer_Report.pdf http://www.adacore.com/uploads/downloads/Tokeneer_Report.pdf
  - marketingPro 6y ago
    We may be talking past each other as your points aren't relevant to Engineering. I'm going to highlight this- Engineering is Science and math vs Programming which is optimization.
    - MaxBarraclough 6y ago
      Software engineering is an optimisation problem in the same sense that other engineering fields are optimisation problems. There are tradeoffs to be made on many dimensions, just like in any engineering discipline. Again, mathematical tools can be used to prove the correctness of programs.
      - marketingPro 6y ago
        I think you are missing the science and math aspect of this. This isn't a contest. Physicians make lots of money by following tradition and practicing medicine as an art. There is huge debate that Physicians could lose their monopoly powers if medical is a science.
        MaxBarraclough 6y ago
        This is vague. Please clarify your point. What aspect are you talking about?
        marketingPro 6y ago
        I recommend reviewing the scientific method. Not that you don't already know the scientific method. But there is a huge difference between science and tradition/authority/art and it's good to realize what is required for something to be science. (And it's not You, people often confuse science with authority/art/tradition)
AnimalMuppet 6y ago
I suspect that marketingPro meant that you can't know what is the most efficient path for writing that game engine.

IggleSniggle 6y ago

If you are writing in an assembly language ie for a specific hardware architecture, why couldn’t you know the most efficient path ahead of time?