raptop changed the topic of #principia to: READ THE FAQ: http://goo.gl/gMZF9H; The current version is Fréchet. We currently target 1.5.1, 1.6.1, and 1.7.x. <scott_manley> anyone that doubts the wisdom of retrograde bop needs to get the hell out | https://xkcd.com/323/ | <egg> calculating the influence of lamont on Pluto is a bit silly… | <egg> also 4e16 m * 2^-52 is uncomfortably large
Jesin has quit [Quit: Leaving]
Jesin has joined #principia
<discord-_>
egg. — @neph I should have a build of Fubini for you to test tomorrow, so you can try your sounding rocket with the new angular momentum correction approach
<discord-_>
egg. — hopefully it will spin less? who knows
<discord-_>
neph. — This is very exciting!
<discord-_>
AgustinCaniglia. — when is next release?
<discord-_>
Pteropodidae. — @dkavolis You actually managed to get cmake builds for Principia working?
Webchat307 has quit [Quit: webchat.esper.net]
<discord-_>
Pteropodidae. — I remember looking into that back when the Makefile build was introduced, but egg told me the same thing he told you and I stopped soon after
<discord-_>
egg. — The Makefile has been satisfyingly low-maintenance in hindsight
<discord-_>
egg. — @Pteropodidae does the new install_deps work well for you?
<discord-_>
Pteropodidae. — Is there anything in the props files that aren't in the Makefile or vice-versa?
<discord-_>
egg. — we’ll probably move the pipelines over to it immediately after releasing Fubini
<discord-_>
Pteropodidae. — I actually haven't tried the new install_deps after making my changes
<discord-_>
egg. — the props have a completely different structure, they talk to a different compiler which wants different options, and where the dependencies aren’t even built in the same way (iirc gmock is built as part of principia on *nix, but separately on Windows)
<discord-_>
Pteropodidae. — The new install_deps worked back when I made the changes, for what it's worth. I'm on my Windows partition right now and can't reboot for the moment so I can't double-check
<discord-_>
egg. — if it worked at that point then it should hopefully still work
<discord-_>
Pteropodidae. — Keeping the props and Makefile in sync sounds fun
<discord-_>
egg. — unless it is very cursed
<discord-_>
egg. — mostly we don’t need to, though
<discord-_>
egg. — a lot of stuff that is at the language level happens completely independently in MSVC and clang
<discord-_>
egg. — so if we need to tweak a warning or version flag, it happens in one place or the other
<discord-_>
Pteropodidae. — I mean, it's a build system. They're always cursed in some way or another 😛
<discord-_>
egg. — the makefile is iirc also less strict/more robust (because the sanity checking matters more on the development platform than in other targets), so it makes all deps available to all targets
<discord-_>
Pteropodidae. — Huh
<discord-_>
egg. — whereas on Windows we explicitly say, e.g., that the physics test suite depends on zfp (but not the geometry one)
<discord-_>
Pteropodidae. — I guess that's something that a cmake build could specify dependencies more precisely, but guess there might not be much real benefit to doing so
<discord-_>
Pteropodidae. — `target_link_libraries` and such
<discord-_>
egg. — yeah, we want it to just-work in *nix as much as possible once we have made sure the source makes some sense on windows
<discord-_>
egg. — we had vaguely looked into using bazel but it turns out that it cannot into Unicode so screw that
<discord-_>
egg. — (protoc also cannot into Unicode identifiers, we should fix that in our fork at some point)
<discord-_>
lpg. — why, oh, why did I make that comment about timing polar TLI being "trivial" shortly before doing my first of the career
<discord-_>
neph. — It's not that bad 🙂
<discord-_>
lpg. — it's not. I've just lost muscle memory
<discord-_>
neph. — You just have to get lucky with your downrange distance of your LV's lower stages
<discord-_>
neph. — At least, for direct ascent
<discord-_>
lpg. — oh I'm not touching _that_ one
<discord-_>
neph. — Then it's even easier! Hell, if you had the longevity on your probe you could just launch whenever and stay in LEO until you're lined up to hit the moon
<discord-_>
neph. — With non-direct polar TLI, you've got a pair of launch windows every day
<discord-_>
lpg. — if you're under the impression I'm asking for help, you've missed the humorous intent of my initial coment
<discord-_>
lpg. — if you're under the impression I'm asking for help, you've missed the humorous intent of my initial comment (edited)
<discord-_>
neph. — But it is trivial
<discord-_>
lpg. — I know
<discord-_>
lpg. — and yet
<discord-_>
lpg. — I can usually eyeball it without even thinking. probably my mistake has been to think about it this time
<discord-_>
Pteropodidae. — What is it with new build tools and not supporting Unicode
<discord-_>
Pteropodidae. — Or at least the impression
<discord-_>
egg. — 6 bit should be enough for anyone
* discord-_
Pteropodidae. — slaps an engineer with 640KiB_
<discord-_>
Sir Mortimer. — but it looks nothing like this -> 💩
<discord-_>
Pteropodidae. — I mean, if you squint reaaallllllly hard....
egg|cell|egg has quit [Ping timeout: 378 seconds]
<discord-_>
Sir Mortimer. — btw, I think the french affinity to little small brittle all over (and under!) their characters leads to an effect that could be described as visual pollution: too much going on in the text to process at a glance. that in turn, I think, is the reason why the french have a tendency to do what germans call *plenken* (typographical term for the insertion of inappropriate spaces before a punctuati
<discord-_>
dkavolis. — > @dkavolis You actually managed to get cmake builds for Principia working?
<discord-_>
dkavolis. — @Pteropodidae Yeah, but only tested with MSVC and Clang-cl 10.0 so far, will try WSL for Unix later. Will upload to a fork Principia once I'm satisfied.
<discord-_>
dkavolis. — @egg Is it okay if I make necessary PRs needed to make everything compile with Clang-cl? And possibly other compilers, maybe Mingw
<discord-_>
dkavolis. — > @dkavolis You actually managed to get cmake builds for Principia working?
<discord-_>
dkavolis. — @Pteropodidae Yeah, but only tested with MSVC and Clang-cl 10.0 so far, will try WSL for Unix later. Will upload to a fork Principia once I'm satisfied.
<discord-_>
dkavolis. — @egg Is it okay if I make necessary PRs needed to make everything compile with Clang-cl? And possibly other compilers, maybe Mingw (edited)
<discord-_>
dkavolis. — Had to disable some tests though due to unicode issues
<discord-_>
Pteropodidae. — Did you try running the benchmarks? Might be interesting to see if clang-cl optimizes better
<discord-_>
Pteropodidae. — What changes did you have to make?
<discord-_>
Pteropodidae. — (Assuming there were non-CMake changes made)
<discord-_>
dkavolis. — From the few benchmarks I ran, clang was very slightly faster. Had to remove vectorcall flag in clang, other changes were warning flags mostly
<discord-_>
dkavolis. — Principia benchmarks take a long time to run
<discord-_>
dkavolis. — Clang binaries are also smaller
<discord-_>
dkavolis. — Clang was complaining about
<_whitenotifier-d13c>
[Principia] pleroy labeled issue #2504: Clean up after the Frobenius fix - https://git.io/JvyhO
egg|cell|egg has joined #principia
<discord-_>
egg. — > PRs needed to make everything compile with Clang-cl
<discord-_>
egg. — What does that entail? We don’t want to add another build config, because it is going get in our way and to rot immediately due to disuse.
<discord-_>
egg. — Are there source changes that are nonconformance/bugs on our part ?
<discord-_>
egg. — > An inline function or variable (since C++17) with external linkage (e.g. not declared static) has the following additional properties:
<discord-_>
egg. — > There may be more than one definition of an inline function or variable (since C++17) in the program as long as each definition appears in a different translation unit and (for non-static inline functions and variables (since C++17)) all definitions are identical. For example, an inline function or an inline variable (since C++17) may be defined in a header file that is #include'd in multiple source
<discord-_>
egg. — cppreference says
<discord-_>
egg. — > An inline function or variable (since C++17) with external linkage (e.g. not declared static) has the following additional properties:
<discord-_>
egg. — > There may be more than one definition of an inline function or variable (since C++17) in the program as long as each definition appears in a different translation unit and (for non-static inline functions and variables (since C++17)) all definitions are identical. For example, an inline function or an inline variable (since C++17) may be defined in a header file that is #include'd in multiple source
<discord-_>
egg. — > It must be declared inline in every translation unit.
<discord-_>
egg. — > It has the same address in every translation unit. (edited)
<discord-_>
dkavolis. — I assume it's a bug on clang side
<discord-_>
egg. — that is how I would read it, yes
<discord-_>
dkavolis. — ksp_plugin\pile_up.hpp(229,7): note: move assignment operator of 'PileUp' is implicitly deleted because field 'euler_solver_' has a deleted move assignment operator
<discord-_>
dkavolis. — euler_solver_;
<discord-_>
dkavolis. — ^
<discord-_>
dkavolis. — ```
<discord-_>
egg. — yeah we should do a pass over those warnings at some point
<discord-_>
egg. — I should it breakfast
<discord-_>
egg. — I should eat breakfast (edited)
<discord-_>
dkavolis. — looks like it though it doesn't work in 64 bit mode as well now
<discord-_>
dkavolis. — a bug from 2016...
<discord-_>
dkavolis. — I guess I can try compiling zfp only with MSVC
<discord-_>
egg. — on a nontrivial codebase like this every compiler will have a slightly different opinion of the language, it is probably not worth wasting too much time on these things tbh—after all, we can compile for windows so it is not like there is a problem
<discord-_>
egg. — the fact that we continuously compile with MSVC + 2 clangs (one on mac and one on ubuntu) gives us some confidence that we don’t completely fall into MSVCisms
<discord-_>
dkavolis. — MSVC is often silly
<discord-_>
egg. — so is clang, at times
<discord-_>
egg. — MSVC got much better in recent years
<discord-_>
dkavolis. — Yeah, and windows dev is no longer a pain with vcpkg
<discord-_>
egg. — there are probably some nontrivial questions of standard interpretation where MSVC and clang have the same unorthodox reading (there is one pattern in particular,
<discord-_>
egg. — ```C++
<discord-_>
egg. — using MyFrame = Frame<enum class MyFrameTag>;
<discord-_>
egg. — I think the intellisense compiler actually dislikes it
<discord-_>
egg. — (I think I have a way to make it more clearly conformant but *shrug*)
egg|laptop|egg has joined #principia
<discord-_>
egg. — (the issue is the `FrameTag tag_ = FrameTag{}` whereas the actual `MyFrameTag` is probably incomplete, but clang and MSVC are happy :-p)
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #principia
<discord-_>
dkavolis. — Well, you're not really instantiating `MyFrameTag`
<discord-_>
dkavolis. — Looks like gcc might be a possibilty soon
<discord-_>
egg. — yeah though again, what problem does that solve :-p
<discord-_>
egg. — (in a similar vein I am pretty sure we would run into issues with libstdc++, since we only compile against either libc++ or the MSVC one)
<discord-_>
dkavolis. — curiosity
<discord-_>
egg. — I think we only have BMP identifiers so far
<discord-_>
egg. — we should solve that problem :D
<discord-_>
egg. — > you're not really instantiating MyFrameTag
<discord-_>
egg. — Well, I am using a constant expression of that type as a template parameter though
<discord-_>
egg. — so it probably shouldn’t be incomplete
<discord-_>
dkavolis. — Ohh
<discord-_>
dkavolis. — Well, gcc doesn't complain either
<discord-_>
egg. — hmm
<discord-_>
egg. — when I checked that one on godbolt GCC did not like it iirc
<discord-_>
dkavolis. — geometry tests pass with mingw
<discord-_>
dkavolis. — oh wait, I had it set to clang-cl
<discord-_>
dkavolis. — D:\KSP\Principia\astronomy\lunar_orbit_test.cpp(466,51): note: in implicit call to 'operator!=' for iterator of type 'const principia::physics::internal_discrete_trajectory::DiscreteTrajectory<principia::geometry::internal_frame::Frame<principia::astronomy::LunarSurfaceTag, principia::geometry::internal_frame::Arbitrary, principia::geometry::internal_frame::Handedness::Right, 0> >'
<discord-_>
egg. — @neph do you need a 1.7.3 and earlier or a 1.8.1 and later build to test 2519
<discord-_>
dkavolis. — Which benchmarks are the most relevant to KSP?
<discord-_>
egg. — tricky question, it kind of depends what you are doing
<discord-_>
dkavolis. — High timewarp/long flight plans
<discord-_>
dkavolis. — Or any other bottlenecks really
<discord-_>
egg. — continuous trajectory evaluation is probably a significant cost in a bunch of situations
<discord-_>
dkavolis. — Want to compare clang-cl with msvc
<discord-_>
egg. — so the ephemeris benchmarks, the polynomial ones, maybe the planetarium plot method ones
<discord-_>
dkavolis. — What are the lowest vector extensions you expect? Clang should have more options than msvc for optimization
<discord-_>
egg. — SSE2
<discord-_>
egg. — well, SSE3 I suppose
<discord-_>
egg. — note that most of the critical bits are written with intrinsics
<discord-_>
dkavolis. — I tried intrinsics in my code, couldn't beat GCC default generated ones
<discord-_>
egg. — we were able to handily beat MSVC, but also we have a vague idea of what is going on because we are using some reasonably classing polynomial evaluation techniques, and also because we know what happens to our numbers where it matters (the 3d vectors almost always stay together, and for the fairly critical polynomial evaluation don’t get mixed across dimensions) so packing them (into two SSE2 registe
<discord-_>
egg. — if we were to require FMA we would use one in the Estrin evaluator, if we required AVX we would put the entire R3Element in an AVX register
<discord-_>
egg. — @dkavolis note that you can compare the unintrinsiced code by setting PRINCIPIA_USE_SSE3_INTRINSICS
<discord-_>
dkavolis. — Thanks
<discord-_>
egg. — (the code in the else branch of that runs when we are in debug mode, so that it does not rot)
<discord-_>
dkavolis. — You're missing ifndef around it though
<discord-_>
egg. — what do you mean
<discord-_>
egg. — ah yeah we define it unconditionally
<discord-_>
dkavolis. — Fails if you pass it from command line
<discord-_>
egg. — this is intentional, we don’t want more knobs :-p
egg|cell|egg has quit [Ping timeout: 190 seconds]
egg|cell|egg has joined #principia
<discord-_>
egg. — @Sir Mortimer re. typesetting, note that the french thing with spaces before punctuation is not inappropriate in french, it is mandatory :-p
<discord-_>
egg. — @Sir Mortimer also, not entirely clear that this is linked to diacritics, e.g. Polish or Vietnamese, which have way more diacritics, do not space before :;!? as we do
<discord-_>
egg. — no space before `,` or `.`, thin nonbreaking space before `;`, `!`, or `?`, normal-sized nonbreaking space before `:`, and inside of « these »
<discord-_>
Sir Mortimer. — damint not enough batteries
<discord-_>
egg. — this on the other hand, benchmarks polynomials, as its name indicates
<discord-_>
dkavolis. — oh, it doesn't have top comment for your benchmark_automation
<discord-_>
egg. — yeah we should probably clean that up eventually (though tbh we rarely look at the results of that automation)
<discord-_>
egg. — the benchmarks mostly exist to help us answer some specific question and improve some specific bit, they don’t necessarily have general-purpose relevance
<discord-_>
dkavolis. — What should I set the repetitions and min_time to for polynomial benchmark?
<discord-_>
egg. — I don’t know
<discord-_>
dkavolis. — Is it a long benchmark?
<discord-_>
egg. — probably not, again, I don’t remember
<discord-_>
egg. — looks like it evaluates a polynomial 1000 times, so it should be rather on the short side
<discord-_>
egg. — Anyway, back to reviewing documentation
<discord-_>
egg. — largely the same or slower on Horner evaluation, oddly faster for some degrees on Estrin evaluation
<discord-_>
egg. — you are in fp-model=strict, right?
<discord-_>
egg. — then again with SSE3 you don’t get to use FMA so precise vs. strict should not matter
<discord-_>
dkavolis. — I didn't specify so it was default value but clang doesn't specify which one
<discord-_>
egg. — the default is precise iirc
<discord-_>
egg. — (it goes without saying that fast should not even be talked about here, since it will break many of the things we do)
<discord-_>
egg. — slightly surprised by the difference in performance on estrin, though I suppose MSVC does tend to emit a lot of dumb moves in some circumstances so that might explain it
<discord-_>
dkavolis. — In my experience MSVC generates slower math in general
<discord-_>
dkavolis. — It's not as good at optimization
<discord-_>
egg. — well, there are only so many things that you are allowed to do here anyway when it comes to optimizing these things—again, strict FP math, most optimizations are forbidden; there aren’t many loops or anything (and it can’t vectorize any more than we do, we choose the intrinsics already) so I think the big difference is in register allocation
<_whitenotifier-d13c>
[Principia] Myshiko commented on issue #2400: History persistence lets .sfs files get very large - https://git.io/JfUPO
<_whitenotifier-d13c>
[Principia] Myshiko edited a comment on issue #2400: History persistence lets .sfs files get very large - https://git.io/JfUPO
<_whitenotifier-d13c>
[Principia] Myshiko edited a comment on issue #2400: History persistence lets .sfs files get very large - https://git.io/JfUPO
<discord-_>
AgustinCaniglia. — so there is already a beta version ? Can I have a link to 1.8.1? or is it too much to ask 😄
<discord-_>
egg. — yes, by clicking on the link I gave @neph
<discord-_>
AgustinCaniglia. — oh okay I thought it was for 1.9.1 only Thanks!
<_whitenotifier-d13c>
[Principia] pleroy commented on issue #2400: History persistence lets .sfs files get very large - https://git.io/JfU1S