On 31 March 2016 at 22:15, roste...@abo.fi wrote: | I have been working on connections between R and my computational | platform on Linux. I have designed a bridge function in C++ using | RInside and the connection seems to work as expected now. However, I | have a question regarding the heap memory usage. | First, take a look at the Valgrind report for a short run without any | R-connections in the executable: | ==13263== Memcheck, a memory error detector | ==13263== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. | ==13263== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info | ==13263== Command: ./supergha stoxx | ==13263== Parent PID: 1 | ==13263== | ==13263== | ==13263== HEAP SUMMARY: | ==13263== in use at exit: 0 bytes in 0 blocks | ==13263== total heap usage: 81,741 allocs, 81,741 frees, 45,942,809 | bytes allocated | ==13263== | ==13263== All heap blocks were freed -- no leaks are possible | ==13263== | ==13263== For counts of detected and suppressed errors, rerun with: -v | ==13263== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
You have to show us the code for the 'null model' here. | Next, take a look at the Valgrind report with exactly the same run, but | with <RInside.h> included in a h-file. Furthermore, I define a C++ class I am afraid that this is not a valid baseline. As I attempted to explain previously, embedding R entails embedding an entire interpreter with its own memory management and memory pool. A proper baseline comparison might start by following "Writing R Extensions" and to see how to embed R 'by hand' in C/C++ executable. _That_ version could then be compared to RInside to assert whether or not RInside has _additional_ allocations. Dirk | for the communication between C++ and R in the same h-file. However, | this class is never used in the program. The only thing connecting the | program to R is the preprocessor directive #include <RInside.h>. No | R-computations at all. No new allocations in the code. No embedded R-calls: | | ==13875== Memcheck, a memory error detector | ==13875== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. | ==13875== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info | ==13875== Command: ./supergha stoxx | ==13875== Parent PID: 1 | ==13875== | ==13875== | ==13875== HEAP SUMMARY: | ==13875== in use at exit: 8 bytes in 1 blocks | ==13875== total heap usage: 81,767 allocs, 81,766 frees, 45,986,922 | bytes allocated | ==13875== | ==13875== 8 bytes in 1 blocks are still reachable in loss record 1 of 1 | ==13875== at 0x4A06A2E: malloc (vg_replace_malloc.c:270) | ==13875== by 0x33B08042B8: ??? (in /usr/lib64/libgomp.so.1.0.0) | ==13875== by 0x33B080ED1A: ??? (in /usr/lib64/libgomp.so.1.0.0) | ==13875== by 0x33B0805452: ??? (in /usr/lib64/libgomp.so.1.0.0) | ==13875== by 0x33B0810A25: ??? (in /usr/lib64/libgomp.so.1.0.0) | ==13875== by 0x33B0803E62: ??? (in /usr/lib64/libgomp.so.1.0.0) | ==13875== by 0x7FF000449: ??? | ==13875== by 0x78786F7473006167: ??? | ==13875== by 0x6F723D52455354FF: ??? | ==13875== by 0x4C00616D72657472: ??? | ==13875== by 0x723D454D414E474E: ??? | ==13875== by 0x616D726574736E: ??? | ==13875== | ==13875== LEAK SUMMARY: | ==13875== definitely lost: 0 bytes in 0 blocks | ==13875== indirectly lost: 0 bytes in 0 blocks | ==13875== possibly lost: 0 bytes in 0 blocks | ==13875== still reachable: 8 bytes in 1 blocks | ==13875== suppressed: 0 bytes in 0 blocks | ==13875== | ==13875== For counts of detected and suppressed errors, rerun with: -v | ==13875== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) | /home/aton6/rosterma/research/catsm/super_catsm_R/stoxx_50/valgrind_test> | | Since my platform scales with tens of thousands of parallel processors | as I have demonstrated in numerous papers, I want to be sure that no | heap memory faults are included in the program for example through R | before invoking it in production runs. | | -- | Ralf Östermark | Ph.D(econ), Ph.D(pol) | Professor of Accounting and Optimization Systems | School of Business Economics at | Åbo Akademi University | 20500 Åbo | Finland | _______________________________________________ | Rcpp-devel mailing list | Rcpp-devel@lists.r-forge.r-project.org | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org _______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
