8 ms·

Assembly is faster and safer than rust. Rust is a fad it will fad.

by zgs 5y ago

frozenport 5y ago
also ++C is faster
- zarzavat 5y ago
  Only C++ programmers will appreciate this joke.
- savolai 5y ago
  Thank you for laughter.
- willbudd 5y ago
  You jest, but I always found it puzzling that there was a time (supposedly?) that compilers were dumb enough to assemble ++c and c++ differently in cases where they simply occur as stand-alone expressions, despite their obvious semantic equivalence. Even stranger: people that insist on writing their (loops; like; ++this) in 2021 as if doing so is in any way superior or something.
  - vbezhenar 5y ago
    Optimizing integer increment might be easy. Hard thing is optimizing overloaded increment operator. ++c is naturally faster, because it does not have to make a copy of its previous value. Especially if that operator implementation is inside another library. So it makes sense to use fast-by-default approach.
    - willbudd 5y ago
      Yeah, I should have specified that I was referring to plain-old-data types such as integers. Custom objects overloading their operators certainly allow any number of differentiated rabbit holes to be dug.
  - deleted 5y ago
    [deleted]
  - jcelerier 5y ago
    With complex iterator types that carry additional state themselves (for example think iterators to sparse data or generators), it definitely makes a difference
    - makapuf 5y ago
      a++; means do nothing then increment a, ++a means increment a then do nothing, what should be the difference? (Of course you can define operator++ to format the hard drive. )
      - IcePic 5y ago
        If you have a single-pass compiler (for speed) then it will not know on pass #2 that the old value is to be used for something or not and can drop it. In a single-pass run, you must generate code to keep the previous value in case the line actually was foo = ++a; or foo = a++; so that foo gets the pre-inc or post-inc value. The small part that creates the code for the small "a++" part of the line will then produce a dead store of the pre-inc value, and no 2nd pass will remove it.
      - ohgodplsno 5y ago
        Allow me introduce operator overloading, where I have suddenly defined a ++ operator on my god object that contains a 50MB pool. This operator increments a single field in it, and I really need it because I do it so often. ++godobject will simply increment that value. godobject++ will make a copy of that object, returning it to you along with allocating another 50MB pool, purely to increment the value.
        makapuf 5y ago
        That's what I meant with operator++ being redefined to do anything.
        jcelerier 5y ago
        but when you write generic algorithms (as you should), you don't know beforehand with which "operator++" your a will be called. So you have to go for the one which will give the best performance.
Dylan16807 5y ago
What measure of safety has assembly basically ever win?
- vbezhenar 5y ago
  There's no undefined behaviour in assembly language.
  - anyfoo 5y ago
    I invite you to search the ARM reference manual (the so called "ARM ARM") for the terms UNKNOWN and UNPREDICTABLE. There is also actually UNDEFINED, but in the context of ARM it means that a specific exception happens, so it's pretty much the most PREDICTABLE of the bunch.
    - nereye 5y ago
      The old VLSI Technology Inc (later Philips, now NXP) reference manuals for one of the first ARM processors (the one used in the Acorn Archimedes 305, 310) mentioned that the algorithm used for cache eviction was not something relatively predictable like LIFO or FIFO but essentially random. Which in theory means that if you were 'unlucky' then your program would run slower than for a luckier person etc.
      - Dylan16807 5y ago
        Ha. Though if you're seeing a persistent difference over time, thousands and millions of evictions, your luck is already so immaculately bad that you should expect the power to go out every time you try to run a program.
  - tlamponi 5y ago
    As Computer Engineer: oh well, do I have bad news for you ;-) Quite a few processors have some undefined behavior, some instructions flags are just not specified, and no not just "this is reserved and must be zero", that would be Ok. The result of the `bsf` or `bsr` instructions on the 0 value And please, don't look too much at the FPU either or it may do some random stuff and jump at you.
tlamponi 5y ago
Yeah, the language that: - has been around stable for over 6 years and was already somewhat popular years before that - is the first real contender to C in the Linux kernel, with support from its BDFL and a lot of work going on, and well those devs know a bit more of pain points in complex systems that need to go fast. - is used in of the major Browsers while the most popular one is contemplating starting to use it - allows refactoring and cleaning up code so nicely, it's just marvellous if one actually worked on big code bases previously to rust, as either one had ten static checkers and three times the amount of CI pipelines as required bolted on, or just risk quite a bit every time something was touched. - deep and mature integration of tests and docs and doc-test (those are damn nice) - want me to continue? I got a few more points surely is a fad ;-) Look, you do not need to use Rust if you do not want too, but living in denial about that Rust has seen a good rate of adoption and that it also has its uses as valid Language to do stuff nowadays, is just not a good thing to do mentally nor socially.

Assembly is faster and safer than rust. Rust is a fad it will fad.

by zgs 5y ago

Assembly is faster and safer than rust. Rust is a fad it will fad.

frozenport 5y ago

also ++C is faster

zarzavat 5y ago
Only C++ programmers will appreciate this joke.
savolai 5y ago
Thank you for laughter.
willbudd 5y ago
You jest, but I always found it puzzling that there was a time (supposedly?) that compilers were dumb enough to assemble ++c and c++ differently in cases where they simply occur as stand-alone expressions, despite their obvious semantic equivalence. Even stranger: people that insist on writing their (loops; like; ++this) in 2021 as if doing so is in any way superior or something.
- vbezhenar 5y ago
  Optimizing integer increment might be easy. Hard thing is optimizing overloaded increment operator. ++c is naturally faster, because it does not have to make a copy of its previous value. Especially if that operator implementation is inside another library. So it makes sense to use fast-by-default approach.
  - willbudd 5y ago
    Yeah, I should have specified that I was referring to plain-old-data types such as integers. Custom objects overloading their operators certainly allow any number of differentiated rabbit holes to be dug.
- deleted 5y ago
  [deleted]
- jcelerier 5y ago
  With complex iterator types that carry additional state themselves (for example think iterators to sparse data or generators), it definitely makes a difference
  - makapuf 5y ago
    a++; means do nothing then increment a, ++a means increment a then do nothing, what should be the difference? (Of course you can define operator++ to format the hard drive. )
    - IcePic 5y ago
      If you have a single-pass compiler (for speed) then it will not know on pass #2 that the old value is to be used for something or not and can drop it. In a single-pass run, you must generate code to keep the previous value in case the line actually was foo = ++a; or foo = a++; so that foo gets the pre-inc or post-inc value. The small part that creates the code for the small "a++" part of the line will then produce a dead store of the pre-inc value, and no 2nd pass will remove it.
    - ohgodplsno 5y ago
      Allow me introduce operator overloading, where I have suddenly defined a ++ operator on my god object that contains a 50MB pool. This operator increments a single field in it, and I really need it because I do it so often. ++godobject will simply increment that value. godobject++ will make a copy of that object, returning it to you along with allocating another 50MB pool, purely to increment the value.
      - makapuf 5y ago
        That's what I meant with operator++ being redefined to do anything.
        jcelerier 5y ago
        but when you write generic algorithms (as you should), you don't know beforehand with which "operator++" your a will be called. So you have to go for the one which will give the best performance.

Dylan16807 5y ago

What measure of safety has assembly basically ever win?

vbezhenar 5y ago
There's no undefined behaviour in assembly language.
- anyfoo 5y ago
  I invite you to search the ARM reference manual (the so called "ARM ARM") for the terms UNKNOWN and UNPREDICTABLE. There is also actually UNDEFINED, but in the context of ARM it means that a specific exception happens, so it's pretty much the most PREDICTABLE of the bunch.
  - nereye 5y ago
    The old VLSI Technology Inc (later Philips, now NXP) reference manuals for one of the first ARM processors (the one used in the Acorn Archimedes 305, 310) mentioned that the algorithm used for cache eviction was not something relatively predictable like LIFO or FIFO but essentially random. Which in theory means that if you were 'unlucky' then your program would run slower than for a luckier person etc.
    - Dylan16807 5y ago
      Ha. Though if you're seeing a persistent difference over time, thousands and millions of evictions, your luck is already so immaculately bad that you should expect the power to go out every time you try to run a program.
- tlamponi 5y ago
  As Computer Engineer: oh well, do I have bad news for you ;-) Quite a few processors have some undefined behavior, some instructions flags are just not specified, and no not just "this is reserved and must be zero", that would be Ok. The result of the `bsf` or `bsr` instructions on the 0 value And please, don't look too much at the FPU either or it may do some random stuff and jump at you.

tlamponi 5y ago

Yeah, the language that: - has been around stable for over 6 years and was already somewhat popular years before that - is the first real contender to C in the Linux kernel, with support from its BDFL and a lot of work going on, and well those devs know a bit more of pain points in complex systems that need to go fast. - is used in of the major Browsers while the most popular one is contemplating starting to use it - allows refactoring and cleaning up code so nicely, it's just marvellous if one actually worked on big code bases previously to rust, as either one had ten static checkers and three times the amount of CI pipelines as required bolted on, or just risk quite a bit every time something was touched. - deep and mature integration of tests and docs and doc-test (those are damn nice) - want me to continue? I got a few more points surely is a fad ;-) Look, you do not need to use Rust if you do not want too, but living in denial about that Rust has seen a good rate of adoption and that it also has its uses as valid Language to do stuff nowadays, is just not a good thing to do mentally nor socially.