4 ms·

This is a pro-level troll! For context, see slides 5 and 6 about the history of Hyperscan and Sensory Networks Inc.: https://openisf.files.wordpress.com/2015/1

This is a pro-level troll! For context, see slides 5 and 6 about the history of Hyperscan and Sensory Networks Inc.: https://openisf.files.wordpress.com/2015/11/oisf-keynote-2015-geoff-langdale.pdf https://openisf.files.wordpress.com/2015/11/oisf-keynote-201...

adorable_monkey 7y ago
History is not a benchmark) Software universal algorithm can not be faster than custom algoritm on FPGA for each job. Here is a real history https://twitter.com/joeerl/status/1115990630793207808 https://twitter.com/joeerl/status/1115990630793207808
- glangdale 7y ago
  You are correct that the failure of Sensory Networks from 2006-2009 to develop an effective FPGA matching algorithm does not imply that no-one can do it. However, the rest of what you said is an assertion for which there isn't really that much proof. FPGA is wonderful when you have the sort of available parallelism it needs; it's not great competing with s/w if the problem is expressed in algorithms with serial dependencies. I think FPGA could do a great job of achieving worst-case performance by simulating NFAs in a very straightforward fashion (beating s/w). However, no-one does this as the headline numbers are terrible. The thread you posted contains an assertion by someone who built an FPGA parser with no performance numbers to back it up; the performance comparison may well reflect relative skills with software and hardware as opposed to the limits of software. Interestingly, one of the first responses refers to another project of mine. :-) (simdjson). Unfortunately, given the subsequent posts on the thread, it does not look like the author can provide further details on the system, which is sad.
- Dylan16807 7y ago
  > Software universal algorithm can not be faster than custom algoritm on FPGA for each job. It often can, because it can clock 50x higher. And if you want a fair comparison, customize both to the job.

adorable_monkey 7y ago

History is not a benchmark) Software universal algorithm can not be faster than custom algoritm on FPGA for each job. Here is a real history https://twitter.com/joeerl/status/1115990630793207808 https://twitter.com/joeerl/status/1115990630793207808

glangdale 7y ago
You are correct that the failure of Sensory Networks from 2006-2009 to develop an effective FPGA matching algorithm does not imply that no-one can do it. However, the rest of what you said is an assertion for which there isn't really that much proof. FPGA is wonderful when you have the sort of available parallelism it needs; it's not great competing with s/w if the problem is expressed in algorithms with serial dependencies. I think FPGA could do a great job of achieving worst-case performance by simulating NFAs in a very straightforward fashion (beating s/w). However, no-one does this as the headline numbers are terrible. The thread you posted contains an assertion by someone who built an FPGA parser with no performance numbers to back it up; the performance comparison may well reflect relative skills with software and hardware as opposed to the limits of software. Interestingly, one of the first responses refers to another project of mine. :-) (simdjson). Unfortunately, given the subsequent posts on the thread, it does not look like the author can provide further details on the system, which is sad.
Dylan16807 7y ago
> Software universal algorithm can not be faster than custom algoritm on FPGA for each job. It often can, because it can clock 50x higher. And if you want a fair comparison, customize both to the job.