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)
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
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
On 31 March 2016 at 22:15, rosterma at 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 at lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
PS Also look at Writing R Extension for _plain_ R via valgrind. Then do
cat("hello, world\n"); q("no")
and see what Valgrind reports. That is the second part of the baseline.
Dirk