freenode/#sbcl - IRC Chatlog
Search
21:57:53
aeth
Is there something considerably more efficient than sb-thread:condition-wait for this use case? Essentially... creating 3-255 threads and having them every 10 ms take input, do a computation, and pass the result(s) and then wait until the start of the new 10 ms period.
21:57:57
aeth
sb-thread:condition-wait will work, but it seems like it has a lot of overhead, repeatedly creating many things in a loop 100 times a second per thread.
0:08:59
aeth
pkhuong: 256 (counting the main thread) is just future proofing things, but it's actually not *very* future proof because you should be able to get a 2x 64c 128t x86-64 CPU server at some point this year.
0:11:36
aeth
but it's more like if it's designed to handle the 64-256 extreme end of today, it can probably handle even 1024+ in the more distant future.
0:19:38
aeth
This is for a game engine's game loop so 95% of non-server users are probably going to be using Windows SBCL
0:20:43
aeth
The high end enthusiast desktop CPU by AMD is going to be 64c 128t this year, and it's going to take me years to finish this.
0:21:47
aeth
It's possible that 128 will be the practical peak of the current architectures, though.
0:22:06
aeth
It's also possible that only using 64 threads would actually be more efficient on that CPU
0:25:16
aeth
Depends on the programming language, game engine architecture, and type of game. AAA games will basically always just take 100% of the GPU with the CPU as something fairly irrelevant, but there are some rare simulation-ish games that do try to use lots of threads.
0:27:57
aeth
The architecture I'm probably going to go for is that each major system will get its own thread and then if it makes sense for it to be divided up further (e.g. maybe the AI or the physics), then I'll just max things out.
0:29:50
aeth
So it wouldn't be 1 thread talking to 255, it would be maybe 1 talking to 4, and of those 4 2 of them might split the remaining available threads.
0:31:03
aeth
The important thing is that I want to be able to synchronize the logic to discrete steps (ticks, which can probably even be represented as ub64s) every 10 ms
0:33:21
aeth
One complicating factor when turning this into real threads is that the rendering will probably not happen in that step, and could be every 16.7 ms or even every 7 ms.
0:43:14
aeth
Is supporting Threadripper's full capabilities overkill for this? Absolutely, but it's an interesting problem because it would be 128 threads that (potentially, probalb) need to synchronize state every 10 ms.