Hacker News new | past | comments | ask | show | jobs | submit login
Centaur Unveils Its New Server-Class x86 Core (wikichip.org)
105 points by parvizp on Dec 14, 2019 | hide | past | favorite | 33 comments



CentaurHauls!

I didn't even know they are still around. Still remember my VIA epia mini ITX board with 800 MHz. Must have been around 2004, before Intel tried the same with Atom. At the time AMD and Intel didn't really have anything to offer in that segment, so that was really a great solution for having a small 24/7 machine in your dorm room that's completely silent.

Cool to see they're still going.


> At the time AMD and Intel didn't really have anything to offer in that segment

Didn’t AMD have Geode for this segment?


They still are still making them, from the Wikipedia article:

"In 2009, comments by AMD indicated that there are no plans for any future micro architecture upgrades to the processor and that there will be no successor; however, the processors will still be available with the planned availability of the Geode LX extending through 2015. In 2016 AMD updated the product roadmap announcing extension of last time buy and shipment for the LX series to 2019. In early 2018 hardware manufacturer congatec announced an agreement with AMD for a further extension of availability of congatec's Geode based platforms."

We have some NTP/GPS appliances acquired in the last 2 years that are still using them.


Wasn't Geode actually Cyrix?


Mostly, but the NX Geode was Athlon based IIRC.


Wow, just weeks ago I was dissing them for looking more like an internship/educational campus rather than an actual company developing real products. It’s one of those cases where I can happily and excitedly post a mea culpa. Doesn’t matter how competitive this is, it’s great that it exists.


Related discussion where this link was posted in the comments: https://news.ycombinator.com/item?id=21789777


No uop cache is a very strange choice. They way they phrased it "we can meet our current performance goals without it in this generation" just sounds like they didn't manage to get it working in time.


That seems to be a very pessimistic interpretation.

Perhaps, they've been evaluating that as an architectural change, but recognize it would be a significant engineering effort. And they can already meet their current performance goals. Thus, they will wait until a future generation, when they cannot meet their future performance goals. In that future generation, they'll implement a uop cache.


One aspect of the design that I like is not downclocking when using wide vector operations. That Intel chips cut their frequency if anything is using AVX-512 makes the instruction set practically unusable for general purpose software, since the whole core runs at that reduced frequency (across all processes and threads) whether or not it's doing vector work. Consequently, it only really makes sense to use these operations if you can dedicate a whole clock domain to them and nothing else --- and few systems are set up that way.


There is no difference between not downclocking and simply downclocking all the time (the decision made here) except it performs worse when running standard workloads.

They didn't include it because dynamically modifying the frequency based on the workload is complicated and they didn't have time.


Not that I work at a level that it's required, but I imagine it greatly simplifies reasoning about performance. Saturating compute units, and changing frequency depending on the operations used, and work done per iteration, all that seems like a lot of work if you're trying to fit a specific performance envelope reliably.


You can downclock an Intel CPU to half speed and run AVX512 1:1 if you want.


I think the idea is that if you design the CPU not to downclock, you can make more balanced design choices (maybe better internal power distribution?) so that the downclock ratio isn't quite as severe as it is on Intel chips even though you're incurring it all the time (because it's baked into the silicon and isn't an operating mode)


What does balanced mean? IMO, balanced internal power distribution would be a system where you have a certain power budget, and whichever execution unit is active can scale up as fast as it can to use that power. A system where the clocks are fixed and the power usage varies widely sounds unbalanced in comparison.


The problem is that the downclocking affects more than just the AVX instructions being executed and can last long enough to impair overall system performance. If you could just make each AVX512 instruction take twice the cycles, you'd get the same throughout and energy use per unit real time but not impair the rest of the system. I know it's not really that simple --- but there must be a better way to avoid the AVX throttling problem than the one we've used so far.


The time it takes to switch power back and forth between units is problematic.


[deleted]


I don’t think OP means throttling. AVX frequency scaling imposes different base and turbo in different types of scenarios.


That figure was from the article.


I found out the other day there is a documentary called "The Rise of Centaur" that I haven't had a chance to watch yet but its on my list. https://www.amazon.com/Rise-Centaur-Glenn-Henry/dp/B01FSZU6F...

Also surprised to see they're still a going concern.


I wonder if it'll be more secure than past VIA offerings ( https://www.bleepingcomputer.com/news/security/backdoor-mech... ) or Intel with the opaque, non-owner-controlled, and often vulnerable ME.


What are we going to do with all these "AI coprocessors" once the AI bubble bursts? Are they at least well documented or flexible enough to be used for more general float crunching?


It's hard to imagine how one gains confidence in this kind of product. How does this vendor have the resources to qualify this chip? Intel can already barely qualify theirs. The last seven generations of AMD parts shipped with serious defects that were discovered by customers in the field. Centaur and Via are far smaller. Is it really possible to be scrappy and scrappily produce a bug-free assembly of billions of transistors?


Any processor in any product you have has bugs.

For instance, according to Intel's own documentation[1] there are 137 errata for "8th and 9th Gen Core" processors, including unpredictable behavior, hangs, security key exposure, etc.

It just has to be good enough to sell to folks.

[1] https://www.intel.com/content/www/us/en/products/docs/proces...


Centaur has already built several generations of x86 processors so you need to make a stronger argument than that.


Sure but what have they built that’s this complicated? The recent AMD flaws have been things like frequency scaling doesn’t work (zen). The more features you have, the harder it becomes to validate the product.


I had a professor in college who contracted for them doing formal verification of their CPUs, in case you’re wondering.


Is it necessary to be bug-free? AMD still sells chips...


There's some sort of irony in calling out the x86_64 vendor who's been the least-touched by all of the recent vulnerabilities


To be clear, I was calling back to PP's example of AMD's errata. I just built a Ryzen machine myself and like their chips just fine.

That was my point. Even if they have bugs, they sell and they work. Centaur's chips will have bugs. Intel's chips will have bugs. They all work, and they all sell.

Being bug-free is not necessary, and an unfair bar for PP to set for Centaur when nobody else in the market meets it either.


To be fair, I am not sure people have been looking particularly deeply at Centaur processors.


I guess technically the Via Nano (2008) was an x86_64 ISA chip, but their previous cores were all 32-bit and they haven't actually productized the chip in the article yet. The Nano was functionally obsolete long before Spectre and Meltdown cropped up. So I don't believe GP was considering Centaur in the category "x86_64 vendor," which is maybe pedantically incorrect but probably broadly reasonable given the context.




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

Search: