walki
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.
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.
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...
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.
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.
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.
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).
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?
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.
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.
What about if all non-US countries start reasoning like you and ban Youtube, Facebook, ...?
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.
I think the level of measuring noise is 0.5%, at least that is what low level system programmers generally consider as noise...
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 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!
Many system programmers will think this line is commented out. Indeed what a nightmare!
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!
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.
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.
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.
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 not against IBM POWER CPUs, I was just disappointed by POWER8...