On modern AWS instance types so much is offloaded to dedicated hardware that the only shared (noisy) components between VMs is memory bandwidth and higher levels of CPU cache (and I think graviton doesn't even share CPU cache now)
I would suspect your performance difference is mostly likely showing that on metal you are sharing the same software wider so not polluting caches as much as a vm neighbour running unrelated software.
The virtual instance is the exact same size as the metal one, which covers an entire physical machine - I guess this is pure overhead rather than noisy neighbors.
That's a surprisingly large overhead. I've not measured that large an impact on AMD, particularly for compute heavy.
Did you profile at all? And have you observed if it's not compute-bound? If it's memory or IO bound it can be due to other virtualization overheads, such as memory encryption.
I read that's not really the case - there's a bunch of equipment on EU-spec (and some other market) BYDs that comes from EU vendors such as Bosch. It additionally has a completely different AC unit as the kind of refrigerant BYD uses in China is illegal in the EU.
I'm not saying it justifies the price difference, but there are changes between the cars.
The 'defensive' nature refers to the mindset of the programmer (like when guilty people are defensive when being asked a simple question), that he isn't sure of anything in the code at any point, so he needs to constantly check every invariant.
Enterprise code is full of it, and it can quickly lead to the program becoming like 50% error handling by volume, many of the errors being impossible to trigger because the app logic is validating a condition already checked in the validation layer.
Its presence usually betrays a lack of understanding of the code structure, or even worse, a faulty or often bypassed validation layer, which makes error checking in multiple places actually necessary.
One example is validating every parameter in every call layer, as if the act of passing things around has the ability to degrade information.
The kind of defensive programming you're talking about has almost nothing to do with the contents of this article. This article is mostly just about structuring code so that bugs appear at compile time rather than runtime.
A function must check its arguments. It cannot assume that the arguments are already checked (against its own requirements). This is regardless of what called it, or where the values came from.
I think CMake is cool when it works, but debugging it when it doesn't is hell. I've often spent an inordinate amount of time trying to figure out why doesn't it pick up library paths.
And although I know Microsoft is uncool, I still want to shill vckpkg as it seems they finally managed to create a usable cross platform package manager for C++
I have a theory about EVs - they don't allow much engineering range.
To have a broadly usable car, you need at least 50+ kWh battery, 100kWish fast charge, and basically almost everything you need in a big car. If you don't have it your car is not really usable as the main car.
Motors are small and efficient so they are not big cost drivers.
Small cars, such as 'cheap' B-segment cars still need all this stuff. If you look at the weight of something like a Renault 5, you find its not lighter than a Model 3. The manufacturer still pays for all that stuff, but the car's supposed to be cheap so they cant pass on the cost.
But in a small car, you have packaging problems with having to fit the battery pack, meaning you need to build them taller and draggier - that means your highway range decreases, and the big weight means big (and compact) crash structures, which again are more expensive.
In contrast, in a Model 3, you can make the pack thinner, design a more aerodynamic shape, have the big roomy frunk as a crash structure.
Your extra cost ist like tens of centimeters of steel and glass, but customers will happily pay more because its an upmarket car.
You can't really go beyond that, because the acceleration and torque is crazy even at the base level and at high speeds your range will still suck.
This basically means imo that the Model 3 and Y are at the ideal intersection of what the technology's good and bad at, and market positioning.
That's why I don't think Tesla will make a C-segment car.
This reminded me of the video about the Tesla door handles, where its explained how they redesigned the retracting door handles of the Model S from having a bunch of switches and mechanical parts to just a motor + a position sensor:
I remember on reddit this was pointed under some article once, and there was a consensus about how West Europeans are just more productive.
Then 2 weeks later there was an article about how much money do Americans make per hours worked, and everyone was falling over each other pointing out how flawed the methodology was.
If you and BMW are correct - if we take it for a fact that a simple fender-bender can make batteries develop life-threatening faults, which absolutely require a 4k euro inspection that involves complete disassembly and specialist equipment, then that means that EVs are unsuitable for public use.
So either all EVs need to be scrapped forever, or BMW needs to engineer a more tractable solution to the problem, or BMW is overreacting and overcharging customers.
We don't have the full picture. Like I mentioned too many times in this thread, I know EV Clinic head boss Vanja likes to overreact and twists stuff to fit into his narrative. Not saying this one was not a fender bender, but I take all his stuff with a grain of salt. Mostly because I worked with him AND work on the same stuff he does - and it usually doesen't match up to what I'm seeing to the degree he 'dramaticizes'.
In the article, it was mentioned that the issue can be caused by hitting the curb, there's a guy in the comments who says his VW grenaded itself this exact way just while charging (luckily his car was in warranty).
We've been running some compute heavy workloads on AWS, with some running on metal instances, and some running on virtualized instances of equal size.
Both were intel 192 core machines.
Virtualized instances tended to perform 20-25% worse in terms of CPU throughput, which is quite significant, and more than I'd have assumed.
Where does the performance go? Is this an AWS thing, does the performance get lost in the software stack, or is it a CPU-level issue?
I haven't tried with other vendors tbh, but would it be possible to mitigate this by switching to another architecture/vendor like AMD or Graviton?
reply