AMD's 64 core 2995WX processor pulls 279.96W peak power in their tests whilst Intel's W-3175X 28 core CPU pulls 290.41 peak.
I'm amazed how Intel has lost their crown.
They don't have the best servers, HEDT and consumer desktop cpus.
And if they are competitive they consume significantly more electricity
Plus on laptops AMD has more cores and consumes less power whilst Intel touts how their CPUs beats AMD on AI photo upscaling.
Not to mention how Apple is in the process of ditching them
"Intel is doomed" stories have been circulating for 45 years, ever since the Zilog Z80 was released, and it's always been the "Intel killers" that have failed. It's pretty hard to bet against Intel.
I don't really buy that. Intel are in deep shit but the sheer amount of market share they have at the moment makes me slightly pessimistic about a true changing of the guard in the long term.
Its hard to stress just how useless AMD have been for most of the last decade barring the Zens.
They also have a status on vendor lock on a few fronts.
Companies like VMware moved to per core licensing. And most have established infra in intel. Cycling that out is much easier said than done. Especially with the capex squeezes coming.
Some of the AMD chips don't support SMT, so maybe this statement doesn't tell the whole story. I recently looked at the Lenovo ideaPad Flex 5 that was offered in an AMD flavor with Ryzen™ 5 4500U or an Intel flavor with Core™ i5-1135G7. The AMD chip is 6 core / 6 thread, and the Intel chip is 4 core / 8 thread.
I'm supposed to care about the number of threads rather than the number of cores, n'est-ce pas?
Not always. Some workloads would prefer to one thread per core. There are some micro-arch structures which are shared across SMT threads and will bottleneck you if they are critical for workload. Common examples; the TLB or the L1.
I'm certainly not equating one SMT core to two physical cores. But if you're an average laptop user (which you would be at the price point of my example) you're probably running a bunch of browser tabs, maybe Spotify, and some work stuff (Excel, Sublime Text, pick your poison) on the side that you're procrastinating while watching videos of space launches or cats or whatever. Much of the memory (re: your comment about bottlenecked computation structures) is just kind of waiting for later rather than being simultaneously mutated. While I'm writing this I'm running 319 processes with 1673 threads yet I'm loading my CPU 11% according to Activity Monitor on a fairly outdated 22nm Haswell chip. So I think for a consumer laptop you'd look at "more cores" in the context of "more price" and if there's some money to be saved, go with the SMT variant.
In my case it turned out to be a moot point because I couldn't get the AMD version anyway; it was available on Amazon from a third-party retailer but that's always sketchy and it was more expensive. But I think the "AMD laptops have more cores" argument deserves an asterisk because that's not really the whole story. (And to your point, having more cores doesn't necessarily guarantee superior execution if there are other aspects of the computation structure that bottleneck your workload.)
That's Serum. Wavetable synthesizers are famously heavy on CPU. No one would run 113 Serums at once for anything practical, but they might have 113 things going. If it can handle 113 Serum instances with 7 unison voices each sounding at once, it can handle any music production task.
It happens. One process mistake cascaded and derailed their whole lineup.
AMD doesn't have to bet their future on process and can, if needed, move to a different supplier. If, however, they make an architecture mistake and end up in a dead-end, Intel will be able to catch up in one or two generations.
Intel still has a significant lead in several important segments and these deep supply chains take a long time (and a lot of money) to shift. AMD has been showing a clear leadership in cost/performance for some time now and it's still not easy to fill a rack with AMD boxes.
The problem is not higher power usage but lower perf/watt. Both can adjust TDP to maximize performance but setting higher TDP generally worse for perf/watt.
I do enjoy how reviewers are now using software rendering of Crysis as a benchmark, even if it's just a joke. It would be pretty interesting to see what kind of game engine you could make if it was hyper-optimized around software rendering for modern, massively parallel CPUs.
ZBrush has entered the chat. Not a game engine, but it's being doing that since the first version many years ago and always surprises me how it outperforms most GPUs. Rendering (and interactively manipulating!) billions of polygons.
Author here - Thanks, I'm proud of that test! It wasn't as easy as just running the thing to figure out, as it crashes on high-end CPUs without the right affinity mask. I've done a couple of videos on it on my YouTube channel. It has two main limitations: 32 threads or 23 cores. That ultimately limits how good Crysis can be on it (you need 23 really fast ST cores), currently around the 17.7 FPS mark at 1080p Low settings.
probably not a very useful one. amd's high core count parts are certainly impressive, but it's hard to beat >3000 dumb cores that are all doing more or less the same thing anyway.
"CUDA Core" is a misleading marketing term. It merely counts the number of FP32 ALUs. If you measured CPUs this way, you'd have up to 16 "cores" per core. If you count it that way, that makes this CPU is roughly as powerful as the GTX 400 series with it's "512 cores". A brief look at benchmarks seems to confirm that.
Conversely if you counted a GPUs independent parallel threads of execution like on CPUs, you'd max out at a very comparable 64 "cores".
SIMT is a much more convenient programming model than SIMD for wide compute, though. So much so that I think the marketing around CUDA cores isn't merely reasonable but for many applications actually strikes closer to the truth than counting ALUs or independent threads.
If you count ALUs, you see that the CPU has many of them, but you don't see how difficult it is to chunk up data to keep those fed.
If you count independent threads, you see that the GPU has few of them, but you don't see how it conceptually has many threads, which simplifies the programming of each thread while gracefully degrading only in proportion to how much branching you actually use.
I definitely agree with it being a useful model, after all that is the the way GPUs are presented to programmers. But when getting into detailed performance comparisons, especially with CPUs, that simplified model breaks down quickly and becomes a hindrance. Which is why I think it's unfortunate that NVidia (deliberately) uses the term "core" that leads people to believe they can make a direct comparison to CPUs. Comparisons that coincidentally lead people to believe GPUs are much more special than they actually are.
In detailed comparisons all simplified models break down. Tallying max theoretical compute is only appropriate if you're going to put in the effort to actually use it, which is exceedingly rare, even in compute kernels that have supposedly had lots of love and attention already paid to them. So the human factor has to be included in the model and the human factor consistently de-rates SIMD more than it does SIMT.
I realize that under the covers this is more of a compiler/language thing than a compute model thing, but for whatever reason I just don't see much SIMT code targeting CPUs, so again, human factor.
My primary objection is not to the SIMT model, but NVidia reusing a term with an established meaning ("core") for something completely different and incomparable. Other companies terms like "execution units", "compute units" and "stream processors" (although perhaps not as much the last) are much more truthful about the nature of GPUs without hindering the programming model at all.
From the standpoint of a programmer who doesn't want to suffer through constant DIY chunking and packing (very close to my personal definition of hell), a CUDA core looks a lot like a CPU core. From the point of view of someone not writing the code, a CUDA core looks like merely another FPU.
Yes, "CUDA Core" is (was?) analogous to "FP32 ALU" - (it may have transitioned to FP16 nowadays to double the count?)
Yes, EPYC has 16 FP32 ALU per Core.
But, single GPU "Compute Units" often have 2-4x that (up-to 64 FP32 ALU), and a lot of other differences which when added up at the whole GPU level don't mean they max out anywhere near '64 "cores"' "if you counted a GPUs independent parallel threads of execution like on CPUs"
That's where they couldn't be more different!
Also, for accuracy, vis-a-vis "independent parallel threads of execution like on CPUs", even the 64-core Threadripper has 128, not 64.
And many GPUs with 64 physical "Compute Units" would have at least 640 by the same measure (since many have 10 independent programs which can be resident in hardware at once, compared to SMT2 on Threadripper).
But when you break it down further, while a model GPU Compute Unit from a few years ago might have 64x FP32 ALUs in hardware, that CU has the capacity to schedule and execute single instructions on 10*64 logical threads (= 640 logical threaded instructions in-flight on a single CU at once). On a 64CU chip, that's 40,960 logical floating point instructions in flight at once, each one of these coming from a different logical thread of execution in a SIMT model.
The superscalar CPU cores can also have lots of instructions in flight, but they are more deeply pipelining instructions for fewer threads of execution (focused on single-threaded performance).
This is all a long way of saying that a.) you may not have been so far off when comparing raw ALU counts; but, b.) you couldn't be misrepresenting the facts more when comparing the differences in "parallel threads of execution."
This is a core architectural difference between CPUs and GPUs, and while yes, there are similarities in ALU count, the way the transistors and ALUs are utilized by software is quite different.
To oversimplify, and ignoring performance of applying these different programming models to different compute architectures:
Using an example 64-CU GPU compared to 64-Core EPYC:
64 CU GPU as SIMD: 640 Threads (SMT10) and 4096 FP32 ALUs (SIMD64 - actually 4xSIMD16)
64 Core CPU as SIMD: 128 Threads (SMT2) and 1024 FP32 ALUs (SIMD16 - actually 2xSIMD8)
64 CU GPU as SIMT: 40,960 Threads (10:1 Threads:ALUs)
64 Core CPU as SIMT: 2,048 Threads (2:1 Threads:ALUs)
So, this model 64-CU GPU can schedule 20x more logical hardware threads in a SIMT programming model than the 64-Core EPYC CPU, despite having only 4x the FP32 ALUs.
My final caveat would be that GPUs are over time increasing single-threaded performance, and CPUs are becoming wider. So, in a way, there is some architectural convergence - but it's not to be overstated.
One last note: Niagara was a bit GPU-like, with round-robin thread scheduling, and POWER now has SMT8. But differences remain.
Hey, thanks for the detailed comment. I should note I didn't intend to create the impression that GPUs and CPUs architectures were completely interchangeable. That's obviously not true, because of the fixed function hardware alone. The intent was more to give a rough idea of what "CUDA Core" actually means and roughly how those concepts map to what we know in CPUs.
> Yes, "CUDA Core" is (was?) analogous to "FP32 ALU" - (it may have transitioned to FP16 nowadays to double the count?)
It's still FP32 ALUs (NVidia disables FP16 in the driver for gaming cards). The doubling between Turing and Ampere is due to the combined int/fp units being counted as CUDA cores. This also means that for int instructions, the expexted performance is not actually increased, another reason the "core" term is unhelpful.
> But, single GPU "Compute Units" often have 2-4x that (up-to 64 FP32 ALU)
Yep, guess I should have left that AVX2048 joke in there for you. It just wasn't very important IMO.
> Also, for accuracy, vis-a-vis "independent parallel threads of execution like on CPUs", even the 64-core Threadripper has 128, not 64.
I did not consider SMT here because while relevant for keeping the ALUs fed with instructions, they don't increase the amount of raw peak compute possible. Those 128 threads can still only issue 64 avx instructions at any one time, which is what really matters here.
If they hadn't Osborned themselves with Zen3, I probably would have ordered a P620 by now. But the weird punchline of this article seems to be it still takes a whole minute to launch GIMP. Software matters.
For any not familiar with Osborned, the Osborn Effect refers to how prematurely announcing a next generation product can cannibalize sales of the existing product.
I have a 3600X, water cooled so it runs at top speed reliably, 64GB RAM, and a gen 4 PCIe SSD. Photoshop takes a solid 30+ seconds to launch, and another 30+ seconds to load even a few dozen KB JPEG. Feels like an app from 1988.
There's always a faster machine coming. Zen3 Threadripper probably won't be in a ThinkStation for, what, another year? So if you need a computer like that, P620 is the machine of the hour.
It also seems likely you will be able to drop a Zen3 Threadripper into the P620's sTRX4 socket.
I agree that they should not wait, but wanted to point out that P620s use Threadripper Pro, which has a different socket (sWRX8) and came out several months after the sTRX4 Threadrippers.
Has Gimp done any work to parallelize plugin / font loading? I recall that was the bottleneck at startup. If they haven't then more cores won't ever help.
As someone who submitted a patch a few years back to fix a gimp startup problem, I don't think they really care.
The visual purity of seeing all those plugins loading, and having it take a long time seems to be part of the mystique they are looking for. If it just started right up, it wouldn't send the same message.
I think that's consistent with it being singlethreaded. AIUI, unless you pin the process to a single core, scheduling can make it bounce around between cores, and the probability you'll land on a different core (and, thus, incur more cache sync issues) goes up with the number of cores.
GIMP decides to optimize the plugins for each individual core in the system, so the complexity of startup increases with the number of cores present. It's a single threaded process, so more cores = takes longer. At least for the first startup when that happens anyway.
I wouldn't say so. The TR series have many more bus lanes than the desktop variants, and support >= 128GB ram, iirc official EEC support, and iirc quad channel memory.
Here 7 seconds on my AMD A8-7600 from 2015 with an SSD from 2012 :)
But the test is with a very big XCF file, loading lots of high quality layers. I would assume that takes all the time. Unless it is the MS Windows filesystem that is terribly slow, that might also be an option :)
At least at one point, most of the delay in starting GIMP seemed to be it groveling through the HD looking for fonts, and getting them into a format it could use (e.g., showing the font properly in the font selection dialog).
As a random Linux schmuck user who occasionally does very light image editing and processing, the few times I've tried to use Krita I have absolutely no idea how to do anything (without looking up a guide), while I can usually do whatever in Gimp pretty easily. Granted, I've never tried for very long, but that was my first impression.
Maybe Gimp has just rotted my brain over the years with its UI...
Are you familiar with Photoshop etc workflows? Krita is pretty similar to those, whereas Gimp is the outlier in UI/UX.
So I can see going from Gimp to a more standard interface being difficult, if Gimp is what you're used to. Conversely so many people hate using Gimp because of the same reason if they're used to Photoshop
Oh, absolutely, hence why I joked that Gimp has poisoned my mind. I'm not sure which would necessarily be more intuitive for a total beginner, but I know I'm just used to Gimp.
On top of that, I downloaded Krita again, and the UI seems more approachable than I remember. Don't know what's up with that, maybe there was some freak misconfiguration last time I tried. Ah well.
Sounds like you opened Krita expecting it to behave just like Gimp. You should take an hour and actually learn Krita. As someone who learned photoshop in the 90s, InkScape, Painter, Gimp, etc. Krita is my GOTO for any art needs now.
Not sure why this is being downvoted. Gimp has a high learning curve and is primitive compared to contemporary commercial tools. I completely understand a disdain for Adobe's subscription model, but there are fantastic relatively low cost commercial options now. Open source is still a wasteland for actually usable video / audio and even photo editing applications. Lots of apps that are functional on paper, but have major workflow, file support or UX limitations that make them limited in practice.
Edit: Guarantee not a single person downvoting this is an audio video or photography professional. This attitude of OSS above all, damn the users is likely part of the reason there aren't more viable creative apps for Linux, and more viable OSS creative apps overall.
Not everyone who does light image editing as part of their professional setting needs professional tools straight away. The mental overhead of having to manage software installation, licensing, etc. is just not worth it, even if you're willing to spend the extra $300 per year for it.
And as mentioned, Affinity/Adobe software is not available on Linux, which immediately disqualifies it for me personally, even though I'd like to upgrade past GIMP and I'm very much used to Photoshop after years of using it.
> there are fantastic relatively low cost commercial options now.
For example? As a Linux user I would love to pay for an
intuitive image editor. Unlike what you suggest the problem is
not the OSS attitude, it's that there's no alternative.
Either way Gimp works well enough for my purposes. The UI could
be a bit more robust, but it's not nearly as bad as some people
make it out to be. For the sake of my blood pressure I'd rather
use Gimp a day than MS Office for half an hour. At least Gimp's
native file format is deterministic.
With all due respect 'Gimp works well enough for my purposes' is the issue. Gimp does not work well enough for most professional image editing purposes, audacity doesn't work well enough for any professional audio purposes. But there's a kind of bizarre refusal to improve these programmes because they meet the extremely limited (and often baroque) use cases of their core developers and existing users. This seems to be a major issue with OSS overall. Local maxima. Added to which is the difficulty of attracting UX talent to an open source project, when there's no clear avenue of career reward for the design aspects of an OSS project (vs say the hiring and social honour kudos of being part of an OSS project for a dev).
In terms of commercial alternatives available on Linux, your options are limited for the same reason that so many professional level graphics programmes are not available on Android. Linux users spend enormously less per desk on software, the balkanisation of the platform makes support difficult or impossible. Worse, unlike Android in the mobile space, Linux has so small a percentage of the desktop market that it likely isn't worth developing for (for commercial creative applications).
If you think this situation is the fault of commercial app developers, you're exhibiting exactly the OSS snob attitude I was criticising.
+1 for a lamentably rare correct use of the learning curve concept.
As for the wasteland of usable OSS media applications, I think that's hyperbolic, but I agree the interfaces are often surprisingly poor in relation to the technical capabilities.
Interface is a huge issue. It's easy to see why - there are certainly gifted individual devs in the open source space with design / UX chops. But in terms of involvement in community projects there's little incentive for UX people / design people (and appears to be little appreciation for their skills).
In terms of the available apps, I think you may be blind to just how great production and editing apps are outside the OSS space for everything from audio production to vector design. Literally in terms of great OSS design / media apps there's VLC for consumption, and Blender. That's it.
There is no usable OSS alternative with comparable functionality (let alone usability) in most of the categories used by professional (or even enthusiastic amateur) for most creative work. Those apps that do exist are decades out of date in terms of features and usability. It's as though the evolution of design language and user interface that took place after the release of the iphone never happened.
Here's a simple analogy. Imagine an operating system where the only IDE was notepad or its equivalent. Writers could point at that and say, whats the issue it meets all my needs, you can absolutely code in it, its uses almost no memory, supports unicode etc etc. Programmers would rightfully find it completely inadequate because it's not suited to their much more specific, rich, evolved usecase.
Similarly there's a complete blindness in OSS circles about how much better design / creative apps are in the rest of the computing world, and how little evolution there has been on these platforms in the OSS world, and how completely the available options fail to offer any of the functionality necessitated by a modern creative workflow for image creation, audio creation, video creation etc.
I would prefer to have photoshop but cost, however if the only alternative was gimp i'd throw all the money at them for my sanity. I use pixelmator pro instead and am quite happy with it.
Especially in the context of workstation class systems where your looking at $5k per CPU and your quite possibly looking at 10g connections for your horizontal cable runs.
At a certain point the old HP (before they where shit) Joke if you have to ask the price you cant afford it still applies.
I think this fundamentally misunderstands how computer users work.
Lets say I'm a programmer who needs to spin up multiple VMs / Docker / etc. etc. to properly emulate some server setup. Multiple cores and tons of RAM (more than 256GB) needed on a regular basis, with a few NVMe drives in RAID0 so that those VMs can be snapshot in blazing fast speeds.
Paying $100 to $4000 for VMWare workstation, Visual Studio subscriptions, SQLServer non-express, Red Hat Virtual Machine License, Visio, and other such top-class tools would be 100% reasonable, along with the $10,000+ Threadripper pro computer with 512GB RAM or whatever.
But image editing wouldn't be part of that user's workflow. Suddenly, the professional developer is asked to make a web-banner on the top of his Github document with the logo of the company on it.
Guess what? Said developer probably is downloading GIMP. The hassle of going to corporate to be compensated for lol $25 on another image editor is just not worth the time.
I also find this preposterous, but it's what the article measured. For me it would be a replacement for my HP z-series workstation I use mostly to build C++ software.
Workstations aren't just load every core up at 100% and see how it runs. That would be a server like workload. Yet nearly every benchmark in this article is for the most part just a core count test.
People use their workstations for office/web browsing/etc tasks, so a large part of the workload continues to be single threaded. Which is why the Threadripper exists at all (its a epyc with faster single threaded perf).
So a good workstation is one that does well with both single threaded as well as multhreaded workloads. So to ignore the other half of the desktop workload performance doesn't give a complete picture.
The framing in the introduction discusses VFX workloads, and this is recurring theme in throughout the article. The conclusion of the article is that if you need high core counts and clock speed with large working sets in RAM, then this is the right choice. VFX and rendering represent one sort of workload that benefits from this type of hardware. Simulations and CAD workloads can also benefit.
There's no indication or suggestion that this is a good choice for a generic desktop system (note that desktop and workstation are different segments). The type of workload that you'd be buying a $1K+ CPU (this includes Threadripper and excludes desktop Ryzen) is the sort of thing that needs some form of specialized hardware. Maybe that's lots of IO (via 64+ PCIe gen4 lanes), or maybe lots of cores, or maybe lots of RAM (via 4-8 channels and support for registered DIMMs).
If you have one of those needs, then it's probably worth a tradeoff of a few hundred MHz of low-utilization peak clock frequency. That said, with low core counts, the highlighted CPU clocks >4GHz. That's on Zen2 cores, so it is largely similar to what you'd see at similar clocks in Ryzen desktop CPUs. If you want lots of general purpose workloads, go check out benchmarks for Ryzen 3000-series. There is ample coverage of these processors.
Yes, workstations have a lot of varying workloads, but they are fundamentally high end desktops because people sit in front of monitors attached to them. The high clock rates advantage the single threaded parts of the workload, otherwise one is better off with more lower clocked/efficient cores.
Many of the vfx, engineering, etc workloads can (and are) also run as batch jobs on server farms. So, frequently what your looking for is a desktop that can do quick single user trial runs, and then the whole thing is farmed out to the cluster for the final product.
But there are also segments (like building code) where the workload actually may have long sections of single threaded work. AKA, the machine burns through a bunch of cores in parallel, then it sits around with a single core linking/packaging/etc (yes I know some build systems can parallelize that too).
So again my point is that if all you need are a pile of cores your not looking for a workstation, your looking for a server which is tuned for max throughput across a lot of cores. Frequently this means running more cores in a more energy efficient configuration (lower clocks/etc).
So now I am regretting not waiting for that one and getting 3970x. 8 memory channels make a huge difference for me to the extent that 3970x at 4Ghz is barely faster than 32core Epyc at 2.6 GHz. I never thought the bandwidth with 4 channels could be a limitation for my CPU heavy (or so I thought) workloads but AMD managed to deliver so many fast cores that it actually started becoming a bottleneck. Now I want to upgrade already. Well done AMD!
I'm amazed how Intel has lost their crown. They don't have the best servers, HEDT and consumer desktop cpus. And if they are competitive they consume significantly more electricity
Plus on laptops AMD has more cores and consumes less power whilst Intel touts how their CPUs beats AMD on AI photo upscaling.
Not to mention how Apple is in the process of ditching them