<div dir="ltr">2008/9/17 Alan Evans <span dir="ltr">&lt;<a href="mailto:ame.fedora@gmail.com">ame.fedora@gmail.com</a>&gt;</span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Wed, Sep 17, 2008 at 7:24 AM, Bingo &lt;<a href="mailto:right.ho@gmail.com">right.ho@gmail.com</a>&gt; wrote:<br>
&gt; Read this for a comparison in performance for 32 bit, and 64 bit linux:<br>
&gt; <a href="http://bingouv.blogspot.com/2008/08/desktop-linux-performance-comparison32.html" target="_blank">http://bingouv.blogspot.com/2008/08/desktop-linux-performance-comparison32.html</a><br>
&gt; .<br>
<br>
</div>Please don&#39;t take undue offence, but I don&#39;t think that your testing<br>
methodology sufficiently isolated the thing you were comparing. For<br>
example, your function for calculating factorials:<br>
<br>
define f (x) {<br>
if (x &lt;= 1) return (1);<br>
return (f(x-1) * x);<br>
}<br>
<br>
Unless the tail recursion was optimized out of this, your result will<br>
likely be swamped by the overhead of much stack manipulation. And the<br>
fact that you used bc means that the the actual calculating is once or<br>
twice removed from the architecture.<br>
<br>
To be fair, you did recognize this in the last paragraph of your<br>
article. And I&#39;m not saying that your comparisons have no value, just<br>
that their value is diminished for considering the difference between<br>
32 and 64 bit processor architecture.<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="Wj3C7c">fedora-list mailing list<br>
<a href="mailto:fedora-list@redhat.com">fedora-list@redhat.com</a><br>
To unsubscribe: <a href="https://www.redhat.com/mailman/listinfo/fedora-list" target="_blank">https://www.redhat.com/mailman/listinfo/fedora-list</a><br>
Guidelines: <a href="http://fedoraproject.org/wiki/Communicate/MailingListGuidelines" target="_blank">http://fedoraproject.org/wiki/Communicate/MailingListGuidelines</a><br>
</div></div></blockquote></div><br><br>Please criticize, this is the value I stand to gain from writing the article: get more criticism.<br>
<br>
I totally understand that bc is distant from the architecture because
of being an arbitrary precision calculator. No other calculator I tried could hold factorial of multi-ten-thousand numbers so I had to choose bc. But stack manipulation? <br><br>64
bit needs to be better at stack manipulation too if it is to perform
better, enough to matter to end users. So I did not shield 64 bit from
this responsibility. Nor do I want to shield bc from the responsibility of optimizing for 64 bit systems. The review is about real programs, on real OSes, real hardware doing (almost) real computation. So it will not make excuses for them.<br>
<br>If some processor intensive tasks have sub-tasks that 64 bit is not drastically better than 32 bit yet, it is only fair that this reflects in the results. Though I&#39;d like any suggestions about other tasks that can be compared.<br>
</div>