Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Linux now an equal Flash player (Linux-Watch)
Posted Oct 19, 2008 20:08 UTC (Sun) by alankila (subscriber, #47141)
Posted Oct 19, 2008 20:24 UTC (Sun) by jengelh (subscriber, #33263)
No. There are opcodes that can represent values/pointers in less than full 64 bits. For example, mov rax, 0x7fffffff has two representations:
(1) 48 c7 c0 ff ff ff 7f
(2) 48 b8 ff ff ff 7f 00 00 00 00
mov rax, 0x7fffffff
48 c7 c0 ff ff ff 7f
48 b8 ff ff ff 7f 00 00 00 00
And the binary you execute and the heap is often loaded into memory below 0x7fffffff on Linux x86_64. Just check yourself: less /proc/$$/maps. Modules are loaded into higher memory though :-/
Posted Oct 20, 2008 7:32 UTC (Mon) by alankila (subscriber, #47141)
I confess my main horror with 64-bit code came from seeing a java program that took 3x the memory when it was run in 64-bit jvm compared to the 32-bit one. (Everything else being equal, just uninstalled the 64-bit one and replaced it by 32-bit jvm.) Might be it is constrained in the tricks it can do, differently from your average small app.
Posted Oct 20, 2008 8:06 UTC (Mon) by jengelh (subscriber, #33263)
If the program uses pointers larger than 0x7fffffff, gcc will automatically switch to the next best opcode or opcode group. There is a really ugly case where you move a 64-bit value into a 64-bit (mov qword ptr [rax], 0xdeadbeefdeadbeef), which gets encoded as 2 instructions actually - but: it uses no more than 128 bits for the actual data. So at least you don't lose anything. It's merely that you win a few bits if your values are smaller. (And that's A Good Thing).
There is no flag to generate narrow code hey, "tiny" model and "huge" model were DOS times ;-) GCC will automatically do the best. You might also want to try compiling with -Os, maybe it got more tricks upon its sleeve.
Java.. long topic. There are things it just cannot do efficiently because the language is so restricted. Whereever you would take a pointer/reference in C, whenever you would store an aggregate object on the stack, you have to involve the heap in Java. That is slow. It takes more memory (due to the allocation management). Or if you do not want to do it via the heap, you (can sometimes) replicate the branch in an if/else for example. Both are just plain horrible.
With just a little more brain to spend, you would get the memory benefit, the speed benefit, by using something like C++. I might just even suggest to use GCJ because that just takes less memory at runtime (unfortunately it is not as fast as the SunJVM-JIT on computationally expensive stuff).
Posted Oct 20, 2008 10:06 UTC (Mon) by alankila (subscriber, #47141)
Posted Oct 20, 2008 15:41 UTC (Mon) by jengelh (subscriber, #33263)
By my words, GCC internally could have something like:
if ((signed long)operand <= 0x7fffffff)
spewout(short opcode version, operand);
/* default */
spewout(long opcode version, operand);
With no option to tune it. Why would you even use the slower one when you can avoid it? It's not going to change anything... unless there is a bug in the CPU that causes the short opcode to go haywire.
Yes, malloc always returns a 64-bit quantity, and it does so in a register, which makes accesses cheap with small values: int *x = malloc(sizeof(int)); *x = 5; equates to mov dword ptr [rax], 5 which is the c7 00 code with a 32-bit operand for the "5".
int *x = malloc(sizeof(int)); *x = 5;
mov dword ptr [rax], 5
Posted Oct 20, 2008 21:24 UTC (Mon) by Ed_L. (guest, #24287)
My current project targets CentOS/Fedora i386 and x86_64. Operationally, all I need do is specify "gcc -m32" when compiling and linking, and the resulting executable "just works."
Subject to the usual constraints on time and coding intelligence, of course...
Posted Oct 20, 2008 20:20 UTC (Mon) by jengelh (subscriber, #33263)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds