Are there plans to release native 64 bit binaries of GRASS 7 for Windows?<div><br></div><div>Aren<br><br><div class="gmail_quote">On Sun, Mar 6, 2011 at 7:26 AM, Hamish <span dir="ltr"><<a href="mailto:hamish_b@yahoo.com">hamish_b@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Glynn wrote:<br>
> There's very little support for parallelism in GRASS. The<br>
> GPDE library supports it via OpenMP, and the 7.0 version of<br>
> r.mapcalc supports it via POSIX threads.<br>
<br>
</div>... and r.sun will have Seth's support for OpenCL as soon as I<br>
get around to merging it. (* AFAIU you can tell OpenCL to work<br>
on multi core instead of GPU if you want)<br>
<br>
as GRASS is made up of many modules, containing many algorithms,<br>
and different multi-processor approaches are better for different<br>
algorithms/load profiles, it's not to surprising that there'll be<br>
a number of multi-proc approaches in the early days.<br>
<br>
also note that much of GRASS is really I/O bound not CPU bound,<br>
so you'll often get the most improvement by getting a fast RAID<br>
array.<br>
<br>
In the case of v.in.ogr being really slow, I think that's more a<br>
matter of a rather inefficient implementation instead of the need<br>
for raw CPU power. And IIRC the v.in.ogr situation is already a<br>
bit improved in GRASS 7-dev? Multi-core would certainly help, but<br>
in the long run it's better to solve the cause of the slowness<br>
rather than just throw more hardware at it.<br>
<font color="#888888"><br>
<br>
Hamish<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
<br>
_______________________________________________<br>
grass-user mailing list<br>
<a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
</div></div></blockquote></div><br></div>