Yes, but that contract was a result of going fabless and spinning off GloFo into its own entity longer before Zen. AMD went fabless in 2009 during K8 lifecycle. Since then, we had an entire dynasty of failed bulldozer CPUs. I fail to see how going fabless helped them?
What helped them is putting the right people in charge of Zen design and intel fumbling 10nm due to their own hubris.
The point is that AMD didn't really go fabless in 2009. They didn't own the fab anymore but were still tied to it, so they were not free to exercise the number one advantage of being fabless until much later.
In your mind, company that as a contract with a fab is not fabless? Do you think AMD can just stop ordering from TSMC today and call it a day?
AMD was fine with having GloFo as a fab until 20nm process. They were already behind, but not terribly.
AMD even used TSMC for their CPUs and GPUs before Zen. Ontario was fabbed at TSMC in 2011.
Point is AMD as free to shop around. Only in 2016 the agreement was amended that GloFo would be preferred for 14nm and 7nm, but since they decided not to work on 7nm, it freed up AMD.
AMD and GloFlo split in 2009 but AMD wasn't able to start actually manufacturing their chips with other foundries until 2019 when GloFlo got downgraded to only providing the IO die for Zen 2. This is because AMD was contractually obligated to continue using GloFlo for that time as a condition of the split.
Zen 2 is also where Ryzen went from "exciting and competitive, but not top of the line" to actually giving Intel a run for their money in more than just highly multithreaded workloads.
Improved architecture put AMD within striking distance of Intel and the move to TSMC allowed them to pull ahead.
UNtil 2009 to 2016 AMD was free to use any fab as long as GloFo still has something to do. In 2016, AMD had to pay GloFo to NOT use them for some node sizes.
AMD used TSMC for their CPUs (not IO die!) at least for one generation, and TSMC actually dropped the ball that time and AMD went back to GloFo.
Once again, AMD was fabless since 2009 it's a fact, and it's also a fact that it didn't help them at all.
Layoffs might have to with what a person is working (project is no longer business priority, just cutting based on performance might lead to delays) or what team a person is working on (whole org gets the axe).
How is 1 false? Log improvement means for 10x the cost the model is 2x as good. For 100x the cost, the model is 3x as good.
Not a curve to be happy about TBH. You need to simultaneously find big efficiency wins and drive up costs substantially to get 4-5x improvements, and it is probably impossible to maintain good year on year improvements after the first 2-3 years when you get all the low hanging fruit.
Yeah it’s the drawback, originally it used segmented stacks but that has its own issues.
And it’s probably not the worst issue because deep stacks and stack pointers will mostly be relevant for long running routines which will stabilise their stack use after a while (even if some are likely subject to threshold effects if they’re at the edge, I would not be surprised if some codebases ballasted stacks ahead of time). Also because stack pointers will get promoted to the heap if they escape so the number of stack pointers is not unlimited, and the pointer has to live downwards on the stack.
I think the discussions in these threads show how accurate the framing of this article is. You have some people celebrating Google and friends (slowly) leaving the C++ ecosystem and those that continue to emphasize the flaws that have driven companies away from it in recent history (safety being #1) on the list.
Around the time the CoC was being established, Linus went to therapy. If I recall correctly, some people had spoke to him about his behaviors and he decided to do something about it. I think it was done in private so it's unclear how much of it was pressure vs his own decision. His tone has become much less aggressive since.
Honesty is often unpleasant, especially when someone tells us that our work isn't good enough. But it is a required thing from a leader. The important thing is that he's cut down on needless personal insults.
No, it is not a "required thing." Furthermore, a leader should set an example and be aware of how their stature keeps others from providing feedback to them about their behavior. For example, cops in many departments are taught to work at being exceptionally polite on the road, because they won't get the "you're being an asshole" feedback the rest of us do. Nobody's going to honk at them or curse them out for cutting them off.
"This isn't good enough, your code is sloppy as shit" - you're being an asshole.
"We have a coding standards and conventions round commenting and formatting. I encourage you to rework your patch with that in mind and re-submit it, because at least on cursory examination, your code looks solid."
"Thank you for resubmitting. This is much more in line with what we prefer. Now we'll be able to take advantage of the work you've done to fix this problem."
But Linus isn't honest. I'm sure he thinks he is, but he's not always "objective". So while he thinks he's being honest, what he's saying can be untrue anyway.
And of course he's Linus and you're a nobody so nobody will ever listen to the other side of the completely subjective "facts"
Being honest doesn’t have anything to do with being objectively correct, unless a person is presenting their subjective feelings as objective fact.
Saying to someone “your work is not good enough for me” is a subjective statement; whether or not it is honest depends on whether or not it is reflective of the speaker’s beliefs about the quality of the work.
A leader not speaking up when they receive subpar work is dishonest, and it is fundamentally unfair to the person doing the work.
1) only if you truly believe the earth to be flat
2) the earth being a sphere is an objective fact that can be proven by multiple means.
You would either be mistaken if you believed the earth to be flat, or a liar if you didn't.
That also has absolutely nothing to do with your original claim -- that Linus has been "dishonest" because his opinions about technical matters discussed on LKML aren't objective. There is a fundamental difference between stating a fact ("the earth is a sphere") and an opinion ("this work is not up to my standards" or "I do not agree with your approach to solving this problem.")
Note: being rude in expressing their opinions might make a person an asshole, but it does not make them "dishonest."
> 2) the earth being a sphere is an objective fact that can be proven by multiple means.
Thanks for telling me the point I was trying to make. It's very useful -_-'
> There is a fundamental difference between stating a fact and an opinion
There is, but often people mistake their own opinions for facts.
I'm sure Linus knew perfectly it was an opinion and not a fact because when he spoke about the issue we were having at a conference he kinda glossed over the bits that would have made it at least doubtful he was correct.
But of course people who hadn't read the mailing list and had no context had no choice but to believe he was absolutely right and forced to deal with very unreasonable people.
Had he said the full story, nobody hearing him would have thought he was completely right.
I don't think there is any point in continuing this conversation. You originally posted that someone was being "dishonest" because he wasn't "objective." That is simply incorrect, in the same way that stating the earth is flat is incorrect.
I wasn't party to whatever conversation you had with Linus, so I can't comment on your anecdote or if or how it relates to the argument(s) you are trying to make, other than to point out that nobody is 100% objective. That includes you.
Go very much is memory safe in the absence of data races.
Data races cause issues in all languages, though it's fair to say that Go is affected slightly more than languages like Java. Rust is a bit special by making data races hard to trigger (impossible in safe code IIUC), but this is not typical.
It is impossible in the context of having all threads accessing in-process memory.
If the data can be accessed externally, regardless of the guarantees being uphold on the Rust side, there are no guarantees from third parties accessing the same data.
It also doesn't prevent other race issues with external data.
Memory like that needs to be wrapped with unsafe for access, there is the volotile crate to mark stuff like that so the compuler won't optimize it away.
Other than rust haskell seems like the other primary candidate for memory safety even across threads.
Yes, but it doesn't guarantee changes occurring from third parties, even if everything is done correctly on Rust side, and all invariants are correct, so corrupted data can be still be seen as valid.
Is there any defense at all against what you are talking about? I mean, I could use a firewire controller to modify memory without the processor or OS being aware. I suppose you could sign every block of memory using the tpm, but you'd have to the signatures in the tpm, and the code to check the signatures, and so on.
ICEs have a lot of advantages that make them much better suited than EVs to certain tasks (extreme climates and remote locations, for example). They will likely stick around for niche use cases (at least) for quite a long time.
As for why Porsche is spending money on ICE engines...well, no one really buys a Porsche because it's a "practical car", do they?
Here in Oslo, Norway, they got BEV busses for a lot of lines, and last year was a really cold winter. Somehow, the ones in power were shocked to discover the range dropped to half due to the electric heaters needing a lot of power, causing a public transportation chaos as busses queued up for charging instead of transporting passengers.
Now the busses are getting retrofitted with fuel-based heaters, which will be running on bio-diesel... better than nothing I guess.
> As for why Porsche is spending money on ICE engines...well, no one really buys a Porsche because it's a "practical car", do they?
I don't know. I find my daily very practical: a Porsche Panamera MY2013, now nearing 125 000 miles and 12 y/o. Still under extended manufacturer warranty. I have it since more than five years now (bought it used). Next car is another used Panamera (probably a 2020 or something). Very sweet, comfy, luxurious ride and yet if you push the pedal to the metal, way funnier to drive than, say, a Mercedes Class S.
Well, in a big city I wouldn't call a 5m long car that drinks 12 or more liters "practical". Also it's an expensive and high maintenance car even when functioning properly (I'd be scared of the bill for changing those tires or doing Porsche's maintenance...)
But, you said it: sweet, comfy, luxurious, funnier. Valid reasons, of course, but different :-)
