Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unusual speed boost: size matters

webkit.org

Post reply on HN
Print view View original

31–40 of 74 posts

Re: Unusual speed boost: size matters

#31

Post by doug363 »

kgabis wrote: post #24
cLeEOGPw wrote: post #11

It is not mentioned in the article that writing "inline" does not automatically make the function inline. It only gives C++ compiler a hint that it might be worth inlining. Compiler can inline function even if it has no inline keyword, and can not inline even when the function has the keyword, if it decides inlining would be inefficient.

Why does that keyword even exist then?

It allows multiple (equivalent) definitions from different translation units to coexist in the same program. That's the only actual meaning attached to it by the standard.

Re: Unusual speed boost: size matters

#32

Post by Rygu »

Qantourisc wrote: post #17

Or even better then double: inline void updateCachedWidth() { m_cachedWidth = computeWidth() * deviceScaleFactor(); } Ghee, was that line so hard to read ? No it's easier ! (Might have just been an example though.)

Came here to ask about this, found your answer. Thanks.

Re: Unusual speed boost: size matters

#33

Post by caf »

brigade wrote: post #20
charliesome wrote: post #18

Earlier quoted context omitted.

> C++ const has no effect on optimization, since it can be casted away. Modifying an object that has had its const-ness casted away is undefined behaviour.

Sorry, I should have been more specific. C/C++ const has no effect on optimization, unless it's on a global/static object and the compiler can see the original declaration. I'm not going to look it up in the C++ spec, but in C it's only undefined behavior if the original object was const, and it would make sense for C++ to be the same.

It doesn't matter whether it's static or automatic storage duration.

Re: Unusual speed boost: size matters

#34

Post by nailer »

unknownian wrote: post #2

Without a doubt, WebKit is one of the most interesting parts of Apple. A community of open source developers that accept contributions (I'm assuming) with a developer-focused open blog with tips on writing C++ - a language not even particularly widely used elsewhere in Apple.

If Apple could have developed their own proprietary rendering engine they would have. Jumping on KHTML meant they could get a working, OS X UI compliant browser when IE for OS X was no longer being maintained, even if the guts of that app had to be shared with others.

Re: Unusual speed boost: size matters

#35

Post by DannyBee »

brigade wrote: post #15
minamea wrote: post #14

Earlier quoted context omitted.

What a fantastic catch. This is also one of Meyer's Effective C++ tips: always use const when applicable.

Wrong const. He's talking about the gcc function attribute extension, which most of the time is too strict, so recommending its general use isn't a great idea. C++ const has no effect on optimization, since it can be casted away. And being aware of aliasing issues is a good idea in general; nothing the compiler does can fix this in the general case (e.g. if computeWidth() is located in an external shared library it's…

"And being aware of aliasing issues is a good idea in general; nothing the compiler does can fix this in the general case (e.g. if computeWidth() is located in an external shared library it's basically impossible for the compiler to determine that it can't modify m_cachedWidth)"

This is of course, false, it would be more accurate to say "in most open source compilers, ....". Doing compile/dynamic link/ analyze based points-to analysis is at least 15 years old (papers published), and likely much older.

There is nothing that fundamentally stops the compiler from knowing things about external shared libs. At some point, the binary is being linked against those libs. You can store the necessary info in those libs, and then use it at link time

(This is in fact, one of the premises of LLVM and having a good, cheap, complete on-disk representation).

In any case, in this example,

1. you don't need the function attribute, just the normal C++ function modifier (It's too early to remember if that is the right C++ terminology) would do, since m_cachedWidth is clearly a member.

2. It's not in a shared library, clearly :)

Re: Unusual speed boost: size matters

#36

Post by nly »

unknownian wrote: post #2

Without a doubt, WebKit is one of the most interesting parts of Apple. A community of open source developers that accept contributions (I'm assuming) with a developer-focused open blog with tips on writing C++ - a language not even particularly widely used elsewhere in Apple.

> C++ - a language not even particularly widely used elsewhere in Apple.

Isn't this why Objective-C++ is a thing?

Re: Unusual speed boost: size matters

#37

Post by pavlov »

unknownian wrote: post #2

Without a doubt, WebKit is one of the most interesting parts of Apple. A community of open source developers that accept contributions (I'm assuming) with a developer-focused open blog with tips on writing C++ - a language not even particularly widely used elsewhere in Apple.

C++ is widely used by the Apple OS teams, but they don't expose C++ APIs directly.

A lot of the plain-C APIs with a CoreFoundation style interface are actually C++ underneath. (No insider information necessary, this is easy to see in stack traces and process call stack samples.)

Re: Unusual speed boost: size matters

#38

Post by astral303 »

moconnor wrote: post #28
kinlan wrote: post #3

I may have missed it, but were there any stats about the actual performance gains? It often mentioned binary size etc but nothing about the impact it had.

I cam here to say this. It's weird to talk about performance without actually showing any performance figures. I'm all for removing old code, but if you're going to claim performance gains then why not measure those?

Exactly. You really should avoid doing performance optimizations without measurements that show improvement as well as provide some coverage against performance regressions.

Here's an example, Thrift (as used in Hector, a Cassandra client), had someone make a performance improvement:

https://issues.apache.org/jira/browse/THRIFT-959

The discussion has a lot of "shoulds", and one measurement of latency distributions, but no measurement of typical workloads or bulk inserts. Turns out, that caused at least a 30% performance regression:

https://issues.apache.org/jira/browse/THRIFT-1121

Re: Unusual speed boost: size matters

#39

Post by khuey »

Someone wrote: post #19
DannyBee wrote: post #5

the updateCachedWidth example probably gives the wrong idea to a lot of folks. You would be just as well off making computeWidth const/pure/readonly/whatever The compiler can even detect if it modifies anything and mark it for you. In fact, better compilers will compute mod/ref information and know that m_cachedWidth is not touched over that call. However, LLVM's (which is what at least Apple is using) basic stateles…

I agree with the 'make things const' part, but I would expect m_cachedWidth to be mutable. I'm too lazy to check that now, but if so, that would not help here. Even if it is not, I still think this is an example of "how you should modify your code". Reason? Doing temp = foo(); temp *= bar(); m_member = temp; keeps your state consistent in case bar() throws. I would even use it if bar() is known not to throw, because…

Most low-level C++ projects (including Webkit and Gecko) don't use C++ exceptions.

Re: Unusual speed boost: size matters

#40

Post by mjn »

fhd2 wrote: post #13
nnq wrote: post #10

looking on example 1, I wonder why don't languages like C++ or D or Go just add a "pure" keyword for functions that don't modify the global environment or their arguments? this will help the optimizers a lot I imagine. and yeah, I get it that there still could be roundabout side-effects, it's not Haskell, but the compiler could just trust the programmer that he knows what he's doing when he sticks the "pure" keyword…

> looking on example 1, I wonder why don't languages like C++ or D or Go just add a "pure" keyword for functions that don't modify the global environment or their arguments? The function in example 1 is modifying a member variable, and there is indeed a keyword that requires functions not to modify the class they operate on: const. It's very powerful, and by a long shot my favourite feature of C++. That said, the fun…

The problem here isn't updateCachedWidth(), which indeed modifies a member variable, but deviceScaleFactor(), which doesn't. Since LLVM doesn't infer that deviceScaleFactor() leaves m_cachedWidth unmodified, it forces a reload of m_cachedWidth after the function call in case the value changed.
Post reply on HN