Hacker Newsnew | past | comments | ask | show | jobs | submit | uluyol's commentslogin

It just needs to be anything that will force OpenAI to IPO.

They count as a different type of failure.

We knew what to do but screwed up hard is a operational failure and we didn't plan for it is a design/planning failure.

The people who are hurt might not care, but understanding the root cause is important to address them.


Are these the current prices or the prices at the time the models were released?


Mostly at the time of release except for 1.5 Flash which got a price drop in Aug 2024.

Google has been discontinuing older models after several months of transition period so I would expect the same for the 2.5 models. But that process only starts when the release version of 3 models is out (pro and flash are in preview right now).


They had contracts which forced them to buy Global Foundries even lasting into Zen 2 (I believe they used it with the IO die).


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.


AMD is not ready to have a full announcement for their new consumer GPUs: https://morethanmoore.substack.com/p/where-was-rdna4-at-amds...


I knew this at the time of writing, should have worded myself better.


Go stacks are dynamically copied and resized. Stack overflow is not a concern.


Oh yuck. Invalidating all the pointers to the stack? That's got to be expensive.

I guess if you're already doing garbage collection moving the stack doesn't make things all that much worse though... still, yuck.


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.


You might be interested in this talk: https://go.dev/blog/ismmkeynote


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: