this post was submitted on 21 Dec 2024
36 points (100.0% liked)

Programming

17668 readers
132 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 2 years ago
MODERATORS
top 6 comments
sorted by: hot top controversial new old
[–] fubo 18 points 2 days ago
  • The compiler hates you
  • The compiler sees nothing wrong with your code and is just giving error messages to look busy
  • The compiler was written by a maniac with a semicolon fixation
  • The compiler could optimize your code, but it's just not feeling it today
  • The compiler wonders why you can't match braces right like your brother does
  • The compiler had a torrid affair with a Perl interpreter in 2006
  • The compiler likes big butts and cannot lie
  • The compiler wants to grow up to be an IDE but hasn't told its parents they need to send it to GUI school yet
  • The compiler reads Nazis on Twitter but only to make fun of them
  • The compiler works for the Servants of Cthulhu
[–] [email protected] 13 points 2 days ago (1 children)

Nice article. For the optimization related ones there’s a good rule of thumb: it’s not an optimization if you don’t measure an improvement.

[–] fulg 9 points 2 days ago (1 children)

it’s not an optimization if you don’t measure an improvement.

This, so much. I often see this at work, theories about this and that being slow, or how something new « should » be better. As the resident code elder I often get to reply « why don’t you measure and find out »…

For some reason it seems nobody uses sampling profilers anymore, those tell you exactly where the time is spent, you don’t have to guess from a trace. Optimizing code is kind of a lost art.

Sometimes I wish compilers were better at data cache optimization, I work with C++ all the time but all of it needs to be done by hand (for example SoA vs AoS…). On the upside, I kind of have a good job security, at least until I retire.

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

I hate when coworkers tell we should do thing in a particular way because it’s ”better”. We try the thing and there’s no measurable difference. Well, it was a good idea in their mind, so it must be an improvement. Therefore, they insist it should be kept, even if it makes the code extra convoluted for no reason at all.

And yes. Profiling is great. Often it is a surprise where most time is spent. Today there’s few excuses not to profile since most IDEs have good enough profiler included.

[–] [email protected] 8 points 2 days ago* (last edited 2 days ago)

Now, because this article got a little long, as per a friend's suggestion, here's a table of contents:

Optimization gives us optimal programs

Branch weights and the CPU's branch predictor

-O3 produces much faster code than -O2

Javascript interpreters JIT at runtime because they don't know which paths are hot ahead of time

If you have a compiler, you don't need an interpreter

The middle-end is target/platform-independent

The compiler optimizes for data locality

-O0 gives you fast compilation

Templates are slow to compile

Separate compilation is always worth it

Why does link-time optimization (LTO) happen at link-time?

Inlining is useful primarily because it eliminates a call instruction

The role of the inline keyword

The best production compiler to study is LLVM

Undefined behavior only enables optimizations

The compiler can "simply" define undefined behavior 99% correctness rate is ok

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

The best production compiler to study is LLVM

Look, I love LLVM!39 In many ways, it's pretty educational. But it's a monstrosity! That's because LLVM is applied to so many use cases. LLVM is used from embedded systems to Google's data centers, from JIT compilers to aggressive high-performance scenarios, and from Zig to Rust to .

This seems like a good time to point out that even Zig has run into problems with LLVM. Its limitations are significant contributors to the removal of async from the language.