i've been following this topic from the begining and I'm really interested.... why don't you start a complete project???, i've seen that there are a few people patching and improving microsoft dlls, not only one...
i don't have the knowledge to take part of this project, but i would be very interested and i can tell you that i would be the first tester!!!

it's just an idea... a web page dedicated to modified dlls with speed improvements...

good bye and happy coding

Is there any such project somewhere on the web?

i didn't find any, and going back to the topic, it's true, the only way to patch system dlls is copying the patched dll to the dll cache directory...

http://www.windowsnetworking.com/articles_tutorials/Tweaking-XP-Windows-File-Protection-SP2.html

good bye n happy coding

Hi

I very interested in this project. I'm codeing a program that can make a "system dll patcher" program. i hope that it can help you

Is the 64 bit version more secure? i mean if it use the same funtion as the 32 bit?

thx, but i need now, new ram, new processor, motherboard, video card, hdd, dvdrw, monitor, keyboard, and some rack

What if we hypothetically rewrite all functions. What happens to that file in general. I mean it doesn't get any smaller because the function entry addresses must remain the same - you might only get it smaller by optimizing the last function in binary for size.
What happens when your new code is more speedwise than size? You will use freed space from other function and jump or call to these This makes for pipeline flush penaly and speed bump.

How would a separate DLL be possible? Do you have to change all references to these functions? Raw-linked programs will not work then

With the amount of space there's no way that I've found to optimize ALL the memory moves. I've tried a few methods but I either run out of space or I only speed up small sizes and medium sizes are slow or visa versa. AMD64 optimization guide was pretty much followed to the letter in the 64bit memmove.

If someone else wants to give it a try good luck the source for the function is 14posts /\ up.

Why you can't change addresses of functions?

However, which important raw-linked program will not work? raw-linking is not the correct way of importing a function, for that exists the import table (and LoadLibrary/GetProcAddress stuff)

sorry, not intend to

I think we've trailed away from the point...
Help me optimize the win64 memmove function END STATEMENT

Anyone know of an AMD *64* paper that has source code on an amd lab optimized memmove?
There's AMD provided source for an MMX memmove but thats not for 64bit architecture.
There 64bit opt guide just says "Your OS will proivde an optimized memmove blah blah blah"

I think that mov is optimized...

Rather try to look for some other extremely-bad optimized function which is often used, you will get more speed that way.

Here is a tool for creating a patch to your patched ntdll file. I have tested it my self and it works finne . I have not coded any size or CRC check to the patcher becouse it is can be different size between the files.

Does this old source of memcpy() help you?
http://www.azillionmonkeys.com/qed/blockcopy.html

This is how results from the end of year 2003 are commented:



...and at the very end of the article he gives you a link to AMD's memcpy(): ftp://ftp.amd.com/pub/devconn/vcc/memcpy_amd.zip

It got me thinking here - the cache pollution theme. When you bypass cache it retains the values in it but is it that neccessary at that moment. Let's say you have a 2MB cache on modern CPU. You have a GB of data to copy or move. Would it be significantly faster to copy in strides of 128Bytes bypassing cache than copying in strides of 2MB (2097152Bytes!!!).

Why I came to this idea was the harddisk problem where you have two threads running that both access disk, but from different areas. The head flips like a maniac
The problem with 128bytes is that you won't get an average speed out of it when there are jumps and comparisons included. 2MB of continuous copying would be a breeze and it would favour even RDRAMs (though they are less common) and other high-speed, high-latency RAMs. You think that they are RANDOM-access-memory, but the fact is that you won't get the full speed out of them if you randomly access by only a few bytes.

Did this make sense or should I be more specific?

due to what i 've read SSE can't be safely used in Win64 anymore

Don't you mean FPU? AFAIK, the SSE should be used instead of FPU in Win64 (since FPU registers are not preserved).

You're wrong, vid, I was talking about MMX and FPU, these are not saved between process switches.

Why MMX/FPU are not saved anymore? If I need a REAL10 number how can I handle it without FPU?

See this link.



Why? I really don't know, maybe because the operation of saving/restoring is too slow.

How? For FP operations, you have SSE, SSE2 and SSE3.

But he's right, there's no 80-bit fp operations in SSE.