I remember very interesting search algo of yours, published in APJ9.
Has it been changed since that time?
If it has, could you,please, send new version?
are BM search versions in MASM32 7 latest versions?
If not - were to get latest ones?

Thanks, (I took it from Ewayne - my good manners teacher :)
Posted on 2002-04-04 16:36:31 by The Svin

The versions in MASM32 are the latest but I have another mod done that I have to exhaustively test yet that is between 5 and 10 percent faster. It impliments another heuristic when the good suffix shift drops below 1 by using the bad character shift in its place.

I just have to make sure it satisfies exhaustive testing before I release it. The technique can be used with both the BM and simplified BM algos.

What I have still not succeeded in yet is breaking the memory access barrier and I don't think it can be done with normal integer code. In partial testing where the memory access and branch prediction problems have been sidestepped, I have seen over 40% speed increases but the matching is not reliable.


Posted on 2002-04-04 17:20:19 by hutch--
Thanks, Steve.
I'm glad to hear that you are again in fight for better code :)
I'm waiting for your work.
Good luck!
Posted on 2002-04-04 18:21:29 by The Svin
I was just wondering if this is a good idea (I know it is, but...) I'm planning to create something like this:

- Will use the stack for the shift table.
- Since most efficient string search algo requires you to pass a parameter of the length of both strings(source & pattern) - why not just loop until we hit a null pointer in either strings during the search.

If this can be done succesfully, it can eliminate the need for strlen(which is an added overhead for current string search algo's).
Posted on 2002-04-05 02:13:07 by stryker

Why not just loop until we hit a null pointer in either strings during the search.
For something like a compression algorithm you need to search for zero bytes, so this is only better in the limited case of text string search.
Posted on 2002-04-05 10:24:41 by bitRAKE