Re: 32bit vs 64bit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 17, 2008 at 8:42 AM, Bingo <right.ho@xxxxxxxxx> wrote:
> 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.

But I guess that's the point. Even if we hypothetically presume that
64-bit can do a factorial twice as fast as 32-bit, that doesn't mean
that it can do everything else twice as fast. Let's exaggerate this
example to make it clear...

Suppose that the difference is exactly 2x in the case of calculating a
factorial.

Suppose further that there is no difference in stack operations. This
makes sense because I don't think anyone believes that 64-bit systems
can perform PUSH or POP operations any faster than 32-bit.

Suppose, hypothetically, that the 64-bit factorial requires 5 seconds.
Therefore, 32-bit would require 10 seconds. Advantage: 64-bit, by
100%.

Suppose further that the associated stack operations require 100
seconds regardless of platform. Now 64-bit requires 105 seconds and
32-bit requires 110 seconds. Advantage: 64-bit, by 4.8%.

This is what I mean by being swamped. To say that 64-bit is only 5%
faster is not really fair. Neither is it fair to say that it's twice
as fast. The correct answer is, "It depends."

Some of your tests required dealing with much data. One was 700MB -- I
can only assume that this data was being read from disk. So upgrading
to faster hard drive would increase the disparity between 32-bit and
64-bit, perhaps by a lot. Because the less time spent in IO, the more
significant the math operations become in the overall equation.

> 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.

Like I said, I don't think your observations are without merit. They
give some real-world metrics which are well worth noting. I'm only
saying that you shouldn't downplay the external factors.

I could specify a usage scenario that would favor 64-bit quite
heavily. I could also come up with scenarios where there was almost no
advantage at all. My guess is that current typical desktop usage is
much closer to the latter.

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux