Date: Wed, 27 May 2009 19:09:47 +0200 (CEST) From: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> To: Kirk Strauser <kirk@strauser.com> Cc: freebsd-questions@freebsd.org Subject: Re: FreeBSD & Software RAID Message-ID: <alpine.BSF.2.00.0905271901431.53380@wojtek.tensor.gdynia.pl> In-Reply-To: <200905271152.34237.kirk@strauser.com> References: <4A1AA3DC.5020300@network-i.net> <200905271048.27837.kirk@strauser.com> <alpine.BSF.2.00.0905271832320.53013@wojtek.tensor.gdynia.pl> <200905271152.34237.kirk@strauser.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> you talk about performance or if it work at all? > > Both, really. If they have to code up macros to support identical operations OK. talking about performance: - 64-bit addition/substraction on 32-bit computer: 2 instructions instead of one (ADD+ADC) - 64-bit NOT, XOR, AND, OR and compare/test etc - 2 instead of one - multiply - depends of machine, something like 7-8 times longer (4 multiples+additions) to do 64bitx64bit multiply. But how often do you multiply 2 longs in C. Actually VERY rarely. the only exception i can think now is RSA/DSA assymetric key generation and processing. - every operation on 32-bit or smaller values - same - every branching - same - external memory access - depends of chipset/CPU not mode - same now do cc -O2 -s <some C program> and look at resulting assembly output to see how much performance could really be gained. about checksumming in ZFS - it could be much faster on 64-bit arch, if only memory speed and latency wouldn't be a limit. and it is, and any performance difference in that case would be rather marginal. > (such as addition) on both platforms, and accidentally forget to use the macro > in some place, then voila: untested code. > >> do you have any other examples of code non-portability between amd64 and >> i386? > > You're also forgetting that this isn't high-level programming where you get to > lean on a cross-platform libc or similar. This is literally interfacing with > the hardware, and there are a whole boatload of subtle incompatibilities when > handling stuff at that level. we talked about C code. if not - please be more clear as i don't understand what you talking about. and no - ZFS is not on interface level, doesn't talk directly to hardware.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0905271901431.53380>