<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><title>Re: [Liblas-devel] I/O performance? -- your help requested!</title><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Your box is too fast. :-(<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Could you maybe do the runs again, but with &#8220;&#8211;n 100000000&#8221; (100x larger)?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-mpg<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Smith, Michael ERDC-CRREL-NH [mailto:michael.smith@usace.army.mil] <br><b>Sent:</b> Saturday, February 05, 2011 4:48 AM<br><b>To:</b> mpg@flaxen.com; liblas-devel@lists.osgeo.org<br><b>Subject:</b> Re: [Liblas-devel] I/O performance? -- your help requested!<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>lidar@lidarora1 tmp]$ uname -a<br>Linux lidarora1 2.6.32-100.0.19.el5 #1 SMP Fri Sep 17 17:51:41 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux<br><br>2 CPU, 4cores/cpu + hyperthreading = 16 virtual cores <br><br>processor &nbsp;&nbsp;&nbsp;: 15<br>vendor_id &nbsp;&nbsp;&nbsp;: GenuineIntel<br>cpu family &nbsp;&nbsp;&nbsp;: 6<br>model &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: 26<br>model name &nbsp;&nbsp;&nbsp;: Intel(R) Xeon(R) CPU &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;X5570 &nbsp;@ 2.93GHz<br>stepping &nbsp;&nbsp;&nbsp;: 5<br>cpu MHz &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: 1600.000<br>cache size &nbsp;&nbsp;&nbsp;: 8192 KB<br><br><br><br>[lidar@lidarora1 tmp]$ time laszippertest -n 1000000<br>(skipping range coder test)<br>laszipper1 wrote 7000000 bytes in 0.03 seconds<br>laszipper2 wrote 3898142 bytes in 0.13 seconds<br>SUCCESS: lasunzipper1 read 7000000 bytes in 0.02 seconds<br>SUCCESS: lasunzipper2 read 3898142 bytes in 0.18 seconds<br><br>real &nbsp;&nbsp;&nbsp;0m0.379s<br>user &nbsp;&nbsp;&nbsp;0m0.349s<br>sys &nbsp;&nbsp;&nbsp;0m0.029s<br>[lidar@lidarora1 tmp]$ time laszippertest -n 1000000<br>(skipping range coder test)<br>laszipper1 wrote 7000000 bytes in 0.03 seconds<br>laszipper2 wrote 3898142 bytes in 0.13 seconds<br>SUCCESS: lasunzipper1 read 7000000 bytes in 0.02 seconds<br>SUCCESS: lasunzipper2 read 3898142 bytes in 0.17 seconds<br><br>real &nbsp;&nbsp;&nbsp;0m0.366s<br>user &nbsp;&nbsp;&nbsp;0m0.336s<br>sys &nbsp;&nbsp;&nbsp;0m0.029s<br>[lidar@lidarora1 tmp]$ time laszippertest -n 1000000<br>(skipping range coder test)<br>laszipper1 wrote 7000000 bytes in 0.03 seconds<br>laszipper2 wrote 3898142 bytes in 0.13 seconds<br>SUCCESS: lasunzipper1 read 7000000 bytes in 0.02 seconds<br>SUCCESS: lasunzipper2 read 3898142 bytes in 0.16 seconds<br><br>real &nbsp;&nbsp;&nbsp;0m0.366s<br>user &nbsp;&nbsp;&nbsp;0m0.338s<br>sys &nbsp;&nbsp;&nbsp;0m0.026s<br>[lidar@lidarora1 tmp]$ time laszippertest -n 1000000 -s<br>(skipping range coder test)<br>laszipper1 wrote 7000000 bytes in 0.03 seconds<br>laszipper2 wrote 3898142 bytes in 0.13 seconds<br>SUCCESS: lasunzipper1 read 7000000 bytes in 0.02 seconds<br>SUCCESS: lasunzipper2 read 3898142 bytes in 0.16 seconds<br><br>real &nbsp;&nbsp;&nbsp;0m0.364s<br>user &nbsp;&nbsp;&nbsp;0m0.338s<br>sys &nbsp;&nbsp;&nbsp;0m0.024s<br>[lidar@lidarora1 tmp]$ time laszippertest -n 1000000 -s<br>(skipping range coder test)<br>laszipper1 wrote 7000000 bytes in 0.03 seconds<br>laszipper2 wrote 3898142 bytes in 0.13 seconds<br>SUCCESS: lasunzipper1 read 7000000 bytes in 0.02 seconds<br>SUCCESS: lasunzipper2 read 3898142 bytes in 0.17 seconds<br><br>real &nbsp;&nbsp;&nbsp;0m0.369s<br>user &nbsp;&nbsp;&nbsp;0m0.339s<br>sys &nbsp;&nbsp;&nbsp;0m0.028s<br>[lidar@lidarora1 tmp]$ time laszippertest -n 1000000 -s<br>(skipping range coder test)<br>laszipper1 wrote 7000000 bytes in 0.03 seconds<br>laszipper2 wrote 3898142 bytes in 0.13 seconds<br>SUCCESS: lasunzipper1 read 7000000 bytes in 0.02 seconds<br>SUCCESS: lasunzipper2 read 3898142 bytes in 0.17 seconds<br><br>real &nbsp;&nbsp;&nbsp;0m0.364s<br>user &nbsp;&nbsp;&nbsp;0m0.335s<br>sys &nbsp;&nbsp;&nbsp;0m0.027s<br><br><br><br>-- <br>Michael Smith<br>Remote Sensing/GIS Center<br>US Army Corps of Engineers<br><br><br>On 2/4/11 11:39 AM, &quot;Michael P. Gerlek&quot; &lt;<a href="mpg@flaxen.com">mpg@flaxen.com</a>&gt; wrote:</span><o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Do you have 5-10 minutes to spare today?<br><br>Your libLAS team (well, me anyway) is wondering about I/O performance of the<br>liblas kit -- specifically, when doing binary reading and writing, is there<br>any fundamental performance difference between using C-style FILE* I/O and<br>C++-style stream I/O? &nbsp;And if streams are better, would boost's stream be<br>better still? &nbsp;If you google around a bit, you'll find lots of contradictory<br>(and sometimes overly passionate) statements about this topic. &nbsp;At the end<br>of the day, though, the consensus seems to be that:<br><br>&nbsp;&nbsp;(1) you need to be &quot;smart&quot; if you're using C++ I/O -- it is easy to shoot<br>yourself in the foot<br>&nbsp;&nbsp;(2) modern C++ streams are implemented on top of the native OS APIs<br>&nbsp;&nbsp;(3) under Visual Studio, FILE* operations and streams are both implemented<br>using the win32 APIs, but streams have an additional lock (that is claimed<br>by some to be not needed)<br><br>and, most importantly,<br><br>&nbsp;&nbsp;(4) performance varies greatly with different I/O patterns, e.g. large<br>sequential block reads vs small random reads<br><br>Very fortunately, we happen to already have a rough, 1st-order I/O<br>performance test built into the laszip tree. &nbsp;If you have that tree built<br>(<a href="http://hg.liblas.org/zip">http://hg.liblas.org/zip</a>), in Release mode, could you please send me the<br>results of running the &quot;laszippertest&quot; test app, as follows?<br><br>&nbsp;&nbsp;&nbsp;&nbsp;time ./laszippertest -n 1000000<br>&nbsp;&nbsp;&nbsp;&nbsp;time ./laszippertest -n 1000000<br>&nbsp;&nbsp;&nbsp;&nbsp;time ./laszippertest -n 1000000<br>&nbsp;&nbsp;&nbsp;&nbsp;time ./laszippertest -n 1000000 -s<br>&nbsp;&nbsp;&nbsp;&nbsp;time ./laszippertest -n 1000000 -s<br>&nbsp;&nbsp;&nbsp;&nbsp;time ./laszippertest -n 1000000 -s<br><br>The first three runs will encode and decode 1 million random points using<br>FILEs, and the second three will do it with streams. &nbsp;This is not a perfect<br>test, but it represents something approximating the real I/O footprint or<br>traces that liblas uses.<br><br>Oh, and be sure to include the kind of platform (processor speed, compiler,<br>OS) you're running it on.<br><br>Thanks much!<br><br>-mpg<br><br><br>_______________________________________________<br>Liblas-devel mailing list<br><a href="Liblas-devel@lists.osgeo.org">Liblas-devel@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/mailman/listinfo/liblas-devel">http://lists.osgeo.org/mailman/listinfo/liblas-devel</a></span><o:p></o:p></p></div></div></body></html>