Re: i386 vs amd64?
On Thu, 7 Aug 2008 11:34:41 +0200, Milan Obuch [EMAIL PROTECTED] said: Funny observation: r is on LEFT keyboard side, l is on RIGHT keyboard side. I for one have problem at times precisely for this reason, but I know this is an important step and one need to act with great care. I use a different mnemonic: r)eplace and l)eave untouched (I read it in this ML a long time ago). Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University [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: i386 vs amd64?
Eugene Kazarinov wrote: [...] # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 5. `reboot' (in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' [...] Pls tell me what for I need 5 step? You need to reboot between installkernel and installworld because the new world might not run correctly with an old kernel, e.g. it might use new syscalls, or other changes happened in the ABIs between userland and kernel. That's why you have to boot into the new kernel first. Those kinds of changes happen rarely, especially on the -stable branches, but they _do_ happen. Single-user mode is required because old binaries might not run correctly with the new kernel. One example of such a change happened on 2007-08-06 in RELENG_6 (see UPDATING): An ioctl structure was changed for if_bridge, causing an incompatibility in the ifconfig(8) utility. This would break multi-user boot with the old ifconfig binary under the new kernel if you use any bridge interfaces. Of course, omitting the single-user reboot will work most of the time, because such ABI problems happen rarely. But when the rare case happens, you'll run into trouble. Therefore it is recommend to always reboot to single-user mode, even if you believe that it won't be necessary. Apart from that, it is usually good to have a quiescent system while installing the new world. Some programs might not like it when files are replaced unexpectedly beneath their butts. #mergemaster -p make -j8 buildworld make -j8 buildkernel KERNCONF=KMD make installkernel KERNCONF=KMD make installworld mergemaster -iU You can do make kernel KERNCONF= There's no reason to do buildkernel and installkernel separately. You can also put KERNCONF=... in /etc/make.conf so you don't have to type it each time on the commandline. All of this I do remotely. Is this way very wrong? I understand that it's not a canonical way but how I can do it right and remotely? Get remote access to the console, either using a serial console connection (physical or emulated), or remote KVM access. Or arrange to have somebody else perform the action (i.e. remote hands). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 vs amd64?
Ask Bjørn Hansen [EMAIL PROTECTED] wrote: We got 4 new SuperMicro boxes[1] with Xeon 3320 processors. They'll be used as firewalls / very basic routers (our network on one side, the world via a /29 on the other side). We currently use Soekris and PC Engine boxes for this (with custom NanoBSD images), so this will be a bit of an upgrade. :-) I was planning to install pfSense on them, but I'm losing faith in that a bit after figuring out that the pfSense project doesn't seem all that open[2]; so I'm considering just installing plain FreeBSD 7 instead. So the question: Would I be happier with 64 or 32bit FreeBSD? Our Linux application and database servers are all 64 bit, but they also have 32GB RAM each. The firewall boxes are probably vastly overdone with memory at 4GB each. :-) There are other reasons to prefer amd64 over i386, beside the amount of RAM and address space considerations. For example, in amd64 mode there are twice as many CPU registers available, enabling better optimizations for the C compiler. Furthermore those registers are twice as long, which means that 64bit quantities can be handled with single processor instructions. That doesn't necessarily mean that code will always run faster in amd64 mode. There have been reports of certain edge cases. But in general, amd64 code is faster. Also note that the networkign and packetfilter code uses quite a few 64bit variables (e.g. packet and byte counters). That's probably not significant for a small router, though. Bottom line: Install FreeBSD/amd64, unless you have _specific_ reasons to stay with i386. A secondary question: Is the preferred way to upgrade a FreeBSD box still cd /usr/src; make update make buildworld ... ? Yes, basically. Please see the section titled To rebuild everything in /usr/src/UPDATING, it lists all the steps required for an update. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure. -- Eric Allman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 vs amd64?
On 2008-Aug-08 14:36:42 +0200, Oliver Fromme [EMAIL PROTECTED] wrote: For example, in amd64 mode there are twice as many CPU registers available, enabling better optimizations for the C compiler. Furthermore those registers are twice as long, which means that 64bit quantities can be handled with single processor instructions. OTOH, this means roughly 4 times as much processor state to save and restore on a context switch. It also means that longs and pointers are 64-bits instead of 32-bits, which makes executables larger (if you compare executables and libraries on disk between FreeBSD/i386 and FreeBSD/amd64, the latter are 10-15% larger). The VSZ of amd64 executables _appears_ significantly larger due to a bug in binutils and our rtld but this space is never referenced. That doesn't necessarily mean that code will always run faster in amd64 mode. There have been reports of certain edge cases. But in general, amd64 code is faster. As always, the best benchmark is your own application mix. Bottom line: Install FreeBSD/amd64, unless you have _specific_ reasons to stay with i386. Keep in mind that, for most things, FreeBSD/amd64 can happily run 32-bit Linux and FreeBSD/i386 executables (though there's no easy way to build FreeBSD/i386 executables on FreeBSD/amd64). This does not extend to KLDs so 3rd-party 32-bit KLDs (eg the nVIDIA graphics driver). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpCU0aTvVdWo.pgp Description: PGP signature
Re: i386 vs amd64?
On Thu, Aug 07, 2008 at 12:58:06AM -0700, Ask Bjørn Hansen wrote: We got 4 new SuperMicro boxes[1] with Xeon 3320 processors. They'll be used as firewalls / very basic routers (our network on one side, the world via a /29 on the other side). We currently use Soekris and PC Engine boxes for this (with custom NanoBSD images), so this will be a bit of an upgrade. :-) What motherboard model is used on those boxes? The website doesn't say. The reason I'm asking is that I'm working on a H/W monitoring project which currently is focusing on Supermicro boards, and need more testers for boards I don't already have data for. :-) I was planning to install pfSense on them, but I'm losing faith in that a bit after figuring out that the pfSense project doesn't seem all that open[2]; so I'm considering just installing plain FreeBSD 7 instead. So the question: Would I be happier with 64 or 32bit FreeBSD? Our Linux application and database servers are all 64 bit, but they also have 32GB RAM each. The firewall boxes are probably vastly overdone with memory at 4GB each. :-) We have numerous Supermicro machines in our co-lo, all of which run i386 except for one. The reason was that I hadn't spent the time to really get a feel for amd64 (all the machines run RELENG_6 except for the amd64 box, which runs RELENG_7). I run amd64 at home, and it's fine. I'm looking forward to being able to upgrade our SQL server in the co-lo to either 4GB or 8GB of RAM without having to bother with PAE (ugh!). But be aware that there still are some applications (ports) which don't behave correctly on amd64. So my recommendation is to build a test box that mimics your production environment, and make sure all of your stuff works on it. You might also be asking is there some form of compatibility where amd64 can continue to run i386 binaries? Yes, it's called lib32. I choose not to install it (during a FreeBSD install), and I disable it from buildworld by using WITHOUT_LIB32=true in /etc/src.conf (that file is new compared to older FreeBSD, so be aware). My attitude is this is a 64-bit box, and you will recompile your programs to work on a 64-bit arch. Avoiding it also greatly decreases buildworld time. A secondary question: Is the preferred way to upgrade a FreeBSD box still cd /usr/src; make update make buildworld ... ? (I mostly use FreeBSD for building my NanoBSD-flavor images these days, so I'm a bit out of touch). First and foremost: to update the sources, you should use csup and not cvsup. csup comes in the base system, is written in C, and supports most all of the flags that cvsup does. The upgrade procedure is described in detail in /usr/src/Makefile. Here's what I'm referring to: # For individuals wanting to upgrade their sources (even if only a # delta of a few days): # # 1. `cd /usr/src' (or to the directory containing your source tree). # 2. `make buildworld' # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 5. `reboot'(in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `make delete-old' # 9. `mergemaster' # 10. `reboot' # 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) Some footnotes: 1) You can put KERNCONF=WHATEVER in /etc/make.conf, thus avoiding the need to specify it during steps 3 and 4. 2) On amd64, your kernel config will go in /sys/amd64/conf, not /sys/i386/conf. (This may be obvious to most, but not so much to newer folks). 3) After step #5, and you're in single-user, you'll probably have to type mount -a -t ufs to get all of your filesystems mounted. 4) Don't skip the single-user step or try to do it from multi-user; I've seen numerous cases where /libexec/ld-elf.so.1 doesn't get updated as a result of people trying to avoid single-user. If you admin these boxes remotely, you're going to need serial console for the above. 5) Get familiar with mergemaster, specifically the side-by-side interactive diff feature. It looks scary the first time around, but once you learn that r applies the stuff you see on the right, and l applies the stuff you see on the left, you should be fine. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 vs amd64?
On Thursday 07 August 2008, Jeremy Chadwick wrote: On Thu, Aug 07, 2008 at 12:58:06AM -0700, Ask Bjørn Hansen wrote: [ snip ] But be aware that there still are some applications (ports) which don't behave correctly on amd64. So my recommendation is to build a test box that mimics your production environment, and make sure all of your stuff works on it. This means you should do some work before actually deciding the way to go... but it's the best way. Test and then use in production. Your own experience is worth an added bit of work. [ snip ] 5) Get familiar with mergemaster, specifically the side-by-side interactive diff feature. It looks scary the first time around, but once you learn that r applies the stuff you see on the right, and l applies the stuff you see on the left, you should be fine. Funny observation: r is on LEFT keyboard side, l is on RIGHT keyboard side. I for one have problem at times precisely for this reason, but I know this is an important step and one need to act with great care. Regards, Milan -- This address is used only for mailing list response. Do not send any personal messages to it, use milan in address instead. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 vs amd64?
Hello everybody. (sorry for my english) # For individuals wanting to upgrade their sources (even if only a # delta of a few days): # # 1. `cd /usr/src' (or to the directory containing your source tree). # 2. `make buildworld' # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 5. `reboot'(in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `make delete-old' # 9. `mergemaster' # 10. `reboot' # 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) Pls tell me what for I need 5 step? I have about 15 remote servers (10 on 6.X-stable and others on 7.0-stable). These servers are far far away from me and I really cant connect serial or keyboard to it. So I upgrade remotely without # 5 reboot very long time, starting from at least 5.4 (maybe 4.x I dont remember), 5.4-stable - 6.0-stable, 6.0-stable - 6.2-stable, 6.0/6.2-stable - 6.3-stable and of couse 6.2/6.3-stable - 7.0-stable. Only once I got a problem with /libexec/ld-elf.so.X then I try upgrade from 6.2-RELEASE-pX to 7.0-stable. Of couse I got phisical access to this server to repair it. I got this file from another server and then succesfully rebuild all the world with my reception. This was really hard situation. (I use /rescue and have shamanian danced with tambourine around this server ;) lol ;) ) I dont remember why I had on that server this strange (for me) version (6.2-RELEASE). So have I a chance to upgrade remote servers without single mode? Now my practice is (a few last years): #cd /usr/src #mergemaster -p make -j8 buildworld make -j8 buildkernel KERNCONF=KMD make installkernel KERNCONF=KMD make installworld mergemaster -iU reboot *) -j8 on 2x- or 4x-kernels cpu and -j4 on 1x-kernel cpu *) some time I did make -j4 installkernel KERNCONF=KMD and make -j4 installworld but it's worked not stable. Sometimes it returns an error. Maybe hdd was not speedy - dont know why it was so and dont know how to say it all in english. :\ *) on Phenom 9750 with 2GB DDR2 800MHz memory -j8 buildworld makes in about 16 minutes and -j8 buildkernel KERN... in about 5 minutes. As a result all upgrade takes about 30 minutes or less. On x2 CPUs I put this long command in ssh-term and go away. When I come back mergemaster -iU is waiting me. And if I make major update (6.x to 7.x) I'll portupgrade all ports as in manual portupgrade -faP and then reboot after that make delete-old and make delete-old-libs and reboot All of this I do remotely. Is this way very wrong? I understand that it's not a canonical way but how I can do it right and remotely? Thanks in advance. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 vs amd64?
On Aug 7, 2008, at 2:34 AM, Milan Obuch wrote: 5) Get familiar with mergemaster, specifically the side-by-side interactive diff feature. It looks scary the first time around, but once you learn that r applies the stuff you see on the right, and l applies the stuff you see on the left, you should be fine. Funny observation: r is on LEFT keyboard side, l is on RIGHT keyboard side. I for one have problem at times precisely for this reason, but I know this is an important step and one need to act with great care. Fortunately, the diffutils maintainer has accepted a patch to allow 1 and 2 (similar to http://www.pkix.net/~chuck/sdiff2.diff); hopefully your system is recent enough to include that change: Regards, -- -Chuck Begin forwarded message: From: Chuck Swiger [EMAIL PROTECTED] Date: June 13, 2007 11:57:34 AM PDT To: LI Xin [EMAIL PROTECTED] Cc: FreeBSD Current [EMAIL PROTECTED] Subject: Re: RFC: diff(1) update On Jun 13, 2007, at 2:10 AM, LI Xin wrote: I have done a first cut of bringing latest GNU diffutils (2.8.1) to the FreeBSD base system. This consists two parts of changes: [ ... ] Some notes: - I have tried to keep as most our local features (DIFF_OPTIONS, etc), but we still need to have some test cases to figure out whether there is regression. - Local changes are now maintained as patchsets. - Still need to find a better way to handle local manpage changes... Comments? Thanks for looking into updating diffutils, Xin. Paul Eggert, the diffutils maintainer, has recently adopted a patch for sdiff which allows using 1 and 2 in addition to l and r, which is exceptionally useful when people are running mergemaster. Also, v2.8.6 also includes a fix for invoking an editor in sdiff mode: Paul Eggert [EMAIL PROTECTED] wrote: Chuck Swiger [EMAIL PROTECTED] writes: At least with diff-2.7 or thereabouts, invoking the external editor via e l or e r would always fail and return the warning from this line of diff code: fatal (Subsidiary editor failed); You can double-check, but I think that bug was fixed here: 2004-04-12 Paul Eggert [EMAIL PROTECTED] * NEWS, configure.ac (AC_INIT): Version 2.8.6. ... * src/sdiff.c (check_child_status): Renamed from ck_editor_status, and accept a new arg MAX_OK_STATUS. All callers changed. Handle status 126/127 as per POSIX. -- Good point, thanks. I installed this: 2007-06-06 Paul Eggert [EMAIL PROTECTED] * NEWS: Mention new sdiff aliases 1 and 2 for l and r. * doc/diff.texi (Merge Commands): Likewise. * src/sdiff.c (give_help): Give help for them. (edit): Support them. Index: NEWS === RCS file: /cvsroot/diffutils/diffutils/NEWS,v retrieving revision 1.25 diff -u -p -r1.25 NEWS --- NEWS5 Sep 2006 23:02:32 - 1.25 +++ NEWS6 Jun 2007 23:40:12 - @@ -14,6 +14,8 @@ User-visible changes since 2.8.7 (in ve Utility Syntax Guidelines in the Minutes of the January 2005 Meeting http://www.opengroup.org/austin/docs/austin_239.html. +* sdiff now understands '1' and '2' as synonyms for 'l' and 'r'. + Version 2.8.7 contains no user-visible changes. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 vs amd64 - benchmark results
On Wed, Jul 27, 2005 at 11:52:30AM -0400 I heard the voice of Vivek Khera, and lo! it spake thus: The amd64 memory architecture is NUMA -- that is, depending on how your RAM is layed out, some of it is faster to access for each processor. Accessing RAM local to the other processor(s) is slower. On the other hand, I've heard from various sources (this is all pure hearsay, so trust it as much as it deserves) that in practice NUMAization in this case isn't really a gain. It's non-uniform, but it's not nearly as non-uniform as a lot of applications of the term, and the performance penalty is so small in absolute terms that the added complexity that comes with NUMA awareness can actually be enough to make it a net loss. But then, I usually don't know what I'm talking about8-} -- 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: i386 vs amd64 - benchmark results
Björn König wrote: You might want to have a look at my private benchmarks too: http://www.alpha-tierchen.de/dateien/etc/benchmark.html Hmmm... your benchmarks show the same effect as I have on 5.4. But I'm impressed by the RELENG_6 results. I think I'm going to upgrade my system instantly. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 vs amd64 - benchmark results
On Tue, Jul 26, 2005 at 07:57:06PM +0200, Martin wrote: Hi, I've tried two benchmarks to check the speed of my system on two FreeBSD architectures i386 and amd64. My results for amd64 (haven't tried i386): Hardware: Athlon64 3400+ (2.4 GHz, 400 MHz FSB) MSI Neo FSR (MSI-6702) 2x512 MB PC3200U-2533 RAM TEST: Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* :--:-: NUMERIC SORT: 1684.8 : 43.21 : 14.19 STRING SORT : 186.1 : 83.15 : 12.87 BITFIELD: 3.9649e+08 : 68.01 : 14.21 FP EMULATION: 134.38 : 64.48 : 14.88 FOURIER : 17671 : 20.10 : 11.29 ASSIGNMENT : 22.259 : 84.70 : 21.97 IDEA: 3618.9 : 55.35 : 16.43 HUFFMAN : 1626.1 : 45.09 : 14.40 NEURAL NET : 25.743 : 41.35 : 17.39 LU DECOMPOSITION: 1156.3 : 59.90 : 43.26 ==ORIGINAL BYTEMARK RESULTS== INTEGER INDEX : 61.508 FLOATING-POINT INDEX: 36.786 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==LINUX DATA BELOW=== CPU : L2 Cache: OS : FreeBSD 5.4-STABLE C compiler : cc libc: /lib/libc.so.5 MEMORY INDEX: 15.896 INTEGER INDEX : 14.951 FLOATING-POINT INDEX: 20.403 Baseline (LINUX): AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 Roland -- R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text. public key: http://www.xs4all.nl/~rsmith/pubkey.txt pgpw2Yzu0Woe3.pgp Description: PGP signature
Re: i386 vs amd64 - benchmark results
Martin wrote: But I'm impressed by the RELENG_6 results. I think I'm going to upgrade my system instantly. Yes, the results are slightly better, even the support of amd64 appears to be much better, but I would be careful; it's easy to overrate benchmark results. There is a lot that you can do wrong if you create benchmarks and I would not guarantee for the correctness of my own results. Nevertheless I think 6.0 will be a great release with increased performance. Björn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 vs amd64 - benchmark results
On Jul 26, 2005, at 1:57 PM, Martin wrote: Please notice the memory speed penalties while the system is running on amd64 kernel. I would like to know what causes this kind of low performance when memory is being accessed. The amd64 memory architecture is NUMA -- that is, depending on how your RAM is layed out, some of it is faster to access for each processor. Accessing RAM local to the other processor(s) is slower. There are many subtle issues relating to non-uniform memory access and how to code programs to take advantage of it (or try to avoid being bit by it). It is a very hard problem, and the three letters following my name came to be from researching this issue 11 years ago :-) The FreeBSD scheduler and memory allocators are definitely not NUMA aware. Vivek Khera, Ph.D. +1-301-869-4449 x806
Re: i386 vs amd64 - benchmark results
On Jul 27, 2005, at 11:52 AM, Vivek Khera wrote: The amd64 memory architecture is NUMA -- that is, depending on how your RAM is layed out, some of it is faster to access for each processor. Accessing RAM local to the other processor(s) is slower. There are many subtle issues relating to non-uniform memory access and how to code programs to take advantage of it (or try to avoid being bit by it). It is a very hard problem, and the three letters following my name came to be from researching this issue 11 years ago :-) The FreeBSD scheduler and memory allocators are definitely not NUMA aware. No, although there appears to be some integration of concepts like virtual memory objects and binary format branding into FreeBSD from Mach, which did make efforts to support assymmetric multiprocessing, heterogenous processor types in one box, and NUMA memory architecture. It is a really hard problem to deal with :-), and you tend to end up with processors that could do specific things very quickly, if only the communications bandwidth between them and other CPUs was fast enough that the cost of distributing work around exceeds the benefits of allocating the right processor for a specific job. I suspect that FreeBSD is going to deal more with this in the context of x86 or AMD64 hardware which has a fancy GPU, maybe a smart RAID controller, and the specialized NIC hardware which can handle more of the TCP/IP stack (not just computing checksums, but handling IPsec, VLAN or other encapsulation of frames, doing IP fragment reassembly, or even higher layer stuff), then with a couple of 68040's glued to a 56001 DSP, with i960's running on the Dimension boards... -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 vs amd64 - benchmark results
On Tue, Jul 26, 2005 at 07:57:06PM +0200, Martin wrote: Hi, I've tried two benchmarks to check the speed of my system on two FreeBSD architectures i386 and amd64. I've never seen anyone posting this kind of benchmark, so here is what I found out: here the results of nbench: http://phpfi.com/71540 here is what openssl speed gives me: http://phpfi.com/71545 Sorry for posting it there, but I don't want to send attachments to this list. Please notice the memory speed penalties while the system is running on amd64 kernel. I would like to know what causes this kind of low performance when memory is being accessed. Is this a hardware problem or a problem with FreeBSD? Generally, FreeBSD-amd64 performs slightly better than FreeBSD-i386 and it's stable as expected, but I cannot find any solution to the memory problems that affect memory intensive applications as you can see. Martin As another data point, below is the nbench output from one of my systems. It's an Athlon 64 3800+ w/ venice core running FreeBSD 6.0-BETA1. Motherboard is an ASUS A8V Deluxe (socket 939) with 1GB of DDR400 RAM (2 512MB sticks). BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST: Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* :--:-: NUMERIC SORT:2326 : 59.65 : 19.59 STRING SORT : 202.35 : 90.41 : 13.99 BITFIELD: 5.2938e+08 : 90.81 : 18.97 FP EMULATION: 153.36 : 73.59 : 16.98 FOURIER : 18608 : 21.16 : 11.89 ASSIGNMENT : 27.817 : 105.85 : 27.46 IDEA:3400 : 52.00 : 15.44 HUFFMAN : 1869.4 : 51.84 : 16.55 NEURAL NET : 24.696 : 39.67 : 16.69 LU DECOMPOSITION: 1237.9 : 64.13 : 46.31 ==ORIGINAL BYTEMARK RESULTS== INTEGER INDEX : 72.257 FLOATING-POINT INDEX: 37.759 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==LINUX DATA BELOW=== CPU : L2 Cache: OS : FreeBSD 6.0-BETA1 C compiler : cc libc: /lib/libc.so.6 MEMORY INDEX: 19.388 INTEGER INDEX : 17.076 FLOATING-POINT INDEX: 20.942 Baseline (LINUX): AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder. -- Bob WillcoxReality is nothing but a collective hunch. [EMAIL PROTECTED] -- Lily Tomlin Austin, TX ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
i386 vs amd64 - benchmark results
Hi, I've tried two benchmarks to check the speed of my system on two FreeBSD architectures i386 and amd64. I've never seen anyone posting this kind of benchmark, so here is what I found out: here the results of nbench: http://phpfi.com/71540 here is what openssl speed gives me: http://phpfi.com/71545 Sorry for posting it there, but I don't want to send attachments to this list. Please notice the memory speed penalties while the system is running on amd64 kernel. I would like to know what causes this kind of low performance when memory is being accessed. Is this a hardware problem or a problem with FreeBSD? Generally, FreeBSD-amd64 performs slightly better than FreeBSD-i386 and it's stable as expected, but I cannot find any solution to the memory problems that affect memory intensive applications as you can see. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 vs amd64 - benchmark results
You might want to have a look at my private benchmarks too: http://www.alpha-tierchen.de/dateien/etc/benchmark.html Björn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
