[Rd] Performance issues with R2.15.1 built from source on Solaris
Is this a SPARC system? On at least some SPARC systems, the "long double" type in C is implemented very slowly in software, and it seems that it is used for the sums done when calculating standard deviations with "sd". Radford Neal > Date: Wed, 8 Aug 2012 18:55:37 -0500 > From: "Eberle, Anthony" > To: > Subject: [Rd] Performance issues with R2.15.1 built from source on > Solaris? > I have a question about building R (2.15.1) from source on a Solaris 10 > 64bit virtual server with 2 cores and 16GB memory that is running on an > Oracle T4 server. Based on several tests I have done this configuration > has been several orders of magnitude slower than any other configuration > I've tested. > > A simple test of some code to calculate the standard deviation 1 > times (simple code to consume resources) takes on average 121.498 > seconds on the Solaris server where the next worst system (Redhat Linux) > takes 1.567 seconds: __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Performance issues with R2.15.1 built from source on Solaris
Yes, the T4 physical host that the zone is configured on is SPARC. Are you saying that this is a function of the hardware or would possibly updating to a newer version of gcc help? I'm actually going to see if I can build a newer version of gcc anyway just to eliminate that variable. I picked the "sd" and "R-Benchmark" tests as I am new to R and functioning more as an administrator than a modeler or statistical engineer. I too have seen that some operations do perform better on certain systems than others. This makes sense as I know different hardware and CPU's are better at some things than others. However I'm not familiar enough with R yet to know what the functions are doing under the hood and which would be more performing on what hardware. However I will try to check into the specs for the T4 and see if anything is mentioned about the "long double" or something along these lines. Thanks. Anthony -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Radford Neal Sent: Friday, August 10, 2012 9:49 AM To: r-devel@r-project.org Subject: [Rd] Performance issues with R2.15.1 built from source on Solaris Is this a SPARC system? On at least some SPARC systems, the "long double" type in C is implemented very slowly in software, and it seems that it is used for the sums done when calculating standard deviations with "sd". Radford Neal > Date: Wed, 8 Aug 2012 18:55:37 -0500 > From: "Eberle, Anthony" > To: > Subject: [Rd] Performance issues with R2.15.1 built from source on > Solaris? > I have a question about building R (2.15.1) from source on a Solaris > 10 64bit virtual server with 2 cores and 16GB memory that is running > on an Oracle T4 server. Based on several tests I have done this > configuration has been several orders of magnitude slower than any > other configuration I've tested. > > A simple test of some code to calculate the standard deviation 1 > times (simple code to consume resources) takes on average 121.498 > seconds on the Solaris server where the next worst system (Redhat > Linux) takes 1.567 seconds: __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] debug vs regular mode
On 08/10/2012 12:04 PM, peter dalgaard wrote: Not to spoil your fun, but this is getting a bit off-topic for R-help. If you wish to continue the debugging process in public, I think you should move to R-devel. Also, it sounds like the problem is in the glmulti package, so you might want to involve its maintainer at some point. actually valgrind complains a lot about rJava, though that can be confusing; the example reproduces, so amenable to investigation. glmulti doesn't have C code and the only unusual dependency is rJava > sessionInfo() R version 2.15.1 Patched (2012-06-22 r59603) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] glmulti_1.0.4 rJava_0.9-3 Here's the stack trace starting a little below the top #21190 0x778b3b88 in Rf_usemethod (generic=0x9f0c80 "terms", obj=0xbcd040, call=0xbf6fb0, args=0x604d18, rho=0xbd9e70, callrho=0xbf88e8, defrho=0x1a873f0, ans=0x7fffb1a8) at /home/mtmorgan/src/R-2-15-branch/src/main/objects.c:339 339 *ans = applyMethod(t, sxp, matchedarg, rho, newrho); (gdb) #21189 0x778b3009 in applyMethod (call=0xbca188, op=0xbf67f0, args=0xbdad30, rho=0xbd9e70, newrho=0xbca118) at /home/mtmorgan/src/R-2-15-branch/src/main/objects.c:125 125 ans = applyClosure(call, op, args, rho, newrho); (gdb) #21188 0x7784c574 in Rf_applyClosure (call=0xbca188, op=0xbf67f0, arglist=0xbdad30, rho=0xbd9e70, suppliedenv=0xbca118) at /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:859 859 PROTECT(tmp = eval(body, newrho)); (gdb) #21187 0x7784b4b5 in Rf_eval (e=0xbf52e0, rho=0xbc8f30) at /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:466 466 tmp = PRIMFUN(op) (e, op, CDR(e), rho); (gdb) #21186 0x7784e12d in do_begin (call=0xbf52e0, op=0x610710, args=0xbee388, rho=0xbc8f30) at /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:1413 1413s = eval(CAR(args), rho); (gdb) #21185 0x7784b4b5 in Rf_eval (e=0xbee3c0, rho=0xbc8f30) at /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:466 466 tmp = PRIMFUN(op) (e, op, CDR(e), rho); (gdb) #21184 0x7784ef32 in do_set (call=0xbee3c0, op=0x610908, args=0xbedbc8, rho=0xbc8f30) at /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:1715 1715s = eval(CADR(args), rho); (gdb) #21183 0x7784b4b5 in Rf_eval (e=0xbedc70, rho=0xbc8f30) at /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:466 466 tmp = PRIMFUN(op) (e, op, CDR(e), rho); (gdb) #21182 0x778b2979 in do_internal (call=0xbedc70, op=0x611620, args=0xbc9518, env=0xbc8f30) at /home/mtmorgan/src/R-2-15-branch/src/main/names.c:1228 1228ans = PRIMFUN(INTERNAL(fun)) (s, INTERNAL(fun), args, env); (gdb) #21181 0x778acdea in do_termsform (call=0xbedf48, op=0x6329f0, args=0xbc9518, rho=0xbc8f30) at /home/mtmorgan/src/R-2-15-branch/src/main/model.c:838 838 PROTECT(formula = EncodeVars(CAR(args))); (gdb) #21180 0x778ac4e6 in EncodeVars (formula=0xbcd040) at /home/mtmorgan/src/R-2-15-branch/src/main/model.c:629 629 return EncodeVars(CADDR(formula)); (gdb) #21179 0x778ac5c5 in EncodeVars (formula=0xbcd2a8) at /home/mtmorgan/src/R-2-15-branch/src/main/model.c:641 641 return CrossTerms(CADR(formula), CADDR(formula)); (gdb) #21178 0x778abafb in CrossTerms (left=0xbcd318, right=0xd7e338) at /home/mtmorgan/src/R-2-15-branch/src/main/model.c:459 459 PROTECT(left = EncodeVars(left)); (gdb) #21177 0x778ac5c5 in EncodeVars (formula=0xbcd318) at /home/mtmorgan/src/R-2-15-branch/src/main/model.c:641 641 return CrossTerms(CADR(formula), CADDR(formula)); (gdb) #21176 0x778abc24 in CrossTerms (left=0xbc5558, right=0x16b6e78) at /home/mtmorgan/src/R-2-15-branch/src/main/model.c:471 471 return TrimRepeats(left); (gdb) #21175 0x778ab934 in TrimRepeats (list=0xbc5558) at /home/mtmorgan/src/R-2-15-branch/src/main/model.c:404 404 SETCDR(list, TrimRepeats(StripTerm(CAR(list), CDR(list; (gdb) #21174 0x778ab88d in StripTerm (term=0x121c1d8, list=0xbc5590) at /home/mtmorgan/src/R-2-15-branch/src/main/model.c:385 385 tail = StripTerm(term, CDR(list)); and so on down to the bottom valgrind says this ==14352== Invalid write of size 4 ==14352==at 0xD4BC2BD: ??? ==14352==by 0xD4AC437: ??? ==14352==by 0xBDE21AE: JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==14352==by 0xBDE1A44: JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==14352==by 0xBDA5A7E: instanceKlass::call_class_initia
Re: [Rd] [R] debug vs regular mode
On Aug 10, 2012, at 4:08 PM, Martin Morgan wrote:
> On 08/10/2012 12:04 PM, peter dalgaard wrote:
>> Not to spoil your fun, but this is getting a bit off-topic for R-help. If
>> you wish to continue the debugging process in public, I think you should
>> move to R-devel.
>>
>> Also, it sounds like the problem is in the glmulti package, so you might
>> want to involve its maintainer at some point.
>
>
>
> actually valgrind complains a lot about rJava, though that can be confusing;
> the example reproduces, so amenable to investigation. glmulti doesn't have C
> code and the only unusual dependency is rJava
>
Actually, this crashes is vanilla R (given low enough stack limit, e.g. ulimit
-s 1024) - simply try
terms(as.formula("h~ X1*X2*X3*X4*X5*X6*X7*X8*X9*X10*X11*X12*X13*X14*X15*X16"))
which is what the code below runs. The problem is that it causes a very deep
recursion so depending on the stack it will fail (interestingly, it will
segfault in the call to R_CheckStack which is paradoxical :)). I think the
proper fix would be to use iteration in StripTerm instead of recursion ...
Cheers,
Simon
FWIW Java is in general not easily traceable through valgrind, unfortunately,
because it uses a lot of dirty tricks like JIT and other things. There are some
hints in the valgrind FAQ 3.4, though.
> > sessionInfo()
> R version 2.15.1 Patched (2012-06-22 r59603)
> Platform: x86_64-unknown-linux-gnu (64-bit)
>
> locale:
> [1] en_US.UTF-8
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] glmulti_1.0.4 rJava_0.9-3
>
>
> Here's the stack trace starting a little below the top
>
> #21190 0x778b3b88 in Rf_usemethod (generic=0x9f0c80 "terms",
> obj=0xbcd040, call=0xbf6fb0, args=0x604d18, rho=0xbd9e70, callrho=0xbf88e8,
> defrho=0x1a873f0,
>ans=0x7fffb1a8) at
> /home/mtmorgan/src/R-2-15-branch/src/main/objects.c:339
> 339 *ans = applyMethod(t, sxp, matchedarg, rho, newrho);
> (gdb)
> #21189 0x778b3009 in applyMethod (call=0xbca188, op=0xbf67f0,
> args=0xbdad30, rho=0xbd9e70, newrho=0xbca118) at
> /home/mtmorgan/src/R-2-15-branch/src/main/objects.c:125
> 125 ans = applyClosure(call, op, args, rho, newrho);
> (gdb)
> #21188 0x7784c574 in Rf_applyClosure (call=0xbca188, op=0xbf67f0,
> arglist=0xbdad30, rho=0xbd9e70, suppliedenv=0xbca118)
>at /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:859
> 859 PROTECT(tmp = eval(body, newrho));
> (gdb)
> #21187 0x7784b4b5 in Rf_eval (e=0xbf52e0, rho=0xbc8f30) at
> /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:466
> 466 tmp = PRIMFUN(op) (e, op, CDR(e), rho);
> (gdb)
> #21186 0x7784e12d in do_begin (call=0xbf52e0, op=0x610710,
> args=0xbee388, rho=0xbc8f30) at
> /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:1413
> 1413 s = eval(CAR(args), rho);
> (gdb)
> #21185 0x7784b4b5 in Rf_eval (e=0xbee3c0, rho=0xbc8f30) at
> /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:466
> 466 tmp = PRIMFUN(op) (e, op, CDR(e), rho);
> (gdb)
> #21184 0x7784ef32 in do_set (call=0xbee3c0, op=0x610908,
> args=0xbedbc8, rho=0xbc8f30) at
> /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:1715
> 1715 s = eval(CADR(args), rho);
> (gdb)
> #21183 0x7784b4b5 in Rf_eval (e=0xbedc70, rho=0xbc8f30) at
> /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:466
> 466 tmp = PRIMFUN(op) (e, op, CDR(e), rho);
> (gdb)
> #21182 0x778b2979 in do_internal (call=0xbedc70, op=0x611620,
> args=0xbc9518, env=0xbc8f30) at
> /home/mtmorgan/src/R-2-15-branch/src/main/names.c:1228
> 1228 ans = PRIMFUN(INTERNAL(fun)) (s, INTERNAL(fun), args, env);
> (gdb)
> #21181 0x778acdea in do_termsform (call=0xbedf48, op=0x6329f0,
> args=0xbc9518, rho=0xbc8f30) at
> /home/mtmorgan/src/R-2-15-branch/src/main/model.c:838
> 838 PROTECT(formula = EncodeVars(CAR(args)));
> (gdb)
> #21180 0x778ac4e6 in EncodeVars (formula=0xbcd040) at
> /home/mtmorgan/src/R-2-15-branch/src/main/model.c:629
> 629 return EncodeVars(CADDR(formula));
> (gdb)
> #21179 0x778ac5c5 in EncodeVars (formula=0xbcd2a8) at
> /home/mtmorgan/src/R-2-15-branch/src/main/model.c:641
> 641 return CrossTerms(CADR(formula), CADDR(formula));
> (gdb)
> #21178 0x778abafb in CrossTerms (left=0xbcd318, right=0xd7e338) at
> /home/mtmorgan/src/R-2-15-branch/src/main/model.c:459
> 459 PROTECT(left = EncodeVars(left));
> (gdb)
> #21177 0x778ac5c5 in EncodeVars (formula=0xbcd318) at
> /home/mtmorgan/src/R-2-15-branch/src/main/model.c:641
> 641 return CrossTerms(CADR(formula), CADDR(formula));
> (gdb)
> #21176 0x778abc24 in CrossTerms (left=0xbc5558, right=0x16b6e78) at
> /home/mtmorgan/src/R-2-15-branch/src/main/model.c:471
> 471 return TrimRepeats(left);
> (gdb)
> #21175 0x7
Re: [Rd] [R] debug vs regular mode
Hi Simon,
That could be the explanation. Is it possible to know stack limit for
different scenarios? For example, if one simply wrap
terms(as.formula("h~ X1*X2*X3*X4*X5*X6*X7*X8*X9*X10*X11*X12*X13*X14*X15*X16"))
in test = function() { terms(as.formula("h~
X1*X2*X3*X4*X5*X6*X7*X8*X9*X10*X11*X12*X13*X14*X15*X16"))
}
It won't cause the problem in the debug mode. Only in the bug report I filed
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15013 it becomes the
problem.
Knowing the limit for different running environment: R vinila, different debug
modes, would help to understand it.
Best,
Peng
On 08/10/2012 05:16 PM, Simon Urbanek wrote:
> On Aug 10, 2012, at 4:08 PM, Martin Morgan wrote:
>
>> On 08/10/2012 12:04 PM, peter dalgaard wrote:
>>> Not to spoil your fun, but this is getting a bit off-topic for R-help. If
>>> you wish to continue the debugging process in public, I think you should
>>> move to R-devel.
>>>
>>> Also, it sounds like the problem is in the glmulti package, so you might
>>> want to involve its maintainer at some point.
>>
>>
>> actually valgrind complains a lot about rJava, though that can be confusing;
>> the example reproduces, so amenable to investigation. glmulti doesn't have C
>> code and the only unusual dependency is rJava
>>
>
> Actually, this crashes is vanilla R (given low enough stack limit, e.g.
> ulimit -s 1024) - simply try
>
> terms(as.formula("h~ X1*X2*X3*X4*X5*X6*X7*X8*X9*X10*X11*X12*X13*X14*X15*X16"))
>
> which is what the code below runs. The problem is that it causes a very deep
> recursion so depending on the stack it will fail (interestingly, it will
> segfault in the call to R_CheckStack which is paradoxical :)). I think the
> proper fix would be to use iteration in StripTerm instead of recursion ...
>
> Cheers,
> Simon
>
> FWIW Java is in general not easily traceable through valgrind, unfortunately,
> because it uses a lot of dirty tricks like JIT and other things. There are
> some hints in the valgrind FAQ 3.4, though.
>
>
>>> sessionInfo()
>> R version 2.15.1 Patched (2012-06-22 r59603)
>> Platform: x86_64-unknown-linux-gnu (64-bit)
>>
>> locale:
>> [1] en_US.UTF-8
>>
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>>
>> other attached packages:
>> [1] glmulti_1.0.4 rJava_0.9-3
>>
>>
>> Here's the stack trace starting a little below the top
>>
>> #21190 0x778b3b88 in Rf_usemethod (generic=0x9f0c80 "terms",
>> obj=0xbcd040, call=0xbf6fb0, args=0x604d18, rho=0xbd9e70, callrho=0xbf88e8,
>> defrho=0x1a873f0,
>> ans=0x7fffb1a8) at
>> /home/mtmorgan/src/R-2-15-branch/src/main/objects.c:339
>> 339 *ans = applyMethod(t, sxp, matchedarg, rho, newrho);
>> (gdb)
>> #21189 0x778b3009 in applyMethod (call=0xbca188, op=0xbf67f0,
>> args=0xbdad30, rho=0xbd9e70, newrho=0xbca118) at
>> /home/mtmorgan/src/R-2-15-branch/src/main/objects.c:125
>> 125 ans = applyClosure(call, op, args, rho, newrho);
>> (gdb)
>> #21188 0x7784c574 in Rf_applyClosure (call=0xbca188, op=0xbf67f0,
>> arglist=0xbdad30, rho=0xbd9e70, suppliedenv=0xbca118)
>> at /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:859
>> 859 PROTECT(tmp = eval(body, newrho));
>> (gdb)
>> #21187 0x7784b4b5 in Rf_eval (e=0xbf52e0, rho=0xbc8f30) at
>> /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:466
>> 466 tmp = PRIMFUN(op) (e, op, CDR(e), rho);
>> (gdb)
>> #21186 0x7784e12d in do_begin (call=0xbf52e0, op=0x610710,
>> args=0xbee388, rho=0xbc8f30) at
>> /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:1413
>> 1413 s = eval(CAR(args), rho);
>> (gdb)
>> #21185 0x7784b4b5 in Rf_eval (e=0xbee3c0, rho=0xbc8f30) at
>> /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:466
>> 466 tmp = PRIMFUN(op) (e, op, CDR(e), rho);
>> (gdb)
>> #21184 0x7784ef32 in do_set (call=0xbee3c0, op=0x610908,
>> args=0xbedbc8, rho=0xbc8f30) at
>> /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:1715
>> 1715 s = eval(CADR(args), rho);
>> (gdb)
>> #21183 0x7784b4b5 in Rf_eval (e=0xbedc70, rho=0xbc8f30) at
>> /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:466
>> 466 tmp = PRIMFUN(op) (e, op, CDR(e), rho);
>> (gdb)
>> #21182 0x778b2979 in do_internal (call=0xbedc70, op=0x611620,
>> args=0xbc9518, env=0xbc8f30) at
>> /home/mtmorgan/src/R-2-15-branch/src/main/names.c:1228
>> 1228 ans = PRIMFUN(INTERNAL(fun)) (s, INTERNAL(fun), args, env);
>> (gdb)
>> #21181 0x778acdea in do_termsform (call=0xbedf48, op=0x6329f0,
>> args=0xbc9518, rho=0xbc8f30) at
>> /home/mtmorgan/src/R-2-15-branch/src/main/model.c:838
>> 838 PROTECT(formula = EncodeVars(CAR(args)));
>> (gdb)
>> #21180 0x778ac4e6 in EncodeVars (formula=0xbcd040) at
>> /home/mtmorgan/src/R-2-15-branch/src/main/model.c:629
>> 629 return EncodeVars(CADDR(formula));
>> (gdb)
>> #21179 0x778ac5c5 in
Re: [Rd] [R] debug vs regular mode
On Aug 10, 2012, at 7:08 PM, Zhang, Peng wrote:
> Hi Simon,
>
> That could be the explanation. Is it possible to know stack limit for
> different scenarios?
The limit is the same - what changes is the stack usage (how deep you are at
that point). Note, however, that it's irrelevant since the new code in R-devel
doesn't use the stack anymore.
Cheers,
Simon
> For example, if one simply wrap
>
> terms(as.formula("h~
> X1*X2*X3*X4*X5*X6*X7*X8*X9*X10*X11*X12*X13*X14*X15*X16")) in test =
> function() { terms(as.formula("h~
> X1*X2*X3*X4*X5*X6*X7*X8*X9*X10*X11*X12*X13*X14*X15*X16"))
> }
>
> It won't cause the problem in the debug mode. Only in the bug report I filed
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15013 it becomes the
> problem.
>
> Knowing the limit for different running environment: R vinila, different
> debug modes, would help to understand it.
>
> Best,
> Peng
>
> On 08/10/2012 05:16 PM, Simon Urbanek wrote:
>> On Aug 10, 2012, at 4:08 PM, Martin Morgan wrote:
>>
>>> On 08/10/2012 12:04 PM, peter dalgaard wrote:
Not to spoil your fun, but this is getting a bit off-topic for R-help. If
you wish to continue the debugging process in public, I think you should
move to R-devel.
Also, it sounds like the problem is in the glmulti package, so you might
want to involve its maintainer at some point.
>>>
>>>
>>> actually valgrind complains a lot about rJava, though that can be
>>> confusing; the example reproduces, so amenable to investigation. glmulti
>>> doesn't have C code and the only unusual dependency is rJava
>>>
>>
>> Actually, this crashes is vanilla R (given low enough stack limit, e.g.
>> ulimit -s 1024) - simply try
>>
>> terms(as.formula("h~
>> X1*X2*X3*X4*X5*X6*X7*X8*X9*X10*X11*X12*X13*X14*X15*X16"))
>>
>> which is what the code below runs. The problem is that it causes a very deep
>> recursion so depending on the stack it will fail (interestingly, it will
>> segfault in the call to R_CheckStack which is paradoxical :)). I think the
>> proper fix would be to use iteration in StripTerm instead of recursion ...
>>
>> Cheers,
>> Simon
>>
>> FWIW Java is in general not easily traceable through valgrind,
>> unfortunately, because it uses a lot of dirty tricks like JIT and other
>> things. There are some hints in the valgrind FAQ 3.4, though.
>>
>>
sessionInfo()
>>> R version 2.15.1 Patched (2012-06-22 r59603)
>>> Platform: x86_64-unknown-linux-gnu (64-bit)
>>>
>>> locale:
>>> [1] en_US.UTF-8
>>>
>>> attached base packages:
>>> [1] stats graphics grDevices utils datasets methods base
>>>
>>> other attached packages:
>>> [1] glmulti_1.0.4 rJava_0.9-3
>>>
>>>
>>> Here's the stack trace starting a little below the top
>>>
>>> #21190 0x778b3b88 in Rf_usemethod (generic=0x9f0c80 "terms",
>>> obj=0xbcd040, call=0xbf6fb0, args=0x604d18, rho=0xbd9e70, callrho=0xbf88e8,
>>> defrho=0x1a873f0,
>>>ans=0x7fffb1a8) at
>>> /home/mtmorgan/src/R-2-15-branch/src/main/objects.c:339
>>> 339 *ans = applyMethod(t, sxp, matchedarg, rho, newrho);
>>> (gdb)
>>> #21189 0x778b3009 in applyMethod (call=0xbca188, op=0xbf67f0,
>>> args=0xbdad30, rho=0xbd9e70, newrho=0xbca118) at
>>> /home/mtmorgan/src/R-2-15-branch/src/main/objects.c:125
>>> 125 ans = applyClosure(call, op, args, rho, newrho);
>>> (gdb)
>>> #21188 0x7784c574 in Rf_applyClosure (call=0xbca188, op=0xbf67f0,
>>> arglist=0xbdad30, rho=0xbd9e70, suppliedenv=0xbca118)
>>>at /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:859
>>> 859 PROTECT(tmp = eval(body, newrho));
>>> (gdb)
>>> #21187 0x7784b4b5 in Rf_eval (e=0xbf52e0, rho=0xbc8f30) at
>>> /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:466
>>> 466 tmp = PRIMFUN(op) (e, op, CDR(e), rho);
>>> (gdb)
>>> #21186 0x7784e12d in do_begin (call=0xbf52e0, op=0x610710,
>>> args=0xbee388, rho=0xbc8f30) at
>>> /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:1413
>>> 1413s = eval(CAR(args), rho);
>>> (gdb)
>>> #21185 0x7784b4b5 in Rf_eval (e=0xbee3c0, rho=0xbc8f30) at
>>> /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:466
>>> 466 tmp = PRIMFUN(op) (e, op, CDR(e), rho);
>>> (gdb)
>>> #21184 0x7784ef32 in do_set (call=0xbee3c0, op=0x610908,
>>> args=0xbedbc8, rho=0xbc8f30) at
>>> /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:1715
>>> 1715s = eval(CADR(args), rho);
>>> (gdb)
>>> #21183 0x7784b4b5 in Rf_eval (e=0xbedc70, rho=0xbc8f30) at
>>> /home/mtmorgan/src/R-2-15-branch/src/main/eval.c:466
>>> 466 tmp = PRIMFUN(op) (e, op, CDR(e), rho);
>>> (gdb)
>>> #21182 0x778b2979 in do_internal (call=0xbedc70, op=0x611620,
>>> args=0xbc9518, env=0xbc8f30) at
>>> /home/mtmorgan/src/R-2-15-branch/src/main/names.c:1228
>>> 1228ans = PRIMFUN(INTERNAL(fun)) (s, INTERNAL(fun), args, env);
>>> (gdb)
>>> #21181 0x7fff
Re: [Rd] Performance issues with R2.15.1 built from source on Solaris
On 10/08/2012 17:50, Eberle, Anthony wrote: Yes, the T4 physical host that the zone is configured on is SPARC. Are you saying that this is a function of the hardware or would possibly updating to a newer version of gcc help? I'm actually going to see if I can build a newer version of gcc anyway just to eliminate that variable. It is a function of the hardware. You will likely do better (I do on a T2) with the native compiler (Solaris Studio) than any version of gcc on Sparc, but things involving long doubles are going to be slow. However, they are a very small part of a typical mix of R work (if e.g. what CRAN packages do is typical). In any case, I would suggest using a recent version of gcc, as R-patched does not compile with gcc3/g77: we have finally required a more modern Fortran (and there are C things like inlining that require more C99 compliance than gcc3 has). I picked the "sd" and "R-Benchmark" tests as I am new to R and functioning more as an administrator than a modeler or statistical engineer. I too have seen that some operations do perform better on certain systems than others. This makes sense as I know different hardware and CPU's are better at some things than others. However I'm not familiar enough with R yet to know what the functions are doing under the hood and which would be more performing on what hardware. However I will try to check into the specs for the T4 and see if anything is mentioned about the "long double" or something along these lines. Thanks. Anthony -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Radford Neal Sent: Friday, August 10, 2012 9:49 AM To: r-devel@r-project.org Subject: [Rd] Performance issues with R2.15.1 built from source on Solaris Is this a SPARC system? On at least some SPARC systems, the "long double" type in C is implemented very slowly in software, and it seems that it is used for the sums done when calculating standard deviations with "sd". Radford Neal Date: Wed, 8 Aug 2012 18:55:37 -0500 From: "Eberle, Anthony" To: Subject: [Rd] Performance issues with R2.15.1 built from source on Solaris? I have a question about building R (2.15.1) from source on a Solaris 10 64bit virtual server with 2 cores and 16GB memory that is running on an Oracle T4 server. Based on several tests I have done this configuration has been several orders of magnitude slower than any other configuration I've tested. A simple test of some code to calculate the standard deviation 1 times (simple code to consume resources) takes on average 121.498 seconds on the Solaris server where the next worst system (Redhat Linux) takes 1.567 seconds: __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
