-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathMachineSummary.Rmd
182 lines (126 loc) · 4.96 KB
/
MachineSummary.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
---
title: "A Machine Profile Summary"
author:
- John C. Nash, University of Ottawa, Canada
date: "14/06/2021"
bibliography: ImproveNLS.bib
output:
pdf_document:
keep_tex: false
---
<!-- date: "`r format(Sys.time(), '%d %B, %Y')`" -->
```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = TRUE)
```
# Providing a characterization of a particular computing environment for R calculations
I have looked at this.
If we want to compare results computed on different machines, we need a way to provide
measures and identifiers of the particular computing environment at hand. This document
attempts to summarize some possibilities available in the R statistical software and language.
# Some possible information desired
There are multiple ways to get information of the type useful for characterizing the
computing infrastructure used for a particular test or timing. We will need to
ensure that identifiers of particular pieces of information are unique, and that
common identifiers really do specify identical information. Otherwise, we need
to develop new names for our set of information.
## Temporal information
Most computatins should have a time/date stamp that is unlikely to be confused with any
other, at least in combination with a machine name and/or other tags.
```{r tdstamp}
#get a timestamp
tsstr<- format(Sys.time(), "%Y%m%d%H%M") # tsstr == time stamp string in form YYYYmmddHHMM
cat("Date and Time stamp:",tsstr,"\n")
```
## Identifier for the computing environment
Some of the important information elements concerning the computing environment that
we need for reporting tests are
- machine name. While most systems (and Linux in particular) offer to let the user
provide a machine name, there are generally defaults that many people accept, and
these are often uninformative and may be non-unique. We note that VirtualBox with
a Windows 10 guest machine gave the name DESKTOP-HF4CKVA. Where this name was
generated we are not sure. Settings / System allows "rename this PC".
- operating system and version
- compiler or interpreter version. For our needs, it is obvious that the R version
will be important. However, if any code is compiled or linked to libraries, we
would like to know that. In particular, versions of compilers (e.g., gfortran,
gcc) or BLAS or LAPACK libraries used will affect performance. Linux generally
displays the BLAS and LAPACK **filenames** in `sessionInfo()`, but to get the
version information, one needs to dig deeper, for example, using operating
system commands. For the present, we will omit such extra information unless
we can extract it easily within R.
- specific variations, if any, that should be noted. Here we may want to note if
a machine is running background tasks, or if some special steps have been
taken to speed up or slow down the operation e.g., overclocking.
## Hardware information
Some of the factors relating to hardware that could be important are:
- cpu
- cores
- operating cycle speed (While the cpu is generally specified )
- RAM total
- RAM available, possibly indicating swap space and usage
- RAM speed (could be variable)
## Software information
?? what to put in.
## R tools for machine information
### sessionInfo()
```{r sessionInfox}
si <- sessionInfo()
si <- as.vector(si)
si
```
### benchmarkme
- uses `proc.time()` for timings
- has single core and parallel timings
- ?? does it do GPUs
- provides far too much for most needs i.e., a succinct summary of
how capable a computing system should be
```{r benchmarkmex}
library(benchmarkmeData)
library(benchmarkme)
ls(package:benchmarkmeData)
ls(package:benchmarkme)
lsf.str("package:benchmarkme")
lsf.str("package:benchmarkmeData")
## This next line takes a lot of time to run, so is commented out here
# benchmark_std()
get_byte_compiler()
gla<-get_linear_algebra()
gsd<-get_sys_details()
```
?? get_ram may not work in Windows 10.
### calceps.R
This is a port of Mike Malcolm's ENVRON to R. ??ref. It computes the
machine precision, radix and number of radix digits.
?? get file into chunk
```
calceps.R
- calceps.R example
### Sys.info()
```{r sysinfox}
Sys.info()
```
## Issues relateing to RNG
## Issues relating to compilation of R
- LAPACK
- BLAS
- others?
# Tools for accessing and clearing environments and dataframes
?? should this be here -- probably to list things in the workspace
```
sys.frame()
sys.frames()
sys.status()
sys.on.exit()
sys.parents()
sys.calls()
```
??JN exp(sin(cos())) benchmark
# Choices
For use in recording tests of R functions and packages for optimization and nonlinear
least squares, it seems that the `benchmarkme` function `get_sys_details()`
provides more than sufficient information for our needs.
From the above discussion, the following offers a possible compact solution.
```{r code=xfun::read_utf8('MachID.R')}
```
Note that we are reading from the file `MachID.R` so that this file is usable elsewhere
and the current document does not become out of sync with the working MachID.