I'm trying now to figure out the best compromise of threads for my rig (2 appears to be acceptable, I will try 4 on my next time window for this). Right now, I'm being able to run KSP >= 1.8 on my oldest rig by using this trick.
#KSP MAC MINI 2012 MAC#
My less old Mac Potato 6.2 managed to withhold some more abuse from KSP 1.8.0 to KSP 1.11.2 because it have twice the cores of my previous rig, but now on KSP 1.12.0 someone increased the default number of threads per CPU again (or something similar), and it screwed up my i7: there's no point on increasing the working threads with spinlocks, all you will get is more threads waiting for something that will never happens because your threads are preventing everything else to run! Aftermath Barely, the game is still sluggish but the rest of the machine is useable! I can even watch Youtube videos while running KSP 1.8.1, something that was impossible for this machine 17 months ago! My old Mac Potato 5.1 is now able to run KSP 1.8.1. On exit, the environment variable will be lost, so no chance for it to linger and end up screwing up some other process you call later.Īnd that, my friends, solved the problem for me. KSP.app/Contents/MacOS/KSP will set the environment variable and then call the executable KSP.
![ksp mac mini 2012 ksp mac mini 2012](https://media.wired.com/photos/59330477b44176024420f651/master/w_640%2Cc_limit/mozilla-mac-mini.jpg)
Since I'm on a UNIX machine, this is what I did:
#KSP MAC MINI 2012 CODE#
:)īy limiting this number, we would have less spinlocks on the process, and so the poor CPU would have a better chance to do its job instead of spinning around the same code waiting for something that will never happens because the CPU is being completely screwed up by the waiting threads. It tells mono to, well, limit the number of threads per CPU.
![ksp mac mini 2012 ksp mac mini 2012](https://gajitz.com/wp-content/uploads/2013/09/back-of-mini-mac.jpg)
Remembering a very productive exchange with darthgently, I decided to use one of the tricks he taught me, the MONO_THREADS_PER_CPU environment variable. What explains a lot - semaphore_wait_trap is used without a mutex, and so somebody somewhere is using a spinlock to do the job - you know, we need to synchronize things between threads, right? Kr = semaphore_wait_signal_trap(cond_sem, mutex_sem) It's not a surprise Refunding was provoking a memory leak - there're som many threads busy waiting for the GC that there's no CPU left for the GC itself, and so we have a dead lock!!!Įvery single thread, including OSX HID Input (Human Interface Devices) are boggling the CPU at 100%! It's evident now why the input is so sluggish when your crafts gets to big for your rig!!!!ĭigging a bit more on the subject around the Internet, I came to a Swift code like this one: if (mutex_sem != 0) LOTS AND LOTS OF THREADS hogging up 100% of the CPU, a clear indication of busy waits! Checking the other threads of the KSP's process, I got horrified! It ended up being (another) bug on KSP that was causing a memory leak, that was triggering the GC a lot, that was being sabotaged by spinlocks on the waiting threads!Ĭhecking the worst processor hogs on the KSP's process, it came to my attention that almost 100% of the CPU time was being used on a system call related to Semaphores inside an Unity thread, the dispatch_semaphore_wait_slow that by itself was spinning around os_semaphore_wait that by its turn was calling semaphore_wait_trap: I then optimised a bit the memory usage, but the bulling just would not stop. At that time, I had pretty little time to fool around and made things the fast as I could in order to work around the problem under my nose, rushed the thingy into the Mainstream and gone back to day job, and by doing this I ended up bullying the GC. :Pīut then I realized I made a less than ideal decision making on a thingy called Refunding from KSP-Recall. I still can run KSP 1.12 for some "quick" and small tests and use 1.11 for the main workload until I figure out a way to buy yet another new old potato.
![ksp mac mini 2012 ksp mac mini 2012](https://sv1.picz.in.th/images/2021/03/04/omm2Zb.jpg)
The new old Potato ended up handling KSP >= 1.8.0 and that allowed me to keep using it for development (besides KSP 1.7.3 still being way more performatic, being the reason my main playing is still 1.7).Īnd so KSP 1.12 came, and screwed everything again: KSP 1.12 did to my Mac Mini 6.2 what KSP 1.8 did on the 5.1. Since I was going to buy a new old rig anyway (that by pure chance ended up being an Mac mini 6.2 - 4 Cores, 8 HTs), I didn't gave it to much attention. Everything were stuttering, it was impossible to watch a video! Facebook, Youtube, command line terminals, you name it. I just could not fire up KSP and keep the machine useable - the whole thing started to stutter. came, using Unity 2019, my old Mac Mini 5.1 (i5, 2 cores, 4 HyperThreads) didn't handled it.