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

linuxmemes

21272 readers
423 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

  • 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
    [–] [email protected] 41 points 4 months ago (2 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.

    [–] [email protected] 30 points 4 months ago* (last edited 4 months ago) (2 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.

    [–] [email protected] 19 points 4 months ago (3 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.

    [–] [email protected] 2 points 4 months ago

    Python is the slowest (widely used) language there is. It's not hard to be faster.

    [–] [email protected] 9 points 4 months 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.

    [–] [email protected] 11 points 4 months 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.

    [–] [email protected] 4 points 4 months ago (2 children)

    Faster, sure. Efficient, fuck no. With Java you have to run around and write ton of boiler plate code to do something simplest in nature.

    [–] [email protected] 3 points 4 months ago* (last edited 4 months ago) (1 children)

    I'm mainly talking efficiency in terms of energy use. I won't deny that some ugly decisions have been made with Java :D

    [–] [email protected] 0 points 4 months ago (1 children)

    Energy use? That's a pointless metric. If that is the goal then whole idea of desktop should be scraped. Waste of memory and hard drive space. Just imagine the amount of energy wasted on booting GUI.

    [–] [email protected] 1 points 4 months ago (1 children)

    Have you ever heard of datacenters, portable devices or climate change?

    [–] [email protected] 0 points 4 months ago

    If you want to talk about climate change then electronics is the wrong place to point the finger at. For start look at cement manufacturing. It requires huge amounts of energy to produce even though we have eco-friendly variants ready to go. And cement production amounts to 8% of all greenhouse gasses released annually.

    Hell, just ban private jets and you've offset all of the bad things datacenters ever made. Elon had 10 minute flight to avoid traffic which consumed around 300l of fuel. Royal family makes so many flights a year that you could go into the wild and eat bark until the rest of your life and you wouldn't be able to offset their footprint in thousands of lives.

    Bill Gates himself talks a lot about reducing carbon footprint we make and yet he refuses to sell his collection of airplanes. He has A COLLECTION of them.

    Using higher level language that requires more operations than assembler is not a thing to worry about when talking about climate change. Especially without taking into account how much pollution have those managed to reduce by smartly controlling irrigation and other processes.

    [–] [email protected] 9 points 4 months ago (1 children)

    Could say the same for C/C++.

    But yeah I'd like it if the features given by Lombok were standard in the language though it's not a big deal these days since adding Lombok support is very trivial.

    [–] [email protected] 3 points 4 months ago (1 children)

    You shouldn’t use Lombok, as it uses non-public internal Java APIs, which is why it breaks every release. At one point we had a bug with Lombok that only resolved if you restarted the application. Switching off of Lombok resolved the issue.

    Just switch to kotlin. You can even just use Kotlin as a library if you really want (just for POJOs), but at this point Kotlin is just better than Java in almost every way.

    [–] [email protected] 3 points 4 months ago

    I agree but I have tried like hell to get my team to use Kotlin but it's hard to convince upper management. The team is reluctant to switch as well.

    Using Lombok is the next best thing.

    Though for POJOs that are immutable you can use record classes now.

    [–] [email protected] 11 points 4 months ago (1 children)

    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.

    As someone used to embedded programming, this sounds horrific.

    [–] [email protected] 7 points 4 months ago (1 children)

    Yep. I used to code a lot in JVM languages, then started learning Rust. My initial reaction was "Why the hell does Rust have two string types?".
    Then I learned that it's for representing actual memory vs. view and what that meant. Since then I'm thinking "Why the hell do JVM languages not have two string types?".

    [–] [email protected] 2 points 4 months ago (1 children)

    I'm not a java programmer, but I think the equivalent to str would be char[]. However the ergonomics of rust for str isn't there for char[], so java devs probably use String everywhere.

    [–] [email protected] 1 points 4 months ago

    Nope, crucial difference between Java's char[] and Rust's &str is that the latter is always a pointer to an existing section of memory. When you create a char[], it allocates a new section of memory (and then you get a pointer to that).

    One thing that they might be able to do, is to optimize it in the JVM, akin to Rust's Cow.
    Basically, you could share the same section of memory between multiple String instances and only if someone writes to their instance of that String, then you copy it into new memory and do the modification there.
    Java doesn't have mutability semantics, which Rust uses for this, but I guess, with object encapsulation, they could manually implement it whenever a potentially modifying method is called...?

    [–] [email protected] 7 points 4 months ago

    At least with Java, its the over(ab)use of Reflections and stuff like dependency injection that slows things down to a crawl.