ainurakne

I absolutely love everything about the new parts. Well done @Porkjet! I can't wait to see all of them completely finished.

But they do stall. Cache misses, branch mispredictions, data dependencies - these all cause stalls, unless you are talking about a branchless program that fits entirely in a level 1 cache (including all the data it processes) and doesn't have any consecutive instructions that depend on each other's results. Also, thread synchronization. Unless you can get the job done with only spinlocks and atomics, your thread is bound to block at some point and get pulled out from the processor to give room for the other threads that are eagerly waiting for their turn. So, the more of those other threads are sitting on some cores, the better for your thread. But... managing the sharing of execution resources on a core has its cost. So, if your game has lots of busy rarely-stalling and rarely-blocking threads that, because of the lack of free resources, are put at the same time on the same core by hyperthreading, then this can be bad. In this case, hyperthreading can reduce performance. Maybe the people who don't understand hyperthreading and what's it actually good for, also don't mostly need it. I'm not really sure myself either about how it actually works, but I hope they don't just wait for the other one to get stalled and instead they're execution is more or less interleaved without the cost of context switches (and rescheduling). Getting to do your job while the other one is stalled is just bonus. Also, as I have understood, stalls are actually quite frequent.

Hyperthreading means that the register sets of processor cores are duplicated. This means that two processes/threads can simultaneously sit on a single core, sharing its common execution resources. When the execution of one process/thread stalls (which happens quite often), the other one can jump in without the need of expensive context switch. So, hyperthreading actually means 2x less rescheduling than without hyperthreading.

I'm also interested about the GPU side of the things. I play KSP on Linux, so OpenGL is my only option (until Vulkan support comes ). So, does the current version of Unity already support core profiles of OpenGL versions of 3.2 and up (or does it still use legacy OpenGL 2.1 only)? If not, will the Unity version that KSP 1.1 uses, support it? The performance difference between OpenGL 2.1 and OpenGL 4.x is actually pretty significant (depending on how well the API is used, of course).

How about starting with making tank-shaped tanks: Tanks would have hemispherical ends and the middle part would be covered with an outer-shell (grey part in picture 1) - this is the aerodynamic/supportive shell, that has some kind of paintjob on it and covers the metallic or single-colored capsule-shaped tank. When tanks are stacked together (or otherwise stacked to something round with similar size) their outer shells would be connected with a fairing-like thingy (blue part in picture 2) to cover the hemispherical ends. Or maybe it would be better and/or simpler if the skirts (extensions of the outer shell) would be toggle-able (red parts in picture 3). In that case you could choose yourself whether you want the hemispherical ends to be covered or not, depending on what the tank is attached to. Or maybe instead a solid skirt you want a mesh or supportive struts or something. Or the whole outer shell could be toggle-able (red part in picture 4). Then you could also use "naked" tanks (tanks without aerodynamic/supportive shell) if you want. This would also allow spherical tanks, because a capsule that is short enough, is a sphere. Engines could be just an engine bell with a combustion chamber (and turbopumps) that have some kind of supportive "legs" and/or pipes on the upper end (without tank-butt or any other large structure). Since engines would be surface-attachable, you could place them anywhere (and in any number) under the tank. This of course makes stacking other stages below such an engine cluster problematic. But maybe it could be possible to attach the decoupler to the upper tank while leaving enough space for the engines, and then a fairing would connect the decoupler to the upper tank (of course the engines should also horizontally fit into the fairing). Or maybe you could build the fairing yourself from the decoupler, without using a fairing base. What do you guys think? Would it be something that would be possible? Would it be something that you would like?

Compression is usually one continuous process. So, if there aren't many other running tasks that demand lots of processor time, your compression task is probably rescheduled only if the core it runs on starts to heat up. Hence the switching two or three times a minute. Rendering and physics threads usually run in cycles (for examples 60 cycles per second) with somekind of sleep or yield (or somekind of synchronization) between the cycles. So, they are rescheduled after every cycle anyway. Depending on how much other stuff currently runs on the processor, how many cores there are and how hot each core is, rescheduling will most likely also cause core switching.

Ok, I had a successful landing. I filled the wings with fuel before launch (but also made my re-entry trajectory as shallow as I could). It was a really close call as the temperature of those wing strakes rose up to over 1800 degrees, but fortunately the speed was already low enough by that time. So it is doable, but really hard. I guess what amplifies the problem is that the wing strakes are attached to the cargo bay, which is hollow and thus has less thermal capacity, which means it gets hot faster than non-hollow parts (which was also visible using the thermal debug overlay). So the wing strakes that already have quite low thermal capacity have nowhere to conduct their heat to.

I have the exact same problem with the same parts with pretty similarly shaped shuttle-like spaceplane. I have tried my descent many times over and over, using heat debug colors/temperatures to see what's going on, and they always get really hot and go *poof* much before the reentry effects kick in. At the time everything around them remains relatively cool. It seems there are some problems with heat flux for this part - for some reason it absorbs heat really fast but gives it out very poorly, compared to other parts. I have thought about raising its heat capacity by filling it up with liquid fuel, but haven't had time to test it out yet.

As I understand, you are still on Kerbin's orbit? I don't think it can even go much lower than 290 K there (unless you use somekind of shades). The Sun radiates heat and nearby planets/moons also supposedly radiate/reflect heat. For example, if I went close enough to The Sun, it got so hot that it started to eat away the ablator from the heatshield I used to protect my craft with. I haven't tried any resource thingies myself yet, but 290 K is around normal room temperature and it really shouldn't overheat things (unless there is some bug). I have noticed that if I turn the timewarp up near maximum, then the heat suddenly "normalizes" (drops or goes up) to the point that is averagely expected at that distance from The Sun. If that doesn't happen in your version KSP, then there may be somekind of bug.

I have started to notice that too, but only recently, since I started to try out large Mk3 space planes with lots of parts - I never noticed it before with smaller grafts. (I've got GeForce GTX 560 Ti) I haven't paid much attention to it, so I am not sure whether it's GPU or CPU, but it seems that one of them chokes because the calculations performed to visualize said effects are very intense. Sorry, I have no idea how or if this can be solved. Hopefully these effects will be optimized in 1.0.

I always get this whine if VSync / sync to vblank is disabled for whatever 3D application. When there is no limit, the GPU renders frames as fast as it can, hence the extreme load. It can also choke the CPU, which must then execute rendering loop continuously without a break to feed the GPU with the data and rendering commands. Check KSP VSync or framerate limiting settings under graphics tab. Hope that helps. EDIT: I've got Linux Mint 17.1 myself, using GTX 560 Ti with proprietary drivers. I recall that when 0.90 came out, I had some problems, because those settings didn't work as they used to anymore. In the end I settled with VSync turned off and framerate limiter set to 60 FPS. That did the trick for me.

Hello, I hope everything is legit here. Stock KSP, without any mods. 243.8t ship with 60 parts. Interestingly past 15 km/s, the orbital and surface velocities started to differ more and more. At the end of the SOI the orbital velocity was 24242.1 m/s while at the same time the surface velocity (from Kerbin's surface) was 34513.8 m/s. I guess orbital velocity is the one that counts in this challenge? http://imgur.com/a/QNqfu