322
Software is slow because of bad design, not slow languages (www.seangoedecke.com)
submitted 2 weeks ago by to c/programming@programming.dev
124 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 2 weeks ago (5 children)

Counterpoint, I wrote a Python program that reads a load of JSON and runs regex searches over it. It was quite slow. Rewrote it in Rust as a straight 1:1 port, no algorithmic changes. 50x speedup.

I think you must have either done something very wrong or your Python program didn't really do anything other than call Python built-ins that are actually written in C.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 3 points 2 weeks ago (3 children)

    Did you use a profiler to find the bottlenecks? Did you try using cjson to speed up the json parsing? I would also avoid using the stdlib regex library too. It's probably more of a convenience/reference implementation, not something to be intended for high performance. Maybe there's a re2 wrapper for Python or a similar regex library in C with Python bindings.

    Rewriting in Rust is fine, but good Python devs know how to find bottlenecks in their software and replace them with fast implementations. I've written plenty of performant Python code, it's not very hard to profile and optimize. Usually the performant stuff is already written in C/C++ or Fortran anyway (numpy, PyQt, etc.)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 2 weeks ago (2 children)

    Did you use a profiler to find the bottlenecks?

    No. It was a simple enough program that there were no areas for improvement anyway. I also did not use a profiler for the Rust code.

    good Python devs know how to find bottlenecks in their software and replace them with fast implementations

    In my experience this is also a sweet sounding lie to make people feel ok with using Python. Yes in some case you make a big mistake and there's a large bottleneck you can easily remove... Or your program has a nice small hotspot where it spends most of its time and you can just write that bit in C++ (AI is the obvious example).

    But most programs are not like that. They're more like MS Word. Slowness is evenly distributed through the code. There is no hotspot to remove.

    As an example of this, look at Nicholas Nethercote's excellent series of blogs on making the Rust compiler faster: https://nnethercote.github.io/

    The "bottlenecks" they find result in 1% speedups.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 5 points 2 weeks ago (1 child)

    If you didn't use a profiler, then how can you be sure that the issue was Python and not something else? If the slowness really is evenly distributed through the code as you suggest, then a profiler would show that almost instantly and it's very easy to do that in Python using cProfile.

    On top of that, the Python standard library is built for convenience, not performance. The nature of it being a standard library means that the implementation has to be simple. fastregex uses LLVM and SIMD for example, that's something that's wildly impractical for the Python stdlib to support. In contrast, I have no idea what regex or JSON library you used for your Rust code, but if it were outside the stdlib, chances are high that it had much more leeway to optimize performance because it didn't have all the other maintenance obligations that stdlib code needs to support.

    All of this is just pure speculation on my part, but ultimately I'm trying to make a point that it is hard to say that the difference was caused by a language issue and not something else. There are lots of other things that could be contributing to this difference and you can't really say for sure without meaningful diagnostics.

    As an example of this, look at Nicholas Nethercote’s excellent series of blogs on making the Rust compiler faster: https://nnethercote.github.io/

    The “bottlenecks” they find result in 1% speedups.

    The kinds of software that you and I write on a daily basis is nothing compared to pieces of software that get millions of man-hours per year. Assuming you're not Linus Torvalds or Ted Ts'o hiding behind a funny alias, of course. I don't think anyone is suggesting that it's a good idea to write a compiler in Python (outside of prototyping purposes perhaps) since it's obviously not I/O bound, but if you and I are trying to optimize something we wrote ourselves, we're more likely to be in the "nice small hotspot" domain you described, rather than the 1% bottleneck speedups discussed in the link you posted.

    Very cool link though by the way, I look forward to reading as much of it as I can....

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] -3 points 2 weeks ago

    If you didn’t use a profiler, then how can you be sure that the issue was Python and not something else?

    It was a relatively simple program and I am good at programming.

    The point is, I put the same amount of effort into writing the same program in Python and Rust, and Rust was 50x faster. With AI, I don't see any reason to use Python these days anyway. I never bought the productivity arguments before (Rust is easily as productive as Python), but with AI Rust is definitely more productive than Python because of the much stronger static checks.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 2 weeks ago* (last edited 2 weeks ago)

    It wasn't a very wrong what I did in Python. I did the obvious thing. While I do not remember details, I remember it had something to do with adding items I think. But sadly I have not documented this issue, that's on me. It was only noticeable for really huge files like 50MBytes json. Edit: Most weren't this big, but it also combined over 100 Json files into one, so a search would search them all through and be able to save as a single file.

  • permalink
  • fedilink
  • source
  • parent