2008/9/17 Alan Evans <ame.fedora@xxxxxxxxx>
Please criticize, this is the value I stand to gain from writing the article: get more criticism.
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?
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.
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'd like any suggestions about other tasks that can be compared.
On Wed, Sep 17, 2008 at 7:24 AM, Bingo <right.ho@xxxxxxxxx> wrote:Please don't take undue offence, but I don't think that your testing
> Read this for a comparison in performance for 32 bit, and 64 bit linux:
> http://bingouv.blogspot.com/2008/08/desktop-linux-performance-comparison32.html
> .
methodology sufficiently isolated the thing you were comparing. For
example, your function for calculating factorials:
define f (x) {
if (x <= 1) return (1);
return (f(x-1) * x);
}
Unless the tail recursion was optimized out of this, your result will
likely be swamped by the overhead of much stack manipulation. And the
fact that you used bc means that the the actual calculating is once or
twice removed from the architecture.
To be fair, you did recognize this in the last paragraph of your
article. And I'm not saying that your comparisons have no value, just
that their value is diminished for considering the difference between
32 and 64 bit processor architecture.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Please criticize, this is the value I stand to gain from writing the article: get more criticism.
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?
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.
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'd like any suggestions about other tasks that can be compared.
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
