31–40 of 77 posts
Earlier quoted context omitted.
Still that assert has to be checked at some point right? I would assume that maybe the compiler could do this optimization without having to be told.
In practice a small function like this would be inlined, which gives room for further optimisations. At any point, if the compiler knows that all accesses are in bounds, it can remove the bounds checks. The trick is actually having it figure that out.
Slow enough to not offer Varnish for Buster, 2 months after Debian release... ;-)
Earlier quoted context omitted.
Chiming in to say I agree with the sibling (dead) comment (not sure why it ended up dead). Djikstra's words (and the article's) are clearly correct, but hardly revolutionary or contrary to modern belief today. The real question is: why, despite a prevailing belief in modern software software engineering that red diffs are beautiful and cathartic things to be celebrated, and that the great spectre of technical debt is…
Software-as-art has lost a lot of ground to software-as-business, and in software-as-business, somewhere up the chain there is a management-level individual who isn't really sure how to measure either progress or code quality. There are myriad tools designed for these people though, and they all chose the simplest (and wrong) solutions to the problem: progress is SLOC added and bug reports clsoed per day. The height…
Slow enough to not offer Varnish for Buster, 2 months after Debian release... ;-)
What are you talking about that they did 'not offer Varnish for Buster?' Was there a packaging problem or more context you could add here?
Earlier quoted context omitted.
Interesting! Do have a link to an example?
Given the following code (and with optimisations on): pub fn no_assert(input: &mut [u8]) { for i in 0..10 { input[i] += input[i+1]; } } pub fn with_assert(input: &mut [u8]) { assert!(input.len() >= 11); for i in 0..10 { input[i] += input[i+1]; } } The no_assert function ends up doing a bounds check for every iteration, and the with_assert function only does a single check.
Both loops get entirely unrolled. Its 5 instructions for each iteration in the first example, and only 3 in the second example. (To say nothing of the fact that conditional jumps are (usually?) much more expensive than add/mov instructions)
From the article: "I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." The obvious Edsger Djikstra reference: [I]f we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. http://plasmasturm.org/log/linesspent/
Chiming in to say I agree with the sibling (dead) comment (not sure why it ended up dead). Djikstra's words (and the article's) are clearly correct, but hardly revolutionary or contrary to modern belief today. The real question is: why, despite a prevailing belief in modern software software engineering that red diffs are beautiful and cathartic things to be celebrated, and that the great spectre of technical debt is…
The 'real' programmer that spends a month on a long term maintainable chunk of code with a well defined API and some documentation to go with it in a few hundred lines of craftmanship will be at a disadvantage to the person that creates an unmaintainable mess half the time and that is promoted away for being so great at 'getting things done' before they have to deal with the mess.
From the article: "I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." The obvious Edsger Djikstra reference: [I]f we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. http://plasmasturm.org/log/linesspent/
Dijkstra wrote that in 1988. Things change. The prevailing wisdom changes over time. Is anybody really proudly counting lines of code at this late date? Is there anyone out there who doesn't love an all-red diff? Is there anyone who really thinks the prolix version of a function is better than the concise one, all else equal? Who is getting paid by line of code, or has to meet a a quota of LOC?
> This is why Varnish is written in "pidgin C" style and lousy with asserts which don't do anything, except clarify programmer intent, and in case of mistakes, stop bad things before they get out of hand. Today I learned a new name for my C coding style.
Earlier quoted context omitted.
What are you talking about that they did 'not offer Varnish for Buster?' Was there a packaging problem or more context you could add here?
It looks like Debian 10 (Buster), which was released 2019-07-06 contains Varnish 6.1 instead of 6.2, which was released 2019-03-15.
Earlier quoted context omitted.
Indeed. Reminds me of arcfide's Co-dfns compiler: >I think the first copyright on this compiler is around 2011. That's 6 years for 750 LoC. That's about 125 lines of code per year. >But that doesn't tell the whole story. If you look at the GitHub contributions that I've made, I've made 2967 of about 3000 commits to the compiler source over that time frame. In that time I've added roughly 4,062,847 lines of code to th…
Is this [1] the code he speaks of? [1] https://github.com/Co-dfns/Co-dfns/tree/master/cmp