4 ms·

To spare, you say? I want to use that computing power for my own purposes. I suddenly decided I want to multiply gigantic matrices.

qwertyuiop924 10y ago
Okay. Go write some C, or some Asm. It might feel unpleasant to you, but if you use most other langauges, you'll be wasting too many cycles, and you won't be using that computing power for your own puposes. Don't forget to use as few abstractions as possible, and remember: every function call takes valuable time and computation.
- catnaroek 10y ago
  > Don't forget to use as few abstractions as possible Huh? I'm perfectly fine with abstractions. Just not with abstractions that are suboptimally designed and implemented. > Don't forget to use as few abstractions as possible Maybe you're confusing abstraction with runtime dispatch? > every function call takes valuable time and computation. Stroustrup's (whom otherwise I don't regard as a great language designer) principle applies: abstractions must elaborate to the best possibly code you would've manually written.
  - qwertyuiop924 10y ago
    Every abstraction has a cost somewhere. If you want to use your computer to its full potential, avoid them all.
    - catnaroek 10y ago
      > Every abstraction has a cost somewhere. It's very simple: (0) Runtime performance degradation is unacceptable. (1) Increased compile times are annoying, but they're tolerable in exchange for more exhaustive automatic static analysis. Anything of interest that the compiler can't prove about my code, I would have to prove myself by hand anyway, which would take even more time than the slowest automated static analysis.
      - lispm 10y ago
        > Runtime performance degradation is unacceptable Requirements like these are not grounded in real software use. In economic terms: a cheaper/slower software can be acceptable over a more expensive/faster software. Example: Java-based software vs. the same written in C++. In reliability terms: a more robust / slower software can be acceptable over a more expensive/faster software. Example: Erlang-based software vs. C++ software on a network switch. And so on. Abstract/absolutist requirements like 'Runtime performance degradation is unacceptable' is not often found in actual software development/use. Software usually has a multitude of different important qualities. Raw performance is just one of these. Especially one then needs to say what performance exactly and how to measure it. Performance can be measured in many ways: throughput, latency, micro-benchmark speed, etc. etc. Optimizing one (say, throughput) then has effects on others (say, latency). To achieve faster throughput, some functionality can be affected.
      - qwertyuiop924 10y ago
        All abstractions degrade runtime performance. Even "zero cost" ones, as they get you to think in less efficient ways, about things like encapsulation, and whatnot. If runtime perf degradation is really unacceptable to you, you shouldn't be writing in functional languages, or even C. You should be writing in raw asm, as low-level as possible.
        catnaroek 10y ago
        Encapsulation is making the internal representation of abstract data types not visible to their clients. In other words, it's a discipline for writing programs. Some languages (e.g., ML) just happen to helpfully enforce that discipline for you. It has no runtime impact whatsoever.
        qwertyuiop924 10y ago
        Not true. While the various abstractions themselves may have no runtime impact, they encourage programming in ways that, while they may be good for maintainability, aren't as fast. For example, if you're using ML, you'll likely represent a list of objects (say, structures representing addresses) by establishing a type for the objects, and keeping a list of them. A C programmer might use a statically allocated array, or actually embed a pointer to the next object in the list into the struct. The C program might be less maintainable, but it would be faster because it's doing less pointer chasing. An asm programmer might optimize further. Now, this is a fairly trivial example, and not too hard for a compiler to optimize out, IIRC, but it's just an example. Other instances of this are far harder to optimize away. The further up you are from the hardware, the less aware you are of the perf tradeoffs, and the less you can do to fix it. So if you want the best perf, go for asm.

qwertyuiop924 10y ago

Okay. Go write some C, or some Asm. It might feel unpleasant to you, but if you use most other langauges, you'll be wasting too many cycles, and you won't be using that computing power for your own puposes. Don't forget to use as few abstractions as possible, and remember: every function call takes valuable time and computation.

catnaroek 10y ago
> Don't forget to use as few abstractions as possible Huh? I'm perfectly fine with abstractions. Just not with abstractions that are suboptimally designed and implemented. > Don't forget to use as few abstractions as possible Maybe you're confusing abstraction with runtime dispatch? > every function call takes valuable time and computation. Stroustrup's (whom otherwise I don't regard as a great language designer) principle applies: abstractions must elaborate to the best possibly code you would've manually written.
- qwertyuiop924 10y ago
  Every abstraction has a cost somewhere. If you want to use your computer to its full potential, avoid them all.
  - catnaroek 10y ago
    > Every abstraction has a cost somewhere. It's very simple: (0) Runtime performance degradation is unacceptable. (1) Increased compile times are annoying, but they're tolerable in exchange for more exhaustive automatic static analysis. Anything of interest that the compiler can't prove about my code, I would have to prove myself by hand anyway, which would take even more time than the slowest automated static analysis.
    - lispm 10y ago
      > Runtime performance degradation is unacceptable Requirements like these are not grounded in real software use. In economic terms: a cheaper/slower software can be acceptable over a more expensive/faster software. Example: Java-based software vs. the same written in C++. In reliability terms: a more robust / slower software can be acceptable over a more expensive/faster software. Example: Erlang-based software vs. C++ software on a network switch. And so on. Abstract/absolutist requirements like 'Runtime performance degradation is unacceptable' is not often found in actual software development/use. Software usually has a multitude of different important qualities. Raw performance is just one of these. Especially one then needs to say what performance exactly and how to measure it. Performance can be measured in many ways: throughput, latency, micro-benchmark speed, etc. etc. Optimizing one (say, throughput) then has effects on others (say, latency). To achieve faster throughput, some functionality can be affected.
    - qwertyuiop924 10y ago
      All abstractions degrade runtime performance. Even "zero cost" ones, as they get you to think in less efficient ways, about things like encapsulation, and whatnot. If runtime perf degradation is really unacceptable to you, you shouldn't be writing in functional languages, or even C. You should be writing in raw asm, as low-level as possible.
      - catnaroek 10y ago
        Encapsulation is making the internal representation of abstract data types not visible to their clients. In other words, it's a discipline for writing programs. Some languages (e.g., ML) just happen to helpfully enforce that discipline for you. It has no runtime impact whatsoever.
        qwertyuiop924 10y ago
        Not true. While the various abstractions themselves may have no runtime impact, they encourage programming in ways that, while they may be good for maintainability, aren't as fast. For example, if you're using ML, you'll likely represent a list of objects (say, structures representing addresses) by establishing a type for the objects, and keeping a list of them. A C programmer might use a statically allocated array, or actually embed a pointer to the next object in the list into the struct. The C program might be less maintainable, but it would be faster because it's doing less pointer chasing. An asm programmer might optimize further. Now, this is a fairly trivial example, and not too hard for a compiler to optimize out, IIRC, but it's just an example. Other instances of this are far harder to optimize away. The further up you are from the hardware, the less aware you are of the perf tradeoffs, and the less you can do to fix it. So if you want the best perf, go for asm.