3 ms·

Ok this is like saying let's make an interpreted Python program run fast, knowing full well it's not intended for that. .Net's intention by using bytecode is sa

Ok this is like saying let's make an interpreted Python program run fast, knowing full well it's not intended for that. .Net's intention by using bytecode is safety, sandboxing and performance. Why not teach the right tool for the job and illustrate it being ported to C (or lower) if the aim is to make it smaller? Can you imagine a mechanical engineer trying to turn a screw with a pair of pliers with the justification that it's just a simple screw and they want to see what the minimal number of turns is whilst shaving the screw to improve grip? You'd think they were nuts...

idlewords 3y ago
Because the true aim of this exercise is to understand and illustrate the various components of a .NET binary. It's like tuning your Geo Metro to go as fast as possible; you do it to learn about the inner workings, not to win a Formula 1 race.
colanderman 3y ago
I actually just did this experiment yesterday with C. Smallest "hello world" I could get from GCC on Linux is somewhere around 14 KiB. (Lots of startup code and unnecessary ELF sections.) So C# has a leg up here. (Granted it's apples-to-oranges, given that this blog post is for C# managed mode (as opposed to AoT).)
- colanderman 3y ago
  Code-golfing some more, I could get it down to 448 bytes (leaving out standard library, reimplementing syscall/2 by hand, and convincing the linker to drop useless sections). So C does win out here, but moreso by virtue of object format than anything I think.
colejohnson66 3y ago
> .Net's intention by using bytecode is safety, sandboxing and performance. Not true. You can get all of that in C++ if you’re careful and enable compiler flags that no one uses. The entire reason for the IL platform that .NET uses is for cross-platform executables, just like Java. .NET does give one safety in the form of bounds checking and what-not, but that’s the runtime, not the byte code. There’s no “bounds check” opcode; array dereferences are managed by the runtime and bounds checks are elided if safety can be proven (like Rust does).

idlewords 3y ago

Because the true aim of this exercise is to understand and illustrate the various components of a .NET binary. It's like tuning your Geo Metro to go as fast as possible; you do it to learn about the inner workings, not to win a Formula 1 race.

colanderman 3y ago

I actually just did this experiment yesterday with C. Smallest "hello world" I could get from GCC on Linux is somewhere around 14 KiB. (Lots of startup code and unnecessary ELF sections.) So C# has a leg up here. (Granted it's apples-to-oranges, given that this blog post is for C# managed mode (as opposed to AoT).)

colanderman 3y ago
Code-golfing some more, I could get it down to 448 bytes (leaving out standard library, reimplementing syscall/2 by hand, and convincing the linker to drop useless sections). So C does win out here, but moreso by virtue of object format than anything I think.

colejohnson66 3y ago

> .Net's intention by using bytecode is safety, sandboxing and performance. Not true. You can get all of that in C++ if you’re careful and enable compiler flags that no one uses. The entire reason for the IL platform that .NET uses is for cross-platform executables, just like Java. .NET does give one safety in the form of bounds checking and what-not, but that’s the runtime, not the byte code. There’s no “bounds check” opcode; array dereferences are managed by the runtime and bounds checks are elided if safety can be proven (like Rust does).