Re:AMD Discloses Initial Zen 2 Details
by bluecalm on Sunday November 18, 2018 @02:42PM
(#18482138)
Damn, with 64core/128 threads becoming widely available a lot of Windows software will have to be updated to use that because of "64 bits should be enough for everybody" kind of decision in Windows when implementing affinity. You can't get more than 64 threads in OpenMp when compiling with MinGW and you can get it with Clang but the implementation wasn't very efficient when tested it.
I suspect the problem is there in most Windows thread pool implementations.
[ Parent
| on HN ]
Re:AMD Discloses Initial Zen 2 Details
by SlowRobotAhead on Sunday November 18, 2018 @03:15PM
(#18482292)
Last I saw MS SQL licensing among others like it have a pricing structure per CPU core...
That’s going to need to be modified I think!
Doubt they will go away from per core pricing. Most SQL servers are VMs so you can assign as many cores as you want. I do expect them to give bulk pricing for more cores. So 4 core=$x, 16cores=$3x, 64cores=$10x.
Oracle says "Haha, no."
Re:AMD Discloses Initial Zen 2 Details
by squarefoot on Sunday November 18, 2018 @03:39PM
(#18482415)
PostgreSQL replies "Haha, thanks." :)
Re:AMD Discloses Initial Zen 2 Details
by astrodust on Sunday November 18, 2018 @03:37PM
(#18482404)
Oracle says "Looks like our profits will double each time AMD doubles the core count of their flagship chip."
Larry Ellison needs a bigger yacht, time to re-up your Oracle per core licensing agreement.
Hah, yacht. He needs a bigger island.
Re:AMD Discloses Initial Zen 2 Details
by anticensor on Sunday November 18, 2018 @02:54PM
(#18482185)
Just run 2 Windows instances. Problem solved.
Re:AMD Discloses Initial Zen 2 Details
by blattimwind on Sunday November 18, 2018 @02:56PM
(#18482202)
Windows can use more than 64 hardware threads, but a single process kinda can't.
I think it can? https://msdn.microsoft.com/en-us/library/windows/desktop/dd4...
The KAFFITY in the GROUP_AFFINITY struct is a bitmap ULONG, so 64 bits on 64 bit archs, and 32 bits on 32 bit archs.
Yes but that means every group is 64 CPUs. Notice you can set affinity for any group (16-bit index).
Yes, starting from Windows 7 / Server 2008 R2 it is possible to support more than 64 CPUs within a single process by using new Win32 APIs supporting processor groups. You'd need to manually set the affinities for the threads, but after that you are all set.
Unfortunately, unaware (legacy) software is still limited to 64 processors.
But AFAIK, if I have 128 logical cores, I can't say "schedule this thread on any of the 128 cores because you as the scheduler should know better than me". You have to manually manage the two thread groups each of 64 cores because new threads are round robin assigned to the two groups on thread creation and aren't migrated as circumstances change.
Huh, I don't really know much about this to be honest, but are you sure that's not a consequence of prefering not to migrate threads across NUMA nodes rather than across thread groups? Are you aware if there's any documentation on the behavior you're mentioning?
Oof, I hadn't read the whole page. Interesting, thanks!
It can but you have to take care too change process affinity groups every time you want to work with threads in another group as a group is limited to 64 virtual cores. It complicates thread pool implementation significantly.
Re:AMD Discloses Initial Zen 2 Details
by zamadatix on Sunday November 18, 2018 @07:26PM
(#18483322)
But bringing it back to the parent comment thread it's easier to manage affinity of your processes than it is to synchronize them across multiple OS instances.
No such inherent limitation on windows
Re:AMD Discloses Initial Zen 2 Details
by anticensor on Sunday November 18, 2018 @03:04PM
(#18482233)
[dropped]