| Age | Commit message (Collapse) | Author |
|---|
|
And adapt a new CMakeLists.txt file for it. On the way I've also
found out that we where double-compilling a few files. I've also
set the subsurface-core as a include_path but that was just to
reduce the noise on this commit, since I plan to remove it from
the include path to make it obligatory to specify something like
include "subsurface-core/dive.h"
for the header files. Since the app is growing quite a bit we ended
up having a few different files with almost same name that did
similar things, I want to kill that (for instance Dive.h, dive.h,
PrintDive.h and such).
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
I know everyone will hate it.
Go ahead. Complain. Call me names.
At least now things are consistent and reproducible.
If you want changes, have your complaint come with a patch to
scripts/whitespace.pl so that we can automate it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Division is expensive, so replace it with multiplication instead. But
don't multiply by 0.1 (inexact in floating point), multiply by 10 and
then do one division at the end.
Make sure the final division is at the very end, so that the result
isn't immediately used. That allow the division to overlap with the
function return overhead, hiding it further.
This is silly, but while thinking about different file formats and doing
profiling of loading big files, it turned out that "strtod_flags()"
actually showed up in profiles. Not very high, but at more than 1%.
This makes the common case (no exponent) use only addition and
multiplication until the very end, and makes the division be the very last
thing it does, which minimizes the data dependencies on the division.
For my stupid test-case, it cut the cost of strtod_flags() in half
according to the profile. The half a percent speedup on loading time isn't
really noticeable or even measurable outside of profiling startup costs,
but rather than carry this along in my tree or just throw it away, I'm
sending it out to see if anybody cares.
Note that we could avoid the final division by instead multiplying
"decimal" with 0.1 rather than multiplying by 10 (and switching the sign
test over), but that's a fundamentally inexact operation in binary floatig
point, so doing the "multiply by tens for decimals" ends up keeping
everything exact as long as possible.
For our use, we probably really don't care, but whatever. End result: this
should not only speed things up immeasurably, it *might* also make things
more precise at a level that we really don't care about :^p
I'm really selling this piece of crap, aren't I?
[Dirk Hohndel: sorry - had to pull the full email into the commit message
this is so good, you couldn't make it up]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
The C library doesn't use const char pointers for legacy reasons (and
because you *can* modify the string the end pointer points to), but
let's do it in our internal implementation just because it's a nice
guarantee to have.
We actually used to have a non-const end pointer and replace a decimal
comma with a decimal dot, but that was because we didn't have the fancy
"allow commas" flags. So by using our own strtod_flags() function, we
can now keep all the strings we parse read-only rather than modify them
as we parse them.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
We'll want to do sane parsing of strings, but the C library makes it
hard to handle user input sanely and the Qt toDouble() function
interface was designed by a retarded chipmunk.
So just extend our existing hacky "ascii_strtod()" to allow a more
generic interface.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
Tomaz Canabrava
Dirk Hohndel
Linus Torvalds