4 ms·
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.qikjmf
by kuschku 9y ago
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.qikjmf7dvnjgbkxe@alap3.anarazel.de 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)
- chrisper 9y agoI 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 9y agoWhich 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.
- SSLy 9y agoif 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 9y agoYes, I am mostly gaming on that PC. Thanks.
- anarazel 9y agoBut 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.
- badsectoracula 9y ago> 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 9y agoThat'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 9y agoNo 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.