this post was submitted on 14 Jul 2024
477 points (96.7% liked)

linuxmemes

20482 readers
687 users here now

I use Arch btw


Sister communities:

Community rules

  1. Follow the site-wide rules and code of conduct
  2. Be civil
  3. Post Linux-related content
  4. No recent reposts

Please report posts and comments that break these rules!

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] Urist@lemmy.ml 40 points 1 month ago (18 children)

Many of these have C-bindings for their libraries, which means that slowness is caused by bad code (such as making a for loop with a C-call for each iteration instead of once for the whole loop).

I am no coder, but it is my experience that bad code can be slow regardless of language used.

[–] Ephera@lemmy.ml 30 points 1 month ago* (last edited 1 month ago) (16 children)

Bad code can certainly be part of it. The average skill level of those coding C/C++/Rust tends to be higher. And modern programs typically use hundreds of libraries, so even if your own code is immaculate, not all of your dependencies will be.

But there's other reasons, too:

  • Python, Java etc. execute their compiler/interpreter while the program is running.
  • CLIs are magnitudes slower, because these languages require a runtime to be launched before executing the CLI logic.
  • GUIs and simulations stutter around, because these languages use garbage collection for memory management.
  • And then just death by a thousand paper cuts. For example, when iterating over text, you can't tell it to just give you a view/pointer into the existing memory of the text. Instead, it copies each snippet of text you want to process into new memory.
    And when working with multiple threads in Java, it is considered best practice to always clone memory of basically anything you touch. Like, that's good code and its performance will be mediocre. Also, you better don't think about using multiple threads in Python+JS. For those two, even parallelism was an afterthought.

Well, and then all of the above feeds back into all the libraries not being performant. There's no chance to use the languages for performance-critical stuff, so no one bothers optimizing the libraries.

[–] UnfortunateShort@lemmy.world 19 points 1 month ago (11 children)

Java is still significantly faster and more efficient than Python tho - because it has ahead-of-time optimizations and is not executing plain text.

[–] Ptsf@lemmy.world 9 points 1 month ago (1 children)

Idk numpy go brrrrrrrrrr. I think it's more just the right tool for the right job. Most languages have areas they excel at, and areas where they're weaker, siloing yourself into one and thinking it's faster for every implementation seems short sighted.

[–] UnfortunateShort@lemmy.world 11 points 1 month ago

At it's heart, numpy is C tho. That's exactly what I'm talking about. Python is amazing glue code. It makes this fast code more useful by wrapping it in simple(r) scripts and classes.

load more comments (9 replies)
load more comments (13 replies)
load more comments (14 replies)