Great question! LLVM's design actually strives to avoid premature optimization (i.e. via a modular, "multi-phase approach" where each pass applies optimizations progressively - though it depends on the target architecture and compilation stage). This way, early passes focus on general, high-level optimizations; later ones handle more hardware-specific tuning. As for different 'flavors' of optimizers, LLVM does allow for customization via custom passes, but you're right - too much fragmentation could hurt modularity / code reuse. The shared intermediate representation (e.g. LLVM IR) ensures that improvements in one part of the pipeline benefit the entire ecosystem. At the EOD, for LLVM it's about modularity / flexibility.

Thank you! My goal is to keep things clear, informative, and fast-paced. While some of my earlier videos may not fully reflect this, I’m committed to applying this mantra to all future content :)

It's my pleasure, thank you for tuning in

This is a common challenge I often face. The audience for this video is quite diverse in terms of skill levels / YOE. This video serves as a basic introduction to Docker and Kubernetes concepts, aimed at developers who are newer to these topics and looking for a soft introduction. At the end, I clarify that Docker and Kubernetes are not an either/or choice; they’re complementary and can work together in a hybrid approach. That said, you make valid points about better comparisons. I’ll take note of them and consider creating a follow-up video focused on Docker Swarm vs. Kubernetes, and I'll incorporate the other comparisons as well. Cheers.

Trying to balance quality of videos with burnout

Pleasure is mine

I'd go with the cow here...

Aesthetically though, I'd take the dragon any day

Yes, added to my ideas list!

Not all optimizations available in Clang have a direct equivalent in GCC, but the core optimizations (i.e. the -O1, -O2, -O3 optimizations in the video) are shared between both compilers

Recursion still seems much less intuitive than a loop

@@martinnovak679 only if you have a call stack, which most functional languages like Haskell don’t have. Function calls in (GHC) Haskell are just jumps, and that’s how we work with infinite lists all the time. It’s be great to do a video on the common misconceptions programmers have about functional programming, people say so many simply wrong things with such confidence.

Isn't recursion how a spreadsheet works when evaluating the cells?

@@yancanam that should be simple reference Recursion is when function call itself (clasical example is factorial)

@@Axman6 1) you can use functional programing in languages like C# and Java where deep recursion cause stack overflow 2) i am curious how does it work without keeping track of caller state 🤔 is there some special syntax for those cases? Does compiler/interpreter recognize it threat that different? Or does it just behave like one huge block of code? Or something zotaly different?

Appreciate the comment

🚀!

That might be a reason why this video is getting quite a bit of traction lately. It hits the LLM hot topic, as well as the LMVH clothing brand 😂

@@TheCodingGopher it gotta be be interesting though if we can replace todays compiler with LLM chatgpt-like compiler that can read 'dumb human prompt' into binary executable

@@eaglemaster7 There would likely need to be a ridiculous amount of fine-tuning as it would be very error-prone. But food for thought

The difference in the shown compilation flow diagrams is partially artificial: a compiler has so many components that there are many ways to group them in an overview. Both have CPU specific optimizations (f.i. to allocate registers), but you may list them into the main optimization (there is a lot over overlap/reuse in that logic anyway) or in the specific CPU backends (which will in reality share a lot of code). So: the flow between components will be organized at bit differently, but by far most effort is put in components which exist in both compilers... in any compiler: the drawings make it look more different than it is.

An SDK implies hardware support, such as drivers and a specific buildsystem or platform. A framework implies a specific user experience, such as a React or iOS app. Both of those includes libraries, which can be loosely described as a set of functions, procedures, or programs published under a single namespace with its own memory.

You may be onto something; grateful for all the support I get ❤️

Thanks for the visit

BSON is designed for storing JSON-like documents (i.e. supports flexible data types / is storage-friendly). Protobufs focus on speed / efficiency, using a compact binary format. TL;DR: BSON is best for document storage. Protobufs is best for efficient data transfer.

@TheCodingGopher OK. Thanks!

That's interesting! Are you sure about this? Because this seems trivially fixable, due to how incredibly much more extensible LLVM (so clang/clang++ compilers) than the gnu compiler "platform", no? Judging by your comments, this seems to be an area of low hanging fruit for contributions?

​@@simonfarre4907 The problem that I encountered is that the LLVM developers community is highly reluctant to introduce target dependent variations to the code that is not part of specific backends. It's understandable because the front end is supposed to generate the same IR code, while applying generic optimizations, regardless of target. Specific backends are responsible for target dependent optimizations, and to translate the IR code into the targeted assembly code. However, in practice the generic code is highly influenced by the main targets capabilities, namely the x86-64 and the ARM64, and many optimizations that should technically be considered as target specific are coded as generic just because (most?) targets will support them. What happens is that simpler targets such as 8 bit or 16 bit processors can't efficiently translate some pieces of the IR to their ISAs because some instructions are just missing, the most flagrant example is lack of multiple shift instructions. You are absolutely right that fixing this should be easy. In fact, my code submissions were not complicated at all, as they mostly consisted on skipping generic code transformations that would result in multiple shifts, based on a compiler command option, which also could be made default depending on architecture. This worked fine as per my tests on the AVR and MSP430 targets, and it was not strictly target specific because it would apply to any architectures that do not support multiple shifts. However, since this involved parametrising the generic LLVM transformations, it was rejected. As an alternative, I was told to "reverse" the already applied optimisations to the IR code during the target specific passes. I actually spend some time looking at it, but found that it was very difficult or required a big amount of code. The reason is that LLVM will apply several code transformations in a row, one over another, until no further transformations are possible. This often creates IR code that is very hard or impossible to "reverse" to the original state. In this case, you may end with parts of IR code making heavy use of multiple shifts that are introduced by generic optimizations, and there's no way to figure out what to do to remove them. This, while just by skipping the transformations that created the shifts in the first place, would just enable the backend or even the generic optimizer itself, to apply alternative optimizations that could be actually translated into efficient target assembly code. (I can go to further detail and examples if you are really interested) At the end, I gave up with trying to "reverse" the undesired "optimizations", not without some frustration as my solution to the problem was already implemented and working, just not acceptable by the LLVM community. So as said, the LLVM complier still lacks /significantly/ behind GCC when compiling for small targets, which is the reason it is not generally used for them.

​​@@simonfarre4907open source spaces are very political. Even if the change is trivial, if it touches something that is "core" to the project, it will inevitably meet a lot of resistance.

@@dancom6030 Sad but true. No wonder why corporations tend to move faster. They are far less allergic to change

@dancom6030 I wouldn't say they are very political, I've contributed to a few different open source projects, one has to be mindful (and respectful! Incredibly important!) of a whole host of things. May be legacy reasons why things are not accepted or not a stated goal etc. I think painting it with a broad brush (though that may not have been your intention) and saying it is "very political" I think is not fair, necessarily even though, of course, those projects exist as well. I should probably have skipped calling it trivially fixable as that probably gave my question the wrong impression.

🙏

Do you mean doesn't dictate?

@@dancom6030 sorry, I meant "does not". My first post threw an error, so I had to retype and post it, but I made a mistake

@@ivanmaglica264 you're all good, my man. Stuff like this happens all the time. I just wanted to clarify.

Not true. The only reason GCC can compile proprietary programs is because they added a special exception. I think the Ada commercial compiler for example have a GPL license but without the exception so you cannot compile proprietary programs with it.

@Nothing_serious nothing in the GPL prohibits compiling proprietary code. I'd like to see a source on that claim.

Good, though your voice sounds pretty clear and good already to me at least. Thanks for the video.

@@lelsewherelelsewhere9435 Thanks for watching + the feedback!

Thanks for the comment! Follow-up video on SSA incoming

@@TheCodingGopher Excellent!

🚀

LLVM IR is a low-level IR used across many compilers for optimization / JIT compilation. GIMPLE is a simplified IR that is specific to GCC - mainly for breaking down complex code for easier optimization. LLVM IR targets multiple platforms; GIMPLE mainly serves GCC’s internal needs. Hope that makes sense.