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.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
