Hacker News Reader

Comment by nemo44x | Hacker News Reader

I hate these articles that feature a programmer who works within a certain domain and assume all programming tasks are similar.

Yes, it would appear there is an anti-pattern of programmers that feel like going lower level for certain things matters. It doesn’t always. Programming computers has multiple levels of abstraction for solving different problems.

But there’s also this idea that the magical compiler does good enough abd there’s no reason to challenge the assembler. But there are programming problems where that is in fact essential.

It’s not a kissing contest. Writing great asm or C is as challenging as writing great css. But to be sure, knowing what your code actually requires hardware to do is really valuable. It matters and we don’t have abstraction in many cases to abstract that away totally.

It doesn’t hurt to have a good idea on how the machine works.

View on HN

The point of the article isn't to belittle someone for having a good, deep knowledge of machines. The foundation of most code written is built by those people.

The point of the article is to point out that languages, frameworks, or apis that expect a level of discipline to write well are inferior to ones that don't expect discipline out of its coders.

The takeaway shouldn't be - I as a programmer shouldn't learn how the machine works.

The takeaway should be - if I'm designing an API/Language/framework, I should figure out how much I'm relying on an engineer's discipline to make the code great (performant, robust, secure, etc). If I can reduce that reliance, the API/Language/Framework becomes better.

I like the focus on scale in the title, and think it’s very apt.

Requiring discipline is not superior or inferior, but doesn’t scale. It’s then your to decide how much it matters: do you have/need to only focus on a small group or are you tools targeted at a wide audience or you want it to widely succeed ?

The answers to that question won’t be the same for everyone.

My usage of inferior/superior is contextualized mainly to scaling but the article mentioned many more things other than scale in the anecdotes (like producing better code overall). Maybe the vagueness of the word choice is a bit controversial in this definition-sensitive environment.

Well, and here I thought that discipline doesn't scale because it is not a universal concept. Having "discipline" in C will not transfer to better discipline in other languages because each language has a different feature to abuse. C might have malloc/free with catastrophic consequences but C++ has templates which lend themselves to a different type of abuse i.e. excess complexity.

> “ The point of the article is to point out that languages, frameworks, or apis that expect a level of discipline to write well are inferior to ones that don't expect discipline out of its coders.”

I think this is what the parent comment that you responded to is saying is totally bogus.

A good example is Python. In my company, the teams using Python run circles around the teams using C++ and Java. The Python teams ship higher quality stuff that is both more reliable (it turns out that lack of a compiler for various static checks not only doesn’t make anything more reliable, but also slows things down unreasonably on large code bases), and easier to modify and adapt to changing requirements.

> Writing great asm or C is as challenging as writing great css

I would argue that writing great asm that is more efficient than your idiomatic C code is going to be a very very challenging task on modern non-embedded CPUs. The compiler definitely knows more than I do about how the internal architecture works and which instructions to reorder to prevent stalls etc

> writing great asm that is more efficient than your idiomatic C code is going to be a very very challenging task

SIMD intrinsics are not idiomatic C, they are idiomatic assembly.

Here's an example when they improved by a factor of 3.6: https://stackoverflow.com/a/63759887/126995 That's not an unusual outcome.

This easily turns into a strawman. Does writing good C code include checking the disassembly and reworking the C code when the compiler produces bad results?

I've seen several examples of the compiler being brilliant until suddenly a simple change makes it not brilliant at all anymore. Compilers are just tools.

Writing assembly pales in comparison to tracking down some of the more ridiculous CSS problems.

Winforms got a lot of hate for some reason I don't understand, but designing with it in Visual Studio is the easiest, best, most sane layout/designing experience I've ever had. It makes me wish the web was more like that.

> Yes, it would appear there is an anti-pattern of programmers that feel like going lower level for certain things matters. It doesn’t always. Programming computers has multiple levels of abstraction for solving different problems.

The thing is, sometimes you need to know how those lower layers work in order to make that judgement. If you’re writing networking code in JavaScript and don’t know what sockets are, you’re going to have a bad time sooner or later.

I hate these articles that feature a programmer who works within a certain domain and assume all programming tasks are similar.

Citation needed? Last I checked, Graham was working on a C64 Smalltalk80 VM as a side project, so I presume he's not completely ignorant of low-level development. And statements like "Your computer is not a fast PDP11" are aimed directly at low level development.

It's Amiga Smalltalk, I think?

You are correct, sir. I must have had commodore on the mind after that VIC20 Doom port made the rounds recently.

> But there’s also this idea that the magical compiler does good enough abd there’s no reason to challenge the assembler. But there are programming problems where that is in fact essential.

Citation needed. I've seen people claiming this for years, and I've yet to see a single case where handwritten assembler actually did better than spending the same amount of effort on speeding up the compiled program (e.g. taking 5 minutes to actually set the right target architecture).

> Writing great asm or C is as challenging as writing great css. But to be sure, knowing what your code actually requires hardware to do is really valuable. It matters and we don’t have abstraction in many cases to abstract that away totally.

> It doesn’t hurt to have a good idea on how the machine works.

On modern hardware both C and ASM are distractions. If you actually want to understand the performance you need to look at cache misses and mispredicted branches; reading through C or an ASM listing will only serve to mislead you. Strangely enough, the crowd that wants you to learn C seem to be the same people who are vehemently against using the kind of profiling tools that will actually tell you what's going on.

> Citation needed. I've seen people claiming this for years, and I've yet to see a single case where handwritten assembler actually did better than spending the same amount of effort on speeding up the compiled program (e.g. taking 5 minutes to actually set the right target architecture).

Take some time looking at established open source projects where IBM has heavily invested in optimizing for the POWER architecture. I'm thinking things like glibc, gmp, Golang, openssl, ... The results they get from their hand rolled assembly far exceeds what gcc/llvm spit out. (At least, it did 2-3 years ago.)

Back when the Linux Technology Center (LTC) was a thing, I was fortunate enough to meet many of the individuals working on these projects. They are all wizards. Brilliant.

One of them retired recently and went on to start pveclib to make some of these optimizations in number crunching more accessible to others: https://github.com/open-power-sdk/pveclib

I was once in his office asking about assembly instructions for SHA-3 (a project that sadly didn't go very far) and he could quote useful scalar/vector instructions to me and their timing/latency stats faster than I could find them in the manual.

> I've yet to see a single case where handwritten assembler actually did better than spending the same amount of effort on speeding up the compiled program (e.g. taking 5 minutes to actually set the right target architecture).

C++ with intrinsics can be very close to assembly. Compilers allocate register and do their magic with the rest of the code, but the real workload translates into assembly almost line-to-instruction. Takes longer than 5 minutes to do, these instruction sets are less than straightforward, but I think 80% of real-world performance sensitive compute-bound code is written like that (the other 20% being assembly).

> that will actually tell you what's going on

When I work on performance critical pieces, I already know what's going on. I design my code from the start to minimize cache misses and branches. The profiling tool I find most useful is sampling profiler. Then I either read assembly and try to do better, or rework higher-level logic or data structures.

Branch mispredictions and cache misses might be hard to see in C and assembly, but in interpreted or JITted languages it's borderline impossible to reason about those things. Even compiled languages have trouble there if you cant control memory layout.

I spent time with a team that wrote math functions in assembly. They also wrote them in C so they would be more portable. Their aims were similar for both - similar accuracy and performance.

The C versions were usually slower - sometimes a lot slower. They knew all the optimizations the compiler was doing and tweaked as much as they could.

In general, though, you're right. I'm particularly annoyed at universities that insist on making their students do all their microcontroller labs in assembly. When I took the course, the professor made us do only two assignments in assembly, and the rest in C. He said it had been over a decade since he had encountered a real world microcontroller problem where one needed the assembly - and he said this some decades ago.

I don't do microcontroller stuff for a living, but anecdotally, the only people I've met who insist one must program in assembly for microcontroller problems do not do it for a living.

The ARM Cortex-M series was designed from the ground up with the goal of being 100% programmable in C. And it has succeeded at that goal, with only a few rare exceptions.

The times I have found it necessary to write assembly (as opposed to just reading compiler output) in the past few years of microcontroller programming seem to fall into three main categories:

1. The vendor-provided startup code is broken and it needs to get fixed. Usually this is indeed 100% written in C for Cortex-M cores, but some vendors get... creative. Vendor code is special. Vendor code has always been special.

2. The compiler is too stupid to use a particular processor feature. This is usually related to performance, and in particular to the math and DSP instructions being too complicated for the poor compiler to understand. This is relatively rare, but when it's in a hot area, a single intrinsic call (sometimes you have to write the intrinsic...) can make a huge difference.

3. You need to debug something hairy and low-level hacks can help you do that. Usually this kind of debug solution only occurs to people who already have good low-level intuition; everyone else just finds a different way to solve the problem, which ends up working out just fine either way.

Reply on news.ycombinator.com