3 ms·

"faster than C" - TBH, I kinda dread these clickbait posts because faster than C doesn't matter in 2023, where speed is dictated by multi-core and GPU. Python

by asah 3y ago

"faster than C" - TBH, I kinda dread these clickbait posts because faster than C doesn't matter in 2023, where speed is dictated by multi-core and GPU. Python is abysmally slow, but provides access to GPU and (soon) multi-core.

deleted 3y ago
[deleted]
mgaunard 3y ago
Without control, power is nothing. C gives you control.
- ahoka 3y ago
  It doesn’t though.
  - dvhh 3y ago
    Well it gives you the belief that you are in control, because undefined behavior are implementation dependent, and that "modern processor" not only predict, but also can decide of the execution order of your nice code. That said, save for the Basic language, C is probably the lowest common denominator for system programming and for all the programming languages to interface with each other (with relative efficiency).
    - ahoka 3y ago
      Every time you would have direct control over the hardware it’s considered UB and the compiler throws the code away.
maccard 3y ago
Did you see the post yesterday about the people who deployed a kubernetes cluster because it took 24 hours to parse a few GB of CSVs in JavaScript?
- nottheengineer 3y ago
  I'd like to read that but can't seem to find it. Do you remember the title or have a link?
  - maccard 3y ago
    Yep! I wish I was joking, but https://news.ycombinator.com/item?id=37415812 https://news.ycombinator.com/item?id=37415812
    - nottheengineer 3y ago
      The best stories are always those that end with a rewrite in rust. This one is no exception, thanks for sharing.
dailykoder 3y ago
uhm, isn't the CPU access in python written in C (mostly)?
astrobe_ 3y ago
One should remember that not all problems can be solve faster with concurrency - not all problems are "embarrassingly parallel". Besides, even when they are, one gets diminishing returns by adding more cores. Raw performance on single core is still relevant. That said, support for concurrency is relevant but more for "masking" I/O latency than for MIPS, a problem which is apparently more common. For a language created after 2010, it is nearly a fault not to have something less primitive than threads to handle concurrency. It is like still manually managing memory manually like C also does. I agree that "faster than C" claims too often hides some kind of cheating. But we have HN "reviewers" for that ;-).

by asah 3y ago

deleted 3y ago

[deleted]

mgaunard 3y ago

Without control, power is nothing. C gives you control.

ahoka 3y ago
It doesn’t though.
- dvhh 3y ago
  Well it gives you the belief that you are in control, because undefined behavior are implementation dependent, and that "modern processor" not only predict, but also can decide of the execution order of your nice code. That said, save for the Basic language, C is probably the lowest common denominator for system programming and for all the programming languages to interface with each other (with relative efficiency).
  - ahoka 3y ago
    Every time you would have direct control over the hardware it’s considered UB and the compiler throws the code away.

maccard 3y ago

Did you see the post yesterday about the people who deployed a kubernetes cluster because it took 24 hours to parse a few GB of CSVs in JavaScript?

nottheengineer 3y ago
I'd like to read that but can't seem to find it. Do you remember the title or have a link?
- maccard 3y ago
  Yep! I wish I was joking, but https://news.ycombinator.com/item?id=37415812 https://news.ycombinator.com/item?id=37415812
  - nottheengineer 3y ago
    The best stories are always those that end with a rewrite in rust. This one is no exception, thanks for sharing.

dailykoder 3y ago

uhm, isn't the CPU access in python written in C (mostly)?

astrobe_ 3y ago

One should remember that not all problems can be solve faster with concurrency - not all problems are "embarrassingly parallel". Besides, even when they are, one gets diminishing returns by adding more cores. Raw performance on single core is still relevant. That said, support for concurrency is relevant but more for "masking" I/O latency than for MIPS, a problem which is apparently more common. For a language created after 2010, it is nearly a fault not to have something less primitive than threads to handle concurrency. It is like still manually managing memory manually like C also does. I agree that "faster than C" claims too often hides some kind of cheating. But we have HN "reviewers" for that ;-).