flat assembler
Message board for the users of flat assembler.

Index > Heap > Why 64-bit Linux run slower on my PC?

Author
Thread Post new topic Reply to topic
OzzY



Joined: 19 Sep 2003
Posts: 1029
Location: Everywhere
OzzY
I installed Ubuntu-64 thinking it was going to run faster than normal Ubuntu for 32-bit.
But it actually ran slower. Why?

Then I installed Arch Linux. It's light and stable but requires too much configuration. I realized that in the end I like gnome and I would configure Arch more or less like Ubuntu is. So why waste time?
Arch is good for low-end PCs and servers though.

I'm going back to Ubuntu now. But why did the 64-bit ran slower? Isn't it strange?
Post 24 Feb 2008, 18:51
View user's profile Send private message Reply with quote
mattst88



Joined: 12 May 2006
Posts: 260
Location: South Carolina
mattst88
How do you know it runs slower? How are you benchmarking this?
Post 26 Feb 2008, 03:18
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
App loading speed could very well be slower, since 64bit binaries are larger. Also, you shouldn't expect much overall system performance improvement from going to 64bit, since not much on a standard linux system is that compute-intensive; on the other hand, you have somewhat larger code and somewhat larger data structures, which higher cache usage...
Post 26 Feb 2008, 13:20
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4237
Location: 2018
edfed
64 bit is not as good as it could be.
the 64 bit shall support 32, 16 and 8 bits without problem, if not, wait they make it.

they say:
yeah, we are the king, we made the 64 bit arch, but this arch is completelly buggy.
and 32 bit arch shall be optimised for 16 bit support without problem before to implement a new 64 bit...
it's my opinion.
just an opinion.
the IA 64 is just an attempt to be the king. it exists since a long time... just an extension of 32 bit to 64 is enough. not a complete remake in 64.
i prefer the 32 bit one.
and in 10 years, i'll still use 32 bit.
64 is too much, it's a big waste of ram.
a 32b PC with 256M of ram is faster than a 64 with 512M.
why?
the bus of the µP, it's limited to 64 bits, so, it takes one ram clock to read two 32bit values.
and 64 bit take one ram cycle for one value...
then, it's slow.
and i reapeat, it's a waste of money and ram.
Post 26 Feb 2008, 15:03
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
edfed: IA64 == Itanium, 64bit x86 has many names, but typically AMD64, IA32e, x86-64 or x64. But NOT IA64, Itanium is a completely different beast.

Now, stop talking out of your ass about topics you don't understand...
Post 26 Feb 2008, 15:28
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17254
Location: In your JS exploiting you and your system
revolution
The only possible slow down when using 64bit code is PUSH/POP and INC. Every other instruction is exactly the same in 64bit mode and 32bit mode. INC is only one byte longer in the RAM, and PUSH/POP always operate on 64bit values.

There is an overhead of one byte when arithmetic operations are "promoted" to 64bits, but that is no issue because the extra computation bandwidth more than compensates for the extra instruction byte. eg. compare two 32bit ADD/ADC instructions (4 bytes) with one 64bit ADD (3 bytes) and you can see there is a saving in both code size and clock cycles.

In short, the only real overhead is PUSH/POP. So if the OS code relies heavily on the stack for doing things then there is a chance for a net slow down to be seen, but only if the 64bit arithmetic does not provide enough gain to balance the PUSH/POP loss.

I don't think it is fair to say that the x86-64 code set is buggy. It was received much more favourably than Intel's IA64 (Itanium). x86-64 has a very small incremental learning curve when moving from 32bit programming. It provides extra arithmetic performance and RAM addressing capabilities with very little overhead in code size.

So to answer OzzY's original question, it would appear that Ubuntu relies heavily on the stack and doesn't/can't take good advantage of the 64bit arithmetic to fully compensate.
Post 26 Feb 2008, 15:38
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
revolution: In 64 bit code, there is almost no PUSH/POP. fastcall is done using mostly MOVs, and so stack access is usually faster than on 32bits. Instead, I think it's more memory usage which f0dder pointed out.
Post 26 Feb 2008, 15:46
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17254
Location: In your JS exploiting you and your system
revolution
vid wrote:
revolution: In 64 bit code, there is almost no PUSH/POP. fastcall is done using mostly MOVs, and so stack access is usually faster than on 32bits. Instead, I think it's more memory usage which f0dder pointed out.
fastcall still needs to reserve the stack space so yes it will require more memory during runtime. Actually the normal way fastcall has been implemented by most compilers is quite wasteful in code size. If the more usual PUSH/POP were used (like with stdcall) it would create similar sized binaries to 32bit and only the runtime stack usage is affected. But either way it is the stack issue that creates the overhead. I may have mis-spoke by implying it is just PUSH/POP, I should have said stack usage by any means.
Post 26 Feb 2008, 16:05
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4237
Location: 2018
edfed
it's possible that ubuntu don't care about alignement.

fodder:
i understand the topic.
the problem ozzy meet is a slow down of his machine with ubuntu.
IA 64 is not a name, but some letters to say:
it's intel arch, in 64 bits.
but you can play with exactness a long time.
all in all, don't buy 64 bit machines now and wait it to be better.
Post 26 Feb 2008, 16:23
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
revolution: code size of fastcall isn't so much bigger than stdcall, maybe few bytes per function, nothing considerable. It's runtime memory that matters. And not just stack. It's also heap, static data, kernel structures, etc.

edfed: IA64 *is* a name. Fact that you didn't know what that name means and still commented on it doesn't make it any less a name.

Seriously, stop commenting on everything. Commenting on something you don't know a shit about only wastes this forum and makes you more trolly.
Post 26 Feb 2008, 16:46
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
MichaelH



Joined: 03 May 2005
Posts: 402
MichaelH
vid wrote:

revolution: In 64 bit code, there is almost no PUSH/POP



Software Optimization Guide for AMD Family 10h Processors
40546 Rev. 3.05 December 2007

Chapter 4 Instruction-Decoding Optimizations 59

Quote:


4.7Stack Operations

Optimization

When saving or restoring registers in function prologues or epilogues, or when passing arguments
through the stack, use PUSH or POP instructions to improve performance and to reduce code size.
When deallocating stack space at function exit, use RET imm to improve performance and to reduce
code size.

Application

This optimization applies to:
•32-bit software
•64-bit software

Rationale

In spite of the implicit dependency between several successive PUSH or POP instructions on the
stack-pointer (which PUSH and POP modify), special circuitry (the Sideband Stack Optimizer) tracks
the value that the stack-pointer assumes, allowing parallel execution of more than one PUSH or POP.
This is also true of instructions that reference the stack-pointer, either implicitly or explicitly,
including:
•Near CALL
•Near RET
•LEAVE
•Instructions that specify the stack-pointer as a source register.
•Instructions that specify the stack-pointer in the addressing mode of a memory operand without
an index register.
However, the Sideband Stack Optimizer cannot break the dependency between the aforementioned
instructions and other instructions that refer either implicitly or explicitly to the stack-pointer,
including:
•LEA instructions that specify the stack-pointer.
•Instructions that specify the stack-pointer as a destination register.
•Instructions that specify the stack-pointer in the addressing mode of a memory operand with an
index register.
•VectorPath instructions that specify the stack-pointer.


Examples

Code:

Avoid
   sub   esp, 20
   mov   [esp + 16], edi
   mov   [esp + 12], esi
   ...
   mov   [esp], eax
   call  ...
   ...
   mov   esi, [esp + 12]
   mov   edi, [esp + 16]
   add   esp, 20
   ret

Preferred
   sub   esp, 8
   push  edi
   push  esi
   ...
   push  eax
   call  ...
   ...
   pop   esi
   pop   edi
   add   esp, 8
   ret
    




I suspect a lot of 64bit code for windows and linux are written using "Avoid" type code


BTW vid, those billy goat gruffs are on your bridge again Smile
Post 27 Feb 2008, 02:50
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
I suspect a lot of 64bit code for windows and linux are written using "Avoid" type code

yes - in fact, all windows code i disassembled used "avoid" type code exclusively, no single PUSH/POP.

Quote:
those billy goat gruffs are on your bridge again

???
I quess my english slang skill isn't good enough to decipher this
Post 28 Feb 2008, 07:03
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
MichaelH



Joined: 03 May 2005
Posts: 402
MichaelH
Quote:

yes - in fact, all windows code i disassembled used "avoid" type code exclusively, no single PUSH/POP.



I guess the AMD Family 10h Processors are new processors and the Sideband Stack Optimizer is not on older processors but at least it's good to know, now when coding in 64bits, one can go back to the good old fashioned push/pop way of doing things.

Fastcall coding in both 64bit linux and windows is a bit odd. I've always wondered with more registers available, why the stack is involved????? Once again I suspect it was because there was no Sideband Stack Optimizer for push/pops so a method of storing values on the stack was invented. If so, does this mean a lot of the XP64, vista64 and linux64 code is now defunct?


Quote:

Quote:

those billy goat gruffs are on your bridge again


???
I quess my english slang skill isn't good enough to decipher this



Oh sorry, I didn't realise you were saying edfed was truck like ..... I was on a completely different tangent Wink
Post 28 Feb 2008, 08:23
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2907
Location: [RSP+8*5]
bitRAKE
MichaelH wrote:
Quote:
Quote:
vid wrote:
Commenting on something you don't know a shit about only wastes this forum and makes you more trolly.

those billy goat gruffs are on your bridge again
I quess my english slang skill isn't good enough to decipher this
Oh sorry, I didn't realise you were saying edfed was truck like ..... I was on a completely different tangent Wink
He is more like a trolley - making every stop.

_________________
¯\(°_o)/¯ unlicense.org
Post 28 Feb 2008, 18:15
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
oh, you meant trolley Smile
Post 28 Feb 2008, 18:23
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4237
Location: 2018
edfed
erf
i like this place... full of pretty girls. Very Happy
Post 28 Feb 2008, 21:44
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.