[kuschku]

It looks like you'll see a significant slowdown, PostgreSQL with pgbench sees a 7% to 16% slowdown.

https://www.postgresql.org/message-id/20180102222354.qikjmf7...

Of course, this depends on workload — gaming will see different results than computationally heavy tasks.

It is likely that games using Vulkan, DX12 or OoenGL's AZDO functions will see much lower performance impact (because they usually only do a handful of syscalls per frame) than games using older APIs, or even OpenGLs immediate mode (which does one syscall per emitted vertex, in worst case)

[badsectoracula]

> or even OpenGLs immediate mode (which does one syscall per emitted vertex, in worst case)

Perhaps with drivers written in the 90s for hardware from the 90s. Any OpenGL implementation worth its salt will buffer those requests on the client side until they need to be observed. Indeed this was a big feature in the heyday of DirectX 9 where D3D programmers had to count the drawcalls whereas with OpenGL you have way more leeway with calls since the driver tends to be smarter and caches that stuff.

In theory with a modern driver using OpenGL's immediate mode API shouldn't need any more syscalls than building the vertex buffers in your program, setting up the necessary state and issuing a buffer draw command.

The only time where you'd need a syscall per emitted vertex would be if the GPU had OpenGL-like commands and your OpenGL implementation was a thin wrapper over that. I think one of ATI's very early GPUs worked like that (although the commands were per primitive, not per vertex).

[kuschku]

That's why I said in absolute worst case scenario. I know that in the past I actually wrote some program in high school that did use that.

Nowadays, thanks to vulkan and AZDO with glMultiDrawElementsIndirect, you're right, of course — you might even use a single syscall per frame.

That's why I said, in absolute worst case.

[badsectoracula]

No i meant explicitly about the part i quoted: the immediate mode. Stuff like glBegin, glVertex3f, glEnd, etc. Those will not get you a syscall per vertex, they will be buffered by the OpenGL implementation. Modern OpenGL implementations, at least those by Nvidia and AMD (and i also suspect Mesa too) do a lot of optimizations on the client side.

[chrisper]

I am also quite annoyed because I paid premium (Intel) prices with the expectation to get premium speed. Now if I can just get the same performance cheaper with AMD, maybe I should just return the whole thing.

[philjohn]

Which chip to get depends on your usecase.

If you absolutely need the best single core performance you can, Intel is the way forward.

If multicore performance is important (lots of multitasking, lots of heavy processes running) then one of the 8 core Ryzen 7's will be better, for cheaper.

[chrisper]

Thanks. I guess I'll stick to my 8700k then.

[otakucode]

Just curious, what do you do that requires a fast single core? I always find it strange when people value that, as most computers nowadays generally run more than 1 process at a time.

[chrisper]

A lot of games only run single core. Though finally, more modern games do take advantage of more cores!

[drb91]

Computing things serially, obviously!

[copperx]

Ruby on Rails.

[SSLy]

if I had an 8700K (I have a 7700K, btw) and my use case was gaming (that's this cpu's target market) I'd keep it. Otherwise I'd get a Ryzen.

[chrisper]

Yes, I am mostly gaming on that PC. Thanks.

[anarazel]

But note that that those benchmarks pretty much are the worst case for PTI. Each of the queries is either near trivial (single pkey lookup) or the most trivial (SELECT 1), therefore the send/recv syscalls to/from the clients are taking the most time. If you instead have queries that do a bit more actual work this'd look very different.