When an RPI just isn't enough


#1

I’m installing a piece on Thursday that runs an openFrameworks sketch on a Raspberry Pi. Unfortunately the CPU usage grows significantly over time (sometimes upwards of 94%) and the framerate plummets. Its possible that my code could be optimized, but it is also possible that my 512MB RAM Raspberry Pi just can’t handle it. I am currently overclocking to 900MHZ and have allowed my GPU to access 128MB of RAM. Does anyone have any suggestions, or does oLab/ATS have a possible 2 week loner CPU (its gotta be pretty small) with more power?


#2

You are copying huge vectors of words like crazy. Return by const ref and your program will run forever.

See the PR.


#3

Also, be careful with overclocking. It’s good way to break sd cards.

Finally, if the const ref thing isn’t enough to get this working on an RPI, there are definitely some memory management things that we could do, namely work out a spatial hash structure for words, rather than iterating through all of the words in an increasingly huge vector every frame.

Any of the nanoflann addons will probably give you good results -

I’d recommend:


#4

There you go.

@kaylalewis @mikewesthad @abrahamavnisan you might also be interested in this trick.


#5

Boy what an & can do. Mem-management is still something that I have to remind myself to do. Thanks a lot @bakercp.


#6

Is it working better on Pi?


#7

@bakercp I see that - in addition to returning a const ref - you also turned his getWords() method into a const method (guaranteeing that getWords() won’t change the Animation object). Was this just a style choice you were suggesting, or are const methods compiled in a different way that allows them to execute faster?


#8

BTW, sometimes C++ compilers can be smart enough to figure out when you don’t want to or need to return a copy using RVO (return value optimization).

This ambiguity is somewhat mitigated by C++11’s new “move semantics”. Currently openFrameworks is not compiled with C++11, but it will be by the end of th year I suspect.


#9

Ultimately neither const was necessary for this speedup. It was returning by reference that was key. But beware – don’t return references to temporary variables … :slight_smile:

Dropping in a const Value& getStuff() return value is always a safe replacement for Value getStuff().

On the other hand, const Value& getStuff() is not a harmless replacement for Value& getStuff() if the caller was relying the the writability of the returned value.

Making a method itself const (placing the const after the method signature) is always a safe replacement.

So ultimately, to answer your actual question … this is primarily a style choice, a user contract, and an extra layer of clarity of API intent. As far as I know, no speed is gained from making a method const.

Here are a few relevant articles:



#10

Great, thanks - that’s what I thought. I knew the ref was eliminating the copying, but I just wanted to make sure some compiler magic wasn’t applied when for const. (And that stackover had this article that tackles that.)


#11

@bakercp it is working much better. Still testing to see if the changes are “good enough”. Framerate after about 60% of completion (13hrs) is hovering around 4fps. I need about 4-6fps.

Great const & explanation by the way. I’ve been reading Arturo’s Memory chapter in ofBook, it is very helpful as well.


#12

Also - just notes to myself for tomorrow:

  • Rendered texture tiles
  • Spatial hash
  • lru cache
  • mixture of above