buliaNaza,
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?
Steve,
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 :)
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?
Steve,
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 :)
Alex,
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.
Regards,
hutch@movsd.com
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.
Regards,
hutch@movsd.com
Thanks, Steve.
I'm glad to hear that you are again in fight for better code :)
I'm waiting for your work.
Good luck!
I'm glad to hear that you are again in fight for better code :)
I'm waiting for your work.
Good luck!
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).
- 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).
Why not just loop until we hit a null pointer in either strings during the search.