Re: [Rd] Package compiler - efficiency problem

[Tomas Kalibera]

Dear Karol,

I don't understand the models behind these function, but I can tell that 
the code generated is very inefficient. The AST interpreter will be very 
inefficient performing each scalar computation with all boxing, 
allocations, function calls. The byte-code compiler removes some of the 
boxing and allocation. While it could certainly compile faster, it will 
always be taking long compiling such functions with so many commands: so 
many expressions to track, so many source references to map, for so 
little computation. The same code could be much more efficient if it 
used vectorized operations and loops. The compiler cannot infer the 
loops and vector operations from the code - it is not that smart and I 
doubt it could easily be for R, but such optimizations could certainly 
be done easily at a higher level, when optimizing computation within the 
model, not within R with all its complicated semantics. I think you 
could hope for ~100x speedups compared to current generated code running 
with R AST interpreter.

So I think it might be worth thinking about writing an interpreter for 
the model (the generator would compute function values on the fly, 
without actually generating code). If that was too slow, it might pay 
off to generate some intermediate representation for the model that 
would be faster to interpret. If that was too hard, then perhaps 
generating the code from the model in a smarter way (use vector 
operations, loops). It is ok to do that opportunistically - only when 
possible. With compilers, this is normal, optimizations often take 
advantage of certain patterns in the code if they are present. If you 
had more specific questions how to optimize the code feel free to ask 
(also offline).

Certainly I don't want the existence of the byte-code compiler to 
require you to switch from R to C/C++, that would be exactly the 
opposite of what the compiler is aiming for. If it turns out you really 
need a way to disable compilation of these generated functions (so they 
run much slower, but you don't have to wait for them to compile), we 
will provide it and using a hack/workaround it is already possible in 
existing versions of R, with all the drawbacks I mentioned previously.

Best
Tomas


On 08/17/2018 12:43 AM, Karol Podemski wrote:
> Dear Thomas,
>
> thank you for prompt response and taking interest in this issue. I 
> really appreciate your compiler project and efficiency gains in usual 
> case. I am aware of limitations of interpreted languages too and 
> because of that even when writing my first mail I had a hunch that it 
> is not that easy to address this problem.  As you mentioned 
> optimisation of compiler for handling non-standard code may be tricky 
> and harmful for usual code. The question is if gEcon is the only 
> package that may face the same issue because of compilation.
>
> The functions generated by gEcon are systems of non-linear equations 
> defining the equilibrium of an economy (see 
> http://gecon.r-forge.r-project.org/files/gEcon-users-guide.pdf if you 
> want to learn a bit how we obtain it). The rows, you suggested to 
> vectorise, are indeed vectorisable because they define equilibrium for 
> similiar markets (e.g. production and sale of beverages and food) but 
> do not have to be vectorisable in general case. So that not to delve 
> into too much details I will stop here in description of how the 
> equations originate. However, I would like to point that similiar 
> large systems of linear equations may arise in other fields ( 
> https://en.wikipedia.org/wiki/Steady_state ) and there may be other 
> packages that generate similar large systems (e.g. network problems 
> like hydraulic networks). In that case, reports such as mine may help 
> you to assess the scale of the problems.
>
> Thank you for suggestions for improvement in our approach, i am going 
> to discuss them with other package developers.
>
> Regards,
> Karol Podemski
>
> pon., 13 sie 2018 o 18:02 Tomas Kalibera  > napisał(a):
>
> Dear Karol,
>
> thank you for the report. I can reproduce that the function from
> you example takes very long to compile and I can see where most
> time is spent. The compiler is itself written in R and requires a
> lot of resources for large functions (foo() has over 16,000 lines
> of code, nearly 1 million of instructions/operands, 45,000
> constants). In particular a lot of time is spent in garbage
> collection and in finding a unique set of constants. Some
> optimizations of the compiler may be possible, but it is unlikely
> that functions this large will compile fast any soon. For
> non-generated code, we now have the byte-compilation on
> installation by default which at least removes the compile
> overhead from runtime. Even though the compiler is slow, it is
> important to keep in mind that in principle, with any compiler
> there will be functions where com

Re: [Rd] odd behavior of names

[Tomas Kalibera]

Both bugs should now be fixed in R-devel. The first one was causing the 
difference between the first and the following element. The second one 
was causing the printing of unnecessary backticks, inconsistently with 
Unix systems.


Best
Tomas

On 07/30/2018 09:32 AM, Martin Maechler wrote:

William Dunlap via R-devel
 on Sun, 29 Jul 2018 10:06:40 -0700 writes:

 > Bugzilla issue 16101 describes another
 > first-list-name-printed-differently oddity with
 > the Windows GUI version of R:
   

Indeed:
1) "first-list-name-printed" [i.e "names" only in that
 context of printing]
2) Windows GUI version of R only
   (not 'Rterm', i.e., not in ESS (emacs speaks
   statistics), nor in Rstudio on Windows

Kevin Ushey has reported this last week in an official (and
perfect) bug report to R's bugzilla bug reporting site:

  https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17447

 Bug ID: 17447
Summary: list() prints first variable name in backticks
   
  Component: Windows GUI / Window specific
   Reporter: kevinushey ..  gmail ..

His minimal REPREX was even much simpler:

> list(a = 1, b = 2)
 $`a`
 [1] 1

 $b
 [1] 2


Thank you, Bill, for the nice extra example.

Martin Maechler
ETH Zurich and R Core Team






a <- "One is \u043E\u0434\u0438\u043D\nTwo is \u0434\u0432\u0430\n"
Encoding(a) # expect "UTF-8"

[1] "UTF-8"

sapply(strsplit(a, "\n")[[1]], charToRaw)[c(1,1,2)]

$`One is один`
  [1] 4f 6e 65 20 69 73 20 d0 be d0 b4 d0
[13] b8 d0 bd

$`One is `
  [1] 4f 6e 65 20 69 73 20 d0 be d0 b4 d0
[13] b8 d0 bd

$`Two is `
  [1] 54 77 6f 20 69 73 20 d0 b4 d0 b2 d0
[13] b0


names(.Last.value)

[1] "One is один" "One is один"
[3] "Two is два"



Bill Dunlap
TIBCO Software
wdunlap tibco.com

[..]

__
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

[Rd] Get Logical processor count correctly whether NUMA is enabled or disabled

[Srinivasan, Arunkumar]

Dear R-devel list,

R's detectCores() function internally calls "ncpus" function to get the total 
number of logical processors. However, this doesnot seem to take NUMA into 
account on Windows machines.

On a machine having 48 processors (24 cores) in total and windows server 2012 
installed, if NUMA is enabled and has 2 nodes (node 0 and node 1 each having 24 
CPUs), then R's detectCores() only detects 24 instead of the total 48. If NUMA 
is disabled, detectCores() returns 48.

Similarly, on a machine with 88 cores (176 processors) and windows server 2012, 
detectCores() with NUMA disabled only returns the maximum value of 64. If NUMA 
is enabled with 4 nodes (44 processors each), then detectCores() will only 
return 44. This is particularly limiting since we cannot get to use all 
processors by enabling/disabling NUMA in this case.

We think this is because R's ncpus.c file uses 
"PSYSTEM_LOGICAL_PROCESSOR_INFORMATION" 
(https://msdn.microsoft.com/en-us/library/windows/desktop/ms683194(v=vs.85).aspx)
 instead of "PSYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX" 
(https://msdn.microsoft.com/en-us/library/windows/desktop/dd405488(v=vs.85).aspx).
 Specifically, quoting from the first link:

"On systems with more than 64 logical processors, the 
GetLogicalProcessorInformation function retrieves logical processor information 
about processors in the 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd405503(v=vs.85).aspx 
to which the calling thread is currently assigned. Use the 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd405488(v=vs.85).aspx 
function to retrieve information about processors in all processor groups on 
the system."

Therefore, it might be possible to get the right count of total processors even 
with NUMA enabled by using "GetLogicalProcessorInformationEX".  It'd be nice to 
know what you think.

Thank you very much,
Arun.

--
Arun Srinivasan
Analyst, Millennium Management LLC 
50 Berkeley Street | London, W1J 8HD


##

The information contained in this communication is confi...{{dropped:30}}

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel