A Dijous 14 Juny 2007 16:32, Lennart Sorensen va escriure: > On Thu, Jun 14, 2007 at 04:08:54PM +0200, Leopold Palomo-Avellaneda wrote: > > really, reading you makes me doubt about the whole port. How many apps do > > we have in the debian pool that can win some kind of performance? > > If nothing else, running a 64bit kernel with 32bit user space is an > option. That gives you support for more than 4GB ram without the > penalty of PAE, but leaves user space limited to 3GB per process. I run > one system that way and it runs great. Systems with that much ram are > starting to be very common.
the question is how many apps need this quantity of ram? Also, the mobo have to support that. My old mobo I think that it's limited to 4Gb. > And as I said anything using floating point will benefit quite a bit. > gcc will hopefully also get better at optimizing for the amd64 > architecture over time. with this are you saying that all the apps that do some kind of operation with doubles and floats will be better? [....] > I guess the real question then is: Does the benefits for those programs > give enough to warrent a tiny loss on many smaller utilities? Running > mixed 32/64bit on one system is just a pain, so in my book the trade off > is worth it. I don't think I will notice the 1 or 2% potential loss due > to the larger pointers, while I probably will notice the benefits of > faster floating point (perl uses lots of floating point by the way) and > direct access to more ram in larger programs. sure, but I don't think that you have a loss, that I think that it's difficult to me to undertand. > Now I just tried a small stupid test here: > > I have a zip file that is 61592222 bytes. I tried running > 'time tar cvzf test.tgz my.zip' on both 32 and 64 bit on an Athlon 64 3500+ > running a 64bit kernel with 1GB ram. > > According to time, it takes 0m3.776s of user time (so not counting > system calls) on 64bit, and 0m4.556s on 32bit. That indicates tar/gzip > runs 20% faster on 64bit than 32bit at least when the kernel is 64bit > and run on the same machine. I ran them a few times each to make sure > caching and such didn't affect them. Maybe your test method wasn't > correct or the two systems aren't as identical as you think. it doesn't worsewhile but thanks for the example, is very appropriate. Leo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
