9

Our school's project only allows us to compile the c program into 64-bit application and they test our program for speed and memory usage. However, if I am able to use 32-bit pointers, then my program will consume much less memory than in 64-bit, also maybe it runs faster (faster to malloc?)

I am wondering if I can use 32-bit pointers in 64-bit applications?

Thanks for the help

jww
  • 97,681
  • 90
  • 411
  • 885
kevin
  • 807
  • 3
  • 11
  • 20
  • How can you be so sure that 32-bit pointers will be noticeably faster than 64-bit pointers (if at all)? – Mysticial Apr 10 '12 at 05:53
  • 1
    at least it consumes less memory. I am not sure about faster run speed thing – kevin Apr 10 '12 at 05:56
  • Are you sure it's even going to be significant? Do you have massive pointer-based data-structures? Also note that the overhead or repeated pointer zero-extension operations may actually cause a *decrease* in performance. – Mysticial Apr 10 '12 at 05:59
  • 9
    Using GCC? The -mx32 option sets int, long, and pointer types to 32 bits, and generates code for the x86-64 architecture. (Intel 386 and AMD x86-64 Options): http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html Other targets: http://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html#Submodel-Options - then benchmark :) – Morpfh Apr 10 '12 at 06:01
  • 1
    @user120115: This should be an answer, not a comment. Then I'd be able to upvote it :-) – Nathan Fellman Apr 10 '12 at 06:18
  • @NathanFellman Your wish, my command ;-) – Morpfh Apr 10 '12 at 06:38
  • @user120115: done :-). By the way, with over 800 rep, isn't it time to update your profile? – Nathan Fellman Apr 10 '12 at 13:25

2 Answers2

38

Using GCC?

The -mx32 option sets int, long, and pointer types to 32 bits, and generates code for the x86-64 architecture. (Intel 386 and AMD x86-64 Options):

Then benchmark :)

Morpfh
  • 4,033
  • 18
  • 26
  • That's pretty much the way to go. Note that you need a fairly recent version of gcc (4.7, or 4.6 with various patches) and a fairly recent binutils. – torek Apr 10 '12 at 07:30
  • Why not specify that at the outset? Anyway this is still a far better answer to the _real_ question (arbitrary pedagogical restrictions notwithstanding) than the horrible hack that was accepted. – underscore_d Apr 19 '16 at 13:51
  • 3
    @kevin: `-m32` is a totally separate mode from `-mx32`. x32 generates fully 64-bit code that just happens to only use 64-bit addresses. (If this was homework, then `-mx32` wouldn't be allowed either, though. But writing it manually in C probably won't optimize to just use an address-size prefix to ignore the high bits of an address register.) – Peter Cordes Jan 22 '19 at 15:30
  • Is there an llvm equiv by chance? – rogerdpack Oct 15 '21 at 06:16
0

You could "roll you own". The following may reduce memory usage -- marginally -- but it may not improve speed as you'd have to translate your short pointer to absolute pointer, and that adds overhead, also you lose most of the benefits of typechecking.

It would look something like this:

typedef unsigned short ptr;
...

// pre-allocate all memory you'd ever need
char* offset = malloc(256); // make sure this size is less than max unsigned int

// these "pointers" are 16-bit short integer, assuming sizeof(int) == 4
ptr var1 = 0, var2 = 4, var3 = 8;

// how to read and write to those "pointer", you can hide these with macros
*((int*) &offset[var1]) = ((int) 1) << 16;
printf("%i", *((int*) &offset[var1]));

with a bit more tricks, you can invent your own brk() to help allocating the memory from the offset.

Is it worth it? IMO no.

rogerdpack
  • 62,887
  • 36
  • 269
  • 388
Lie Ryan
  • 62,238
  • 13
  • 100
  • 144
  • 2
    Strictly speaking, this code relies on undefined behavior, though in practice it will probably not cause alignment problems on most systems(?). – Lundin Apr 10 '12 at 06:30
  • It will improve the speed. In case your program experiences many data cache misses, like binary search, traversing a binary tree, traversing a linked list etc, using smaller pointers can translate to significant time saves. Smaller pointers mean better data cache hit rate and better performance. I did an experiment with binary tree traversal, 32-bit version ran at 0.85 time of 64-bit version: https://johnysswlab.com/the-price-of-dynamic-memory-memory-access/ – Bogi Aug 11 '20 at 17:57