Introduction and welcome

Hello, world.

This is my blog where I will talk about things that interest me (and a no doubt small collection of others). Topics that I’m interested in include:

  • Low-level and performance-oriented programming
  • Computer architecture (especially as it related to performance-oriented code)
  • Programming languages
  • Regular expression implementation and automata theory
  • … and of course, implementing things without branches! Thus the name.

I was the designer of the Hyperscan project. I built this system at Sensory Networks, which was acquired by Intel Corporation in 2013, and worked on Hyperscan at Intel for over 4 years.

I hope that I can show you some interesting things. I have a few things in the pipeline that I will show shortly, including some string matching work, fast Random Forest implementation and a lot of my favorite low-level coding tips and tricks.

I request that my readers can bear with me and forgive the (hopefully temporary) amateurish nature of the site; I am not an expert blogger or user of WordPress.

5 thoughts on “Introduction and welcome”

  1. Thanks for sharing your knowledge with the world! I’m eager to learn more from your posts in this website.

    Like

  2. Hi Geofflangdale,

    I had few queries related to certain APIs no longer supported in HyperScan 5.4.2 version.

    They are:

    1)hs_stream_interesting

        2)hs_open_and_reconstitute_stream

        3)hs_reset_and_reconstitute_stream

        I am currently on an older HyperScan version, ie HyperScan 2.1 which was supporting the above APIs. But, the later versions including HyperScan 5.4.2 seem to not support the above APIs.

        Any insight into why these APIs were removed in later versions ?

        Also, are there equivalent APIs in HyperScan 5.4.2 which give same functionality as above APIs ?

        Thanks in advance

        Like

        1. Hi,

          You must be have been a commercial Hyperscan user!

          These APIs were removed because there simply weren’t enough users to justify the complexity that created. The problem was that the interesting/reconstitute functionality (as well as a few other bits and pieces for specialized APIs) created multiplicative complexity through our entire codebase – every sub-engine sprouted more work to deal with these features. We already have a number of sources of “multiplicative complexity” just from the normal pattern matching task, so the weight of supporting these features was too high.

          There’s no easy way to reconstruct these features – I’d need to understand more about your use case to figure out what a good workaround would be.

          Like

          1. Thanks for the prompt response Geoff. I will get back to you with my requirement in the next few days.

            Like

      Leave a reply to geofflangdale Cancel reply