AMD Pushes Back 3rd Gen Threadripper & Ryzen 9 3950X Until November

[coder]

handwritten Assembly scales poorly once you want to do something more complex than a Super Mario clone. John Carmack is one of a kind.

Um, he codes in mostly C++, AFAIK. And I doubt he's that exceptional, apart from the fact that the games industry probably burns out too many coders or doesn't pay them as much as other employment options available to most of them.

Engine	Initial Release	Languages
Doom	1993-12-10	C, Asm
Quake	1996-06-22	C, Asm
Quake II	1997-12-09	C, Asm
id Tech 3	1999-12-02	C
id Tech 4	2004-08-03	C++
id Tech 5	2011-10	C++, AMPL, Clipper, Python
id Tech 6*	2016-05	C++

* Carmack probably started this, but left for Oculus in 2014.

According to this post from 1.5 years ago, he still has a fondness for C, though it's clearly not his primary working language:

In hindsight, I should have just gone full retro and done everything in ANSI C. I do have plenty of days where, like many older programmers, I think “Maybe C++ isn’t as much of a net positive as we assume...”. There is still much that I like, but it isn’t a hardship for me to build small projects in plain C.

It should be noted this is right after he got done complaining about the lack of C++11 support, on his chosen platform. Perhaps if he'd had that, he wouldn't have harbored such misgivings about sticking with C++.

[angrypie]

coder What I mean is: nobody cares about software optimization when a half-assed optimization for the lowest common denominator (Intel/NVIDIA) is simpler and reduce the time to market.

"What do you mean, our game stutters in your PC? Just throw more hardware at it. Hardware is cheap."

No one is giving a single fuck about chiplets and fabric interconnects until Intel does the same.

[coder]

coder What I mean is: nobody cares about software optimization when a half-assed optimization for the lowest common denominator (Intel/NVIDIA) is simpler and reduce the time to market.

Targeting lowest-common-denominator is definitely a factor, but also some game developers are sometimes effectively bribed by GPU makers to optimize games for their GPUs, potentially to the disadvantage of their rivals'.

[ermo]

What did you use for underclocking, in Linux?

Said hardware lives in a Wintendo box, so I haven't fiddled with underclocking in Linux.

I'm debating acquiring a used RX 580 for Linux use, since it's better supported than my ageing HD 7970 GHz Ed. card.

[coder]

Said hardware lives in a Wintendo box, so I haven't fiddled with underclocking in Linux.

Okay, no prob. I just took my own advice[1] and got a Radeon VII - that's why I asked.

I'm debating acquiring a used RX 580 for Linux use, since it's better supported than my ageing HD 7970 GHz Ed. card.

Mine will replace a HD 7870. It's a XFX-brand 2-heatpipe card that sounds like a lawnmower if subjected to a stressful workload! I don't know if the thermal compound degraded or if it was always that bad, because I didn't really stress it when I first got it.

Anyway, I picked up a cute, little RX 550, a while back, that I was going to use for that box, but the VII will be much more fun. Still, I want to keep its heat & noise in check.

1. https://www.phoronix.com/forums/foru...ue-gpu-compute

[caligula]

Unless you're talking about removing the kernel/userspace boundary, I don't see any big wins from that. I don't believe there's a whole lot of overhead weighing down Linux gaming, beyond the sort of stuff that's already addressed by Game Mode.

Hard to tell. At least one advantage is that a small kernel could be further optimized (e.g. LTO). If the "driver" (including kernel, mesa, gpu kernel and vulkan drivers) was this small, it would probably fit in L3 cache. If, instead of thread scheduler, it only had one thread per CPU core and fibers as user mode threads, the engine could probably shave off few % of context switching overhead, especially now with all those mitigations. I'd also turn off all gr security patches etc.

[coder]

If the "driver" (including kernel, mesa, gpu kernel and vulkan drivers) was this small, it would probably fit in L3 cache.

Interesting, but I think it would continually get evicted by games' own code & data.

If, instead of thread scheduler, it only had one thread per CPU core and fibers as user mode threads, the engine could probably shave off few % of context switching overhead, especially now with all those mitigations. I'd also turn off all gr security patches etc.

Yeah, that's sort of like how I was talking about removing system call overhead. Basically, just put the whole game in the kernel, maybe implementing it as a kernel module.
; )

It's as if you're trying to turn a PC into a games console, meanwhile games consoles are trying to be more like PCs.

Anyway, work-stealing schemes like what TBB supports can already load-balance work without relying on context-switching.

https://www.threadingbuildingblocks....algorithm.html

The downside might be a bit more thrashing of L2, if related tasks operating on some shared data get handled by threads on different cores. I guess TBB has some notion of affinity, and you could also potentially mitigate this by tuning the granularity of said tasks.