Optimizing functions in alg.c

[usernamepi]

0. Reviewed guide and contributing documents? : Yes
1. version : 4.2.2
2. installed as a package or compiled from sources [deb, rpm, git, other]: compiled from source
3. standalone or part of third party [motion, MotionEyeOS, other]: standalone
4. video stream source [V4L (card or USB), net cam (mjpeg, rtsp, other), mmal]: USB & several RTSP
5. hardware [x86, ARM, other]: x86
6. operating system [16.04, Stretch, etc, FreeBSD, other]: 18.04

I optimized some functions in motions alg.c file, using intel SSE2.
Why? Mainly for fun and learning, also hoping that I could squeeze more out of old hardware.
That last reason was abandoned as soon as I realized that most of the CPU utilization was caused by encoding and decoding of video.

If there is any interest, let me know and read on ...

It's in a "works for me" stage.
I use it 24x7 on a 720p stream and two 480p streams.

I did it for the top 5 that showed up in gprof at the time I started.

• the erode and dilate functions
• the alg_update_reference_frame

Below the current results (roughly):

Somehow gprof could not profile the dilate function.
So I the took the numbers from despeckle, which also includes labeling.
The last column shows the speedup for the total amount of time motion was busy during processing of my testclip (an approximation of CPU time spent). Note: this column is motion code only, gprof did not profile the linked libraries (encoding, decoding, etc...) which consume the most CPU time in the motion application.

I used a (real life) testclip,, 7 minutes, 720p, 25 fps, in which a couple of events take place
I used standard despeckle (EedDl)

I'm now planning:

• to create some unit tests for the work I did.
• create runtime detection of SSE2 capabilities
• cleanup/test, and then request a pull

[tosiara]

Hi,

could you please also review the following attempts to optimize NEON and SSE made by @notorca? Maybe you could benefit and improve those

#466
#498

I'm already using NEON optimizations in my motion fork for few years, works great

[usernamepi]

@tosiara Thank you for pointing this out.
Two different people, two different starting points (Intel/ARM), two different approaches:

• Overall: notorca discovered the better code sharing way for two different arch's. Nice.
• Unit tests! Very nice.
• NEON/SSE4.1 versus SSE2
• Erode & dilate:
  ** mine approach is not as fast as notorca. He kept close to to the "old" algo, which is better optimized wrt to reading from memory, mine is simpler but does more expensive memory reads.
  ** I only use two loops to process arbitrary image height/width : 16 bytes at once loop and a 1 byte at once loop. notorca adds an 8 byte at once loop in between the 16 bytes and 1 byte at once loop.
• update reference frame: approach is the simular:
  ** mine is faster because I "cheated" with the type of ref_dyn. Instead of u16_t[] I made it u8_t[] like the rest of the arrays handled in the loop. This way 16 bytes can be handled in one go. notorca's implementation handles 8 bytes in one go. My implementation needs some extra conditions to be met (ACCEPT_STATIC_OBJECT_TIME < 52), notorca's implementation does not.
  ** In case of no motion in 8 consecutive pixels or more, notorca's implementation will be faster.

I understand MrDaves concerns with respect to maintainability.
However:

• you can always ask for help in open source development
• NEON and SSE can be used in packages, but then run time detection needs to be implemented
• adding unit tests for alg.c will make it more maintainable.

My insights (so far) during this whole exercise are:

• the most gain in CPU utilization is won by a totally different strategy, which motion already allows for: reduce network cam decoding resource needs by using a lowres stream for motion detection and a highres stream for motion recording (passthrough).
• code optimization will be most beneficial for battery powered applications (like wildlife cams). These tend to use ARM. They usually do not need to decode, since the cam module is integrated in the device.
• for scalabilty (more and more cameras), motion detection integrated into the cameras themselves is better.

Yes I see benefits and improvements. notorca's branch would be the start for that.

[usernamepi]

@tosiara I noticed that the fork from notorca is gone.
I guess I need to do some more manual work then, or is there a better way ? (I'm relatively new to github).

[usernamepi]

@tosiara Hmmm, notorca's work can be found in your fork of course ... sorry for interrupting you.

[notorca]

Hi guys! I’m not using this project anymore, but ping me if you need any help.

[usernamepi]

Will do, thanks for the good work!