If your problem is "speeding up X", one of, if not the first question you should ask is: "how fast can X be"?
If you don't know, find out, because maybe X is already as fast as it can be, and there is nothing to speed up.
Sure, the OP just looks around and sees that others are faster, and they want to be as fast as they are.
That's one way to go. But if all others are only 1% as fast as _they should be_, then...
- either you have fundamentally misunderstood the problem and the answer to "how fast can X be?" (maybe its not as fast as you thought for reasons worth learning)
- what everyone else is doing is not the right way to make X as fast as X can be
The value in having a model of your problem is not the model, but rather what you can learn from it.
You can optimize "what an application does", but if what it does is the wrong thing to do, that's not going to get you close to what the performance of that application should be.
Sure, its more complex than that, and an accurate model would be more complex as well.
But hey, doing science[0] is hard, better not be scientific instead /s
[1] science as in the scientific method: model->hypothesis->test , improve model->iterate. In contrast to the "shoot gun", or like the blog author called it, "whack-a-mole" method: try many things, be grateful if one sticks, no ragrets. /s
Your network links supports certain throughput and latencies depending on the packet sizes. Your vendor should tell you what these are, and provide you with benchmarks to reproduce their claims (OSU reproduces these for, e.g., MPI).
The network card also has hardware limits in the BW that it can handle, its latency. It is connected with the CPU via PCI-e usually, which has also latency and bandwidths, etc.
All this go to the CPU, which has latencies and BW from the different caches and DRAM, etc.
So you should be able to model what's the theoretical maximum of request that the network can handle, and then the network interface, the PCI-e bus, etc. up to DRAM.
The amount that they can handle differs, so the bottleneck is going to be the slowest part of the chain.
For example, as an extremely simplified example, say you have a 100 GB/s network, connected to a network adapter that can handle 200GB/s, connected with PCI-e 3 to the CPU at 12GB/S, which is connected with DRAM at 200GB/s.
If each request has to receive or send 1 GB, then you can at most handle 12 req/s because that's all what your PCI-e bus can support.
If you are then delivering 1 reqs/s then either your "model" is wrong, or your app is poorly implemented.
If you are then delivering 11 req/s, then either your "model" is wrong, or your app is well implemented.
But if you are far away from your model, e.g., at 1 reqs/s, you can still validate your model, e.g., by using two PCI-e bus, which you then expect to be 2x as fast. Maybe your data about your PCI-e bw is incorrect, or you are not understanding something about how the packets get transfer, but the model guides you through the hardware bottlenecks.
The blog post lacks a "model", and focus on "what the software does" without ever putting it into the context of "what the hardware can do".
That is enough to allow you to compare whether software A is faster than software B, but if you are the fastest, it doesn't tell you how far can you go.
I'm missing one thing from the article, that is commonly missing from performance-related articles.
When you talk about playing whack-a-mole with the optimizations, this is what you are missing:
> What's the best the hardware can do?
You don't say in the article. The article only says that you start at 250k req/s, and ends at 1.2 req/s.
Is that good? Is your optimization work done? Can you open a beer and celebrate?
The article doesn't say.
If the best the hardware can technically do is 1.3M req/s, then you probably can call it a day.
But if the best the hardware can do is technically 100M req/s, then you just went from very very bad (0.25% of hardware peak) to just very bad (1.2% of hardware peak).
Knowing how many reqs per second should the hardware be able to do is the only way to put things in perspective here.
> Nvidia don’t need ARM in-house to be successful. They already are.
You keep saying this, but this still does not match the reality that Nvidia has bid a lot of money for ARM.
So there must be something "in" for them that makes it worth it for them to pay 40 billion dollars.
The claim that this deal will be a disaster for ARM is IMO equivalent to saying that "killing ARM is worth 40 billion dollars to NVIDIA".
That makes no sense, at all. The only reason ARM is worth 40 billion dollars is because of its users. If ARM loses its user base, it is worth as much as MIPS or OpenPOWER (aka 0 dollars).
Also, if ARM loses its user base, NVIDIA ARM CPUs become worthless.
I have a hard time believing that, after investing 15 years of R&D into their own ARM CPUs and finally shipping serious ARM CPUs to market, NVIDIA would pay 40 billions to make that all worthless.
> why buy ARM and almost certainly damage the ARM business model which is as an independent processor IP provider?
That's the 40 billion dollar question, isn't it. Why are they doing this?
I don't know, I guess they know something that I don't.
What do you know that we don't ? :D
> For ARM, it’s a strategic disaster IMV. Better to stay independent!
How do you arrive at this conclusion?
For all we know NVIDIA might (1) invest a lot more money into ARM, (2) improve their ecosystem, (3) start licensing their IP to third parties as well using a similar model to ARM, (4) start contributing more to open source like ARM does, etc.
ARM does not make CPUs (it makes CPU IP), Qualcomm does.
The fact that NVIDIA builds bad ARM CPUs does not change with the acquisition as far as I can tell.
For that NVIDIA would need to invest a lot of R&D into their CPU team, and again, if it does that, it can compete with Qualcomm, independently of whether the acquisition takes place.
> which customer would prefer to buy IP from a potential competitor rather than from a neutral provider.
The same customers that buy NVIDIA GPUs, NVIDIA interconnects, support NVIDIA's software, etc.
You seem to be suggesting that this "somehow" matters, but are not explaining "why" do you think this matters.
AFAICT if AMD wants to ship a data-center node, it needs Mellanox interconnect, and has to buy that from NVIDIA, pretty much in the same way that NVIDIA ships AMD CPUs with their DGX boxes.
There are dozens of thousands of pattents that all these companies need to buy from each other on a regular basis to function.
I don't see how this particular change makes the status quo worse.
You claim that it is in the interest of an ARM CPU vendor that wants to buy ARM to cut ARM's R&D and sell it for parts after buying it.
What's the rationale of this claim? (you don't say)
I'd expected that ARM CPU vendors are interested in having "great" CPUs to sell and having as big of an ecosystem as possible.
So my expectation would be that NVIDIA would significantly increas - not cut - ARM's R&D budget, and will significantly invest in the ARM platform.
On top of this, NVIDIA apparently is trying to cut its reliance on Intel and AMD CPUs. I don't see how cutting ARM's R&D budget and stripping it for parts would allow them to reach that goal.
I think its worth pointing out that Wayland does support NVIDIA's hardware, that the two most widely used Wayland compositors (GNOME and KDE) do support NVIDIA's hardware, and that NVIDIA pays people to work full-time on Wayland, and these compositors, opensourcing their work.
The issue here is that sway, one wayland compositor, does not want to support NVIDIA hardware because they lack manpower. They are also not able to attract anyone willing to implement this support, like other compositors have done.
If you wonder why this is the case, just read this blog post again, and wonder if you'd like to spend your free time working with maintainers that write like this. Go ahead, read any of the other blogpost, or skim through the closed issues in the sway repository.
Trying to spin sway's failure to support NVIDIA's hardware as "NVIDIA hates wayland" is ridiculous in 2021.
FYI I use sway as my main DE, and I'm indeed grateful to its creators and maintainers (ddevault is not a maintainer anymore). But when I read this:
> "We’ve sacrificed our spare time to build this for you for free."
they sound to be entitled to my gratefulness. This is just such a toxic way to go through this world.
> Oh and ppl like you are just cheap "brains" to give the optics of credentials for this sordid affair.
100% whataboutism, and I'm not defending the OP or McK, but I wonder what you think of the PhD "brains" hired at Google that end up being in charge of implementing a menu in Google Carplay.
Duolingo is just another tool at your disposal.
Nobody is claiming that any single tool - much less Duolingo - will make you proficient in a language.
If Dolingo is claiming this, that would be false advertisement / scamming.