Interesting. I've hit this bug before, but not often in Python as far as I can remember. I guess if I need a huge list of something, I'm more likely to look to a dict than use a list with normal indexes.
If you're on a GNU/Linux system that is not actually relevant unless you've also opted into glibc's 64b time_t, and recompiled everything locally: by default, glibc uses 32b time_t even on 64b machines.
> Currently it defaults to 64 bits on most architectures. Although it defaults to 32 bits on some traditional architectures (i686, ARM), this is planned to change and applications should not rely on this.
... what floating point determinism?
Sorry, couldn't help myself. Even in the cases where it's deterministic, the implementation differences across hardware AND software make such a prospect downright hilarious to me.
The determinism that ensures a game replay can use only initial conditions to recreate a whole sequence. There is tons of code relying on fp determinism.
This works when running the game on the same machine and same software. Once you use a different CPU or different compiler, floating point determinism (and such replay) can easily fail.
FP hardware is in this sorry state where they have varying capabilities, but we need to dispel this notion that floating point can't be made deterministic across architectures. If it runs on a computer of course it can be made deterministic. Right now it requires some care, but I hope in the future it will be easier.
You can absolutely have determinism across different architectures, if you stick with architectures that support IEEE 754-2008. Also if a compiler break determinism this is a serious bug (as long as you don't enable -ffast-math of course - otherwise you're asking for breakage).
Unfortunately this means no SIMD, also you need to bring your own transcendental functions (sin, cos, etc). Also you need to be wary of other forms of nondeterminism like threads.
There's a physics engine meant for games and robotics called Rapier [0] that has a feature enhanced-determinism that will enable cross-platform determinism (by disabling threads and simd). If you spot any form of nondeterminism, it's absolutely a bug (either on the compiler or on the library itself), just like it would be a bug if it used only integers (which, by the way, was how nphysics, the antecessor of Rapier, implemented determinism: it used fixed-point math with integers [1])
No it works within the same architecture if care is taken. So playing back a game replay on any x64 machine is ok. When recompiling, care must be taken of course, but a compiler doesn’t reorder instructions randomly to produce different results.
Care must also be taken not to risk using the x87 80-bit registers differently, but these days this is much easier - just don’t use x87 at all and use SSE instead.
I write software that does finite element analysis and similar things and results are reproducible across machines and across versions of the software.
SSE is a special case that makes it easier to be deterministic, but you still need to be careful, since the reciprocal instructions can be implemented differently and could produce different bit patterns for their results.
My statement was about non-SSE scalar floating point operations. Using different optimizations ('Debug'/-O0 versus 'Release'/-O3 mode) will possibly produce different results, unless you are very careful. Using a different compiler (gcc versus clang versus visual studio) will likely produce different results.
If you want results to be reproducible across different CPU architectures (x86, arm64 etc) one option is using fixed-point arithmetic.
I meant SSE registers but (typically) scalar instructions. That is, a 64 bit op is always executed with 64-bit arguments and no risk of extended precision sneaking in. The .NET Jit has that guarantee on x64.
> Using different optimizations ('Debug'/-O0 versus 'Release'/-O3 mode) will possibly produce different results, unless you are very careful.
Yes. But .NET I think is much more predictable in that case as I don’t observe differences from optimization either. Having a spec and a decent memory model and no undefined behavior makes the compiler worse at optimizing things but better at consistency I guess. If the language spec strictly defines what math operators do and prevents reordering and similar, then there isn’t much outside transcendental functions that can go wrong. On 32bit .NET this did go wrong because whether or not something was in an 80bit x87 register or spilled to a 64 bit memory value seemed to depend on the moon phase. Those were bad times.
> If you want results to be reproducible across different CPU architectures (x86, arm64 etc) one option is using fixed-point arithmetic.
Luckily I never had that need. .NET (C#), x86-64, Windows. In that target, things look extremely stable now.
Step outside into 32bit or non-windows or C/C++ or even non x86 then all bets are off obviously.
No, it does not. There's plenty of subtle implementation differences between x86 CPUs of the same manufacturer. Usually different generations, but it's enough to mess up meteorology.
Can you give any examples of where two different CPUs have different or non IEEE compliant behavior (disregarding things like actual bugs or atypical settings)?
Let’s say for regular x64 code and SSE FP.
I’m surprised you say it’s common as I haven’t yet bumped into the problem and I have a large suite of complex FP tests (engineering calculations) that have reproduced to the last digit over 15 years and dozens of different test machines of all flavors.
Results calculated 2004 on P4’s still work out to the same results after millions of calculations on every cpu since then and dozens of versions of the software.
Which instructions are you using? I'd trust basic arithmetic, but I wouldn't trust functions like sine (AFAIK the standard fully specifies the former, but not the latter).
There’s lots of trig. But as far as I’m aware those have also been identical in SSE.
Edit: SSE actually do transcendentals at all so it’s possible I’m saved by stable software defined transcendentals in .net (effectively then the Windows x64 implementations)
I'm a secular Satanist. I believe Christianity and Abrahamic religions are inherently unethical. I have very strong utilitarian principles that run even deeper, which is ultimately what pushed me to Satanism. I'm a member of the Satanic temple, but in some ways it's more of a political organization than religious. I'm open to the possible existence of the paranormal, but I do not trust it at all and would question the intentions of such entities.
> I'm open to the possible existence of the paranormal, but I do not trust it at all and would question the intentions of such entities.
I think you're already making a mistake in thinking about it as 'entities' and 'paranormal'. Liber O vel Manus et Sagittae sub figura VI has a great bit about this:
> 2. In this book it is spoken of the Sephiroth and the Paths; of Spirits and Conjurations; of Gods, Spheres, Planes, and many other things which may or may not exist. It is immaterial whether these exist or not. By doing certain things certain results will follow; students are most earnestly warned against attributing objective reality or philosophic validity to any of them.
Which combined with the Mathers/Crowley Goetia gives more insight into a different perspective:
> The spirits of the Goetia are portions of the human brain.
Would you question the intentions of parts of your own brain? :) Maybe! But this gives a pretty different perspective on them than external 'entities' influencing you. In the end, all that matters is that note from Liber O -- by doing certain things, certain results will occur. Whether it is external entities or parts of your own brain is kinda irrelevant to causing results.
Atheist here and I've been pretty impressed with the work of the Satanic Temple over the last few years.
What's membership actually look like?
I'd consider joining in a secular/political sense, but I have no interest in hanging out with people who believe in and actually praise a "Satan" deity.
I'm not too active in the Temple because of work, but you will only generally find atheists, agnostics, or at worst "woo lords" in TST. Such irrational thought is frowned upon by TST, so it is discouraged. TST does lean a bit left, but as the old offensive saying goes, "reality has a liberal bias". They do not, however, typically look kindly upon SJWs. Someone tried that once and was fired by TST itself.
You will hear people say "Hail Satan!" a lot, but it's meant more in the sense of what Satan stands for from the Satanic viewpoint, which is, among many other things, primarily freedom and knowledge.
I do believe in their tenets myself, I think they're remarkably well distilled principles. I think the first and fourth tenets are especially important for the current times.
I think what you'll find a lot of Satanists believe is "an it harm none, do what ye will", and you'll find that they take that principle more seriously than others who espouse that, such as Wicca.
The Church of Satan was on the right track in some areas (such as viewing Abrahamic God as evil and nonexistent), but in others it is clear that it is an incoherent "first attempt" with lots of contradictory statements, such as the belief in magic yet the disbelief in Satan, and its hatred of abortion despite its otherwise Social Darwinist leanings. More damning (no pun intended) is how the Satanic Bible (LaVey's work) simultaneously condemns the authority of "God" yet says that dictators are good Satanists. It was very much the views of a single man, Anton LaVey, which while not entirely without merit and LaVey not being necessarily a completely terrible person, are far off course in my view in many ways.
Anton loved Ayn Rand. Many TST members are appalled at Rand's ethical ideology, or lack thereof, myself especially included.
You'll find that in many areas, The Satanic Temple is diametrically opposed, and represents a much more coherent, logical, refined ideology, and wholly rejects social darwinism as mostly discredited, advocating instead for empathy and compassion, recognizing their evolutionary benefit.
What both organizations have in common is the demand for rationalist thinking, the belief in the immorality of God, the belief in personal freedom, and deriving their ideologies partly from the sciences of their respective time periods.
Sorry I'm so late in my reply. I largely agree with you. After reading the "manifesto" of TST I find that it's much more to my taste (although keeping "Satan" in the name is a bit much of an "inside joke" for me- the evangelicals in my family can't get past it.
My advice is for the OP to make his build system GPLv3 licensed and sue anyone who willfully violates that license.
Open source still has lots of life left in it, but copyleft licenses are now increasing in importance, and the days of letting it slide when a company violates your license are now gone.
To decide on what license you want, ask yourself, do you want this to improve software as a whole, or do you want this to improve FOSS? Does the image of proprietary software benefiting from your work soothe or anger you? Nowadays, it's becoming increasingly important to choose the latter. If you don't care what happens, you can license it as MIT or something. There are still valid cases for that.
> My advice is for the OP to make his build system GPLv3 licensed and sue anyone who willfully violates that license.
Except that filing a lawsuit costs money, and if by nature your product is free, where are you getting the money for said lawsuit, and what damages are you suing over? You might be able to get a cease and desist order for copyright, but then what?
No password authentication? That's a problem to me. I use keys for everything serious, but sometimes I want to have a Raspberry Pi with the root password "derp". :^(
Rust is a good language overall, but it has some serious flaws that it seems those in control of Rust have no interest in fixing.
For example, it is possible to make the borrow checker accept self-referential structures, but nobody has done the immovable type etc work required for that. Which means, for non-trivial data structures, you need to either reach for unsafe or Rc/Arc. I write a lot of very multithreaded code, so for me it's almost always Arc, which means paying for atomics. And since the Drop trait takes an exclusive &mut reference, you must use fugly nested structs to prevent UB if you have shared mutable pointers you need deleted automatically.
I'd recommend learning Rust, but I'd also strongly recommend that you willfully push the limits of the language. Rust needs to be stretched out to accommodate more contemporary programming constructs, and you can help with that. Also, stay away from the core team and organization, they're poisonous as hell. I'd recommend donating to gccrs to help alternate implementations.
On the positive side, you do still end up with an awful lot of zero-cost safe code, and Rust is pretty nice to work in once you actually understand it.
As far as I understand, that should be practically zero-cost on x86, and quite cheap also on ARM - and it's also only paid during acquisition and destruction. I haven't yet caught refcounting in profiling as being the cause of unacceptable performance.
It’s practically zero cost when uncontested. When contested, the instructions with that `lock` prefix are concurrently accessing a single cache line from multiple cores at the same time.
These cache coherency protocols are relatively slow. On some processors, reading a cache line recently modified by another core can cost 300-500 cycles, way more expensive than a cache miss and roundtrip to off-chip memory.
That is also true. But as said, I haven't yet personally run into a case where refcounting was contested to a point of making it an optimisation priority.
I think one the main use-cases for RCU in kernel is to alleviate the need for atomic reference counting in places where it would significantly impact performance. What you are saying might be indicative of one of the points that author raised: People mostly use Rust in non-system contexts where they don't really care that much about performance and would be better served by GC-ed language with runtime.
I'm not sure what counts as a non-system context these days. Most of my experience with using Rust in production was with a message queue type of service, where the desire was to minimize latency and to have consistent performance over prolonged use. I did make an initial prototype with C#, but things were much easier to make work well on both counts with Rust and Tokio.
> a message queue type of service, where the desire was to minimize latency and to have consistent performance over prolonged use.
Your requirements are probably similar to this C# queues class: https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Aud... That library decodes and plays realtime video + audio, both low latency and consistent performance over prolonged use were rather important. BTW that code runs on Raspberry Pi4, CPU performance is a fraction of what you’d expect on modern desktops or servers.
