Someone should write LW for 686.

limewire does already use more CPUs and since its java it does use the available instraction set, ie i586 on pentium and sse2 on pentium4.

lg Clemens

Sun has already announced that it will fully support 64-bit processors very rapidly, as well as dual-cores.
All this should come starting next summer, with the release of Windows x64, and the start of Longhorn in next August.

The issues are not in Limewire, but in the OS kernels, and in the compiler supports for the new OSes, and more importantly in the support of security within OS and applications.

This requires collaboration between OS vendors (Microsoft, Sun, IBM, RedHat, ...), CPU manufacturers (Intel, AMD, IBM) for updates in the kernel drivers and compiler optimizers, and Java VM vendors (mostly Sun, BEA, Oracle and BEA).

So Limewire will run mostly without change on future 64-bit Java platforms. For now, there's simply no stable platform to deploy it.

There are products already available now, but they are only for tests, and they badly interroperate for now.

Limewire should only depend on Java VM support for 64-bit architectures. Until then, Java 1.5 already uses the 64-bit wide registers for internal operations that benefit from them (notably long integers, and Java2D), but the core program is still using 32-bit pointers.

Even when OSes will be 64-bit, very few people will benefit of a 64-bit addressing space, because 32-bit is ample enough to support the memory needed by an application including its swapped area. 64-bit is really important mostly for servers that need to address very large databases.

I'm not sure that upgrading to 64-bit will be significantly faster (for now the native 64-bit mode is in fact... slower than 32-bit emulation mode with WoW). And it takes more resources on the system (so you need 64-bit processors with larger but expensive internal caches, and more memory).

It seems that the dual-core architectures (including HyperThreading) will be more useful immediately.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

Hmm, seems like a professional ;-)

Sun already supports 64-bit CPUs and Limewire works about 10-15% faster on those boxes but also needs 20% more memory.
Dualcores are supported since Java-1.0 since each thread has it won interpreter and a dual-core is nothing more to LW/Java than a second processor.

Hmm? gcc supports amd64 since 3.3 or 3.4 I think so no problem since a long time.

The support of security in applications? You speak about the nx-bit?
Well this is something a normal program does not need to care at all, except it uses self-modifying assembler which should not be the case for LW and only very limited for java.

I am using LW on my Linux-2.6/amd64 box and it works as stable as using it with 32 bit.

Would you call +15% performance a bad interoperability==

Hmm, java-1.5 for amd64 USES 64-bit pointers otherwise it could not support more than 4GB of RAM. And it does, we've Tomcat running on a 12GB-Ram machine, and tomcat works with an 8gb heap!
However 64-bit pointers are even a drawback of 64-bit processors since they need more memory and have no other advantages (why should copying 64bit from the ram-> processor be faster than copying 32bit?)

Where have you heard this nonsence?
64-bit mode is almost every time faster (except for some special cases)!

You completly missed the main-fact why 64-bit mode is a lot faster: more registers. A normal x86 cpu has to live with 8 registers (!!!) whereas 64-bit has 16. This means only 1/2 as much register renaming

Hyperthreading is broken by design (TM). Don't you know what hyperthreading is?

I would suggest to study computer science or something like that before telling everybody how great and experienced you are.

lg Clemens

The case of the new NX bit in AMD64 processors (and more recently in new Pentiums) was an issue, not in LimeWire itself, but in the JVM that internally generates and uses self-modifying code (in the JIT compiler that compiles the Java Bytecode into native assembly, and then immediately starts running it). Support for it has been patched by Sun (there were tricky cases where a page of memory could be allocated to store the generated assembly, where the page was R/W data and initially not intended to be executable; the CPU driver for Windows is in charge of loading shared program pages in read-only executable mode, and this part of the code is where the Kernel memory mamager collaborates with a CPU-specific driver)

Initially there's a compatibility mode where all pages are executable, but the interest of the NX bit comes only when the OS candetermine which page is effectively data, and which page contains valid code. A basic implementation can assume that writable pages are not executable because they are normally not shareable without synchronization across processes; and the OS program loader normally loads pages of program code sections in read-only executable memory. (In rtecent kernels of Windows, these pages are, as much as possible supported by memory-mapped file fragments (unless the file's code need to be patched b the program loader, for example if a DLL is compiled with a base address which conflicts with pages of other DLLs).

For the case of JIT in Java, the program loader does not offer help, because the code is not backed by a file (this uses traditional Virtual memory allocator). Don't forget that JIT needs to collaborate with the Java garbage collector, so pages of memory may need to change of status. For security in recent versions of the JVM, there are now different pools of memory pages to avoid sollicitating the OS VM manager which is in charge of setting the NX bit and other access restrictions (including process isolation) within page descriptors that can be used natively by the processor's builtin descriptors cache.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

The NX bit is an issue in the Java VM, exactly because it creates native code at run time by allocating memory and writing to it, before executing it. Normally, executable code is now writable, and writable memory should not be executable. So the memory block must be allocated differently, and the Java VM for AMD64 must be modified to support the new memory allocation mode.

Also You have missed important words in my sentence before sayin "non sense": I said "until then" to refer to other architectures than 32-bit ones. When running in 32-bit mode, no pointer is larger than 32-bit, so the VM is limited to 4GB. A larger VM requires a new port to support 64-bit running mode.

[/QUOTE] I spoke here about the new large instruction format of IA64. Compilers are still not ready to support it, and IA64 is still too much a child. The extended AMD x64 instruction set is much more viable (IA64 is a failure)

I can agree with you, but this requires a 64-bit processor runing in 64-bit mode. In 32-bit mode, these extra registers are difficult to use as they are seen as MMX. It's true that the 64-bit mode has unified the set of general, FP and MMX registers (including the stack pointer, frame pointer). Not all those 16 registers are usable for general purpose in practice.

I know what it is. It allows parallel execution of instructions using two independant sets of registers and parallel pipelines in the same core, and sharing some resources such as the internal cache. It's an intermediate solution before the full dual-core implementation, but it offers interesting optimization (and better usage of energy) which is otherwise more difficult to reach with independant dual cores.

I have studied that and practiced it since long (that's my job).

You don't need to adopt such agressive and negative attitude. I've been polite and respectuous with you, and I expect you'll do the same with me. If there are errors in what I say (nobody's perfect), you can correct things. Please adopt a more neutral style when replying to someone in a public area such as this forum.

There's no need to flame or insult anyone, or even assert things about someone you don't know, such as the type of studies and courses he has followed. Remember that in public groups, we are not required to reveal all our personnal details or history, and reposnes could have been longer to include the details you lack.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

And it uses SSE3 also, when available (new high-end AMD64 processors, excluding Sempron and older Athlon 64, and new dual core Intel Pentiums). But support for Athlon64 MMX, SSE2 and SSE3 causes a problem when porting Java: there are bugs in many BIOSes with the way they manage the internal cache running mode (and its synchronization with the external memory buses). This causes instructions like MOVNTQ (non-timed moves) to be not-reflected in the internal cache, even after using a synchronization instruction that invalidates the internal cache. In the Athlon, there's a mode that allows superfast moves, at the price of not invaldating the data already present in the internal cache. There are also issues caused by ACPI in some non-modified BIOSes that causes memory instability when the CPU goes to idle HALT mode (useful for notebooks to preserve energy), or when disconnecting one or two cores from the cache (some BIOSes fail to reconnect the cores correctly, and forget to flush the internal cache).

This is not an issue of Java itself, because such problem can only be solved at the OS kernel level, or in the BIOS itself; however t still requires some work-arounds, notably in highly optimized Java APIs that use MMX, 3DNow, SSE, SSE2 or SSE3. Finally, some BIOSes do support the new 64 bit processors, but still don't support their 64-bit running mode (this means that an application may detect a processor capability, that is not correctly handled at BIOS or OS level, for example when the kernel forgets to save some extra registers when performing native thread switches). Such problem can be solved however with a processor specific driver added to the OS installation. User-mode softwares however must take extra precautions to make sure that no BIOS or OS issue will cause problems, if they want to use native threads, instead of impelmenting their own internal, but slower, multithreading scheduler.

There's nothing wrong with Hyperthreading, as it's not more bogous than other multicore (or even SMP) architectures regarding the timing issues that some have reported in cryptology groups. Such security issue is not a processor problem but an implementation problem for the cryptographic libraries.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml