Hacker News Reader

> What is this post supposed to prove?

It proves that the compilers for many programming languages emit a lot of instructions and a lot of system calls they could have optimized away theoretically.

This is particularly true when there are lots of "startup routines". When the program to be run is known, almost all of that startup can be found out to not be necessary, and stripped from the final executable.

> Your users are not going to wait shorter for your program because you and your team are taking another year to write, test, and debug it in assembly.

They might, if your program is interactive and is used often enough. Now, writing assembly is not very realistic, but considering a different language with less overhead - is.

For all the daily articles that pop up here on HN concerning premature optimization I find it surprising to see this thread and all the sentiment of language choice mattering.

It’s far easier to work in and translate thoughts to more feature rich languages. The vast majority of the time it’s not the language itself that will be an optimization issue down the line but rather the written code.

Here's the problem, your language isn't the optimization issue... until it is. You optimize all the hot-spots on your profile, and then... all the sudden you're looking at a very big samey chart of everything taking slightly-too-long even though you've optimized every possible thing and there's nothing that particularly sticks and and there's nothing you can do about it. And then you're totally fucked, because you're looking at a rewrite at that point; probably in a language your team doesn't know and doesn't like.

Sometimes language matters! Not always, but frequently!

> you're looking at a rewrite at that point; probably in a language your team doesn't know and doesn't like

Or you commit atrocities like rip the garbage collector out of Python. I’m not joking; Instagram did this: https://instagram-engineering.com/dismissing-python-garbage-...

That’s actually a pretty clever (and crazy) idea, because when you disable the gc in Python the reference counting still works and only the cycle detection part is vanished. So you are just dealing with reference semantics the same as C++’s shared_ptr or Swift’s references, which isn’t that hard to use if you are careful about cyclic refs. And if the memory leak exceeds a certain amount they can just restart the process.

Disabling the python GC like that isn't that crazy. They didn't add gc.disable() because you shouldn't use it. The crazy part is some library calling the gc directly without a way to disable it. That's just bad form.

A lot of games in gc-ed languages turn the gc off, and then manually run the gc whenever there's some spare time in a frame. The same thing should more or less work for a server handling web requests too. Maybe run it after every request or perhaps every couple of requests depending on memory usage.

That's also how Perl functions. No generational GC, just ref counting. So you're fine if you don't make circular references.

Heh! That is fantastic!

> they could have optimized away theoretically.

For a hello-world program, this is true, you do not need any of the features that usually come in the language runtime - no garbage collection, no runtime memory safety, no runtime introspection, et cetera. This stems directly from the fact that many of these languages have borrowed features from Lisp, which has the whole language (GC, compiler, debug functions, etc..) always available for the code.

And that, considering your point of view, might be a feature, not a bug - especially if your program, having a runtime of its own, actually produces its own stacktrace, allows you to interactively inspect values of variables throughout the stack, and - in case of some runtimes - is capable of opening up its own debugger for you to perform introspection and issue analyzing in.

> This stems directly from the fact that many of these languages have borrowed features from Lisp, which has the whole language (GC, compiler, debug functions, etc..) always available for the code.

Right, I think the point was that this isn't always necessary, in which case it becomes extra baggage that you have to carry around.

I think it would be interesting to make a slightly more complex program involving maybe a few hello worlds, and then see how much the size of all these languages increases.

> Now, writing assembly is not very realistic, but considering a different language with less overhead - is.

https://en.wikipedia.org/wiki/RollerCoaster_Tycoon_(video_ga...

"Sawyer wrote 99% of the code for RollerCoaster Tycoon in x86 assembly language, with the remaining one percent written in C."

I didn't say "impossible" or "completely unrealistic"...

I wonder how that code gets maintained.

Also - that game absolutely needs better resolution to do the coasters justice.

It's quite an old game now, released in 1999. Runs beautifully under wine and one of my favorite games of all time. I recommend giving it a go if sim games are your thing. Hard to believe it was all written in assembler and I too would love to know how Chris managed his code.

It could just be trying to be interesting, not to prove anything.

The language in the post, "Most languages do a whole lot of other crap other than printing out “hello world”, even if that’s all you asked for." certainly seems to imply it's moralizing about something.

Why is it attempting to moralize if it is not meant to prove any morals then?

If your compiler generates something huge for the most basic test, how can you trust it's doing well on actual programs? Most real programs are far too complicated to analyze. It may be a toy example, but if your language can't handle a toy, it's probably bad on real world programs also.

You have a weird definition of "handling". A high-level language performs the same amount of work as the lower-level one - I cannot see a language listed in the blogpost that has failed to display a command in the console.

It's the lower-level languages that, for the sake of efficiency and minimalism, cannot handle systems larger than a hello-world and actual programs written in them without long development times and a mass of bugs that come straight from their inability to abstract when necessary and from their memory management systems that lack sanity and safety. This "simplicity"[0] is often fetishized, and this blog post looks no different to me - look how many overflow bugs in operating system kernels this "simplicity" has caused.

Or, paraphrasing your quote, if your language prevents you from creating most basic abstractions, how can you trust it's doing well on actual programs?

[0] I can agree, writing in a memory unsafe language is simple, as long as it's someone else who maintains the code you wrote, accepts or reroutes all of the bugtickets that happen, and analyzes heisenbugs that come from weird memory corruptions caused by unsafe code.

I don't think what people are saying here is that the languages are too abstract, it's that compilers are implementing those abstractions with too much overhead.

Most compilers (i assume) optimize by applying specific optimizations to patterns they find in the source. most of the time this is pretty good compared to non-optimized code. but the other day on HN i learned about polyhedral compilation, which is pretty crazy of an optimization. it got me thinking: what about all the optimizations we don't know about? is it possible to find the absolute best optimization for a program given some specifications of what we want from it?

I think an ideal compiler would brute-force optimize like this so we don't miss out on optimizations we didn't think of:

1: compile the code normally without optimizations

2: generate a binary [see note1], and test if it produces the same output as the binary from (1)[see note2]

3: sort through the binaries and choose the best ones (perhaps some binaries are more optimized for speed, size, etc so there may be tradeoffs)

note1: here are a couple ways i think you could do this, in order of practicality:

A: modify the binary from (1) a bit at a time

B: modify the binary from (1) X bits at a time, or any of the other binaries from (2) that passed the test, more likely to modify binaries that perform better in the tests.

C: iterate through every possible binary up to around the size of the binary from (1)

note2: the easiest way to implement this would be to test it with a ton of sample input, but it would be better if the binary could be analyzed somehow to see if it satisfied the parameters of the source code.

I wouldn't use a such a brute-force optimizer to actually produce code which would then be undefined, but you could use it to reverse-engineer optimizations and implement them in source code.

edit: formatting

Your thinking like a cog in a machine. It is easier to program in high level languages. So easy that the hard part becomes dealing with management, constantly rewriting for marginal improvements. You start thinking the sprint is important and you ststt choosing a language so hiring is easier. In the end we end up with bloating teams and bloated software that continues to do less use more cpu but costs more

It was more difficult to write a huge program in C. But you needed a smaller team. You are so deep in the system management is always over their heads.

This example is not too relevant because the overhead is probably the additional tools (e.g. debug, error handlers, etc), there should be multiple examples for a normal comparison, e.g. 3-4 examples of more and more advanced code since then maybe these numbers would increase in a similar fashion.

"What is this supposed to prove?"

Perhaps it proves that if one is writing relatively small, simple programs, some of these languages are overkill.