Quote:
Originally posted by Linuxhippy2
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.
|
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.