One vision in the article that stood out for me, was how formal proof assistants allow for large teams to collaborate on proving theorems. Imagine what we could achieve if we could do mathematics as a hive mind!
But that's basically what mathematics has been from day 0. What you mention as a hive mind presumably don't refer to a situation where individual minds and intimate reflection can be put out of the equation. On the other hand, mathematics are not possible outside a society which provides a large set of conveniences to leverage on, including communication tools such as a language.
What books will get me started into understanding recent scientific publications?
I’m interested in the theoretical side but even more in the engineering/hardware side.
I think part of the reason why 3 is special is because you get a lot of bang for your buck. Order 3 is a low order polynomial that is relatively easy to analyse, but already gives tremendous mathematical properties.
For example, the points of elliptic curves form groups. The operation of combining the points is described in the article (draw a straight line through two points and mirror in x-axis).
That means that all the theorems that are proven for Groups, are also true for elliptic curves.
But I think there are many more exciting properties
Amateur here (just studying abstract algebra for hobby). I’m also very curious for more reasons.
I wouldn’t upgrade major versions until the x.2 version is out. New major versions come with new bugs and I’d like to wait two minor versions until I start using the image in production.
Could an expert strong man the argument that functional programming languages like Haskell could in theory be more performant than C because of the nice properties of pure functional languages?
CPUs are imperative and pervasively mutable. Languages like Rust are able to have so called zero-cost abstractions that are reminiscent of functional programming (iterators for example) but the thing is abstractions are by nature always slower than the real thing.
But not all games are AAA FPS that require ingenious optimized codepaths to perform well, not in this day and age, so this is why you see commercial games running on "slower" abstractions such as C# (AOT compilation doesn't make it less of an abstraction layer), so you can very well design a commercial game in Haskell or Scheme or Lisp or Clojure if you wish. Nothing stops you, apart from the lack of serious game dev frameworks built in those languages.
It all depends on the compiler, really, and it is asymptotically hard to compile functional languages so they perform as fast as C for example. There is no market for "high performance Haskell or Clojure", so there is no compiler that good either.
"Cost" in C# comes from the (ab)use of classes for transient data, virtual/interface calls and automatic memory management. Another source of difference is in compiler capability of Unity's own flavours: IL2CPP, Mono and Burst, versus .NET's CoreCLR JIT and NAOT versus GCC/Clang. However, the latter has much less impact on "application code" and more impact w.r.t loop autovectorization, for which in C# you're supposed to use bespoke portable SIMD API which is fairly user-friendly. For the former, you are not "locked" into a particular paradigm like with Java or Rust and can mix and match depending on how hot a particular path is (for example - construct buffer slices with LINQ because there are only 16 of them, but each one is 512MiB large, so do the actual work with Vector<T>).
JVM languages have a huge gap* in low-level capabilities where-as C# sits next to C and Rust in many of the features that it offers, even if the syntax is different. JVM implementations also come with significantly higher FFI cost. This makes them an overall poor choice for game development. Your experience of writing a game engine in pure C#, calling out to rendering and other device APIs will be massively better than doing so in Java/Kotlin/Clojure/etc, because of both runtime capabilities and ecosystem of interop libraries.
Also, C# has zero-cost abstractions in the form of struct generics which are monomorphized like in Rust, and performance-sensitive code relies on this where applicable in "modern" codebases.
* Projects like https://github.com/bepu/bepuphysics2 are impossible to implement on top of JVM without calling out to native components. This might change once the incubating Panama vectors improve upon their API and what they compile to.
GHC is effectively an attempt to strong-man that argument over a couple of decades, and in short, it failed. It has pretty good performance for what all Haskell is doing, but if you want to write C-speed Haskell you are restricted to a tiny portion of Haskell that you can only understand with deep knowledge of GHC, and based on what I've seen of it, it is completely unrealistic to call it "Haskell" anymore. It's more a language that happens to be embedded inside of Haskell, but unspecified. (Sort of like "the performant subset of Javascript if you want the JIT to do its best"... it exists, but it's undocumented, it isn't the same between engines, and it's very hard to write it without an intense knowledge of the innards.)
The "sufficiently smart compilers" turn out to either not exist, or be beyond the ability of even the smartest humans.
This is not celebration of that, or condemnation that anyone tried. It's a major bummer, actually, and I am suitably bummed. I'd love to have the Sufficiently Smart Compiler. But wanting doesn't count for much. At this point if someone wants to argue that something at a Haskell level of "functional programming" can run at C speed routinely, they need to produce the compiler; we ran the gamut on mere theories.
(I have to qualify it that way because we do have a lot of evidence that you can have "functional flavored" languages that run much more quickly, like O'Caml (at least in single thread) and Rust, if you consider that "functional flavored". But straight-up Haskell does not appear to be able to "just" get transformed to C-speed code reliably.)
Only in some very specific situations, which amount to an arbitrarily smart compiler and arbitrarily dumb C code. Haskell does provide more opportunities for the code to not do something you tell it do because it can prove you don't use the result, but it is a dumb programmer who is writing code to do those unneeded calculations, and thus a good programmer would eliminate them from C.
A lot of effort has gone into optimizing C compilers, Haskell is easier to optimize in theory, but in practice it isn't enough easier as to overcome the massively larger amount of effort put in C.
In the best case for both the code will be roughly the same speed. However the best case for both can look very different and any comparison is suspect as it is likely that whoever wrote the code wasn't as good at one as the other and so wrote bad code.
C is basically portable assembly so handwritten C can be as fast as the hardware can allow.
High-level languages like Haskell can and do approach the performance of handwritten C if you encode enough information to get the optimizations for free:
I wonder how you view farming as the safest bet. Farming is quite challenging and the competition will drive any noob into the ground. Not just the knowledge but also capital.
Our team also suffered from the problems you described of public helm charts. There is always something you need to customise to make things work on your own environment. Our approach has been to use the public helm chart as-is and do any customisation with `kustomize —enable-helm`.
