Hi, yes, you can submit your patches to the exim bugzilla: http://bugs.exim.org/
As a starting point check pcre_exec() which is the primary matcher function. You can also play with pcretest, which is a tester program, which provides command line access to all features of PCRE. For pattern examples you can check the testdata subdirectory. It is also a good idea to check the pcre byte-code. Btw, PCRE has excellent documentation thanks to Philip's effort. Regards, Zoltan Roman Vasilyev <[email protected]> írta: >I'm new in libpcre,> if I want to try OpenCL improvements for it, could you recommend me start point? As well as if I'll have patch for review can I send it here?> > -----Original Message-----> From: Zoltán Herczeg [mailto:[email protected]] > Sent: Tuesday, February 12, 2013 1:47 PM> To: Roman Vasilyev> Cc: [email protected]> Subject: RE: [pcre-dev] PCRE GPU offload> > >Now I'm completely clear where is the problem.> > But seems like OpenCL doing it same way as OpenSSL makes AES en/decryption.> > It uses 16byte blocks for operation, just you know you using full 16 or just > part of it.> > And in case of texture size, you can create smaller texture size and > >upload your 1MB "string stream" by blocks, once first entry is done, you can >stop uploading.> > Minimum texture size 1pixel.> > Is this called texture atlas? Or is that something different? I am not a CL expert :)> > The other thing we need to worry about is the matching length. Let's say we start matching parallelly from the first 128 starting offsets, but the matching length is not known at compile time. It can be 100 bytes, 1000 bytes, anything. Are you able to do that without uploading the whole input, which is the worst case? E.g: /\p{Any}*/ matches the whole input.> > Regards,> Zoltan> -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
