What happens when you page align everything | Hacker News Reader

What happens when you page align everything

adrianchadd.blogspot.com

58 pointsinopinatus53 comments

Introductionary link, with everything you need to know before you read this blog 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.

... turns out the #1 feedback was "that blog template sucks."

yes, it does. So I just flipped back to "simple" for now. Ugh.

http://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality

Please continue writing solid technical posts.

Thank you and sorry ;)

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?

Ok, I guess not everything is about CSS :)

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."

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?

Likely https://homes.cs.washington.edu/~bornholt/post/performance-e... (*"Even more terrifying than linking order is a result in this paper that shows how the size of your UNIX environment variables biases performance")

That was what I was looking for, thanks!

There's literally tabula rasa for everyone blocking scripts...

World's worst blog design strikes again with its mandatory Javascript and annoying layout. Here is a static copy: https://archive.today/uvbua

Thank you.

In a similar vein. Can we please never use `text-align: justify;` it might as well be called `hard-to-read: dyslexics`

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

It looks like browsers only support it with a prefix like -moz-. Doesn't that mean it's not even a standard yet?

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'?

I assume justifying text is to primarily maximise the amount of text on the paper to make a cheaper book. It shouldn't even exist on the web.

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.

> You can fit more characters per line in a justified layout.

no you can't

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.

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.

justification refers only to adjusting intra-word and -letter spacings, your example shows hyphenation only

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.

No argument there.

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.

I assumed it was some kind of joke about page alignment

Me too, in a desktop publishing sense of the thing

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.

This business of requiring code execution in order to read a blog entry really must end. It's unsafe, but worse it's ridiculous.

Mandatory JavaScript delenda est!

Why is this JS unsafe? It's all hosted by Google, just like the blog.

Requiring execution of unnecessary code increases the surface area for any potential exploit.

You don't need JS to display HTML text. Browsers have had that ability since Berners-Lee.

Ugh, that template sucks. Fixed.

Fortunately it still remains easy to convert almost any blogger/blogspot blog to a simple HTML file with no gratuitous Javascript or CSS.

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

    filename adrianchadd > f.html
    browsername f.html

It is still an annoyance to have to do this; I wholeheartedly agree with your comment.

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?

TL;DR - yes.

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.

Hi! Author here!

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?

Reply on news.ycombinator.com