I was heavily into assembly before I discovered C. For the first decade and half or so I could usually beat the compiler. Since then, especially when supporting multiple architectures I have not been able to do that unless I knew some assumption that the compiler was likely to make wasn't true. The 'const' keyword alone killed most of my hand optimized stuff.

In the end the only bits where I resorted to assembly were the ones where it wouldn't make any sense to write stuff in C. Bootloaders, for instance, when all you have to work with is 512 bytes the space/speed constraints are much more on the space side and that's where I find I still have a (slight) edge. Which I guess means that 'optimal' is context dependent and that the typical 'optimal' defaults to 'speed'.

▲

taeric 5 hours ago | parent [-]

I think this is talking past my question? I don't necessarily think "low level" has to be "writing assembly." I do think it means, "knows the full layout of the data in memory." Something a surprising number of developers do not know.

I've literally had debates with people that thought a CSV file would be smaller than holding the same data in memory. Senior level developers at both startups and established companies. My hunch is they had only ever done this using object oriented modeling of the data. Worse, usually in something like python, where everything is default boxed to hell and back.

	▲	jacquesm 5 hours ago \| parent [-]
		I was really only responding to this part, apologies for not quoting it: > How many people are writing somewhat bog standard RUST/C and expect optimal assembly to be created? As for: > I don't necessarily think "low level" has to be "writing assembly." I do think it means, "knows the full layout of the data in memory." Something a surprising number of developers do not know. Agreed. But then again, there are ton of things a surprising number of developers don't know, this is just another one of those. Similar stuff: - computers always work - the CPU is executing my instructions one after the other in the same order in which they are written on the line(s) - the CPU is executing my instructions only one at the time - if I have a switch (or whatever that construct is called in $language) I don't need to check for values I do not expect because that will never happen - the data I just read in is as I expect it to be You can probably extend that list forever. Your CSV example is an interesting one, I can think of cases where both could be true, depending on the kind of character encoding used and the way the language would deal with such a character encoding. For instance in a language where upon reading that file all of the data would be turned into UTF-16 then, indeed, the in memory representation of a plain ASCII CSV file could well be larger than the input file. Conversely, if the file contained newlines and carriage returns then the in-memory representation could omit the CRs and then the in memory representation would be smaller. If you turn the whole thing into a data structure then it could be larger, or smaller, depending on how clever the data structure was and whether or not the representation would efficiently encode the values in the CSV. > My hunch is they had only ever done this using object oriented modeling of the data. Yes, that would be my guess as well. > Worse, usually in something like python, where everything is default boxed to hell and back. And you often have multiple representations of the same data because not every library uses the same conventions.