| 1 |
I believe this strategy has been discussed before.
|
1 |
I believe this strategy has been discussed before.
|
| 2 |
\n
|
2 |
\n
|
| 3 |
The main problems with multithreaded unit scripts are
|
3 |
The main problems with multithreaded unit scripts are
|
| 4 |
1.
you
would
need
a
lua
context
for
every
unit.
You
may
have
64GB
of
RAM,
but
most
people
don't.
The
Spring
engine
is
already
very
memory
intensive
|
4 |
1.
you
would
need
a
lua
context
for
every
unit.
You
may
have
64GB
of
RAM,
but
most
people
don't.
The
Spring
engine
is
already
a
massive
memory
hog
|
| 5 |
2. you would need to communicate with the global game state via message passing, incurring even bigger overhead than Lua->C interop
|
5 |
2. you would need to communicate with the global game state via message passing, incurring even bigger overhead than Lua->C interop
|
| 6 |
3. you would need to execute in sync over a network- meaning 'messages' to SyncedRead/SyncedCtrl will need to be in the same order for every client
|
6 |
3. you would need to execute in sync over a network- meaning 'messages' to SyncedRead/SyncedCtrl will need to be in the same order for every client
|
| 7 |
\n
|
7 |
\n
|
| 8 |
1 can be somewhat alleviated via some artificial environment and 'pinning' said environment to a specific thread context, but 2 can't. 3 is going to be a big problem.
|
8 |
1 can be somewhat alleviated via some artificial environment and 'pinning' said environment to a specific thread context, but 2 can't. 3 is going to be a big problem.
|
| 9 |
\n
|
9 |
\n
|
| 10 |
Besides, the other main performance issue with Zero-K is related to CPU-side rendering. There are a lot of draw calls, and maybe some things could be instanced, but I personally haven't touched the engine in a long time. If Spring Lua-side performance got too slow, then LuaJIT could be considered given it can be made to sync.
|
10 |
Besides, the other main performance issue with Zero-K is related to CPU-side rendering. There are a lot of draw calls, and maybe some things could be instanced, but I personally haven't touched the engine in a long time. If Spring Lua-side performance got too slow, then LuaJIT could be considered given it can be made to sync.
|
| 11 |
\n
|
11 |
\n
|
| 12 |
GC is not a dated concept. It hasn't been phased out, many languages still rely on GC instead of manual memory management- many with great performance. Regarding mark and sweep GC (what Lua uses), how else will you deal with cyclic tables? Lua is a scripting language, and if I have to begin worrying about cyclic tables, then that scripting language isn't very good. The performance of GC vs reference counting (smart pointers) is debatable. Smart pointers are quite slow.
|
12 |
GC is not a dated concept. It hasn't been phased out, many languages still rely on GC instead of manual memory management- many with great performance. Regarding mark and sweep GC (what Lua uses), how else will you deal with cyclic tables? Lua is a scripting language, and if I have to begin worrying about cyclic tables, then that scripting language isn't very good. The performance of GC vs reference counting (smart pointers) is debatable. Smart pointers are quite slow.
|
| 13 |
\n
|
13 |
\n
|
| 14 |
Fun fact, there exists a garbage collector for C/C++: https://www.hboehm.info/gc/
|
14 |
Fun fact, there exists a garbage collector for C/C++: https://www.hboehm.info/gc/
|
Is there MT in zero-k?