exDM69

18 ms·

181.
by exDM69 3y ago
Compared to what? Scalar loopy C code sure. The auto vectorization is not great. But give LLVM some SIMD code as input, and it will be able to optimize it, and it does a great job with register allocation, spill code, instruction scheduling
182.
by exDM69 3y ago
This is dated to 2009. Probably sound advise back then. Compilers are much much better with SIMD code than they were then. Today you'll have to work real hard to beat LLVM in optimizing basic SIMD code (edit: when given SIMD code as in
183.
by exDM69 3y ago
The example you show has integer division and multiplication. SSE or AVX instructions don't have an integer division instruction so neither GCC or Clang will emit SIMD code for the division. For the multiplication you need to bump up G
184.
by exDM69 3y ago
No, compilers may be able to vectorize basic loops, but they won't for example turn four adjacent additions into a vector addition.
185.
by exDM69 3y ago
The article you link to uses Intel intrinsics, not built-in vector extensions. Intrinsics are probably the most popular method of doing SIMD but they are not portable to other CPUs and are quite difficult to discover due to shorthand naming
186.
by exDM69 3y ago
There is a fourth way of writing SIMD code that is not among the three mentioned in the article: using language built-in features for SIMD. For C and C++ this is GCC vector extensions (also available in Clang), for Rust (nightly) it's
187.
by exDM69 3y ago
The roll is to change the orbital inclination, the pitch is to set ascent trajectory.
188.
by exDM69 3y ago
1000m is much higher than real rockets pitch over, but good for KSP with forgiving aerodynamic stress. It's just a convenient round number and gives a few seconds of breathing room to make sure the fiery end of the rocket points to the
189.
by exDM69 3y ago
In vanilla KSP1 with a reasonable orbital launcher, fly up to 1000m altitude and tap D on your keyboard 1 to 10 times. Then hands off until 2nd stage and then throttle down to avoid overshooting the apoapsis. Finding the correct number of k
190.
by exDM69 3y ago
No, most rocket engines have quite limited amount of throttle capability and run near maximum thrust until cutoff. The rocket yaws and pitches in the first seconds of flight while the vehicle is still subsonic, then flies a gravity turn tra
191.
by exDM69 3y ago
No, that's inefficient and real spacecraft don't do that for typical low earth orbits. Works in Kerbal Space Program, though. Normal orbital insertion is a single burn to orbit (with staging). With the correct initial roll and pit
192.
by exDM69 3y ago
The ISS is boosted to a higher orbit every few months using on board thrusters, otherwise atmospheric drag would have deorbited it a long time ago. But the hardware will not last forever, it has taken a beating from micrometeorids, radiatio
193.
by exDM69 3y ago
Off the top of my head: Dynamic rendering, timeline semaphores, buffer device address, shader subgroups, push descriptors, descriptor indexing. These are mostly "software" features and they are all required in Vk1.3, and a huge im
194.
by exDM69 3y ago
But you still get the latest API version and you can use all the features available on your hardware (at runtime). You don't need to stick with Vulkan 1.1. Ray tracing, mesh shaders, etc need hw support. But my potato Intel laptop from
195.
by exDM69 3y ago
I totally agree, and so do the people working on it as well as some of the volunteers who write tutorials. There's an ongoing effort to create beginner friendly introductory material which was discussed in the recent Vulkanised confere
196.
by exDM69 3y ago
One improvement in Vulkan vs. OpenGL is that it effectively decouples software updates from hw generations. As of today, you can write Vulkan 1.3 code (which is significantly better and less verbose than 1.0) and run it on 10+ year old hard
197.
by exDM69 3y ago
In hindsight, adding the RenderPass API to in Vulkan 1.0 support mobile chips was probably a mistake. Vulkan 1.3 without render passes ("dynamic rendering") is so much easier, it reduces hundreds if not thousands of lines of code
198.
by exDM69 3y ago
clang-format can be applied to new changes only, for this very reason. Adding it will remove white space nitpicking from code review, even if it isn't perfect.
199.
by exDM69 3y ago
I've used SymPy in a very similar way, in my case it was some nasty derivatives that were needed for some orbital mechanics calculations. First write down the equations, then let SymPy do the laborious math part and turn the output int
200.
by exDM69 3y ago
When git came out it was (arguably) miles better than SVN and others. It was a big leap from centralized to decentralized version control. Git to Pijul is a much smaller change, it is much more difficult to justify. And then there is the fa
201.
by exDM69 3y ago
When the contents has a conflict, git and pijul behave similarly. When the contents are identical, but the order of commits is different, git will conflict and require manual resolution. Pijul will not. As you say, neither will automaticall
202.
by exDM69 3y ago
I have clarified the comment above. A pull is needed before pushing. That pull does not need a merge or a rebase like git does because the order of commits A nd B does not matter (iff they are commutative). This gets a lot more useful when
203.
by exDM69 3y ago
Yes, of course you can manually do that. > If you can losslessly convert between the two models, then it seems like you could make git's conflict resolution smarter without changing the underlying data model. No, this will turn into
204.
by exDM69 3y ago
You kinda missed the point. You have two repos with different history: master -> patch a -> patch b master -> patch b -> patch a But the contents of the files are equal after applying both patches (in either order). Git will con
205.
by exDM69 3y ago
No, it applies to everything. If adding patches A and B (same or different files) will lead to same result regardless of which order they are applied, they are called "commutative" and pijul won't care which order they are in
206.
by exDM69 3y ago
Yes, git "recreates" the patches when you view a diff. But git can't decide that these two patches are independent of each other and thus their order does not matter so it'll give you a merge conflict where pijul doesn&#
207.
by exDM69 3y ago
> Can someone give me a real world example (person a makes X change, person b makes y change etc. etc.) that would work better in Pijul than Git? Simplified example: Persons A and B check out master branch. Person A adds a.txt, commits a
208.
by exDM69 3y ago
This is a chicken and egg problem and I don't see a way out of it. Even if Pijul is better (not voicing an opinion here), it's not drastically better enough to replace Git in widespread use in the near term. The difference in day
209.
by exDM69 3y ago
In day to day use, there's very little difference in the practical use of git vs. pijul. You edit files, commit then push. Of course the user interface is different and some of the terminology is different but it's still a distrib
210.
by exDM69 3y ago
Pijul is a version control system that is patch based (like Darcs) instead of snapshot based (like Git and Mercurial). Together with some mathematical models on the properties of patches it can deal with some merge situations that need to b

More ›