[1] for example

[1] https://danluu.com/anon-benchmark/#:~:text=Over%20the%20year....

I like IBM’s clause, seems the most reasonable.

This reminds me the time when Linus said that linux will be hard to port to other architectures, since it is tightly coupled with the 386 architecture...

Just shows that he didn’t have much knowledge of other platforms or didn’t have much vision about where his project would go. Fact is if you squint enough every modern system looks like a VAX. The same abstractions fit nearly every architecture.

At the time he said that he was not wrong. There were huge chunks of .s files that did interesting asm things.

Certainly would've been less easy without large community contributions.

I'm pretty sure you could do this using hardware performance counters, but I never actually tried, so I might be wrong

The author did say he's removing the article for now, and he'll upload a fixed article later [1].

[1] https://mstdn.social/@osnews/111335189028196715

I believe that fibers are considered more trouble than they worth? [0]

[0] https://devblogs.microsoft.com/oldnewthing/20191011-00/?p=10...

The Gor Nishanov paper linked in that piece goes into a lot of detail of some of the downsides of fibers in an unmanaged language like C++.

[0] http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p136...

Thanks for the link to the Gor's paper.

Apparently the 2018 paper table only covered top 10 languages in the TIOBE index, I wished it can be updated and extended further to top 50 languages.

Another popular compiled language with GC (by default) namely D language (TIOBE ranked 37 as of Sept 2023) does support fiber and it's implemented in its vibe.d web framework [1],[2].

Gor also mentioned about significant 160 ns overhead for stackful fiber in Go (goroutine) to interact with a C library i.e. cost of switching between Go's goroutines and C threads (as of 2018). It will be interesting to know the fiber overhead in D language since C compilation is now natively supported by D compiler [3].

[1] Fibers in Programming in D:

https://ddili.org/ders/d.en/fibers.html

[2] Fibers, what for:

https://forum.dlang.org/thread/eowfajvnzqnncmfnjhnf@forum.dl...

[3] Adding ANSI C11 C compiler to D so it can import and compile C files directly:

https://news.ycombinator.com/item?id=27102584

You may have missed a few.

But it generally seems like a good idea, similar to headlines ending with a question mark.

My guess is that C# will be much better, since it has support for Value types.

Wasn't Java supposed to get support for Value types some time ago?

Project Valhala has the goal to be ABI compatible with existing JARs, hence why it has taken so long, they want to add value types semantics without breaking Maven central.

C# can be much better, or it can be much the same. It depends on which implementation you use. Standardisation is an issue here, the system library has the "Nullable<T>" struct (1), but not a standard Result<T, E> class (or struct). Popular libraries such as "OneOf" use a class type. The single-valued "OneOf" type is effectively an "Option<T>" (2)

Nullable<T> itself is not exactly the same as Option<T> since it does not cover types that already allow nulls. It adds nulls rather then removing them.

Many people roll their own Option<T> or Result<T,E> type, since it's easy enough to start, and it's usually a class type.

1) https://learn.microsoft.com/en-us/dotnet/api/system.nullable...

2) https://github.com/mcintyre321/OneOf/blob/master/OneOf/OneOf...

C# does indeed produce a rather tight assembly

https://sharplab.io/#v2:EYLgtghglgdgNAFxBAzmAPgAgLACgACATAMx...

The compiler takes care of this, but the idiomatic way to write the body of the loop in C# is

    sum += things[i] ?? 0;

You could even argue the most idiomatic C# is things.Sum(x => x ?? 0) and there the real test would be if the compiler/jit would match the speed of the for() loop exactly, i.e. not allocating any enumerators on the heap, not boxing any values and so on.

unfortunately LINQ-to-objects doesn't have the greatest reputation for generating great code/perf, due to a number of factors (largely due to historical impl/interface decisions, from what I understand)

Well, Valhalla is described as “requiring 7 PhD’s knitted together”, doing that while remaining backwards compatible is insanely hard.

In the enlarged photo of the ROM transistors, the transistor in the third row, second column, seems like it should be marked as disconnected.

Should it? Or is there something I'm missing in the way the transistors are connected?

Oops, yes you are correct. Now I need to fix my diagram :(

Regarding the more convenient alternative - as I understand it, it was using assembler and compiler that can run on a modern system, and only passing the floppy image between the host and the vm, instead of running the development tools inside the vm.

Yes my understanding of the article was that he was cross-compiling and cross-assembling on his modern system.

There is a difference between asking if you want to change something, and going and changing this something without the user consent.

There is a difference between asking, and constantly nagging until the user presses the wrong key by mistake one day.