slower_than_mallocfree is failed with Release build type. about playrho HOT 5 CLOSED

Thank you for reporting this.

Is there any chance that you are using any flags or environment variables or anything else that might make the standard library malloc and/or free routines monitored in any way, shape, or form for things like using free'd memory or writing beyond the memory allocated?

I'll investigate this in the meantime with the assumption that you're not using anything like this.

from playrho.

As for me I'm not using any specific environment variables. But anyway I'll post there all my env variables:

GREP_COLOR=1;33
KDE_MULTIHEAD=false
GS_LIB=/home/megaxela/.fonts
KDE_FULL_SESSION=true
BASH_IT_THEME=powerline
BASH_IT=/home/megaxela/Development/Tools/bash-it
LANG=en_US.UTF-8
HISTCONTROL=ignorespace:erasedups
TODO=t
DISPLAY=:0
PROFILEHOME=
SHELL_SESSION_ID=3c16b89ecc13419abadc4318a45beb11
COLORTERM=truecolor
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
XDG_VTNR=1
QT_QUICK_CONTROLS_STYLE=org.kde.desktop
[email protected]
SCM_CHECK=true
XDG_SESSION_ID=c2
USER=megaxela
LSCOLORS=Gxfxcxdxdxegedabagacad
DESKTOP_SESSION=/usr/share/xsessions/plasma
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/megaxela/.gtkrc-2.0:/home/megaxela/.config/gtkrc-2.0
PWD=/home/megaxela/Development/Build/PlayRho/build/UnitTests
HOME=/home/megaxela
XDG_SESSION_TYPE=x11
XDG_DATA_DIRS=/usr/share:/usr/share:/usr/local/share
KONSOLE_DBUS_SESSION=/Sessions/2
XDG_SESSION_DESKTOP=KDE
GTK_MODULES=canberra-gtk-module
MAIL=/var/spool/mail/megaxela
TERM=xterm-256color
SHELL=/bin/bash
KONSOLE_DBUS_SERVICE=:1.25
XDG_SESSION_CLASS=user
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XCURSOR_THEME=breeze_cursors
XDG_CURRENT_DESKTOP=KDE
KONSOLE_PROFILE_NAME=Default
AUTOFEATURE=true autotest
XDG_SEAT=seat0
COLORFGBG=15;0
SHLVL=2
LANGUAGE=
IRC_CLIENT=irssi
GTK_RC_FILES=/etc/gtk/gtkrc:/home/megaxela/.gtkrc:/home/megaxela/.config/gtkrc
WINDOWID=33554438
LOGNAME=megaxela
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
XDG_RUNTIME_DIR=/run/user/1000
XAUTHORITY=/tmp/xauth-1000-_0
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
QT_AUTO_SCREEN_SCALE_FACTOR=0
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
KDE_SESSION_UID=1000
KDE_SESSION_VERSION=5
HISTSIZE=5000
SESSION_MANAGER=local/ArchLinuxLaptop:@/tmp/.ICE-unix/643,unix/ArchLinuxLaptop:/tmp/.ICE-unix/643
_=/usr/bin/printenv
OLDPWD=/home/megaxela/Development/Build/PlayRho/build

Also I checked UnitTests executable with valgrind and I didn't get any memory errors. But with valgrind enabled I'm getting this slower_than_mallocfree test result:

Expected: (elapsed_secs_custom.count()) > (elapsed_secs_malloc.count()), actual: 75.9262 vs 300.953

from playrho.

I see this is reproducible on Travis-CI too now that I added this unit test back into the CI build:

[ RUN      ] StackAllocator.slower_than_mallocfree
/home/travis/build/louis-langholtz/PlayRho/UnitTests/StackAllocator.cpp:95: Failure
Expected: (elapsed_secs_custom.count()) > (elapsed_secs_malloc.count()), actual: 1.9401 vs 6.82618
[  FAILED  ] StackAllocator.slower_than_mallocfree (8767 ms)

Note that I've seen this fail before with debug builds which may include a lot more debugging checks in the standard library malloc so I'm not concerned about this test failing in debug builds. It does however concern me that this is failing in release builds.

I've made some implementation choices based on picking what operates faster. In this case, I've seen the custom StackAllocator being slower than malloc. I added this unit test to continually confirm this observation and across different compilers and platforms. Unfortunately I also wound up disabling this unit test from being run on the release builds (in Travis-CI).

Anyways, seems there's more to this question of what's faster - like why would the stack allocator actually ever be slower. The addition of the benchmark application to this project repo provides another tool to get more insight now into this. Another detail to the stack allocator is memory alignment which I don't believe was addressed in the original stack allocator from Erin's code and really needs to be looked into as well. If the stack allocator is six times faster than malloc et al. but the memory is misaligned on an architecture that incurs slowdowns then that could prove worse performance ultimately.

from playrho.

I checked out StackAllocator in Erin's code and your one. Erin's allocator is not using any alignment, as I see your allocator using alignment on std::max_align_t so by standard it has to be the same as align value that used by malloc. As for me only reason why stack allocator is faster than malloc for now because of linear data access, against random access of malloc version.
I'm using laptop with 12Gb RAM with Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz (2 cores, 4 threads). I will be able run UnitTests on some powerfull production servers with much more RAM and another processor in monday.

from playrho.

I've removed this unit test now (as of commit 31a1fdb ) which of course does away with the problem of it failing.

The data from it was interesting to me but I hadn't designed to really represent any memory access pattern that the library uses. It's also questionable to me whether timing related tests really belong in a unit test suite. The benchmark application seems like a more appropriate place for them.

I'll definitely be visiting performance optimizations but these can wait more till after beta.

from playrho.