[DimmestMouse]

Hello.

What is the status of having a 64bit version of eMule?

Has anyone successfully managed to compile eMule from source as a native 64bit application? Using Visual Studio 2010?

[ducho]

There is no need for a x64 version.
Works really fine with 2GB of available private memory address.
If you compile 32bits with /largeadressaware, I didn't check the source but I guess that extra giga will be of no use.

Even if you managed to compile a x64 version, how can you check if all code has the same functionality?

[Some Support]

IIRC some mods offer 64bit compiled versions. We do not plan to do so for the official version anytime soon.

[McAfee]

I haven't checked but,
What is eMule's typical memory footprint?
And what kind of scenario would it take to make eMule use 2GB's of memory?

With computers having more and more memory available with time. Could eMule be configured to take advantage of this extra memory (like more caching).
Or would it pretty much go to waste, or do more harm than good?

[Meuh6879]

McAfee, on 03 April 2012 - 05:18 PM, said:

What is eMule's typical memory footprint?
And what kind of scenario would it take to make eMule use 2GB's of memory?

1) 200-300Mo after 10-15-30-45 days 24h/24
2) max 700-900Mo for a short period (24-36 hours)...if eMule take more than 1,6Go, my PC reboot automaticly to reset the environment (because it's a bug for me, an app that it take more than 1Go of RAM ... except for the games).

[ducho]

McAfee, on 03 April 2012 - 12:18 PM, said:

I haven't checked but,
What is eMule's typical memory footprint?
And what kind of scenario would it take to make eMule use 2GB's of memory?

With computers having more and more memory available with time. Could eMule be configured to take advantage of this extra memory (like more caching).
Or would it pretty much go to waste, or do more harm than good?

I tested eMule with windows 2008 r2 (x64)
Memory footprint for a fresh execution, without connections or shared files, etc. Like a new installation.
private memory 10.664 KB, including heap size 2.652 KB
working set 19.652 KB
Commited memory 106.612 KB

As I have one emule running for 19 days 8 hours , the memory footprint is
private memory 407.500 KB, including heap size 395.828 KB
working set 397.740 KB
Commited memory 540.736 KB

Commited memory uses near 70MB from loaded 32bits windows dlls. This dlls would be swapped for equivalent 64bits dlls when running a x64 emule.

[netfinity]

McAfee, on 03 April 2012 - 04:18 PM, said:

With computers having more and more memory available with time. Could eMule be configured to take advantage of this extra memory (like more caching).
Or would it pretty much go to waste, or do more harm than good?

You, don't need a 64 bit eMule to take advantage of the extra memory. A 64 bit version of windows will suffice. The reason is that windows will use all unused memory as disk cache. Using larger buffers in eMule, can be useful if the majority (>50%) of your memory is unused. However, Windows may start to reclaim memory from eMule to increase the disk cache, when memory runs low (often happens around 75% utilization), which could result in eMules internal cache to be swapped to disk (which would be bad!).

The benefits with 64 bit versions is that 2x more and 2x larger data registers can be used, which sometimes cut the amount of CPU instructions required to perform a given task into half. However the benefit is mainly for math intense operations, like hashing and encryption. Decision making algorithms like data compression is less likely to benefit from this.

When speaking about registers, Windows can usually pass most function parameters using registers (microsoft calls it fastcall) when code run in 64 bit mode. In 32 bit code the stack (little slower) many times has to be used instead.

Also, 64 bit CPUs always support SSE and SSE2 instructions, so the code could be compiled to take advantage of those instruction without having to think about backwards compability. However, only very little code in eMule could really take advantage of this. It can speed up memory copy operations, but so far I only seen one SSE instruction that seemed somewhat useful. It was the prefetch instruction, which cause a slight speed up when scanning through a big chunk of data.

There is a negative side to compiling eMule for 64 bit and that is that the memory foot print is slightly larger, which causes more CPU cache misses as not all the data structures can fit in the CPUs data cache. CPU cache misses causes the program to run slower.

Conclusion of 64 bit :
+ functions can often be generated with less CPU instructions (which equals faster execution)
- data structures tend top grow (which consumes memory and slows down execution)
* eMule can take advantage of additional memory (as disk cache) even when not being compiled for 64 bit.

[fox88]

ducho, on 03 April 2012 - 10:43 PM, said:

As I have one emule running for 19 days 8 hours , the memory footprint is

The memory usage mostly depends on the number of shared files and queue size, not on running time (which would imply memory leaks).

netfinity, on 04 April 2012 - 11:25 PM, said:

There is a negative side to compiling eMule for 64 bit and that is that the memory foot print is slightly larger

On the other hand, running 32-bit in 64-bit OS requires additional software layer of WoW64 plus additional processor mode switches from native mode to compatibility mode.
So I guess it might be preferable to run 64-bit eMule in 64-bit OS even without major changes in code.

This post has been edited by fox88: 18 May 2012 - 06:05 PM

[fitchness]

There is no need for a x64 version.

[YumeYao]

netfinity, on 05 April 2012 - 04:25 AM, said:

The benefits with 64 bit versions is that 2x more and 2x larger data registers can be used, which sometimes cut the amount of CPU instructions required to perform a given task into half. However the benefit is mainly for math intense operations, like hashing and encryption. Decision making algorithms like data compression is less likely to benefit from this.

True. And decision making algorithms(instructions) may even run slower because the 64-bit instructions are much longer (taking more bytes) than 32-bit instructions. -> cache miss rate, yeah!

netfinity, on 05 April 2012 - 04:25 AM, said:

When speaking about registers, Windows can usually pass most function parameters using registers (microsoft calls it fastcall) when code run in 64 bit mode. In 32 bit code the stack (little slower) many times has to be used instead.

True on old CPUs. Latest CPUs have done optimizations on stacks. As pointed by AMD's manual, AMD is using something like 'a stack cache' or 'stack registers' to optimize the stack performance. Intel now uses a 'predictable' stack pointer to remove the dependency on stack pointer ( and as the stack is likely to be cached, so the access could be as faster as register accesses), the using push/pops won't stall the pipeline.

netfinity, on 05 April 2012 - 04:25 AM, said:

Also, 64 bit CPUs always support SSE and SSE2 instructions, so the code could be compiled to take advantage of those instruction without having to think about backwards compability. However, only very little code in eMule could really take advantage of this. It can speed up memory copy operations, but so far I only seen one SSE instruction that seemed somewhat useful. It was the prefetch instruction, which cause a slight speed up when scanning through a big chunk of data.

One thing that M$ compilers should be blamed at is unless SSE/SSE2 enabled, the compiler won't generate instructions using CMOV.
CMOV exists since Pentium Pro, so it's hard to image there is really someone running eMule on a CPU older than this. But we could expect people using very old Celeron, or Pentium II, on which there is no SSE but CMOV available...
Speaking of eMule, when SSE/SSE2 compiler option is enabled, 99.9% of the performance gain is done by merging condition jumps to CMOVs(Except Pentium IV, on which CMOV may be even slower), the rest is really where SSE/SSE2 help. SSE/SSE2 could only help on memory copy and clearing memory (setting to zero), and the benefit is really small because there aren't large memory operations.

netfinity, on 05 April 2012 - 04:25 AM, said:

There is a negative side to compiling eMule for 64 bit and that is that the memory foot print is slightly larger, which causes more CPU cache misses as not all the data structures can fit in the CPUs data cache. CPU cache misses causes the program to run slower.

True. As suggested above, the instruction cache may be also problematic.



On the opposite, MSVC 2012's compiler is doing a good job on 64-bit optimizing(M$ almost stopped optimizing 32-bit binaries further since VC2008), as eMule is not really good-coded, it may benefit from this... But still I don't think it worth.

[fox88]

YumeYao, on 22 January 2013 - 04:51 PM, said:

CMOV exists since Pentium Pro, so it's hard to image there is really someone running eMule on a CPU older than this. But we could expect people using very old Celeron, or Pentium II, on which there is no SSE but CMOV available...

What's the point of this?
64-bit support requires P4 or later.
While 32-bit eMule still could be used on Win95, and here as low as 486 processors would be good enough.

[YumeYao]

fox88, on 23 January 2013 - 12:44 AM, said:

YumeYao, on 22 January 2013 - 04:51 PM, said:

CMOV exists since Pentium Pro, so it's hard to image there is really someone running eMule on a CPU older than this. But we could expect people using very old Celeron, or Pentium II, on which there is no SSE but CMOV available...

What's the point of this?
64-bit support requires P4 or later.
While 32-bit eMule still could be used on Win95, and here as low as 486 processors would be good enough.

eMule is a file-sharing software, 486 may not even play a mp3 file fluently. So I doubt people are using eMule on old machines like 486 and Pentium. Also I doubt people are storing files for share on such old machines, you know when Pentium II ( I had one with win98 ) is out, the mainstream HDD size is 6GB or 4GB (Mine was 6GB, my bro's Celeron bought 1 year later was 4GB).

This post has been edited by YumeYao: 23 January 2013 - 03:01 AM

[fox88]

YumeYao, on 23 January 2013 - 05:49 AM, said:

eMule is a file-sharing software, 486 may not even play a mp3 file fluently. So I doubt people are using eMule on old machines like 486 and Pentium. Also I doubt people are storing files for share on such old machines, you know when Pentium II ( I had one with win98 ) is out, the mainstream HDD size is 6GB or 4GB (Mine was 6GB, my bro's Celeron bought 1 year later was 4GB).

Sorry, the topic is not about mp3, you doubts and what configuration you ever used.

A program compiled to work in Win95 should not use anything beyond 486 instruction set.

[DavidXanatos]

fox88, on 23 January 2013 - 06:59 AM, said:

YumeYao, on 23 January 2013 - 05:49 AM, said:

eMule is a file-sharing software, 486 may not even play a mp3 file fluently. So I doubt people are using eMule on old machines like 486 and Pentium. Also I doubt people are storing files for share on such old machines, you know when Pentium II ( I had one with win98 ) is out, the mainstream HDD size is 6GB or 4GB (Mine was 6GB, my bro's Celeron bought 1 year later was 4GB).

Sorry, the topic is not about mp3, you doubts and what configuration you ever used.

A program compiled to work in Win95 should not use anything beyond 486 instruction set.

I'd say you shouldn't maintain compatibility with Windows'es that not longer have extended support (meaning don't get any security patches anymore).
Making eMule work in Win XP upwards would be still good enough and you could optimize it a lot.

[fox88]

DavidXanatos, on 26 January 2013 - 12:28 PM, said:

I'd say you shouldn't maintain compatibility with Windows'es that not longer have extended support (meaning don't get any security patches anymore).

Is M$ paying you for saying so?
Compiler can generate code that runs on Win95; fancy features from later OSes are not mandatory. So far there is no point in changing that and breaking compatibility; the rest is user's choice.

DavidXanatos, on 26 January 2013 - 12:28 PM, said:

Making eMule work in Win XP upwards would be still good enough and you could optimize it a lot.

XP starts from Pentium, still no SSE.
Did you get the point at all?

This post has been edited by fox88: 26 January 2013 - 03:31 PM

[DavidXanatos]

fox88, on 26 January 2013 - 03:29 PM, said:

Compiler can generate code that runs on Win95; fancy features from later OSes are not mandatory.

You mean fancy features from later OSes like IPv6 support.
Or support for large HDD's

[fox88]

DavidXanatos, on 26 January 2013 - 06:35 PM, said:

You mean fancy features from later OSes like IPv6 support.
Or support for large HDD's

I see you are not answering questions and changing topics.
Could you give an answer first?

This post has been edited by fox88: 26 January 2013 - 10:14 PM

[Ejack79]

Hey!
Focus on techinical issues.
Let different opinions go.

[DavidXanatos]

Windows XP runs on almost everything: http://winhistory.de...6/xpmini.htm.en



Now: whats the point in that?

XP hit the market when > 1 GHz CPUs ware common, P3's and P4's with SSE.
That you can it praxis install in on the first Pentium ever made is not really relevant.
The relevant question which OS Hardware configuration is reasonable in terms of performance.

And I'd dear to say anything jess than medium P3 is pure masochism.

And eMule is not very nice on the CPU if you download any reasonable amount of files at once to get decent download speeds, you will need over a GHz of CPU power to run smoothly.

David X.

[Zangune]

DavidXanatos, on 26 January 2013 - 10:28 AM, said:

Making eMule work in Win XP upwards would be still good enough and you could optimize it a lot.

How much?
Can you explain me better, please?

DavidXanatos, on 27 January 2013 - 12:00 PM, said:

And I'd dear to say anything jess than medium P3 is pure masochism.

And eMule is not very nice on the CPU if you download any reasonable amount of files at once to get decent download speeds, you will need over a GHz of CPU power to run smoothly.

I disagree, but maybe. Let's try?

Windows 98 Second Edition Intel Pentium II 361MHz 64MB RAM 4GiB HardDisk, 10Mbps Download / 1 Mbps Upload 2 PCs, eMule on mine and a mmorpg on my brother's laptop (can't ask him to stop playing ).

What I have to do exactly?

This post has been edited by Zangune: 27 January 2013 - 02:47 PM