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
