Re: Pros and Cons of amd64 (versus i386).
Chris H. wrote: Interesting to note (to me anyway) is my SCSI reports fastest on the outside whereas my (earlier reported) ATA reports faster in the center (middle). You get better seek times on average in the center. Maybe that affected your results? -- Tuomo ... Nitpicking - not just a hobby, it's a way of life! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
Note that using different slices may change your results. All modern disks are faster near the outside (start of the disk) then the inside (I get more than 50% increase from inside to outside on one system). I am thinking this will not be an issue, given that it is the performance of the network interface which I am interested in :-) -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
On Sun, 2006-04-09 at 13:22 -0500, Matthew D. Fuller wrote: On Sat, Apr 08, 2006 at 06:00:56PM -0600 I heard the voice of Scott Long, and lo! it spake thus: Modern disks (I don't know how to define a cutoff to this term, unfortunately) definitely put more bits onto the outer rim of the platter than the inner rim. Pretty much any disk you'd currently find, I'd say. diskinfo -t won't run through on my 4 or 2 gigs (disk too small for test :), but on my 9 gigger: Transfer rates: outside: 102400 kbytes in 5.215159 sec =19635 kbytes/sec middle:102400 kbytes in 6.268067 sec =16337 kbytes/sec inside:102400 kbytes in 8.237962 sec =12430 kbytes/sec da4 at ahc2 bus 0 target 5 lun 0 da4: IBM DNES-309170W SAH0 Fixed Direct Access SCSI-3 device da4: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da4: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Just for comparison: [EMAIL PROTECTED] diskinfo -t ad1 ad1 512 # sectorsize 61492838400 # mediasize in bytes (57G) 120103200 # mediasize in sectors 119150 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: 250 iter in 5.650173 sec = 22.601 msec Half stroke: 250 iter in 4.581880 sec = 18.328 msec Quarter stroke: 500 iter in 7.510191 sec = 15.020 msec Short forward:400 iter in 3.556557 sec =8.891 msec Short backward: 400 iter in 3.294277 sec =8.236 msec Seq outer: 2048 iter in 0.285684 sec =0.139 msec Seq inner: 2048 iter in 0.288960 sec =0.141 msec Transfer rates: outside: 102400 kbytes in 1.896157 sec =54004 kbytes/sec middle:102400 kbytes in 2.297042 sec =44579 kbytes/sec inside:102400 kbytes in 3.853005 sec =26577 kbytes/sec ad1: 58644MB IC35L060AVV207 0 V22OA63A at ata0-slave UDMA100 As you can see, the outside is more than twice as fast in this case. Just a guess, since both are IBM disks: You're using a Workstation/Server disk, which probably performs in a more balanced way across the platter, while this (consumer disk) is not performance-oriented. Maybe SCSI and IDE devices are not as similar as we all thought? -- Christian Lopez de Castilla Wagner [EMAIL PROTECTED] [EMAIL PROTECTED] (+591-705)98290 http://lopisaur.googlepages.com http://lopisaur.blogspot.com signature.asc Description: This is a digitally signed message part
Re: Pros and Cons of amd64 (versus i386).
On Mon, Apr 10, 2006 at 10:02:34AM -0400 I heard the voice of Christian Lopez de Castilla Wagner, and lo! it spake thus: As you can see, the outside is more than twice as fast in this case. Just a guess, since both are IBM disks: You're using a Workstation/Server disk, which probably performs in a more balanced way across the platter, while this (consumer disk) is not performance-oriented. Maybe SCSI and IDE devices are not as similar as we all thought? I would think it's more a matter that it's just a much older and much lower-density disk, so the difference isn't as pronounced. The seeks show where the SCSI pulls ahead of the IDE. For instance: Full stroke: 250 iter in 5.650173 sec = 22.601 msec Full stroke: 250 iter in 3.986904 sec = 15.948 msec Half stroke: 250 iter in 4.581880 sec = 18.328 msec Half stroke: 250 iter in 3.314294 sec = 13.257 msec Quarter stroke: 500 iter in 7.510191 sec = 15.020 msec Quarter stroke: 500 iter in 5.683162 sec = 11.366 msec Now, compare a modern SCSI drive: Seek times: Full stroke: 250 iter in 2.144289 sec =8.577 msec Half stroke: 250 iter in 1.649111 sec =6.596 msec Quarter stroke: 500 iter in 2.707602 sec =5.415 msec Short forward:400 iter in 1.726583 sec =4.316 msec Short backward: 400 iter in 1.076023 sec =2.690 msec Seq outer: 2048 iter in 0.198563 sec =0.097 msec Seq inner: 2048 iter in 0.194318 sec =0.095 msec Transfer rates: outside: 102400 kbytes in 1.406852 sec =72787 kbytes/sec middle:102400 kbytes in 1.557666 sec =65739 kbytes/sec inside:102400 kbytes in 2.112654 sec =48470 kbytes/sec da0: SEAGATE ST373453LC 0006 Fixed Direct Access SCSI-3 device da0: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) The difference in transfer rates is less than half there, too. But, this is a 15k RPM drive, which means that the platters are much smaller, so there's much less difference in the linear speed between the rim and the spindle side. It's not because of any attempted compensation toward an average performance, it's just a side effect of trying to not require a nuclear reactor to power it8-} -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
On Sat, 2006-Apr-08 18:00:56 -0600, Scott Long wrote: Modern disks (I don't know how to define a cutoff to this term, unfortunately) I got my first ZBR (zone-block recording) Seagate SCSI disk at work about 20 years ago. I'm not sure when it became common. other day. I'm still not clear on whether the drive starts recording at the outer rim or the inner rim of the disk, and that could very well different between manufacturers. Traditionaly hard disks have cylnder 0 at the outside. It's possible that some manufacturers may have swapped this. Note that CDs and DVD have block 0 at the inside and so the best I/O performance is usually at the end of the disk. The only way to get a 'fair' comparison is to use separate identical disks with identical partition layouts for each of your OS installs. If disk I/O is an issue, maybe even newfs the partitions for each test. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
On Sat, Apr 08, 2006 at 06:00:56PM -0600 I heard the voice of Scott Long, and lo! it spake thus: Modern disks (I don't know how to define a cutoff to this term, unfortunately) definitely put more bits onto the outer rim of the platter than the inner rim. Pretty much any disk you'd currently find, I'd say. diskinfo -t won't run through on my 4 or 2 gigs (disk too small for test :), but on my 9 gigger: Transfer rates: outside: 102400 kbytes in 5.215159 sec =19635 kbytes/sec middle:102400 kbytes in 6.268067 sec =16337 kbytes/sec inside:102400 kbytes in 8.237962 sec =12430 kbytes/sec da4 at ahc2 bus 0 target 5 lun 0 da4: IBM DNES-309170W SAH0 Fixed Direct Access SCSI-3 device da4: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da4: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
Quoting Matthew D. Fuller [EMAIL PROTECTED]: On Sat, Apr 08, 2006 at 06:00:56PM -0600 I heard the voice of Scott Long, and lo! it spake thus: Modern disks (I don't know how to define a cutoff to this term, unfortunately) definitely put more bits onto the outer rim of the platter than the inner rim. Pretty much any disk you'd currently find, I'd say. diskinfo -t won't run through on my 4 or 2 gigs (disk too small for test :), but on my 9 gigger: Transfer rates: outside: 102400 kbytes in 5.215159 sec =19635 kbytes/sec middle:102400 kbytes in 6.268067 sec =16337 kbytes/sec inside:102400 kbytes in 8.237962 sec =12430 kbytes/sec da4 at ahc2 bus 0 target 5 lun 0 da4: IBM DNES-309170W SAH0 Fixed Direct Access SCSI-3 device da4: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da4: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) Well, as long as we're at it: 512 # sectorsize 1572864 # mediasize in bytes (15G) 3072# mediasize in sectors 1912# Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: 250 iter in 4.058565 sec = 16.234 msec Half stroke: 250 iter in 3.249077 sec = 12.996 msec Quarter stroke: 500 iter in 5.544275 sec = 11.089 msec Short forward:400 iter in 2.595878 sec =6.490 msec Short backward: 400 iter in 2.547004 sec =6.368 msec Seq outer: 2048 iter in 0.486885 sec =0.238 msec Seq inner: 2048 iter in 0.500109 sec =0.244 msec Transfer rates: outside: 102400 kbytes in 5.517532 sec =18559 kbytes/sec middle:102400 kbytes in 6.233613 sec =16427 kbytes/sec inside:102400 kbytes in 8.044342 sec =12729 kbytes/sec at ahc0 bus 0 target 1 lun 0 WDIGTL WDE18300 ULTRA2 1.30 Fixed Direct Access SCSI-2 device Serial Number WS7060096840 40.000MB/s transfers (20.000MHz, offset 31, 16bit) Interesting to note (to me anyway) is my SCSI reports fastest on the outside whereas my (earlier reported) ATA reports faster in the center (middle). --Chris H. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Linux: As OS for users who think their using UNIX. - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
On Fri, 7 Apr 2006, Peter Jeremy wrote: PJ I know that what I should do is install i386 on the client and test again, but PJ doing that will lose my only 64 bit environment so I am loathe to do so. Any PJ comments ? PJ PJ Backup your amd64 environment and install i386. You can re-install PJ the amd64 once the testing is finished. The best benchmark is always PJ your own application. Or, even better, use spare disk or at least spare slice. Having fresh good backup never hurts though ;-) For local tinderbox I have the following partitioning scheme: partsizepurpose ad0s1a 2G RELENG_6/amd64 ad0s1b 2G swap/dumps ad0s1d 2G RELENG_5/amd64 ad0s1e 2G RELENG_6/i386 ad0s1f 2G RELENG_5/i386 ad0s1g 2G HEAD/amd64 ad0s1h 2G HEAD/i386 ad0s2 restall version-independent data, such as sources, ports, /usr/obj and homedirs This seems to be useful, if you do not use/check huge packages such as OopenOffice.org; in the latter case, you can increase partitions size accordingly. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
On Sat, 2006-Apr-08 20:41:36 +0400, Dmitry Morozovsky wrote: On Fri, 7 Apr 2006, Peter Jeremy wrote: PJ Backup your amd64 environment and install i386. You can re-install PJ the amd64 once the testing is finished. The best benchmark is always PJ your own application. Or, even better, use spare disk or at least spare slice. Having fresh good backup never hurts though ;-) Note that using different slices may change your results. All modern disks are faster near the outside (start of the disk) then the inside (I get more than 50% increase from inside to outside on one system). A second disk is OK as long as it's the same type of disk running at the same transfer rate. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
Quoting Peter Jeremy [EMAIL PROTECTED]: On Sat, 2006-Apr-08 20:41:36 +0400, Dmitry Morozovsky wrote: On Fri, 7 Apr 2006, Peter Jeremy wrote: PJ Backup your amd64 environment and install i386. You can re-install PJ the amd64 once the testing is finished. The best benchmark is always PJ your own application. Or, even better, use spare disk or at least spare slice. Having fresh good backup never hurts though ;-) Note that using different slices may change your results. All modern disks are faster near the outside (start of the disk) then the inside (I get more than 50% increase from inside to outside on one system). My experience(s) seem to indicate the center of the platter results in a quicker hit rate. But none the less; this still only further confirms your point about the different areas of the platter(s) returning different results. It might also be worth noting that the large onboard disk caches that come on most modern hard drives will *also* likely help skew the results. --Chris H. A second disk is OK as long as it's the same type of disk running at the same transfer rate. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Linux is not, nor never will be, UNIX. - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
Chris H. wrote: Quoting Peter Jeremy [EMAIL PROTECTED]: On Sat, 2006-Apr-08 20:41:36 +0400, Dmitry Morozovsky wrote: On Fri, 7 Apr 2006, Peter Jeremy wrote: PJ Backup your amd64 environment and install i386. You can re-install PJ the amd64 once the testing is finished. The best benchmark is always PJ your own application. Or, even better, use spare disk or at least spare slice. Having fresh good backup never hurts though ;-) Note that using different slices may change your results. All modern disks are faster near the outside (start of the disk) then the inside (I get more than 50% increase from inside to outside on one system). My experience(s) seem to indicate the center of the platter results in a quicker hit rate. But none the less; this still only further confirms your point about the different areas of the platter(s) returning different results. It might also be worth noting that the large onboard disk caches that come on most modern hard drives will *also* likely help skew the results. --Chris H. Modern disks (I don't know how to define a cutoff to this term, unfortunately) definitely put more bits onto the outer rim of the platter than the inner rim. The days of disks having a fixed number of sectors per track across the entire platter are long gone. I was actually just talking about this with a Maxtor servo engineer the other day. I'm still not clear on whether the drive starts recording at the outer rim or the inner rim of the disk, and that could very well different between manufacturers. But, different parts of the disks do indeed perform differently, both for seek time and for sequential data thoroughput. The only way to get a 'fair' comparison is to use separate identical disks with identical partition layouts for each of your OS installs. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
Skipping all of your technical questions I'll tell you my experience. The only regret i have is one that makes me sometimes wish I'd not upgraded my desktop 64 bit... the dri drivers for xorg lock up my box (ATI card). This has been a thorn in my side for over 6 months now, but I just haven't had the time to try to debug and deal with it... Other than that, things have worked out quite nice. The way I get around the occasional software compatibility problems is that I run 32 bit linux emulation for a couple of things... amazingly enough this works (though i seem to recall I had to hack a Make file somewhere in ports to make it ignore DRI or something... sorry, hazy memory). I don't use it very often, so I don't mind. Until there are 64 bit versions for FreeBsd I have OpenOffice 2, and Skype, and a couple of other things running as 32bit linux apps. I'm actually just running generic kernel these days... i just can't be bothered compiling even a kernel for my desktop system... that's how lazy (or busy) I am. Works fine. -- Tim Middleton | Vex.Net| One afternoon, disgusted, bravo, you fall [EMAIL PROTECTED] | VexTech.ca | asleep. --T.Lilburn (MS) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
Sex, 2006-04-07 às 00:18 -0400, Tim Middleton escreveu: Skipping all of your technical questions I'll tell you my experience. The only regret i have is one that makes me sometimes wish I'd not upgraded my desktop 64 bit... the dri drivers for xorg lock up my box (ATI card). This has been a thorn in my side for over 6 months now, but I just haven't had the time to try to debug and deal with it... My amd64 desktop works fine, also with ATI card. There are always problems. I have them with ehci, but the same problem with amd64 and i386. I suppose every hardware/os change must imply some compatibility testing. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
On Apr 6, 2006, at 1:30 AM, Nikolas Britton wrote: $200 bucks got me a Athlon 64 3000+ Venice and a ASUS A8V Motherboard. I'll be converting my Pentium 4 2.26GHz desktop system that has FreeBSD 6.1-PRERELEASE i386 on it, gcc is currently set to build with -march=pentium2 and -mtune=pentium4 via make.conf If your running a desktop, I'd recommend sticking with 32-bit. For a server doing a lot of I/O, go with 64-bit. The Athlon will run very fast in both modes, but your software compatibility is better in i386 mode. * How do I buildworld to amd64, and should I? same as always. * What are the best gcc -mtune / -march flags to use? i use none. however, you could set the CPU type to something more specific; see the /etc/defaults/make.conf file for your options. * What do all the other -m flags do? read the man pages. * What -march flags won't run on the AMD platform, will CPUTYPE=p2 work on AMD? maybe. maybe not. probably would, but recovering from a system with broken binaries is very hard. * Can I still build packages for other i386 (non 64-bit) systems? no. * Where can I find more info about FreeBSD on AMD? the freebsd amd64 project page has a little. mostly there is no difference, but some drivers are not stable with large RAM which is the main reason for having 64-bit systems. * What did I forget to add here? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
If your running a desktop, I'd recommend sticking with 32-bit. For a server doing a lot of I/O, go with 64-bit. The Athlon will run very fast in both modes, but your software compatibility is better in i386 mode. Interesting comment - I have a server at home with a pair of Opteron 242s in it that I just built and was wondering about switching to amd64 mode. It's primary purpose is to provide file servring over Samba, mail using imapd (large mbox format files) and also to be a firewall using PF/ALTQ. So it's pretty much entirely doing I/O. I was thinking of moving this to amd64, but was kind of put off by results from a test system I setup using an Athlon 64 3700+ to talk to this machine. The opteron box is currently running 6.1-PRE/i386, and the 3700 is runiing either Windows XP or 61-PRE/amd64. Under Windows I can completely saturate the ether comming in, and get 70% bandwidth going out (it's gig ether). Under amd64 on the client end I can only get about 55% utilisation in both directions. This surprised me a lot as when I was running i386 on that box it was always faster. Of course a number of variables have changed since then (primarily moving from a broadcom gigabit card to using the onboard realtek card), but I was concened that the difference was due to the 64 bit operating system, as opposed to superior windws drivers, which seemed unlikely! I know that what I should do is install i386 on the client and test again, but doing that will lose my only 64 bit environment so I am loathe to do so. Any comments ? -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
On Apr 6, 2006, at 10:38 AM, Pete French wrote: I was thinking of moving this to amd64, but was kind of put off by results from a test system I setup using an Athlon 64 3700+ to talk to this machine. The opteron box is currently running 6.1-PRE/i386, and the 3700 is Let me comment that my 64-bit commentary about I/O is based on experience with Opterons, which have excellent I/O bandwidth. The Intel EM64T boxes do ok, too, but I have no experience with other 64- bit CPUs. The opterons are just a notch above anything else that I've used. That said, I run 64-bit FreeBSD on all servers capable of it, just to have consistent system images (all my new boxes going forward are 64 bit, so I can eventually phase out the 32-bit system images). Management of multiple systems changes the decision making process sometimes... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
Let me comment that my 64-bit commentary about I/O is based on experience with Opterons, which have excellent I/O bandwidth. The Intel EM64T boxes do ok, too, but I have no experience with other 64- bit CPUs. The opterons are just a notch above anything else that I've used. Ah, O.K. - so they dont necessarily have better I/O bandwidth in 64 bit mode than they do in 32 bit mode then ? I am still quite keen to move to a 64 bit architecture though. I am having problems to get the system to boot SMP, and all the people who ahve told me that they can make it run on the same motherboard are using amd64. cheers, -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pros and Cons of amd64 (versus i386).
On Thu, 2006-Apr-06 15:38:20 +0100, Pete French wrote: I was thinking of moving this to amd64, but was kind of put off by results from a test system I setup using an Athlon 64 3700+ to talk to this machine. The opteron box is currently running 6.1-PRE/i386, and the 3700 is runiing either Windows XP or 61-PRE/amd64. Under Windows I can completely saturate the ether comming in, and get 70% bandwidth going out (it's gig ether). Under amd64 on the client end I can only get about 55% utilisation in both directions. This surprised me a lot as when I was running i386 on that box it was always faster. Of course a number of variables have changed since then (primarily moving from a broadcom gigabit card to using the onboard realtek card), but I was concened that the difference was due to the 64 bit operating system, as opposed to superior windws drivers, which seemed unlikely! If you want to do a valid benchmark, you really need to use the same hardware for the testing. amd64 is not necessarily faster than i386 on the same hardware: On the downside: - amd64 has more, larger registers so context switching is slower - 64-bit long/pointer and lower code density means larger working set size and lower cache effectiveness On the upside: - more registers means less register spills (better code) - I think there's more efficient support for PIC code - 64-bit arithmetic means faster multi-precision math (think RSA/DSA/SSL) - access to 2GB virtual address space I know that what I should do is install i386 on the client and test again, but doing that will lose my only 64 bit environment so I am loathe to do so. Any comments ? Backup your amd64 environment and install i386. You can re-install the amd64 once the testing is finished. The best benchmark is always your own application. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
