It is probably very domain specific. In robotics for example everything is a zero sum game: CPU, memory bandwidth, GPU, battery life etc ... So it is really a topic, probably true for anything embedded actually. Some other offline applications: HFT, Telco etc..
I wish the GUI apps devs respect more the laptop resources they are running on, don't get me started on the 4 instances of chrome I need to run just for discord, signal etc ...
GUI engine developers need to trade EVERYTHING for execution time, otherwise JavaScript would simply not be fast enough to handle modern applications.
If your device has enough resources to power V8, modern GUIs are certainly very pleasant and snappier than a more minimal GUI like HN. Otherwise they are horrendous and very laggy.
I don't know if you got my point. Starting a multi gigabyte machinery for the web just for a chatting app is pure insanity sorry. It will be slow to start, slow to react and a battery hog vs a comparable quality QT app. The worse part is usually people use the web stack for desktop app because they don't want to bother giving a good experience to the people on their own native platform.
I do wish more things were written in Qt, but Qt Widgets is very unpleasant to work in for a modern dynamic app.
QtQuick/QML/JS is very pleasant and I do wish more people would use it, but from I've seen it's 25-50% the resource use of electron, not some multi-order-of-maginute improvement, do I understand why many people still prefer electron for portability in this case.
When writing code for end-user applications, I think it's mostly true. When it's writing code for a database engine, a game engine, a 3d renderer, or anything else that involves heavy data processing, optimization is the core "thing" often and it might not even be a good enough solution without it. Although, a lot of time even then C++ is good enough even then when picking reasonable data structures to represent the data.
Definitely need to optimize a bit for games and huge scale web apps. We've been finding big optimizations in our app recently. App works without them because we can scale horizontally but cutting CPU usage by 30% by eliminating redundant work and reducing copies of big objects? Why wouldn't we want to do that? This isn't even fancy algorithm stuff, mostly just shoddy initial implementations by 100s of eng working on a codebase over 7 years (not even that old). Stuff like that creeps in.
Then why are you using C++? Java/C#/Go are already fast enough for general application development. Why would you accept the footguns if not for performance?
In my case, about 5% of our code needs the power of C++. Mixing C++ with any other language is a huge pain. Even if we were using C, mixing C with anything else is a pain, and that's despite being the most supported FFI.
Note that we started our project before Rust was an option. These days I would certainly look at rust to see if that would cover our 5% of the needs but now we have a lot of C++ and mixing rust with C++ is a pain.
I agree that mixing languages adds complexity. And I say that as someone who routinely does it, because many times it's better to reuse a mature/audited component than rewrite it from scratch.
> Mixing C++ with any other language is a huge pain.
It is less pain than for most other languages, except for C. The pain is in exposing a C API for your C++ code. Then you build a library and you're set - because basically every language has the ability to call C code. Python, Rust, Java, etc. etc.
Well once you have a C API, it is relatively easy to call it from any other language.
The painful part is to have to go through a C API (modern languages can express much richer APIs and of course there are different constraints on the different runtimes, e.g. GC).
The annoying part is that each language adds overhead (its runtime). I wouldn't call it painful (I don't have much to do about it), I say "annoying" just because I would rather minimise the amount of code I ship.
True, but moving from a list of unique polymorphic pointers to a std::variant gains you at least a 2-3x speed up in terms of TLB and cacheline locality. From there, swapping to SOA will net you another 4-8x, so you're looking at nearly 25x improvement by going data first. That may not matter in the unique case of say, games, where rendering a million entities will dwarf the cost of SIMD processing a million entities, but in something like numerical simulations (fluids) or quant it will be warmly welcomed
If you take the linked benchmark and use the latest compiler version, the std::variant version is faster. The annoying thing about std::variant (and with some other features of modern C++) is that it generates a bunch of code that the compiler has to optimize away.
Somehow and for some reason rust enums don’t have this problem and are far more ergonomic and easier to work with (not to mention compile times are amazing). I don’t know exactly why it’s better to have it as a first class language primitive and why the compiler has such a problem with std::visit, but clearly c++ meta programming slows down things in a super linear way such that the compiler has problems both from code gen and then optimization.
That, and it frees the compiler from reasoning about virtual inlining, and that the std::variant approach can pack potentially more than one object into a single cacheline. TLBs also work with 4096 byte pages, so 32 polymorphic 128 byte entities may (at the absolute worst case) use 32 distinct pages which requires 32 TLB virtual translations, while the std::variant one uses 1.
The next step of going SOA benefits from all of the above, it just further unlocks you packed quad and oct instructions (AVX256 and 512 depending if you buy AMD or not).
In (soft) realtime audio programming, your audio callback might only have a time budget of 1.3 milliseconds. Everytime you exceed that limit, you'll hear a dropout. That's when you'll start to optimize the hell out of your program :)
And the code might be faster, too, like in that 2005 series of articles by Raymond Chen and Rico Mariani (in which one of them wrote a program in C++ and the other wrote the same program in C#).
I started writing a [CPU-only] 3-D rendering library in C++ recently, after having written the equivalent in C as a proof-of-concept and an experiment. The reason I decided to write it in C++ after C, is not only because I wanted to tap into meta-programming which is facilitated much better with C++, or that I wanted niceties like procedure overloading, but because some things with C or C++ aren't automagically optimised -- like if you want to leverage struct-of-array (SoA) memory layouts because it allows fewer SIMD (AVX in my case) instructions in the rendering pipeline. You do _not_ get that "for free" just writing a single procedure in C++, much less with C. Both languages are layout-sensitive, I mean this is in part what gives you the speed -- optimising with memory layout for cache locality etc. But you have to do it yourself. Meaning that if you need array-of-struct (AoS) or in fact don't know which path the CPU would prefer, there's no other way than roll up your sleeves and one way or another implement both.
The kicker is, in my case I chose C++ because templates allow me to reuse most of the code in the rendering pipeline _regardless_ of whether I go for AoS or SoA layout. I leverage operator overloading to do vector by matrix multiplication which is implemented in both variants. I do have to specify the desired variant during building, but I've profiled and for Intel x86 AVX in my case SoA is something like twice as efficient because I process ("shade") 8 vertices with 4-5 instructions instead of 1 vertex at a time (still shaded with vectorisation -- just "rotated", i.e in the pipeline axis and not vertex buffer axis).
TL;DR; C++ gives you plenty fast by default, but it's not always enough. The difference between 5 and 15 frames per second, well, makes all the difference -- our eyes are only fooled once the frames-per-second rate goes sufficiently up, anything below an acceptable threshold and it's completely different experience. You then either sacrifice resolution or level of detail etc, or decide to squeeze more from the language by helping the compiler.
People please, an LLM is just a vector database that spits out statistically viable answers which highly depend on its training material. There's no real "intelligence" involved.
Embedding vectors assign semantic features to syntactical structures of the vector space. Operations on these syntactical structures allow the program to engage with semantic features of program state directly, leveraging the meaning of program state to alter its execution. Intelligence is leveraging information/experience to achieve one's ends. Manipulating meaning through embedding vectors in service to answering prompts is an example of that.
Intelligence is the ability to predict. To pretend that only we can do it, is silly. I mean read the article, and see what AI is doing to the math community.
I can't explain how the bunch of atoms inside my skull interact to produce me. If I can't explain that, I don't have a good grounding to explain why a bunch of atoms in a data center can't make something like me. That's my point.
He talks about applications he generated without specifying what they are or do. Does he really believe everybody is going to generate their own text editor, paint program, file explorer or graphical windowing environment with A.I. just because they can?
I believe the author is misguided about A.I.'s capabilities just like many analysts and investors are.
A.I. (or should I say LLMs) is useful for specific problems but contrary to its name it has no "intelligence."
He's talked about this before. I don't remember exactly what those apps were, but they sounded like reasonable tools one would want. Thomas is a competent guy, but I think he's vastly overestimating the agency and competence of normal people. They don't have a product-oriented mindset; they might get annoyed by a bug or slow loading times, but they're not good at coming up with features or entire apps that they would want to use. Even if there are people who can do this, they don't want to spend their weekend thinking about a detailed spec for an app they want. They really just want to consume.
People could already vibe-code simple products today, but there's hardly any non-programmers that do. This is even true for businesses. For the last year people have been boasting about canceling their SaaS products, but nothing seems to have changed. SaaS stocks got hit by the ai hysteria in January, but many are back to previous levels and some even higher. There's an Indiehacker on Twitter whose product is a simple stage timer. It's not a hardware product. It's literally just the software for a stage timer. One would expect his business to have died already, but he's apparently doing completely fine.
I often wonder if our brains are capable of understanding the Universe around us. Our brains were made to help us survive on this planet, not to understand the laws that govern our Universe.
The story that haunts me is the one where scientists attempted to understand how the brain of a simple organism worked. It only had 40 neurons yet they were unable to unravel the mystery on how it functioned.
I think about this sometimes too but I do believe we have at least for a fact described some aspects of the universe (speed of light for example) so we are at least capable of doing that, if not understanding much of the rest too.
Soon the musical chairs game will come to a screeching halt. Interest rates are skyrocketing and not even a Presidential decree will make them come down.
To me it's clear the U.S. is heading for a default. Instead of toning down the deficit Trump made it much worse with his "Big Beautiful Bill" and is bankrupting the country.
What happens next is anyone's guess, but it won't be pretty.
Elon lets out a fart and everyone's running after it. This is another misguided attempt to pump-up their share price or give clueless investors the feeling that Google is leading the A.I. pack.
Orbital data centers are a stupid idea conjured up by Musk when he was taking mescaline or ketamine. Anyone with half a brain knows this doesn't make sense.
This definitely feels like Hyperloop, but for data centers instead - a really cool idea that falls apart the moment it meets contact with reality. The most bizarre thing is how any of this and the Hyperloop got any amount of funding and development beyond just an initial feasibility report.
The idea of "orbital data centers" was conjured up merely to justify Musk's merging of xAI and SpaceX. I thought that was obvious to everyone but apparently there are still plenty of little-minded people that see Musk as some sort of God and suck up every lie he shoots from the hip.
Musk is merging all of his failed enterprises (Tesla, xAI, Boring Company, Twitter) into the one that has been relatively succesful, SpaceX. Mostly because of Starlink, the idea for which he himself didn't even come up with and was initially seen as an afterthought to get some revenue.
Solving climate change by mostly eliminating fossil fuel use, antibiotic resistant bacteria with new antibiotics, eliminating risks of pandemics generated from meat agriculture, creating novel antimycotics, curing various cancers, and reversing shrinking peace, freedom, privacy, and middle classes around the world to name a few.
> The satellite, dubbed MVP, is about the size of a refrigerator. Inside, it has four of Google’s custom TPU AI accelerators, which are used to train AI models and run inference to generate tokens for AI workloads.
Yeah, this is a science-fair project. They threw some cards in a box and are paying someone to launch it to generate idiotic news articles.
Europe is mostly interested in supporting its car industry. But soon they won't have to worry about that either.
There are no companies in Europe designing high-end semiconductors because the wages are much lower than in the U.S. The best European talent is moving Stateside and raking in ten times what they can get at home without having to build up seniority first.
There's certainly semiconductor design capacity in Europe, but it's mostly geared towards low-end semiconductors, like the ones used in automotive and industrial. NXP and ST are designing ICs in Europe but relatively commodity stuff like low-end MCUs and motor controllers.
The problem with the Blackbird were its two engines. If the airplane had one centrally located engine it would've been safe to fly but with two engines even a small "hiccup" in one engine could lead to a thrust difference which would tear the airplane apart in mid-flight.
> “The airplane yawed to the right so far and so fast, it felt like it was going sideways!” said Osterheld. The SR-71’s right engine had just experienced an “intake unstart.”
Doesnt seem like a "hiccup" would "tear apart" if one engine failing entirely (intake unstart) didn't.
Europe is continually complaining about its dependency on Chinese steel, cars, electronics and semiconductors yet their carmakers are buying cheap Chinese steel instead of European steel and European semiconductor manufacturers are preferring cheap Chinese semiconductor equipment over ASML gear.
The European Commission wanted to put hefty tariffs on dumped Chinese steel but the carmakers sought an exemption. They don't care about European sovereignty, only about their profits. Penny wise and pound foolish. I doubt there will still be a European car industry in two decades or so.
> Europe is continually complaining about its dependency on Chinese steel, cars, electronics and semiconductors yet their carmakers are buying cheap Chinese steel instead of European steel and European semiconductor manufacturers are preferring cheap Chinese semiconductor equipment over ASML gear.
You clearly have no idea about the value creation chain. Steel is a commodity, why shoot yourself into the foot by buying expensive one. And semiconductors are not commodities.
But I guess this logic only makes sense to a country that insists on using its own overpriced steel to save a couple jobs.
How are you gonna fight a war when you can't make the steel for your bullets and artillery grenades? Yes, that's the scary logic we need to take into account these days.
Steel is not a commodity, it's a basic ingredient in any industrial base.
reply