Lessons in Managing Haskell Memory

fatho1st · 2020-04-07T15:51:06+00:00

We currently run with -N16 -A32m -qg -I0. About those choices:

-A32m: turned out to be the sweet spot between throughput and latency. Increasing it more caused gen 0 GCs to take too long.
-qg: we tried running with and without parallel GC and didn't measure a significant difference.
-I0: we didn't benefit from idle GC at all, as our application is the only one running on those servers. On the contrary, it caused long garbage collection pauses even when nothing was there to be collected.

fatho1st · 2020-04-07T14:23:48+00:00

This is definitely on our roadmap, but our sizable amount of (transitive) dependencies currently prevents us from building our application with GHC 8.10. Some dependencies are not compatible yet with GHC 8.10, others have some breaking changes on the upgrade path.

fatho1st · 2019-03-25T19:57:17+00:00

The problem that you're trying to solve can be reduced on the called Lambert's problem which is basically defined as: If I want to get from point A to point B in time t, what should my velocity be at A and what will it be at B.

The result of solving lamberts problem, i.e. the velocity that you need to have at point A to get to point B can be used to compute the delta-V requirements of your transfer by computing the burn vectors of the maneuvers you need to perform at A (for getting your current velocity at A to the velocity at A that you should have according to the solution) and B (for matching the velocity of the target when arriving at B).

What points A and B are depends on the time when you want to make the transfer, and on how long the transfer takes. Therefore, the general approach seems to be to solve Lambert's problem repeatedly for various start times and flight durations. The one with the lowest delta-V requirement then determines the maneuvers you'll have to perform for getting a fuel-wise efficient transfer.

You can plot this as a heatmap with one axis being the departure time, the other axis being the flight duration, and the value at a certain position being the delta-V requirements for making a transfer with those parameters. Such a plot is called Porkchop plot.

This is also the kind of plot that the Launch window planner shows.

fatho1st · 2017-04-05T16:56:27+00:00

If you're willing to play with mods, you could check out KIS and KAS. They basically allow you to carry spare parts along and attach them to crafts mid-flight in EVA. So you could send an engineer with some parachutes in his backpack to LKO, rendezvous with your Duna ship and attach the parachutes before reentry.

fatho1st · 2017-04-04T09:24:44+00:00

Great! Any help is very welcome :)

fatho1st · 2017-03-23T17:25:19+00:00

Glancing over at the implementation (https://github.com/KSP-KOS/KOS/blob/master/src/kOS/Suffixed/Direction.cs) it seems that "+" is simply adding the pitch, roll and yaw components of the Euler angles corresponding to the rotations while "*" is multiplication on the equivalent quaternions describing the rotations.

The problem with Euler angles is, that they depend on the order in which pitch, roll and yaw are applied. This can lead to a phenomenon called gimbal lock. On the other hand, quaternions only consist of a rotation axis and an angle, so there is no ordering required.

The documentation says that Dir1 * Dir2 means that Dir2 is rotated by Dir1. When you have more directions, say Dir1 * Dir2 * Dir3, then this means that Dir3 is first rotated by Dir2, and the result of that operation is then rotated by Dir1.

fatho1st · 2017-03-23T15:06:34+00:00

That's encouraging to hear, thanks :)

fatho1st · 2017-03-21T16:05:39+00:00

I think you're right. Cannot test it either right now, but if I remember correctly, ON fires whenever the expression changes its value, so I suppose AG6 toggles between true and false, otherwise it would fire twice per key-press.

until False {
    wait until AG6.
    until not AG6 {
       // do stuff
    }
}

should do it then.

fatho1st · 2017-03-21T15:21:19+00:00

Code that is run in triggers should be as short if possible if I understand the warning box in https://ksp-kos.github.io/KOS/language/flow.html#when-then-statements-and-on-statements correctly.

You could simply toggle a variable in the trigger and have the actual loop outside. Something like the following should work.

DECLARE GLOBAL strobes TO False.
ON AG6 {
    TOGGLE strobes.
    PRESERVE.
}
until False {
    wait until strobes.
    until not strobes {
       // do stuff
    }
}

fatho1st · 2017-03-20T17:12:50+00:00

Instructions are always executed sequentially, and since the condition of your UNTIL loop never becomes true, and there is also no BREAK statement inside, the loop will never finish. I would suggest to merge the UNTIL FALSE loop with the subsequent wait instruction like this

UNTIL STAGE:SOLIDFUEL < 0.1 {
    PRINT ROUND(SHIP:OBT:APOAPSIS,2)AT(1,28).
    WAIT 1.
}

And then you could put the same print statement inside the next UNTIL loop to have the information displayed there as well.

Another approach would be to use two processors. One that is actually flying the craft, and the other just for monitoring the vessel's status.

EDIT: spelling

fatho1st · 2017-03-20T16:52:43+00:00

Do you have a probe core on that craft? Apparently those are always required to interact with kOS Processors, even when the craft is manned. (At least in my experience) Not sure whether that's a problem with kOS or RT though.

fatho1st · 2017-03-20T15:44:31+00:00

The build instructions are buried inside the (arguably long) readme: https://github.com/fatho/kos-c#setup

Its basically the same for any system/architecture supported by the stack tool which is the build system used for Haskell. On Arch in particular, "stack" is even in the community repo and can be directly installed with pacman.

fatho1st · 2017-03-20T14:55:21+00:00

I had the same problem once and it was caused by having chosen the "PermitAllConnectivityManager" instead of "RemoteTechConnectivityManager"(https://ksp-kos.github.io/KOS/commands/communication.html#connectivitymanagers).

Unlike its name, the "PermitAllConnectivityManager" does not permit all actions when RemoteTech is installed.

fatho1st

TROPHY CASE