hehe, indeed I thought it was.
"The TL;DR is this - there's some hardware inside the Intel CPUs that tracks memory ordering and cache contents - but they don't use all the address bits."
Thanks for that, I wondered why I bounced straight off that. I'm usually fine with text heavy articles, but there was something about that page which meant I just couldn't process it at all.
I always wondered why people don't use text-align: justify more often. Is this really a reason? What about all the books out there? Why are Web pages different?
(I get the feeling I am missing something obvious.)
The justify only works out (i.e. not too ugly) with certain text sizes and page widths. I guess in books it is much easier to make a decent layout because the page size is fixed.
Another thing is that, actually, design has come a long way and many modern websites look way better than many older books.
Edit: Yep, totally forgot about hyphenation. I guess I haven't seen hyphenated text in a long time, as everything in web is unhyphenated.
Hyphenation. Browser support is not good and so words usually are not hyphenated which leads to stretching whitespace. http://caniuse.com/#feat=css-hyphens
Experience: One of my primary clients when I ran an agency for 7 years was a book publishers.
You'd fall over if you saw the subtlety of the tools and the amount of effort that goes in to typesetting a book with justified body text. It is not at all unusual for a publisher to employ staff specifically for the task of typesetting. In the final stages of book production, the typesetters are assigned sections of the book after all edits are complete (ha! in a perfect world), at which point they meticulously review each page of text, often manually inserting/removing hyphenation, until the text is laid out correctly.
Care to venture a guess at the number of bloggers who do the same when using 'text-align: justify'?
Justification doesn't change the amount of text on the paper; it spreads out lines which would otherwise have a ragged right edge (in left-to-right languages) so that the text has a visually appealing right edge. It's done to look good, and succeeds. But it requires work to do right.
> Justification doesn't change the amount of text on the paper
You can fit more characters per line in a justified layout.
> It's done to look good, and succeeds. But it requires work to do right.
Absolutely, but well executed left-alignment can also look good, and in a format where you don't necessarily have control over the size of the page and the time to properly justify the text it should be preferred. IMO, left-alignment beats poorly justified text every time.
Kerned properly, you absolutely can. Please don't make authoritative statements if you've only ever justified text by highlighting a paragraph and having the computer do it automatically.
My example shows, respectively, justification with hyphenation, justification without hyphenation, and left aligned type. You can keep backpedaling, but I have demonstrated that you can have more characters per line with justified text.
> You can fit more characters per line in a justified layout.
Ummm, justification is about adding space to spread a line out: it's impossible to fit more text on a line that way.
Kerning is about removing space. It's related to by independent of justification. A well-laid-out work will do both.
> Absolutely, but well executed left-alignment can also look good
Meh. For printed material I think it's worth the effort to justify.
> in a format where you don't necessarily have control over the size of the page and the time to properly justify the text it should be preferred. IMO, left-alignment beats poorly justified text every time.
Typically a paragraph of justified text (at least in most word processors) has some lines that are uncomfortably compressed and others that are uncomfortably spread out.
It's not just about hyphenation. Typesetting a book includes eliminating "widows" and "orphans" (lines isolated from their paragraphs by page breaks, and final lines of paragraphs with only one or two words) as well as "rivers" of whitespace that can occur when spaces between words inadvertently line up vertically, and the stretching / compression when a line has more or fewer words than average. This is done by adjusting where line breaks fall.
Basically, in a well-typeset book, nearly every line break is a manually selected hard break rather than an automatically generated soft wrap.
If you or some other reader are in the mood, a browser plugin that would remove the vast majority of instances of text-align: justify would be a decent bite-sized project.
A reader emailed to complain about how this and other HN discussions often become derailed by off-topic carping about blog design. I agree completely. Could there be a more classic form of bikeshedding? It would seem parodic if it weren't sadly real. This has become more of a thing on HN lately. It needs to become less of a thing.
I don't mean to pick on you personally, or just on this one comment. (Your second sentence alone, by the way, would have been a helpful contribution.) The problem is the tedious stampedes such comments spawn.
I did not mean to have a comment that sits on top of the on-topic comments. If people upvote it so much that it does, it can mean something though. I would not call it bike shedding, it's a usability and security issue. I will always keep complaining about unnecessary Javascript requirements and especially about this specific design...
Maybe a "offtopic" or "noise" flag could be used for punishing comments like this (similarly to random comments that praise a submission without adding anything) so they float down but not into the grey negative score area?
"Premature optimization is the root of all evil" -- Donald Knuth
What works for i386 may not be applicable on arm/hppa/ppc/etc. It should not even matter these days as almost every CPU clocks well over 1000MHz. If that is still not enough, extra cloud instances are probably cheaper than wasting your time with extensive profiling and manual optimizations.
I'm so tired of people trotting this quote out. We get it – you don't care about performance – hardware is fast and your problems are easy. But there are people who have difficult problems to solve – some hard enough that the limits of what hardware can do represent a real constraint. For those people, having a deep understanding of hardware and performance is essential.
I couldn't agree more. It is the most pre-fab of dismissals and takes threads like this in precisely the wrong direction: into generic goo, when we ought to be discussing salient details, like the impact of varying page alignments.
Few of us have anything substantive to say about that, which is fine—but then we ought to post nothing, not regurgitate truisms.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." -- Donald Knuth (My emphasis)
Donald Knuth was clearly for optimizing software, he merely said that you should profile before you optimize. The author is clearly profiling his code, and there's nothing wrong with getting more out of the hardware you paid for.
"Page align everything" by convention is in fact a form of optimization without profiling. TFA explains in detail why this is yet another bad idea, perhaps you read something in my comment I did not write?
That is ridiculous. Page align everything can easily be a leftover code that is fast for old CPU, as you said in your original content. You would still call that premature optimization? Or you think that every time new processor is released, you must re-profile all your original code to see whether the old optimization still solve the hot path?
Probably the part where you said, "If that is still not enough, extra cloud instances are probably cheaper than wasting your time with extensive profiling and manual optimizations."
At least profiling showed the author why page aligning all the things is silly. I have yet to work on an architecture where it isn't at best a waste of time, so I'm not sure why the measurement was necessary, but hey—running the test cured a potential delusion.
I also have yet to work on a system that can talk over the network faster than it can to another core that shares a layer of cache with it.
Besides, hardware savings are multiplied over all your customers—it's only 1:1 if you're working on software for a single entity. If that's your case, then you're probably right—any time on making quality software is probably wasted because few will benefit, and hardware probably is cheaper than dev time. That's not the world everyone lives in, though.
Quite right, but if you ship software to customers you'd have to profile on a variety of CPUs or risk regressing on other models. Profiling on recent Intel x86_64 CPUs gave me the (perhaps false) impression TFA author writes for a known or even controlled environment. That is indeed not a luxury everyone enjoys, so I raised a portability concern. However, the potential benefits of cheap horizontal scaling also extends to said customers.
I use recent Intel CPUs at work but ARM/MIPS/PPC for non-work. The point of the article wasn't to say "do this, it's better!" it's "hey, turns out this easy thing people were doing may be making things slower; maybe you should double-check first."
The funny thing: in fact, it will work, and for exactly the same reasons. The manual describes it thus: "The conflicting condition is a stride determined by the size of the cache in bytes, divided by the number of ways."
L1 caches for most modern CPUs work in this manner, and you see the same result. (Wikipedia has a description - http://en.wikipedia.org/wiki/CPU_cache - the type of cache commonly employed today being the N-way set associative type.) You can run the same calculations to get an equivalent value for each CPU. For example, you asked about HPPA: for a PA8700, this value would - I suppose... I just found the cache specification using Google :) - be 384KBytes, as its data cache is 1.5MBytes 4-way set associative.
As a more general note: If you try to seriously solve performance problems, you'll quickly find, as I always have, that there's little basis in reality for the idea that they can be fixed late in the day with a few spot hacks. Indeed, that idea is usually the reason the problems have arisen in the first place.
But that idea has to be the basis of any doctrine of adopting a just-in-time policy for performance problems! So if you're not a big fan of programming with performance in mind, then I do think you should be celebrating this kind of quick tweak, rather than decrying it. It's evidence for your position.
My position is based in pragmatism. Code that works and is delivered in time is often more desirable than code that works, is fast, but delivered late. There's always a cost-benefit tradeoff to be made and if warm bodies yield more performance per buck than cold ones^, that's great for us programmers!
As for mindset, page aligned allocations are required to use protection modes and I tend to program more with security in mind. Glad it helps performance, but it could often times be a completely unintentional side effect. Thanks for your insights, though. Appreciated!
^: Assuming they're at present in idle (or off) state.
Yet Knuth is one of the greater optimizers of all time with his combinatorial work. I ran into this myself writing a muscle tremor filter to run in real time in an ECG data collection system in 1970. The point was to drop the phone call from the patient's bedside if there was too much tremor interference from the patient.
There just wasn't enough CPU bandwidth to handle very much processing. So the first version tried to be quite fast. But it turned out that it gave false positives as well as false negatives. No shipping of that sucker. I made up a rule for performance-critical software: "First, make it right, then make it fast".
I am curious what about the article suggests that the optimization is premature? Do you mean to say that one should never worry about optimization?
Somewhere in the past few months I read a blog post where the author showed how even the same code, compiled and executed on the same machine, could show significantly different performance between compiles. Does anyone have a reference to that post?
(This benchmark) "shows a dramatic difference in behaviour between Linux and FreeBSD/DragonflyBSD (and likely other BSDs.) It turns out that most of the difference is due to memory layout by the allocator. The matrices are large, and jemalloc page aligns these. So there's significant cache line aliasing effects."
The blog article author measured then the speed of the above benchmark adding different offsets, and gave some useful links.
Best read not on the original blog site (ugly javascript dependency and moving wheels, I do hope such technologies get to be avoided) but on the link given by aw3c2 here.
You did get 55 upvotes from people that appreciated your post, and possibly didn't leave a comment. I hope you can see that as the positive feedback it's meant to be?
54 comments
[ 3.2 ms ] story [ 103 ms ] thread(I get the feeling I am missing something obvious.)
Another thing is that, actually, design has come a long way and many modern websites look way better than many older books.
Edit: Yep, totally forgot about hyphenation. I guess I haven't seen hyphenated text in a long time, as everything in web is unhyphenated.
You'd fall over if you saw the subtlety of the tools and the amount of effort that goes in to typesetting a book with justified body text. It is not at all unusual for a publisher to employ staff specifically for the task of typesetting. In the final stages of book production, the typesetters are assigned sections of the book after all edits are complete (ha! in a perfect world), at which point they meticulously review each page of text, often manually inserting/removing hyphenation, until the text is laid out correctly.
Care to venture a guess at the number of bloggers who do the same when using 'text-align: justify'?
You can fit more characters per line in a justified layout.
> It's done to look good, and succeeds. But it requires work to do right.
Absolutely, but well executed left-alignment can also look good, and in a format where you don't necessarily have control over the size of the page and the time to properly justify the text it should be preferred. IMO, left-alignment beats poorly justified text every time.
no you can't
editing to be a bit more descriptive: Here's an example: http://i.stack.imgur.com/ahM5C.png
With hyphenation and acceptable kerning, the justified text has more characters per line.
Ummm, justification is about adding space to spread a line out: it's impossible to fit more text on a line that way.
Kerning is about removing space. It's related to by independent of justification. A well-laid-out work will do both.
> Absolutely, but well executed left-alignment can also look good
Meh. For printed material I think it's worth the effort to justify.
> in a format where you don't necessarily have control over the size of the page and the time to properly justify the text it should be preferred. IMO, left-alignment beats poorly justified text every time.
No argument there.
Basically, in a well-typeset book, nearly every line break is a manually selected hard break rather than an automatically generated soft wrap.
Mandatory JavaScript delenda est!
You don't need JS to display HTML text. Browsers have had that ability since Berners-Lee.
Then open the file in your browser of choice.
Here is one quick dirty way using only shell, sed, nc and the openssl binary:
https://news.ycombinator.com/item?id=7367156
Example:
Copy and paste the script into a file and save as some filename.
Then
It is still an annoyance to have to do this; I wholeheartedly agree with your comment.I don't mean to pick on you personally, or just on this one comment. (Your second sentence alone, by the way, would have been a helpful contribution.) The problem is the tedious stampedes such comments spawn.
Maybe a "offtopic" or "noise" flag could be used for punishing comments like this (similarly to random comments that praise a submission without adding anything) so they float down but not into the grey negative score area?
What works for i386 may not be applicable on arm/hppa/ppc/etc. It should not even matter these days as almost every CPU clocks well over 1000MHz. If that is still not enough, extra cloud instances are probably cheaper than wasting your time with extensive profiling and manual optimizations.
Few of us have anything substantive to say about that, which is fine—but then we ought to post nothing, not regurgitate truisms.
Donald Knuth was clearly for optimizing software, he merely said that you should profile before you optimize. The author is clearly profiling his code, and there's nothing wrong with getting more out of the hardware you paid for.
At least profiling showed the author why page aligning all the things is silly. I have yet to work on an architecture where it isn't at best a waste of time, so I'm not sure why the measurement was necessary, but hey—running the test cured a potential delusion.
I also have yet to work on a system that can talk over the network faster than it can to another core that shares a layer of cache with it.
Besides, hardware savings are multiplied over all your customers—it's only 1:1 if you're working on software for a single entity. If that's your case, then you're probably right—any time on making quality software is probably wasted because few will benefit, and hardware probably is cheaper than dev time. That's not the world everyone lives in, though.
I use recent Intel CPUs at work but ARM/MIPS/PPC for non-work. The point of the article wasn't to say "do this, it's better!" it's "hey, turns out this easy thing people were doing may be making things slower; maybe you should double-check first."
L1 caches for most modern CPUs work in this manner, and you see the same result. (Wikipedia has a description - http://en.wikipedia.org/wiki/CPU_cache - the type of cache commonly employed today being the N-way set associative type.) You can run the same calculations to get an equivalent value for each CPU. For example, you asked about HPPA: for a PA8700, this value would - I suppose... I just found the cache specification using Google :) - be 384KBytes, as its data cache is 1.5MBytes 4-way set associative.
As a more general note: If you try to seriously solve performance problems, you'll quickly find, as I always have, that there's little basis in reality for the idea that they can be fixed late in the day with a few spot hacks. Indeed, that idea is usually the reason the problems have arisen in the first place.
But that idea has to be the basis of any doctrine of adopting a just-in-time policy for performance problems! So if you're not a big fan of programming with performance in mind, then I do think you should be celebrating this kind of quick tweak, rather than decrying it. It's evidence for your position.
As for mindset, page aligned allocations are required to use protection modes and I tend to program more with security in mind. Glad it helps performance, but it could often times be a completely unintentional side effect. Thanks for your insights, though. Appreciated!
^: Assuming they're at present in idle (or off) state.
There just wasn't enough CPU bandwidth to handle very much processing. So the first version tried to be quite fast. But it turned out that it gave false positives as well as false negatives. No shipping of that sucker. I made up a rule for performance-critical software: "First, make it right, then make it fast".
I am curious what about the article suggests that the optimization is premature? Do you mean to say that one should never worry about optimization?
https://github.com/erikarn/himenobmtxpa
(This benchmark) "shows a dramatic difference in behaviour between Linux and FreeBSD/DragonflyBSD (and likely other BSDs.) It turns out that most of the difference is due to memory layout by the allocator. The matrices are large, and jemalloc page aligns these. So there's significant cache line aliasing effects."
The blog article author measured then the speed of the above benchmark adding different offsets, and gave some useful links.
Best read not on the original blog site (ugly javascript dependency and moving wheels, I do hope such technologies get to be avoided) but on the link given by aw3c2 here.
yes, it does. So I just flipped back to "simple" for now. Ugh.
Please continue writing solid technical posts.