Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

HX question about link.exe (DOSX)

posted by marcov, 29.07.2008, 09:33
(edited by marcov on 29.07.2008, 17:10)

> marco, you run a 64-bit OS, right? What are your experiences?
> Faster? Slower? Good 32-bit compatibility? Uses more RAM?
(I run Linux and Windows Vista under 64-bit now. Also have a run 64-bit FreeBSD, but managed make that unbootable when I let Vista repair a disk. and haven't had time to look into it. The machine is a Core2 6600 with 4GB, the main reason for the memory is because of Xen VMs under Linux.)

Total RAM use under Windows is higher, but not twice. This is logical, since most are buffers anyway. Moreover, both systems can run also 32-bit binaries, and e.g. 64-bit bootcds often only have a 64-bit kernel, but a complete 32-bit userland. So does e.g. Mac OS X (which installs a 64-bit kernel on x86 during setup if it sees that you have enough ram iirc)

If you see programs in the process manager, they are nearly twice the size. Say 170-180% of the 32-bit eq. Similarly on disc.

In general, performance difference is not really notable on a Core2. For good or worse. Before Vista sp1, I had a feeling that Vista 64-bit was slower, but the servicepack seem to have erased that pretty much. Since I was up to date with drivers, it felt like it was really the sp that did it).

Since the memory difference (3.25GB visible under XP, 4GB on 64-bit Vista) isn't that big, you can't really notice the difference, unless you really get to the edges.

I read up a lot on 64-bits programming and the summary is that rule of thumb, general purpose code is slightly slower. But this is only a measurable difference, not a noticable one.

Roughly these are the factors that matter. Some are in favour of 64-bit, some against. Note that I write this up from memory, so there might be little mistakes:

1 pointer is bigger (integer remains 32-bit) -> average data size bigger
1a -> worse cache utilization,
1b -> more data to shovel around if you segmove() something. I think this is more significant than the cache for general purpose programs (a few programs that random access read enormous trees excluded). If you don't do random access, but work on e.g. streams, the memory bandwidth is eventually always the limit, despite cache size.

2 x86_64 has more registers. Some functions that previously had to spill registers to the stack now don't have to. However the register usage is slightly different due to more use of register parameters calling conventions, so this is not always a straightforward to predict. Afaik, all OSes use the same calling convention now btw. A lot less cdecl vs stdcall nonsense.

3 x86_64 has 64-bit registers. This mainly speeds up recoded (!) special purpose code as codecs, compression and encryption that didn't use SIMD or float. (since that was already 64-bit a time on x86). The occasional 64-bit integer used in the code is of course also sped up, but this is even rarer than recoding the "special" code.

4 x86_64 can move (R)IP to a register. This speeds up PIC somewhat, though IIRC the Athlon and Core archs already recognized and optimized the x86 construct.

5 The minimum instruction set is raised. This is theoretic (since you can generate code for e.g. SSE2 too on x86), but in practice it is often the biggest difference. SSE2 is guaranteed, and so are P6 conditional moves. The variation in CPU capabilities on x86_64 is also much lower than on x86, at least for now.

6 On Windows, the x87 is not documented to work on 64-bit XP due to a MS documentation glitch. Registers are not saved properly during a context switch. This lowers theoretical maximal performance since you can't use an unit.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 186 users online (0 registered, 186 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum