New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gdaldem: syncing all datatypes to 64-bit float for faster shading on 64bit machines #53

Closed
wants to merge 1 commit into
base: trunk
from

Conversation

Projects
None yet
2 participants
@Komzpa

Komzpa commented Apr 4, 2015

Shaves off 15% of hillshade generation time on my machine/dataset.

@rouault

This comment has been minimized.

Show comment
Hide comment
@rouault

rouault Apr 5, 2015

Member
  • There are a few unnecessary whitespace changes in lines not changed otherwise
  • A side effect of this commit is that the output of the slope, aspect, TRI, TPI and roughness algorithms is now Float64 instead of Float32 (i.e. twice larger files). We probably don't need that much of output precision (and the gdaldem manual in apps/gdal_utilities.dox explicitely mentions 32-bit floating point). So you should probably only acquire data on Float64, but still output Float32 (in the non Byte cases)
Member

rouault commented Apr 5, 2015

  • There are a few unnecessary whitespace changes in lines not changed otherwise
  • A side effect of this commit is that the output of the slope, aspect, TRI, TPI and roughness algorithms is now Float64 instead of Float32 (i.e. twice larger files). We probably don't need that much of output precision (and the gdaldem manual in apps/gdal_utilities.dox explicitely mentions 32-bit floating point). So you should probably only acquire data on Float64, but still output Float32 (in the non Byte cases)
@Komzpa

This comment has been minimized.

Show comment
Hide comment
@Komzpa

Komzpa Apr 6, 2015

@rouault should I not change whitespace at all, or separate it into a "tidying" commit?

As for further profiling, one of the slowest parts now is ARE_REAL_EQUAL define, which probably should be rewritten into something like AlmostEqual2sComplement from http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm (but I lack skills to make it polymorphic for both float and double in current code layout).

Komzpa commented Apr 6, 2015

@rouault should I not change whitespace at all, or separate it into a "tidying" commit?

As for further profiling, one of the slowest parts now is ARE_REAL_EQUAL define, which probably should be rewritten into something like AlmostEqual2sComplement from http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm (but I lack skills to make it polymorphic for both float and double in current code layout).

@rouault

This comment has been minimized.

Show comment
Hide comment
@rouault

rouault Apr 6, 2015

Member

I'd prefer avoiding the whitespace changes completely.

Member

rouault commented Apr 6, 2015

I'd prefer avoiding the whitespace changes completely.

@rouault

This comment has been minimized.

Show comment
Hide comment
@rouault

rouault Oct 11, 2016

Member

Substantial speed improvements have been made into trunk, in particular when the input DEM is byte/int16. Closing this PR under the assumption that the trunk improvements make it obsolete

Member

rouault commented Oct 11, 2016

Substantial speed improvements have been made into trunk, in particular when the input DEM is byte/int16. Closing this PR under the assumption that the trunk improvements make it obsolete

@rouault rouault closed this Oct 11, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment