Quote:
Originally posted by stief
Don't die tonight (the FrostWire projects needs your scrutiny, expertise, and support especially for licensing and international issues  ) |
Don't worry, I'm not dead this morning. But that's not something I all always be able to decide myself.
Quote:
Seriously: your English tone may often be understood
|
What do tou mean there? that my English looks too much British? Or too much French? OR too difficult to understand from a native American English?
Quote:
| but your ideas and contributions are always appreciated. I still think of you every time LW or FW has to hash big files--your optimizations there have been really effective. Thanks again |
Note that the version bundled in LimeWire is not the latest. I have updated it several times, and in last spring I found other optimizations (and then discovered some processor caching issues, that caused additional processor cycles to be used for wait states, due to too many cache lines being used.
Compared to thecurrent version in LimeWire, the one thatis on
www.rodage.org/pub/java has about 20 to 25% of speed improvement (also the sources there include other hashing algorithms, also extremely optimized for performance for the new standard hashes. However the benefit face to the JDK implementation is much less impressive, because thesealgorithms are more complex and need more registers when the internal JIT compiler in the Java VM compiles the bytecode to native code. You would find there the fastest impelmentations anywhere on the web, made in 100% pure Java, and that outperforms most commonly used C-written implementations.
None of them are in Limewire which has my first versions made about 1,5 year ago.
I could be faster, but I need to study how to dynamically generate a Java class directly with manipulating the bytecode (this is possible with BCEL) as the only limitations I can see now are caused by the Java compiler (and the Java syntax requirements) that does not allow swapping some statements (however the JVM has made significant progresses since version 1.4.2, so that the extra time caused by suboptimal bytecode generated by the Java compiler can most often be avoided at runtime by the JIT compiler, which is now extremely impressive in the way it can generate excellent native assembly instructions from the Java bytecode. The benefit is extremely visible for example in 100% pure Java classes that now can perform 3D animation, or handle realtime audio/video streams.
The other important benefirts in Java 1.4.2and 1.5 is definitely its new memory manager, the much faster garbage collector, the new unsynchronized classes for most I/O, the new multithreading scheduler, the internal refoundation of the JIT compiler with a more generic engine that can handle more registers and 64-bit architectures with smarter rules (including the use of MMX/SSE/SSE2 instructions if present, for 64-bit computing in 32-bit mode; also many benefits frome from the newer Java2D API which interacts cleanly with DirectX on Windows and so can use hardware acceleration for display of the various elements of the Swing interface; as well, Swing is now much more optimized. And there are lors of optimizations in Java 1.5 regarding the internal APIs that allow reusing direct buffers or that allow computing with platform native buffers without additional copies or transforms). Overall, this has helped LimeWire a lot.
Bit Limewire itself was enhanced with faster internal processing, and with smarter management of internal priorities and worker threads.