douglar wrote on Yesterday, 18:44:

Most companies have more diversity consultants that developers? Good grief. This thread should get renamed to “Hot takes that dont stand up to any sort of scrutiny”

Nationally there are low thousands of diversity consultants out of 160 million workers ,(less than a thousandth of a percent?)
I think we are safe.

What I find funny is the people who are supposedly against whatever it is they think an employee of that type does
seem to inject diversity into every topic accomplishing the opposite of their intent.

The anti cancel culture folks seem to support cancel culture more avidly than anyone else.

65C02 wrote on Today, 00:14:

Ffs, not again. Vogons doesn’t need this. There was recently a thread that mentioned how some long time posters don’t visit vogons anymore. I suspect one reason is that posts like this regularly appear in milliways now.

Small angry men ruin things, that's just what they do.

I think the bigger problem is that multithreaded game engines are really hard.

The painting can and has been made parallel.

The main thread is more difficult to break out into discrete chunks, and keep operating in sync.

Sure, you can break out sound, networking, and other elements, but their requirements are relatively trivial. 1 spare core from 15 years ago could do all of that.

The "best" gaming CPU is practically always in every generation the one with the most mhz.

Right now, if it was possible to build a lopsided dual core with 25ghz for one and a sidekick core of say 2ghz, it would most likely win all the gaming benchmarks.

That's the biggest problem. It is hard to break up the main thread and keep it all in lockstep.

The graphics card does all the painting.

Multithreading is not hard. It is basically a system of message queues and locks.

What gets challenging is the scheduling of the threads. The application is not guaranteed when which thread will be given some cpu, that is why the locking is so important to ensure nothing that shouldn’t be gets front run.

The main game loop needs to do stuff in a specific order to maintain a coherent state, and finding meaningful stuff to spin off into separate threads is rather moot.

A thread that does spatial audio and just periodically receive events and updates can work great, as it can continue and does not need to phone back with anything time critical.

Otherwise, AI threads performing an advisory role on enemy behaviour can also do heavy work in parallel and update enemy models when it phones back, which the main thread then executes at the relevant point in the gane loop.

Networking is part of the main loop. State ks transmitted at a certain point and sockets read (packets already caught by kernel) - this really does not take much time at all and the variables it touches is in the main thread anyway.

Cannot really think of anything else that can gain much from threading.

st31276a wrote on Today, 05:33:

The graphics card does all the painting. […]
Show full quote

The graphics card does all the painting.

Multithreading is not hard. It is basically a system of message queues and locks.

What gets challenging is the scheduling of the threads. The application is not guaranteed when which thread will be given some cpu, that is why the locking is so important to ensure nothing that shouldn’t be gets front run.

The main game loop needs to do stuff in a specific order to maintain a coherent state, and finding meaningful stuff to spin off into separate threads is rather moot.

A thread that does spatial audio and just periodically receive events and updates can work great, as it can continue and does not need to phone back with anything time critical.

Otherwise, AI threads performing an advisory role on enemy behaviour can also do heavy work in parallel and update enemy models when it phones back, which the main thread then executes at the relevant point in the gane loop.

Networking is part of the main loop. State ks transmitted at a certain point and sockets read (packets already caught by kernel) - this really does not take much time at all and the variables it touches is in the main thread anyway.

Cannot really think of anything else that can gain much from threading.

One of the biggest hurdles for efficient and timely multithreading is windows itself, AMD had to fix it themselves via their chipset drivers and IIRC Intel did the same thing as the standard Windows scheduler is fucking terrible at handling chiplet CPUs with non heterogeneous designs like the Intel 14th/15th gen or Ryzen multi CCD CPUs like the 9950 X3D with one CCD having no X3D cache. (I know 14th gen isn't chiplet .. but its has the same problem with big little design)

douglar wrote on Yesterday, 18:44:

Most companies have more diversity consultants that developers? Good grief. This thread should get renamed to “Hot takes that dont stand up to any sort of scrutiny”

Yes, especially when talking about software engineering, RAM usage, lazy devs and such.

It is ridiculous and absurd.

xcomcmdr wrote on Today, 07:17:

douglar wrote on Yesterday, 18:44:

Most companies have more diversity consultants that developers? Good grief. This thread should get renamed to “Hot takes that dont stand up to any sort of scrutiny”

Yes, especially when talking about software engineering, RAM usage, lazy devs and such.

It is ridiculous and absurd.

Unless we want this thread gutted or binned I feel we should just move on, nothing useful will be gained by dwelling on it.

st31276a wrote on Today, 05:33:

The graphics card does all the painting. […]
Show full quote

The graphics card does all the painting.

Multithreading is not hard. It is basically a system of message queues and locks.

What gets challenging is the scheduling of the threads. The application is not guaranteed when which thread will be given some cpu, that is why the locking is so important to ensure nothing that shouldn’t be gets front run.

The main game loop needs to do stuff in a specific order to maintain a coherent state, and finding meaningful stuff to spin off into separate threads is rather moot.

A thread that does spatial audio and just periodically receive events and updates can work great, as it can continue and does not need to phone back with anything time critical.

Otherwise, AI threads performing an advisory role on enemy behaviour can also do heavy work in parallel and update enemy models when it phones back, which the main thread then executes at the relevant point in the gane loop.

Networking is part of the main loop. State ks transmitted at a certain point and sockets read (packets already caught by kernel) - this really does not take much time at all and the variables it touches is in the main thread anyway.

Cannot really think of anything else that can gain much from threading.

"multithreading isn't hard"

*Lists all the things that make it hard.*
*Repeats what I said in different ways.*

🤣?

Trashbytes wrote on Yesterday, 16:22:

Edit - Not looking to hurt anyone's feelings with words on the internet. Also not a part of whatever thread occurred recently ...that caused people to get hurt feelings.

But clowns would make better software at this point. I saw what you wrote there originally.
---
I occasionally look at new computers. I noticed one model with Intel Core Ultra 7 265KF, 64 GB of RAM, NVIDIA GeForce RTX 5070 Ti and 2 TB SSD, it costs about 3250 €. Any guesses how much it would cost before the price explosion in recent years?

This is actually still in the relatively lower range, I noticed one model that costs over 11500 €.

myne wrote on Today, 07:54:

"multithreading isn't hard" […]
Show full quote

"multithreading isn't hard"

*Lists all the things that make it hard.*
*Repeats what I said in different ways.*

🤣?

😮 ?

Nothing about it is hard.

The problem does not scale.