Today there are two kinds of CPU architectrues, big endian and little endian. So data needs to be converted between the two representations. Each CPU architecture, instruction set in particular, is different and each allows for different implementations for changing endianness. Some CPUs contain specific instructions while others do not.
My question is this, with today's architectures is it more efficient to have data BE and convert on LE architectures or other way around, in order to minimize data conversion latency and thus maximize throughput in a BE to LE communication.
Second question, can the cost of conversion quantified, is there any data on the matter?
How costly is this conversion in Java from a byte array? Is there data on specific JVMs on specific architectures? Is it different on Dalvik?
AFAIK the relevant architectures for this would be x64, ARM, MIPS and JVM/Dalvik. Am I missing any?
Storing data is one of the most basic things computers do, why only a few architectures relevant? All architectures must follow a specific endianness (such as x86/x86_64) or bi-endian (ARM, MIPS...) if their word size is bigger than an octet
However even if the architecture is bi-endian, the endian must be set at startup and CPUs only work in that endian mode until the mode is changed and everything is restarted. The CPUs can't deal with data in the reversed endian. Therefore data should always be in the native endian unless you only copy the value and then send it back without any processing, or you do some very simple operations that are endian-agnostic like bitwise operations
Network activities are much slower than CPU, not even comparable to RAM speed. You'll hardly ever see any difference in speed but most likely will be memory bound
Related
Recently 64-bit ARM mobiles started appearing. But is there any practical advantage to building an application 64-bit? Specifically considering application that does not have much use for the increased virtual address space¹, but would waste some space due to increased pointer size.
So does ARM64 have any other advantages than the larger address that would actually warrant building such application 64bit?
Note: I've seen 64-bit Performance Advantages, but it only mentions x86-64 which does have other improvements besides extended virtual address space. I also recall that the situation is indeed specific to x86 and on some other platforms that went 64-bit like Sparc the usual approach was to only compile kernel and the applications that actually did use lot of memory as 64-bit and everything else as 32-bit.
¹The application is multi-platform and it still needs to be built for and run on devices with as little as 48MiB of memory. Does have some large data that it reads from external storage, but it never needs more than some megabytes of it at once.
I am not sure a general response can be given, but I can provide some examples of differences. There are of course additional differences added in version 8 of the ARM architecture, which apply regardless of target instruction set.
Performance-positive additions in AArch64
32 General-purpose registers gives compilers more wiggle room.
I/D cache synchronization mechanisms accessible from user mode (no system call needed).
Load/Store-Pair instructions makes it possible to load 128-bits of data with one instruction, and still remain RISC-like.
The removal of near-universal conditional execution makes more out-of-ordering possible.
The change in layout of NEON registers (D0 is still lower half of Q0, but D1 is now lower half of Q1 rather than upper half of Q0) makes more out-of-ordering possible.
64-bit pointers make pointer tagging possible.
CSEL enables all kind of crazy optimizations.
Performance-negative changes in AArch64
More registers may also mean higher pressure on the stack.
Larger pointers mean larger memory footprint.
Removal of near-universal conditional execution may cause higher pressure on branch predictor.
Removal of load/store-multiple means more instructions needed for function entry/exit.
Performance-relevant changes in ARMv8-A
Load-Aquire/Store-Release semantics remove need for explicit memory barriers for basic synchronization operations.
I probably forgot lots of things, but those are some of the more obvious changes.
While HDDs evolve and offer more and more space on less room, why are we "sticking with" 32-bit or 64-bit?
Why can't there be a e.g.: 128-bit processor?
(This is not my homework; I'm just a student interested beyond the things they teach us in informatics)
Because the difference between 32-bit and 64-bit is astronomical - it's really the difference between 232 (a ten-digit number in the billions) and 264 (a twenty-digit number in the squillions :-).
64 bits will be more than enough for decades to come.
There's very little need for this, when do you deal with numbers that large? The current addressable memory space available to 64-bit is well beyond what any machine can handle for at least a few years...and beyond that it's probably more than any desktop will hold for quite a while.
Yes, desktop memory will continue to increase, but 4 billion times what it is now? That's going to take a while...sure we'll get to 128-bit, if the whole current model isn't thrown out before then, which I see equally as likely.
Also, it's worth noting that upgrading something from 32-bit to 64-bit puts you in a performance hole immediately in most scenarios (this is a major reason Visual Studio 2010 remains 32-bit only). The same will happen with 64-bit to 128-bit. The more small objects you have, the more pointers, which are now twice as large, that's more data to pass around to do the same thing, especially if you don't need that much addressable memory space.
When we talk about an n-bit architecture we are often conflating two rather different things:
(1) n-bit addressing, e.g. a CPU with 32-bit address registers and a 32-bit address bus can address 4 GB of physical memory
(2) size of CPU internal data paths and general purpose registers, e.g. a CPU with 32-bit internal architecture has 32-bit registers, 32-bit integer ALUs, 32-bit internal data paths, etc
In many cases (1) and (2) are the same, but there are plenty of exceptions and this may become increasingly the case, e.g. we may not need more than 64-bit addressing for the forseeable future, but we may want > 64 bits for registers and data paths (this is already the case with many CPUs with SIMD support).
So, in short, you need to be careful when you talk about, e.g. a "64-bit CPU" - it can mean different things in different contexts.
Cost. Also, what do you think the 128-bit architecture will get you? Memory addressing and such, but to handle it effectively, you need higher bandwidth buses and basically some new instruction languages that handle it. 64-bit is more than enough for addressing (18446744073709551616 bytes).
HDDs still have a bit of ground to catchup to RAM and such. They're still going to be the IO bottleneck I think. Plus, newer chips are just supporting more cores rather than making a massive change to the language.
Well, I happen to be a professional computer architect (my inventions are probably in the computer you are reading this on), and although I have not yet been paid to work on any processor with more than 64 bits of address, I know some of my friends who have been.
And I have been playing around with 128 bit architectures for fun for a few decades.
I.e. its already happening.
Actually, it has already happened to a limited extent. The HP Precision Architecture, Intel Itanium, and the higher end versions of the IBM Power line, have what I call a folded virtual memory. I have described these elsewhere, e.g. in comp.arch posts in some details, http://groups.google.com/group/comp.arch/browse_thread/thread/53a7396f56860e17/f62404dd5782f309?lnk=gst&q=folded+virtual+memory#f62404dd5782f309
I need to create a comp-arch.net wiki post for these.
But you can get the manuals for these processors and read them yourself.
E.g. you might start with a 64 bit user virtual address.
The upper 8 bits may be used to index a region table, that returns an upper 24 bits that is concatenated with the remaining 64-8=56 bits to produce an 80 bit expanded virtual address. Which is then translated by TLBs and page tables and hash lookups, as usual,
to whatever your physical address is.
Why go from 64->80?
One reason is shared libraries. You may want to have the shared libraries to stay at the same expanded virtual address in all processors, so that you cam share TLB entries. But you may be required, by your language tools, to relocate them to different user virtual addresses. Folded virtual addresses allow this.
Folded virtual addresses are not true >64 bit virtual addresses usable by the user.
For that matter, there are many proposals for >64 bit pointers: e.g. I worked on one where a pointer consisted of a 64bit address, and 64 bit lower and upper bounds, and metadata, for a total of 128 bits. Bounds checking. But, although these have >64 bit pointers or capabilities, they are not truly >64 bit virtual addresses.
Linus posts about 128 bit virtual addresses at http://www.realworldtech.com/beta/forums/index.cfm?action=detail&id=103574&threadid=103545&roomid=2
I'd also like to offer a computer architect's view of why 128bit is impractical at the moment:
Energy cost. See Bill Dally's presentations on how today, most energy in processors is spent moving data around (dissipated in the wires). However, since the most significant bits of a 128bit computation should change little, it should mitigate this problem.
Most arithmetic operations have a non-linear cost w.r.t operand size:
a. A tree multiplier has space complexity n^2, w.r.t. number of bits.
b. The delay of a hierarchical carry look ahead adder is Log[n] w.r.t number of bits (I think). So a 128bit adder will be slower than a 64bit add. Can anyone give some hard numbers (Log[n] seems very cheap) ?
Few programs use 128bit integers or quad precision floating point, and when they do, there are efficient ways to compose them from 32 or 64bit ops.
The next big thing in processor's architecture will be quantum computing. Instead of beeing just 0 or 1, a qbit has a probability of being 0 or 1.
This will lead to huge improvements in the performance of algorithm (for instance, it will be very easy to crack down any RSA private/public key).
Check http://en.wikipedia.org/wiki/Quantum_computer for more information and see you in 15 years ;-)
The main need for a 64 bit processor is to address more memory - and that is the driving force to switch to 64 bit. On 32 bit systems, you can really only address 4Gb of RAM, at least per process. 4Gb is not much.
64 bits give you an address space of several petabytes.(though, a lot of current 64 bit hardware can address "only" 48 bits - thats still enough to support 256 terrabytes of ram though).
Upping the natural integer sizes for a processor does not automatically make it "better" though. There are tradeoffs. With 128bit you'd need twice as much storage(registers/ram/caches/etc.) compared to 64 bit for common data types - with all the drawback that might have - more ram needed to store data, more data to transmit = slower, wider buses might requires more physical space/perhaps more power, etc.
I suppose I am focussing on x86, but I am generally interested in the move from 32 to 64 bit.
Logically, I can see that constants and pointers, in some cases, will be larger so programs are likely to be larger. And the desire to allocate memory on word boundaries for efficiency would mean more white-space between allocations.
I have also heard that 32 bit mode on the x86 has to flush its cache when context switching due to possible overlapping 4G address spaces.
So, what are the real benefits of 64 bit?
And as a supplementary question, would 128 bit be even better?
Edit:
I have just written my first 32/64 bit program. It makes linked lists/trees of 16 byte (32b version) or 32 byte (64b version) objects and does a lot of printing to stderr - not a really useful program, and not something typical, but it is my first.
Size: 81128(32b) v 83672(64b) - so not much difference
Speed: 17s(32b) v 24s(64b) - running on 32 bit OS (OS-X 10.5.8)
Update:
I note that a new hybrid x32 ABI (Application Binary Interface) is being developed that is 64b but uses 32b pointers. For some tests it results in smaller code and faster execution than either 32b or 64b.
https://sites.google.com/site/x32abi/
I typically see a 30% speed improvement for compute-intensive code on x86-64 compared to x86. This is most likely due to the fact that we have 16 x 64 bit general purpose registers and 16 x SSE registers instead of 8 x 32 bit general purpose registers and 8 x SSE registers. This is with the Intel ICC compiler (11.1) on an x86-64 Linux - results with other compilers (e.g. gcc), or with other operating systems (e.g. Windows), may be different of course.
Unless you need to access more memory that 32b addressing will allow you, the benefits will be small, if any.
When running on 64b CPU, you get the same memory interface no matter if you are running 32b or 64b code (you are using the same cache and same BUS).
While x64 architecture has a few more registers which allows easier optimizations, this is often counteracted by the fact pointers are now larger and using any structures with pointers results in a higher memory traffic. I would estimate the increase in the overall memory usage for a 64b application compared to a 32b one to be around 15-30 %.
Regardless of the benefits, I would suggest that you always compile your program for the system's default word size (32-bit or 64-bit), since if you compile a library as a 32-bit binary and provide it on a 64-bit system, you will force anyone who wants to link with your library to provide their library (and any other library dependencies) as a 32-bit binary, when the 64-bit version is the default available. This can be quite a nuisance for everyone. When in doubt, provide both versions of your library.
As to the practical benefits of 64-bit... the most obvious is that you get a bigger address space, so if mmap a file, you can address more of it at once (and load larger files into memory). Another benefit is that, assuming the compiler does a good job of optimizing, many of your arithmetic operations can be parallelized (for example, placing two pairs of 32-bit numbers in two registers and performing two adds in single add operation), and big number computations will run more quickly. That said, the whole 64-bit vs 32-bit thing won't help you with asymptotic complexity at all, so if you are looking to optimize your code, you should probably be looking at the algorithms rather than the constant factors like this.
EDIT:
Please disregard my statement about the parallelized addition. This is not performed by an ordinary add statement... I was confusing that with some of the vectorized/SSE instructions. A more accurate benefit, aside from the larger address space, is that there are more general purpose registers, which means more local variables can be maintained in the CPU register file, which is much faster to access, than if you place the variables in the program stack (which usually means going out to the L1 cache).
I'm coding a chess engine named foolsmate. The best move extraction using a minimax-based tree search to depth 9 (from a certain position) took:
on Win32 configuration: ~17.0s;
after switching to x64 configuration: ~10.3s;
This is 41% of acceleration!
In addition to having more registers, 64-bit has SSE2 by default. This means that you can indeed perform some calculations in parallel. The SSE extensions had other goodies too. But I guess the main benefit is not having to check for the presence of the extensions. If it's x64, it has SSE2 available. ...If my memory serves me correctly.
In the specific case of x68 to x68_64, the 64 bit program will be about the same size, if not slightly smaller, use a bit more memory, and run faster. Mostly this is because x86_64 doesn't just have 64 bit registers, it also has twice as many. x86 does not have enough registers to make compiled languages as efficient as they could be, so x86 code spends a lot of instructions and memory bandwidth shifting data back and forth between registers and memory. x86_64 has much less of that, and so it takes a little less space and runs faster. Floating point and bit-twiddling vector instructions are also much more efficient in x86_64.
In general, though, 64 bit code is not necessarily any faster, and is usually larger, both for code and memory usage at runtime.
Only justification for moving your application to 64 bit is need for more memory in applications like large databases or ERP applications with at least 100s of concurrent users where 2 GB limit will be exceeded fairly quickly when applications cache for better performance. This is case specially on Windows OS where integer and long is still 32 bit (they have new variable _int64. Only pointers are 64 bit. In fact WOW64 is highly optimised on Windows x64 so that 32 bit applications run with low penalty on 64 bit Windows OS. My experience on Windows x64 is 32 bit application version run 10-15% faster than 64 bit since in former case at least for proprietary memory databases you can use pointer arithmatic for maintaining b-tree (most processor intensive part of database systems). Compuatation intensive applications which require large decimals for highest accuracy not afforded by double on 32-64 bit operating system. These applications can use _int64 in natively instead of software emulation. Of course large disk based databases will also show improvement over 32 bit simply due to ability to use large memory for caching query plans and so on.
Any applications that require CPU usage such as transcoding, display performance and media rendering, whether it be audio or visual, will certainly require (at this point) and benefit from using 64 bit versus 32 bit due to the CPU's ability to deal with the sheer amount of data being thrown at it. It's not so much a question of address space as it is the way the data is being dealt with. A 64 bit processor, given 64 bit code, is going to perform better, especially with mathematically difficult things like transcoding and VoIP data - in fact, any sort of 'math' applications should benefit by the usage of 64 bit CPUs and operating systems. Prove me wrong.
On my machine, same h265 encode works almost twice as fast using virtulDub_x64 (with x64 h265 library) vs virtulDub_x32 (regular x32 h265 library). That's probably because longint (64bits) numbers operations (ie: add) can be done on a single instruction on x64, but on 32bit needs two: add lower part, and then add (with carry) the higher part. So unless integer maths are limited to 32bit integers, most of it will take more time under x32.
I have some SIMD code in Altivec processing 32 bit integer values in parallel. In some cases I want to load the integers as little endian, in other cases as big endian (note: this choice is regardless of the native CPU endianess; it is based on what algorithm is running). Doing the actual byte swap is very easy using Altivec's permute operations, as documented by Apple.
The part I'm worried about is that PowerPC allows either big or little endian operation, and so I don't know if I need to byte swap on little endian loads/stores or big endian loads/stores. (Currently my code just always does it for little endian and never swaps for big endian memory ops, which works fine on the 970 I'm currently using since of course it's running big-endian).
From what I can find, PPCs in little-endian mode are relatively rare, but they do exist, and ideally I'd like to have my code work correctly and quickly regardless of mode.
Is there a way of handling big and little endian loads to AltiVec registers regardless of CPU endianness? Are there other issues related to this I should know about? Wikipedia has the (uncited, naturally) statement:
"AltiVec operations, despite being 128-bit, are treated as if they were 64-bit. This allows for compatibility with little-endian motherboards that were designed prior to AltiVec."
which makes me think there may be other nastiness specific to AltiVec in little-endian mode.
Pretty much all PowerPC code out there will assume big-endian and all ARM code out there will assume little endian.
There are a few specialized cases where endian-swapping is used — apparently VirtualPC relied on little endian mode and thus initially didn't work on the G5 (which doesn't include it) — but I wouldn't worry about these.
ARM has a similar problem in big-endian mode: doubles are mixed-endian. The "pseudo-endianness" is achieved by XORing the low-order address bits with 0x2 (for halfword accesses) and 0x3 (for byte accesses) so that the effective order within a 32-bit word is swapped, but this breaks for 64-bit accesses. I suspect the same trick is used on PowerPC except done 64 bits at a time.
Does the change of macs over to Intel chips mean we are done with the bit twiddling on numbers in binary resources for cross platform data distributions?
Is that the last of this problem or are there some other platforms I'm not aware of?
Well, actually there are plenty of big endian CPUs left over.
Actually the PPC is not dead. You are aware, that the Xbox360 uses PPC CPUs (and it is a good example, that these CPUs are not as bad as their reputation - the Xbox360 is anything but slow). Okay, this one may not count as a PC.
But does a server count as a PC? There are still plenty of servers using Sun's UltraSparc CPUs, that are generally big endian, though the latest models can be either big or little endian. There are many CPUs that can be either one or the other (e.g. ARM, still used in many devices like mobile phones and the like), as supporting both adds greatest flexibility for the hardware and for the software vendors. Even the IA64 CPUs (the Intanium, that was intended to replace x86 before AMD invented x86-64, that was true 64 bit and could only emulate 32 bit, unlike x86-64 that can be both) is one of the CPUs that can be switched to big endian. CPUs that can be both are called bi-endian.
Actually if you ignore Intel (and compatible CPUs) for a second, most CPUs on the market are either big endian or at least bi-endian, though most of these are not used in any consumer PCs as far as I know.
However, I see no endian problem as many programmers do. Every modern CPU can swap endian in hardware. Actually if you'd write a program on a little endian Intel CPU, that swaps endianess of every integer read from memory and again when writing back to memory, this will cause maybe a performance penalty as little as 5%; and in practice you only need to swap endianess for data coming in and going out of your application, as within your application the endianess is constant, of course.
Also note:
Almost all network protocols I know specify byte order to be big endian, TCP/IP being the most familiar family. So if you work on lower network layers, you will always have to continue swapping bytes.
You seem to forget the endianness transcends processor architectures. There are plenty of algorithms and protocols that demand a particular byte order. For example, I spent two weeks trying to get an MD5 hashing algorithm to work, only to realize that I had assumed network byte order (Big Endian) while Ronald Rivest had assumed (without stating so in the RFC) that the implementor would use Little Endian byte order.
I was thinking the same question: since Macs are now Intel, is the endian issue dead? Nope. Aside from certain supercomputers (which, let's face it, us lay-folk will never have to deal with) there is still one major area where big-endian order is used: network protocols, particularly: the Internet Protocol (as in: "IP" of TCP/IP).
This is certainly not the last of this problem, particularly if you are writing for embedded systems, including Pocket PCs, etc. MIPS, ARM, and other architectures support bi-endian architectures which can select their endian-ness on system start-up.
If you're writing code that depends on byte ordering, you need to care about endian-ness. Don't expect this "problem" to go away anytime soon.
Pesky x86's dirtying up my memory registers with their segment pointers! ;)
I believe you don't need to flip words between PCs and Macs anymore, assuming you're eschewing backwards-compatibility with PowerPC.
Now, more than ever, a person's main computer is less likely to be a deskop computer running a general purpose operating system. Although that is still quite common, many other folks are using smartphones or umpc devices that are purpose built, ie for browsing the web. These platforms do not neccesarily have x86 cpus. More often, especially with smartphone devices, they are using an ARM core, which is big endian.
Define PC, what do you consider a PC?
I am currently typing this from an Linux distribution that is running on an arm 9 processor, which can be set into different endianness, but the default is big endian. Little endian is used by Intel, AMD and Via (x86 compatible).
Endian-ness won't go away any time soon, anytime you transmit anything over the network you have to make sure that it is in the right endianness, since the endian specified by Internet Protocol is actually big endian.
See the Wikipedia article on Endianness for more information.