walki

I feel like the NT kernel is in maintenance only mode and will eventually be replaced by the Linux kernel. I submitted a Windows kernel bug to Microsoft a few years ago and even though they acknowledged the bug the issue was closed as a "won't fix" because fixing the bug would require making backwards incompatible changes.

Windows currently has a significant scaling issue because of its Processor Groups design, it is actually more of an ugly hack that was added to Windows 7 to support more than 64 threads. Everyone makes bad decisions when developing a kernel, the difference between the Windows NT kernel and the Linux kernel is that fundamental design flaws tend to get eventually fixed in the Linux kernel while they rarely get fixed in the Windows NT kernel.

Microsoft's %Appdata% directory is a security nightmare in my opinion. Ideally applications should only have access to their own directories in %Appdata% by default. I recently came across a python script on GitHub that allows to decrypt passwords the browser stores locally in their %Appdata% directory. Many attacks could be prevented if access to %Appdata% was more restricted.

I also found a post of an admin a few days ago where he asked if there was a Windows setting for disallowing any access to %Appdata%. The response was that if access to %Appdata% is completely blocked Windows won't work anymore.

> For performance, can’t you “just” have a swap-endianness instruction in your CPU

Yes, most CPUs have special instructions for swapping between little and big endian byte arrangement. The GCC compiler has the __builtin_bswap64(x) for accessing this instruction. However this is an additional instruction that needs to be executed for each read of a 64-bit word that needs to be converted, in some workloads this can double the number of executed instructions and hence add significant overhead.

Supporting big endian CPUs in systems programming sucks beyond imagination. There are virtually no big endian users anymore and making sure your software works fine on big endian requires testing it on a big endian CPU. However it is not possible to buy a big endian CPU anymore as there exist no more consumer big endian CPUs. For this reason I still have a Mac PowerPC from 2003 at home running an ancient version of Mac OS X. But over the last 2 years I have stopped testing my software on big endian, I just don't care about big endian anymore...

> not sure if this is still the case though

No this is not the case anymore. Nowadays support for unaligned memory accesses is very good on ARM and most other CPU architectures. On x86 aligned memory used to be very important for SIMD but now there are even special SIMD instructions for unaligned data and the performance overhead of unaligned memory accesses is generally very small in my experience.

> it’s good for software robustness that file formats and hardware use different endianness, as it forces you to read things byte-by-byte rather than lazily assuming you can just read 4 bytes and cast them directly to an int32.

Except that it is very bad for performance. As far as CPUs are concerned little-endian has definitely won, most CPU architectures that have been big endian in the past (e.g. PowerPC) are now little endian by default.

If all new CPU architectures are little endian this means that within a decade or two there won't be any operating systems that support big endian anymore.

What's interesting to note though is that I tried marking pointers __restrict__ in the performance critical sections in 2 of my C++ projects and the assembly generated by Clang was identical in all cases!

So while it is true that by default Rust has a theoretical performance advantage (compared to C/C++) because it forbids aliasing pointers I wonder (doubt) whether this will cause Rust binaries to generally run faster than C/C++ binaries.

On the other hand Rust puts security first, so there are lots of array bounds checks in Rust programs (and not all of these bounds checks can be eliminated). Personally I think this feature deteriorates the performance of Rust programs much more than you gain by forbidding aliasing pointers.

OK thanks, indeed Clang is able to generate better assembly using __restrict__. And -O3 generates the same assembly as -O3 -fstrict-aliasing (which is not as good as __restrict__).

I wish there was a C/C++ compiler flag for treating all pointers as __restrict__. However I guess that C/C++ standard libraries wouldn't work with this compiler option (and therefore this compiler option wouldn't be useful in practice).

> C compilers have to assume that pointers to memory locations can overlap, unless you mark them __restrict...

What I don't fully understand is: "GCC has the option -fstrict-aliasing which enables aliasing optimizations globally and expects you to ensure that nothing gets illegally aliased. This optimization is enabled for -O2 and -O3 I believe." (source: https://stackoverflow.com/a/7298596)

Doesn't this mean that C++ programs compiled in release mode behave as if all pointers are marked with __restrict?

> Has anyone tried machine learning on this or the Graviton2?

I have not done any machine learning on AWS Graviton2 CPUs but I ran many other CPU benchmarks on Graviton2 CPUs and overall I have been disappointed by their performance. They are still much slower than current x64 CPUs (x64 CPUs are up to 2x faster in single thread mode).

According to the benchmarks from Anandtech the Ampere Altra should have much better performance than Graviton2 CPUs as its performance is neck to neck with the fastest x64 CPUs.

They also asked for the VAT number of the company...

Yes, I am based in Europe. If this was EU's fault then why didn't any of the other cloud vendors have this requirement?

I have personally used a large number of cloud compute services: AWS, packet, Alibaba, Digital Ocean, nimbix, Azure, Oracle, ... I still use all of these services from time to time. If you carefully look at my list of cloud vendors you realize that there is only one of the big cloud vendors missing: GCP. Why?

When GCP came out I wanted to switch from AWS to GCP because AWS was costing me a lot of money and GCP was marketed as being cheaper. So I went to their website and signed up. Or at least I tried to sign up, because GCP did not care about individuals, you had to be a company! No other cloud vendor I tested had this requirement! So up to this date I have never tried to sign up with GCP again.

> The facts: we gain almost nothing by having tiktok around. We lose nothing by banning it, and gain a little bit of buffer against possible threats like election meddling, data mining for nefarious purposes and other things. Completely leaving politics aside, I basically support this.

What about if all non-US countries start reasoning like you and ban Youtube, Facebook, ...?

> It's worth pointing out how extremely far ahead Apple seems to be in terms of CPU power...

I agree that Apple's ARM CPUs are very competitive on simple scalar instructions and memory latency/bandwidth. However x86/x64 CPUs have up to 512 bit wide vector instructions and many programs use vector instructions somewhere deep down in the stack. I guess that the first generation of Apple ARM64 CPUs will offer only ARM NEON vector instructions which are 128 bit wide and honestly a little pathetic at this point in time. But on the other hand I am very excited about this new competition for x86 CPUs and I will for sure buy once of these new Macs in order to optimize my software for ARM64.

> Net result: they do not. For my use case (Clojure/JVM and ClojureScript compilation), compile times did not get shorter. There seemed to be a slight improvement, but it was below the level of measuring noise (which was around 8%).

I think the level of measuring noise is 0.5%, at least that is what low level system programmers generally consider as noise...

I absolutely agree with this. The author has spent an insane amount of time to build all this stuff and instead of getting recognition and/or being payed adequately he is getting shitstorm after shitstrom.

As an outsider I have to say that I think what the Rust community has technically achieved is remarkable. But on the social side it is not so bright, avid Rust users constantly spam forums of other programming languages with toxic comments. But this incident shows that the situation is even worse than expected, the Rust community even treats its own peers like sh..

I absolutely think you made the right decision!

I look up to you because you are not just another random math professor producing papers that no one ever reads. Instead you take a risk and try to succeed at what you are most passionate about. In my opinion this is both more noble and more exciting than being a pure math professor. I sincerely hope CoCalc works out well for you, good luck!

For many packages it is difficult to get packaged for all Linux distributions. Hence if your package does not get packaged for a particular Linux distribution users can still install your package using homebrew.

> #aargh

Many system programmers will think this line is commented out. Indeed what a nightmare!

No garbage collection.

> I've recently dropped out of highschool and I've been considering two options: promptly returning to school and finishing my degree or dedicating time to self-educate via the internet.

There is a 3rd option (if you want to work as a programmer):

You practice programming interview questions in your favourite programming language for a few weeks and start applying for jobs. Companies often hire young talented programmers without university degree in entry level positions because they are cheaper.

After having worked in the industry for 5 years no one cares about your degree anymore. The good thing about this 3rd option is that you are learning on the job what the other students learn at university and you don't have to pay for your software engineering education.

Students often tend to overestimate the importance and the benefits of a higher education. Personally I don't like your second option: "self-educate via the internet" because it won't help you getting a job and you will eventually forget what you have learned anyways. For this reason I prefer your first option and my 3rd option.

Good luck!

Gnome has never been hosted on GitHub!

Agreed, this is ridiculous.

> ... Glibc are evidently not the best

The GNU GCC compiler and the glibc are actually the 2 GNU projects I like most. If you are interested in high performance you won't find any better, most Linux servers (which means 99% of cloud servers) are based on these 2 projects! There are other C library implementations that may be suited better for embedded or low power devices but for servers and Desktop CPUs glibc is very good/fast.

> How does, e.g., POWER8 compare? (And POWER9, soon?)

POWER8 is not well suited for HPC workloads as their vector instructions (VMX/AltiVec) are only 128-bit wide vs Intel's latest Skylake Xeon CPUs have vector instructions (AVX512) that are 512-bit wide.

For non HPC workloads (e.g. integer arithmetic) the POWER8 CPUs were somehow competitive with Intel's CPUs when they were first released in 2015 but today AMD and Intel's CPUs are clearly faster.

From what I can tell CPU enthusiasts were not impressed by the POWER8 CPU architecture.

> Just out of curiosity, why would tax competition be considered bad?

This is not about tax competition, this is about abusing tax loop holes and trying to avoid paying any tax at all. E.g. before 2015 Amazon declared their entire European income in Luxembourg and payed about 1 percent of tax on that money. This way other (much bigger) European countries like Germany and France lost billions.

> This is ongoing - enabled by Junker himself ...

No, it is not. Before 2015 many companies (one prominent example being Amazon) declared their entire European income in Luxembourg and payed about 1 percent tax on that money. This tax loop hole has since been closed by the EU, Luxembourg lost about 10 percent of its budget because of this. Today when somebody from e.g. Germany buys a product from Amazon.de, Amazon pays tax in Germany for this product.

I am a Luxembourger and I fully agree that the EU must close these kinds of tax loop holes. In the past my country made a little money out of these tax loop holes, this was immoral money that my country did not even need. Doing this, other European countries lost a lot of tax income. The only ones winning big time in scheme were the international companies abusing the EU and its people.

I compiled my code using the latest GCC version available, I even made sure I used the right compiler flags to enable e.g. hardware POPCNT support. I know that IBM claimed that POWER8 CPUs were faster than Intel Xeon CPUs but I found the opposite to be true (at least for the benchmarks I cared about). You can also find many other benchmarks on the web which are in favor of Intel Xeon CPUs compared to POWER8.

I am not against IBM POWER CPUs, I was just disappointed by POWER8...

When POWER8 came out in 2014 I ran a couple of numerical benchmarks against Intel Xeon CPUs. In my benchmarks the POWER8 CPUs where slightly faster than Intel Xeon CPUs when the data fitted into the CPU's cache, so far so good (the speed advantage of the POWER8 CPU can easily be explained by the much higher clocking). But once I started running heavy benchmarks involving gigabytes of data the POWER8 CPUs where at least twice as slow. Now 3 years later POWER9 CPUs will come out that are about 1.5 times faster, in my opinion this is not enough to compete against Intel. Why would anybody want to get locked into a rare and more expensive CPU architecture if there is no speed advantage?