| |||||||||||||
That way lies madnessThat way lies madnessPosted Sep 5, 2011 22:38 UTC (Mon) by intgr (subscriber, #39733)In reply to: That way lies madness by dlang Parent article: The x32 system call ABI
> and pointer-heavy things like Java are especially likely to benifit from
> the smaller pointers of x32
Offtopic, but interesting: 64-bit Java already offers the -XX:+UseCompressedOops option which turns on pointer compression. By dropping 3 bits from the least significant end of the address, it can address 32GB of memory using 32-bit pointer fields.
(Log in to post comments)
That way lies madness Posted Sep 6, 2011 14:35 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Userspace pointer compression has its own costs. In my tests it often performs worse than non-compressed version.
That way lies madness Posted Apr 2, 2012 14:30 UTC (Mon) by Richard_J_Neill (subscriber, #23093) [Link]
This is quite a clever trick. If I understand rightly, what Java is doing is giving up byte-addressability, in favour of more address space. I.e. you can't create a pointer to a byte/char any more; the smallest data-type then becomes an int, and strings have to contain 4*n bytes. Given that x86 accesses memory 32-bits at a time anyway, this is a fairly natural thing to do.
That way lies madness Posted Apr 3, 2012 20:49 UTC (Tue) by ibukanov (subscriber, #3942) [Link]
> Given that x86 accesses memory 32-bits at a time anyway,
On modern CPU memory is addressed internally by cache lines that are typically 16-32-64 bytes in size. On x86 the byte access is just as fast as 32-bit access. Moreover, misaligned access to 32-bit values is allowed and is not costly as long as the variable does not cross the cache line boundary.
That way lies madness Posted May 21, 2012 15:08 UTC (Mon) by mikemol (subscriber, #83507) [Link]
For basic instructions, yes. Take a look at the SSE instructions; while there are unaligned and aligned versions for several, the aligned versions will carry better performance.
|
|||||||||||||