Mailing List Archive

Are There a GPU Version
Hi There,

I wonder whether there is a GPU-based pattern matching to improve the
runtime performance? If there is, could someone point me to that? If not,
has anyone thought about this or are there any blockers?

I recently read a bunch of paper about this topic, and am happy to discuss
with anyone who is interested.

Thanks,
Yuede

--
Yuede Ji,
PhD student,
Department of Electrical and Computer Engineering,
George Washington University
_______________________________________________

clamav-devel mailing list
clamav-devel@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-devel

Please submit your patches to our Bugzilla: http://bugzilla.clamav.net

Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml
Re: Are There a GPU Version [ In reply to ]
Hi there,

On Mon, 26 Aug 2019, Ji, Yuede wrote:

> I wonder whether there is a GPU-based pattern matching to improve the
> runtime performance? If there is, could someone point me to that? If not,
> has anyone thought about this or are there any blockers?

I've thought about it. Quite a lot. :)

On a typical day on a typical server here, ClamAV might scan just a
few megabytes of mail. The average scan rates achieved are typically
between one-half and one megabyte per second of CLOCK time. I'm sorry
that I can't give you CPU time consumed but I've made a note to add it
to my logging, to fix what I now feel is a serious omission on my part.
Thanks for the prompt. :)

So scanning mail using ClamAV "might use a few" of the 172800 seconds
of CPU time available to all processes on one of my (2-core) servers.
Reloading databases after the updates takes a lot more CPU than that,
three or four minutes per update with the large number of third-party
databases that I use.

Granted there are people who would scan a couple of dozen VM images
daily, if you'd let them, but they're rare, and I think certifiable.

Granted, also, my mail traffic is at the low end of the scale, but a
fifteen-year old 2.7GHz Opteron box can scan 20,000 times the amount
of traffic using ClamAV without taking the load average into the red,
and there are plenty more not-very-busy boxes lying around the place.

In my view the performance which needs to be addressed is not the
speed of code execution, it's the detection rate. Improvements in
execution speed, and even massive parallelism, probably won't help.

Here are some of my messages to the ClamAV Users' Mailing List which
might give more food for thought. As you can see I've been banging on
about this for a while:

Sat, 4 Oct 2014 20:35:03 +0100 (BST)
Wed, 24 Dec 2014 17:32:07 +0000 (GMT)
Fri, 24 Apr 2015 17:43:22 +0100 (BST)
Sat, 28 May 2016 15:00:09 +0100 (BST)
Sat, 28 May 2016 18:19:58 +0100 (BST)
Tue, 9 Aug 2016 17:40:11 +0100 (BST)
Sun, 8 Jan 2017 18:06:50 +0000 (GMT)
Thu, 9 Feb 2017 18:20:52 +0000 (GMT)
Sun, 2 Apr 2017 19:10:06 +0100 (BST)
Tue, 13 Jun 2017 20:51:43 +0100 (BST)
Sun, 18 Jun 2017 18:23:32 +0100 (BST)
Sun, 9 Jul 2017 17:48:27 +0100 (BST)

> ... happy to discuss with anyone who is interested.

Also happy to discuss. :)

--

73,
Ged.
_______________________________________________

clamav-devel mailing list
clamav-devel@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-devel

Please submit your patches to our Bugzilla: http://bugzilla.clamav.net

Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml