Hacker News new | ask | show | jobs
by seniorgarcia 1924 days ago
And I do not get this at all. For my desktop you would get 12, I'm on a i7-8700k with a base frequency of 3.7GHZ and a permanent boost of 5.1GHZ. This rig runs Oculus VR/Steam VR all the time.

If I ran that site from my Surface laptop the response would be 12 as well. The 12 cores on my surface boost is 12 1.3GHZ cores though if they boost. The cooling might work out to boost 2 cores to 1.9GHZ. Or however the Intel boosting works out in this thermal constraint.

So, what is the useful info you get for your VR app from these values?

3 comments

If I spawn 8 threads to do some kind of processing while you have 12 logical cores, I am missing out on a 50% performance boost (assuming the work is CPU bound).

If I spawn 20 threads when you only have 4 logical cores, they will just stand in each other's way (caches, context switches, etc.) and possibly eat 5x as much memory as needed on top of that.

I don't want to skirt the HN rules, but let me be clear that your replies appear as aggressive and incendiary while hinting at a lack of understanding for basic concurrency concepts. I don't know whether that's what it actually is or whether there's some miscommunication happening, but either way you're coming off as an ass. Be kind.

Your native VR games need to know how many CPU threads you have to efficiently allocate game processes. Some processes can run at a lower priority, and your OS scheduler figures out the rest.

I can assure you that most of your VR games are using this same data.

But how is my CPU count useful to you in that situation? My i7-8700k has 12 threads, my Surface book 2 pretends to have 16 threads, my iPad Pro pretends to have 16 cores, my iPhone pretends to have 12 cores.

What is the API I can use to map that to any sort of useful 3D performance? How are 3d game processes using this data to evaluate what they are supposed to be doing?

Never said it was for the 3D rendering. If all my app did was 3D rendering, it wouldn't be an app, it'd be a tech demo.
So, considering the amount of responses for thread count that you can not count on for any sort of performance, why do you need the thread count? Since you already answered downstream, I'll spare you the bother of doing it here...

>You don't need it. I do. blabla, it makes it easier for me blabla native apps are tracking you as well

Do you... Do you maybe not know how concurrency works?

It's not about hitting a minimum threshold of performance. It's about achieving the best possible performance for whatever system it's running on.

Maybe you think because I said VR it must mean I need to be running on massive gaming rigs. We run quite nicely on 5 year old smartphones, too. We run a pancake mode for people without VR. We run on every headset on the market, and we don't have to pay a lick of attention to what Facebook or Google or Apple thinks should and should not be in their app stores. And we can do this because of the broad range of browser APIs.

Maybe you do not know what words in the English language mean? I have a Quest and an Oculus VR and a Samsung Gear VR and a shitty cardboard daydream.

I get how concurrency works. I do not get how you get any sort of useful information from my desktop claiming 12 threads, to my phone claiming 8 threads, to my quest claiming 6 threads, to my ipad/samsung tablet claiming however many threads over webxr.

I do not see how you can do anything useful with the thread count which is what I have been disputing. CPU thread count seems especially useless since it has no relation to VR performance.

How many concurrent operations I can run. I use it to download and decode textures and audio data. Without it, you're waiting 15 second between scene transitions, massively dropping frames all the while. With it, is 1 second and there is never a hitch.