61–70 of 197 posts
Const won't necessarily make things faster but constant values will (whether or not explicitly inferred). I noticed, for example, a 2x+ speedup in one of my ray tracers by downgrading my dynamic 2d/3d/4d vector class* to always have a constant size of 3. * (poor choice, I know)
Const won't necessarily make things faster but constant values will (whether or not explicitly inferred). I noticed, for example, a 2x+ speedup in one of my ray tracers by downgrading my dynamic 2d/3d/4d vector class* to always have a constant size of 3. * (poor choice, I know)
Const won't necessarily make things faster but constant values will (whether or not explicitly inferred). I noticed, for example, a 2x+ speedup in one of my ray tracers by downgrading my dynamic 2d/3d/4d vector class* to always have a constant size of 3. * (poor choice, I know)
Having a constant size probably made it easy for the compiler to properly generate bytecode that uses vectorized instructions
> This is true in practice because enough real-world C code has “I know what I’m doing” casting away of const. I found this out the hard way when I implemented OptimumC, the first data flow analysis optimizer for DOS C compilers back in the 1980's. I had to undo doing optimizations on const. Anecdote: Optimum C blew away all the other C compilers on a magazine benchmark article because it figured out that the benchma…
I'd love to hear more about any aspect of this if you have time. (:
Shouldn't the test instead be: const int * const Haven't profiled it but would make more sense to have the pointer also be const instead of having a non const pointer as input?
Const pointer is a statement about the internal variables of a function definition, usually not of any interest outside the function itself and therefore rarely used.
> This is true in practice because enough real-world C code has “I know what I’m doing” casting away of const. I found this out the hard way when I implemented OptimumC, the first data flow analysis optimizer for DOS C compilers back in the 1980's. I had to undo doing optimizations on const. Anecdote: Optimum C blew away all the other C compilers on a magazine benchmark article because it figured out that the benchma…
> Anecdote: I'd love to hear more about any aspect of this if you have time. (:
We included full library source with the compiler, for free. No reviewer ever noticed that. One day, Borland decided to make source code for their library, sans the floating point stuff, available for an extra charge. This generated headlines in the next compiler roundup article. No mention that complete library source code, including floating point, came with my compiler.
So we decided to split off the library source code into a separate package, and charged for it. This solved the marketing problem, and doubled the money we were making.
This was how I learned about the common practice of upselling. I am a slow learner.
Of course, these days we give away everything for free!
I've worked with JavaScript weenies who are in love with the const declaration. They don't have an answer, though, when I ask, "Shouldn't the compiler be able to notice that a variable isn't changed in it's lifetime?" Most of the const values are just local and never leave the function but the weenies continue to stomp their feet when I use "var". The compilers are smart. Let them do their thing.
Actually no, compilers can't assume that `foo` is const. var foo = 0; eval("foo = 1"); With that said, virtually nobody uses `const` for performance reasons, but for developer readability and avoiding mistakes.
Given code like `function foo(fn, str) { var foo = 0; fn(str); return foo; }`, you might be wondering what happens if foo is called with `foo(eval, "foo = 1");`. The answer is that a standard eval call isn't actually a normal function call but better understood as a special syntax resembling a function call. There's a big difference between `eval(x);` and `var e = eval; e(x);`. When you take the value of `eval` (by passing it as a parameter or assigning it to a variable, etc), the value you get is actually the "indirect eval" function, which works slightly differently than standard eval: it does not get access to the local scope that it's called in. This means its usage won't break any optimizations that assume the local scope won't be modified.
> So most of the time the compiler sees const, it has to assume that someone, somewhere could cast it away, which means the compiler can’t use it for optimisation. This is true in practice because enough real-world C code has “I know what I’m doing” casting away of const. Some years ago i'd agree, but experience has shown that C/C++ compiler writers would rather win benchmark games than keep working code working. So…
I may have a non-const object that I pass to a function that takes it by const pointer: that doesn't magically make it const! The object can still be modified, e.g., by an opaque function in the caller which modifies the object not necessarily by casting away cost, but because the object isn't const at all (e.g., it may have a non-const reference to the object).
Const definitely helps optimizations, but only when the object is actually cost. References or pointers to const objects can't tell you that.
For const to help, the object itself needs to be defined const. Just taking a `const object * ` (or `const object&` in C++) doesn't help you determine the constness of the underlying object, and that usually accounts for the majority of const usage by volume.
Limiting the scope to of actual const definitions, it can help a lot, but only in cases where the compiler couldn't move that anyways. So local variable const definitions rarely help, because the compiler can often already prove they are const by inspection (but they can help if the variable escapes).
They are useful especially for global variables (and moral equivalents, like static class members in C++), since the compiler cannot prove by examining only the current TU whether the variable is unmodified (and it is a hard problem even if the whole program can be inspected), so const is a useful promise there.
Earlier quoted context omitted.
> Anecdote: I'd love to hear more about any aspect of this if you have time. (:
Here's another failure of marketing on my part. We included full library source with the compiler, for free. No reviewer ever noticed that. One day, Borland decided to make source code for their library, sans the floating point stuff, available for an extra charge. This generated headlines in the next compiler roundup article. No mention that complete library source code, including floating point, came with my compil…