more updates in r40860, mostly documentation
Hamish wrote:
Markus Metz wrote:
The core of the lidar tools is the lidarlib, that is AFAICT
robust and working. Bugs are most likely in modules, so I'll try
to add comments there. I have reorganized the code for v.surf.bspline
in the hope that it is now easier to read.
Slightly off-topic, but while we are thinking about this code ...
A while back I did some crude profiling of the v.lidar tools and found
that it was spending lots and lots of time in the Tcholetsky decomposition
loop (3-for loops deep).
That's better now because the matrix is a bit smaller.
It seemed like a good & simple test case for using OpenMP to multi-thread
it, but I got stuck with it segfaulting. AFAIR the problem was that OpenMP
wanted you to malloc the entire thing before starting, and this could
get big.
if it interests you, see the attached patch and
https://trac.osgeo.org/grass/ticket/657
http://lists.osgeo.org/pipermail/grass-dev/2009-June/044709.html
http://lists.osgeo.org/pipermail/grass-dev/2009-June/044705.html
http://grass.osgeo.org/wiki/OpenMP
Hmm, if I understand the code right, only the innermost for loop can be
executed in parallel because the first two for-loops need results of
previous runs (not possible to run i + 1 before i, same for j). But I
don't know that parallel stuff, I would in any case first optimize the
code without parallelization, only then add multithreading.
I forgot to mention, there is a problem with sqlite, it is much slower
than dbf, no idea if this is a problem of my system or of the grass
sqlite driver or of the way auxiliary tables are accessed by the lidar
tools.
that sounds vaguely familiar, but as a general thing not necessarily
to do with v.lidar. probably something about it in the archives?
I discovered two little tricks: first, create the table, close database
and driver, open database and driver again, work with table, second,
creating an index on the table if possible helps too. Tested with sqlite
and dbf.
Markus M
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
