Ajitha Rajan

Adel Noureddine
email: a.noureddine@uel.ac.uk

Panagiotis Stratis

A Study on the Influence of Software and Hardware Features on Program Energy *

Software energy consumption has emerged as a growing concern in recent years. Managing the energy consumed by a software is, however, a difficult challenge due to the large number of factors affecting it -namely, features of the processor, memory, cache, and other hardware components, characteristics of the program and the workload running, OS routines, compiler optimisations, among others. In this paper we study the relevance of numerous architectural and program features (static and dynamic) to the energy consumed by software. The motivation behind the study is to gain an understanding of the features affecting software energy and to provide recommendations on features to optimise for energy efficiency.

In our study we used 58 subject desktop programs, each with their own workload, and from different application domains. We collected over 100 hardware and software metrics, statically and dynamically, using existing tools for program analysis, instrumentation and run time monitoring. We then performed statistical feature selection to extract the features relevant to energy consumption. We discuss potential optimisations for the selected features. We also examine whether the energy-relevant features are different from those known to affect software performance. The features commonly selected in our experiments were execution time, cache accesses, memory instructions, context switches, CPU migrations, and program length (Halstead metric). All of these features are known to affect software performance, in terms of running time, power consumed and latency.

INTRODUCTION

With rising energy costs and the need for environmental improvements, one of the key challenges faced by the ICT industry now and in the coming years will be reducing its carbon footprint and energy consumption while still delivering the performance and quality that users expect. Energy consumption is not only an issue for the mobile embedded systems domain, but also for servers, desktops and laptops which constitute more than a third of ICT energy consumption [START_REF]Network of Excellence in Internet Science. Overview of ict energy consumption[END_REF].

Measuring and managing the energy consumed by a software is, however, a difficult challenge due to the large number of factors affecting energy consumed -namely, characteristics of the processor (clock frequency, voltage, pipeline depth), memory (instruction and data cache reads, writes and misses), communication network, GPU, sensors for mobile devices, compiler and optimisations enabled, features of the program and workload running (number of instructions, input data, number of branches, number of operators and operands, algorithmic complexity, multi-threading) among others. Before we embark on proposing optimisations for software energy consumption, we believe it is imperative to first identify and understand the factors that contribute to energy consumption. Our ultimate goal is to use this understanding to guide techniques in choosing factors to optimise for energy. We would also like to ascertain if the factors affecting software energy are the same as those affecting software performance, in which case there is no need to propose new optimisation techniques specifically targeting energy. Existing optimisation techniques targeting performance may also be adequate for energy.

Existing literature, particularly in the embedded systems domain, has estimated energy consumption based on several architectural features [START_REF] Sinha | JouleTrack-a Web based tool for software energy profiling[END_REF][START_REF] Tan | High-level software energy macro-modeling[END_REF][START_REF] Jeffry | Software power estimation and optimization for high performance, 32-bit embedded processors[END_REF]. Recent literature in the mobile devices domain estimated energy consumption using features related to the application and several other integrated hardware components [START_REF] Li | Calculating source line level energy information for Android applications[END_REF][START_REF] Hao | Estimating mobile application energy consumption using program analysis[END_REF]. The goal in all of these studies has been to profile or estimate energy based on architectural and, in some cases, application features [START_REF] Seo | [END_REF][START_REF] Tan | High-level software energy macro-modeling[END_REF]. Our empirical study does not aim to estimate energy but instead tries to understand the statistical relevance of features, both architectural and program specific when taken together, to energy consumed. We then select the relevant features as targets for energy optimization techniques. The selection technique we use takes interaction between features into account and eliminates redundancy in the selection. Our empirical study has the following salient features

• We collect data on energy consumption and over a hundred features, static and dynamic, related to the architecture and the program. • Our data is collected using 58 subject programs, each with their own workload, from different domains. Many of these programs are part of industry standard benchmarks. • We use a statistical machine learning technique called feature selection to select the features relevant to energy consumption. • We analyse the features selected, discuss their use as potential targets for optimisation and determine if they are different from optimisations proposed for software performance. The feature selection technique we use is the LASSO technique [START_REF] Tibshirani | Regression shrinkage and selection via the lasso[END_REF]. To validate the usefulness of the features selected by Lasso, we compared accuracy of energy predictions using only the selected features against energy predictions from a linear regression model using all the features. We found the features selected in our study were the same as known features in existing optimisations for execution time.

Our paper is organised as follows. Section 2 discusses related work. In Section 3 we describe the experimental setup to gather hardware and software features over different programs. We detail and discuss the results of our experiments in Section 4. We provide more insights into the features selected by our experiments, and the effect of existing optimisations in Section 5. Threats to validity in our experiment and conclusions are presented in Sections 6 and 7.

RELATED WORK

Monitoring and modeling energy consumption of applications has been and still is an active research area. As stated earlier, the goal in our work is not to model or estimate energy but to understand the relevance of many hardware and software features, when taken together, to energy to guide optimisations. Nevertheless, we present relevant literature on energy modeling since that is the most closely related body of work.

Previous work in the embedded systems domain has focussed extensively on estimating power consumed by the processor [START_REF] Tiwari | Instruction level power analysis and optimization of software[END_REF][START_REF] Sinha | JouleTrack-a Web based tool for software energy profiling[END_REF][START_REF] Tan | High-level software energy macro-modeling[END_REF]. The estimations rely on a complete characterisation of the underlying instruction set architecture and inter-instruction effects to estimate power consumption. Cycle-accurate simulators developed to estimate power can simulate the actions of a processor at an architecturelevel [START_REF] Brooks | Wattch: a framework for architectural-level power analysis and optimizations[END_REF][START_REF] Ong | Power-conscious software design-a framework for modeling software on hardware[END_REF][START_REF] Ye | The design and use of simplepower: a cycle-accurate energy estimation tool[END_REF]. They identify the architectural blocks that are active in each clock cycle and record the input operands seen by each architecural block. Power consumption is then estimated for each architectural block as a function of the input data values. Both instruction-level characterisation and cycle-accurate simulator estimation methods are slow, compute-intensive, and infeasible for applications outside the embedded systems domain.

Several tools have been developed to estimate energy using hardware component characteristics. pTop [START_REF] Do | ptop: A process-level power profiling tool[END_REF] estimates energy consumption using a model based on the characteristics of hardware components (such as CPU, hard disk, ethernet). PowerAPI and BitWatts [START_REF] Colmant | Process-level power estimation in vm-based systems[END_REF] use hardware performance counters to learn the energy model of hardware components. They build the model by benchmarking the computer and collecting power measures using a power meter. Jalen [START_REF] Noureddine | Towards a Better Understanding of the Energy Consumption of Software Systems[END_REF] is built on top of PowerAPI's energy models and maps energy estimations to an application's source code. In [START_REF] Seo | [END_REF], Seo et al. estimate energy consumption of distributed Java applications by benchmarking Java byte code and native methods, measuring their energy consumption with a multimeter. Collected results are then used to construct an energy model for Java components and applications.

For mobile devices, integrated hardware components, such as the GPS, screen, or the 3G communication interface, introduce additional complexity into the energy models. Recent literature [START_REF] Pathak | Where is the energy spent inside my app?[END_REF][START_REF] Li | Calculating source line level energy information for Android applications[END_REF][START_REF] Hao | Estimating mobile application energy consumption using program analysis[END_REF] has focussed on energy models for mobile devices. Eprof [START_REF] Pathak | Where is the energy spent inside my app?[END_REF] maps back energy consumption of hardware components to applications by adopting a last-trigger policy. For example, it associates tail energy drains of a hardware component1 to the last application that triggered the usage of that component. Hao et al. [START_REF] Hao | Estimating mobile application energy consumption using program analysis[END_REF] and Li et al. [START_REF] Li | Calculating source line level energy information for Android applications[END_REF] propose an approach called eLens to estimate energy usage at the source code level. They estimate the energy consumption of mobile applications using program analysis and linear regression analysis. Applications are first instrumented to determine paths traversed during execution. This along with instruction energy costs are used to predict source line energy.

EXPERIMENT DESCRIPTION

The experiment we conducted is comprised of two phases, Phase 1: Data Collection -We ran a series of experiments on programs from three different benchmark suites to measure energy consumed and features related to the hardware and program. The benchmarks, features measured, and tools used for measurements are explained in the following sections. Phase 2: Prediction Models -Using the measurements in the data collection phase, we trained our model to select features2 that are relevant to the energy consumed. The statistical feature selection technique we use is Lasso regression and is described in Section 3.4. In order to validate the accuracy and usefulness of the selected features, we also trained and constructed a Linear regression model using all the features. We then compared the energy prediction error of Lasso regression (with the selected features) against that of Linear regression using all the features. Phases 1 and 2 are described in the following sections.

We ran our experiments using a desktop computer powered by an Intel Core 2 Duo E8400 processor at 3 GHz, 2 GB of DDR2 memory at 800 MHz, 128 KB of L1 cache and 6 MB of L2 cache. The machine was running Ubuntu Server 14.04 with Linux kernel 3.16.0.33.

Phase 1 -Data Collection

Benchmarks

The programs in our experiments are from a range of application domains such as image processing, biomolecular simulation, networking, automotive, fluid dynamics, operating system, signal processing among others. The programs perform diverse tasks varying in the type and intensity of computation, file I/O, amount and frequency of memory operations, and several other features. For test cases and benchmarks that run in just a few milliseconds, we run them in a loop (ranging from 1 to 10,000 cycles) to get execution times that are large enough for measurement. Collected data is then averaged for a single program run and compared with the other programs. The programs and benchmark families used in our experiments are as follows.

SIR

We used 9 programs from the SIR (Software-artifact Infrastructure Repository) repository [START_REF] Do | Supporting controlled experimentation with testing techniques: An infrastructure and its potential impact[END_REF]. Programs include GNU projects (gzip 1.0.7 and sed 1.17), two lexical analysers (printtokens and printtokens2), two priority schedulers (schedule and schedule 2), a pattern matching program (replace), a statistics program (totinfo), and an aircraft collision avoidance system (tcas). Test cases were either provided, or generated using the Make-test-script program and test plans described in universe files. The test cases exercise the parameters and behaviour of the programs as described in [START_REF] Do | Supporting controlled experimentation with testing techniques: An infrastructure and its potential impact[END_REF]. We run our experiments and collected metrics for test cases over each SIR program. We performed two different analysis on the SIR programs, (1) For each SIR program, we used 300 randomly selected test runs to collect observations. We performed feature selection over these observations for each SIR program, (2) We randomly selected 30 test runs for each SIR program, resulting in a total of 270 observations over all 9 SIR programs. We then performed feature selection across observations over all SIR programs. We limited the test runs in order for the total number of observations per benchmark family to be comparable. It is worth noting that each observation in our context is a record of the energy consumed along with measurements of the different hardware and program features for that test run.

Parboil Benchmark

We used all 11 programs from the Parboil benchmark [START_REF] Stratton | Parboil: A Revised Benchmark Suite for Scientific and Commercial Throughput Computing[END_REF], which is an open source benchmark suite with benchmarks collected from throughput computing application researchers in many different scientific and commercial fields including image processing, biomolecular simulation, fluid dynamics, and astronomy. Applications in the benchmarks perform a variety of computations including ray tracing, finitedifference time-domain simulation, magnetic resonance imaging, 3-D stencil operation. Parboil provides applications implemented as both serial C++ and OpenMP, along with workloads specific to the programming model. We run both the base and parallel OpenMP versions of these programs. We collected 51 observations over all the programs in Parboil.

EEMBC Benchmark

Embedded Microprocessor Benchmark Consortium (EEMBC) [START_REF] Poovey | A benchmark characterization of the eembc benchmark suite[END_REF] provides a diverse suite of processor benchmarks organised into categories that span numerous real-world applications, namely automotive, digital media, networking, office automation and signal processing, among others. There are a total of 38 programs -17 from automotive domain, 6 from consumer, 4 in networking, 5 in office, and 6 from telecom. We used the workload in the benchmarks to generate a total of 304 observations over all 38 programs.

The features measured and tools used are explained in the next section.

Measurements

For every run of every program, we used existing run time monitoring and program analysis tools to measure, Hardware performance features reflecting CPU, cache and memory performance. We measure these features since they are known to impact power and energy [START_REF] Brooks | Wattch: a framework for architectural-level power analysis and optimizations[END_REF][START_REF] Datta | Cpu scheduling for power/energy management on multicore processors using cache miss and context switch data[END_REF][START_REF] Do | ptop: A process-level power profiling tool[END_REF][START_REF] Tony D Givargis | Interface and cache power exploration for core-based embedded system design[END_REF]. Dynamic program features relating to types of program instructions generated, memory operations performed, and register utilisation. Different types of instructions are associated with different base energy costs [START_REF] Tiwari | Instruction level power analysis and optimization of software[END_REF].

Inter-instruction effects, and operands also affect the energy consumed. Memory operations are also associated with high energy costs. Finally, effective register utilisation during machine code translation is shown to help improve energy efficiency [START_REF] Jeffry | Software power estimation and optimization for high performance, 32-bit embedded processors[END_REF]. Static program features such as number of basic blocks, number of loops, branches, global variables, cyclomatic complexity. We measure these high-level program features since they have been shown to be useful in estimating energy consumed by software [START_REF] Tan | High-level software energy macro-modeling[END_REF], and are the primary guide in creating and measuring adequacy of test runs (over which execution time and energy are measured) [START_REF] Staats | Coverage metrics for requirements-based testing: Evaluation of effectiveness[END_REF][START_REF] Mats | On mc/dc and implementation structure: An empirical study[END_REF][START_REF] Rajan | Coverage metrics to measure adequacy of black-box test suites[END_REF]. In addition to the above features, we also measured the execution time and energy consumed by each of the program runs.

Hardware Features

We use Linux's Perf tool [START_REF]Perf tool[END_REF] to collect 37 hardware features. Perf uses special-purpose CPU registers to count the number of events, such as CPU misses or mispredicted branches. Perf runs in the user space and is part of the kernel. It has a low overhead compared to instrumenting profilers [START_REF] Vitillo | Performance tools developments[END_REF]. The hardware features collected with Perf are as follows: Performance features. We collected 8 features that provide CPU performance information for the program, such as the number of instructions executed between each performance sampling, total CPU cycles, total bus cycles, the total time spent by the application or it's tasks on the CPU (CPU clock and task clock). Additional metrics include the number of context switches and the number of CPU migrations. Number of context switches corresponds to the number of times the CPU restored the context (e.g., state) of a process or thread. Context switches can invalidate some TLB3 entries, since the virtual-to-physical address mapping is different. This results in misses in the TLB for a memory reference. The number of CPU migrations counts the number of times the executing process has migrated to a new CPU or a new CPU core. Branch Instruction features. We collected 4 features that count the number of executed branch instructions, mispredicted branch instructions, number of branch instructions with a load access, and the number of those loads that resulted in a cache miss. Cache Related features. Cache effects are known to have a significant impact on performance [START_REF] Tony D Givargis | Interface and cache power exploration for core-based embedded system design[END_REF]. We collected 19 features that record the number of loads and stores (in addition to load misses and store misses) for Level 1 Cache (L1), Last Level Cache (LLC) and Translation Lookaside Buffer (TLB). For L1 cache and TLB buffer, we collect separate metrics for data and instruction cache. Page Fault features. We collected 6 features including, total page faults, minor and major page faults, alignment and emulation faults. When a page fault occurs, the thread that experienced the page fault is put into a Wait state while the operating system finds the specific page on disk and restores it to physical memory. Page faults can cost millions of CPU clock cyles because of disk access and, as a result, severely affect performance. In addition to the above hardware features, we also measured execution time of the program using the "time" Linux command.

Dynamic Program Features

We use the Pin tool [START_REF] Luk | Pin: building customized program analysis tools with dynamic instrumentation[END_REF] (version 2.14) to collect 42 dynamic program features. Pin is a dynamic binary instrumentation framework where instrumentation is performed at run-time on the compiled binary files. We built instrumentation tools in this framework to collect features in the following categories: Program Instructions. We used 4 features to count the number of executed instructions, the number and size of basic blocks executed, and the number of threads. Memory Instructions. We used 6 features counting the number of times instructions were read or written from/to memory, and the number of malloc/realloc/calloc and free calls. Processor Registers. We used 32 features to count the number of read and write accesses to the different processor registers.

Static Program Features

We collect 25 static program features using Frama-C's [START_REF] Frama-C | Software Engineering and Formal Methods[END_REF] metrics plugin [START_REF]Frama-C Metrics plugin[END_REF] (Sodium release). The Frama-C platform helps analyse the source code for C programs. We collect the following metrics: Halstead Complexity measures [START_REF] Halstead | Elements of Software Science (Operating and Programming Systems Series)[END_REF]. We have 13 features that count the total and distinct number of operators and operands, the program length (which describes the size of the abstracted program by removing everything except operators and operands), the program volume (which models the number of bits required to store the abstracted program), and program level (which defines the ratio between the program volume and the volume of its most compacted implementation).

McCabe's Cyclomatic complexity [START_REF] Mccabe | A complexity measure[END_REF]. We use this feature to provide an indication of the complexity of a program by measuring the number of linearly independent paths in a program. Other static progam features. We have 11 features representing the number of source lines of code, number of loops, Ifs, Gotos, functions declared, exit points (e.g., return statements), the number of decision points, global variables and the number of pointer dereferences.

Energy Metric

We measure the energy consumed by the computer for each program run using a Watts Up? .Net power meter [START_REF]Watts Up? power meter[END_REF]. The power meter is connected to another computer that collects energy observations at runtime. We also measured and continuously monitored the idle energy of the computer. We used the server edition of Ubuntu as our operating system with no additional services running. Energy consumption of a program run is the difference between the measured energy and idle energy. It is also worth noting that our energy measurements do not include the energy consumed by the monitor since the monitor we use has its own independent power supply.

In summary, we observed a total of 106 features, both hardware and program specific, that we believed will be relevant to the energy consumed by the program. In the next sections, we describe the regression models and feature selection technique we use in our experiments.

Phase 2 -Prediction Models 3.3 Linear Regression

One of the most widely used regression models is linear regression. This asserts that the response we wish to predict, y ("dependent variable") is a linear function of the input vector x ("independent variables" or features). In this paper, x is a vector of hardware and software features measured over the program that is used to compute y, the energy consumed by the program. Linear regression is expressed by Murphy et al. [START_REF] Murphy | Machine learning: a probabilistic perspective[END_REF] as

y(x) = w T x + = D j=1 wjxj + (1)
where w T x represents the scalar product between the input vector x and model's weight vector w, also referred to as vector of coefficients for x. D is the length of input vector x. is the residual error between our linear predictions and the true response. Now given this regression model and a training data with N number of observations, we need to find an optimal setting of the coefficients vector, w, for best predicting y from x. This optimisation is typically done by minimizing the residual sum of squares (RSS) or sum of squared errors (SSE) as defined by,

RSS(w) . = N i=1 (yi -w T xi) 2 (2)
This method is referred to as least squares. The values of wi computed for minimal RSS represent the regression coefficients to be used in the model. We used the WEKA (Waikato Environment for Knowledge Analysis) tool [START_REF] Hall | The weka data mining software: An update[END_REF] to build the Linear regression models.

Feature Selection using Lasso

We use a machine learning technique, called feature selection, to select a subset of statistically relevant features to improve the overall performance of the learning model by preventing overfitting. In the context of this paper, we apply feature selection to [START_REF]Frama-C Metrics plugin[END_REF] understand the relationship between the features and energy consumed, and (2) to select the set of relevant features (among all hardware and program features) that can provide insight on where to target energy optimisation efforts. Note that we are interested in the effect of features taken together, rather than individually, on the energy consumed. Feature selection also eliminates the need for measuring features that are not relevant, or are redundant to the energy consumed. We use an L1 regularization method called LASSO to apply feature selection in the linear regression model [START_REF] Murphy | Machine learning: a probabilistic perspective[END_REF], [START_REF] Tibshirani | Regression shrinkage and selection via the lasso[END_REF]. Lasso is an embedded algorithm performing feature selection as part of the model construction process. Regularization methods introduce a penalty term for the size of the weights that is tuned empirically for minimizing the RSS. Lasso regression is often preferred because it produces sparse models effectively, i.e., the regression coefficients for most irrelevant or redundant features are shrunk to zero, thereby achieving feature selection [START_REF] Li | From lasso regression to feature vector machine[END_REF]. Interactions among features are also taken into account by Lasso. We achieve Lasso feature selection in our experiments using the 'glmnet' package [START_REF] Friedman | Regularization paths for generalized linear models via coordinate descent[END_REF] in R [START_REF]R: A Language and Environment for Statistical Computing[END_REF], a software environment for statistical computing.

Validation

We use cross validation, in particular, Leave-One Out Cross Validation (LOOCV) to evaluate the performance of the different prediction models. Cross validation technique works as follows; suppose the original dataset has N observations, then, for each i ∈ {1, ...., N }, we train the regression model on all except the ith observation, test the model on the ith observation and compute the error. This process is repeated in a round-robin fashion and the error averaged over all i, i.e, N validation runs. In our case, every test case run from every program results in an observation of vector x of features and response y of the energy consumed. For each regression model, we compute, using LOOCV, the Root Mean Squared Error,

RM SE = 1 n n i=1 (yi -ŷi) 2 (3)
which is the square root of the mean of the squared errors over n different predictions. We then normalize the RMSE to the range of the observed response using the minimum and maximum actual response, i.e., Normalised RMSE

N RM SE = RM SE ymax -ymin (4)
NRMSE is a popular error metric to compare numerical prediction errors between models. Compared to mean absolute error, RMSE amplifies and severely punishes large errors, such as those from outliers.

EXPERIMENTAL RESULTS

Features 2. Per benchmark family. Within each benchmark family, we analysed the results from runs of all programs. Each analysis was carried out as follows: We used the Lasso learning technique to select a subset of features from all the hardware and program specific features observed. We assessed the usefulness of the selected features by comparing the NRMSE for energy prediction using Lasso against that of Linear regression with all features. We list the relevant features selected by Lasso and their coefficients. The coefficient values of the different features cannot be compared directly since the magnitudes and units of the measurements are not comparable. For instance, execution time is measured in milliseconds, while a Halstead metric gives the number of distinct operators and operands.

We did not conduct per program analysis for EEMBC and Parboil benchmarks since the number of test runs available per program was significantly smaller than the number of features measured. Predictions for such programs in our high-dimensional feature space will be highly inaccurate due to the curse of dimensionality [START_REF] Bellman | Adaptive Control Processes: A Guided Tour[END_REF]. As a result, we only conducted per program analysis for SIR programs that had greater number of test runs than features measured.

Individual SIR Programs

For each of the SIR programs, we ran 300 randomly selected test cases. The NRMSE results for the individual SIR programs are presented in Figure 1. Lasso regression performs well with a lower NRMSE across all SIR programs. Linear regression has a slightly higher NRMSE (less than 0.2%).

Table 1 lists for each of the 9 SIR programs, the features selected by LASSO for energy estimation. It is important to note that the Lasso feature selection technique will suppress features that are relevant to energy but redundant with respect to another feature selected.

Execution time is a feature selected in all SIR programs. This was to be expected since execution time has a high impact on energy consumption, and aligns with observations in previous investigations [START_REF] Corral | Can execution time describe accurately the energy consumption of mobile apps? an experiment in android[END_REF][START_REF] Pathak | Where is the energy spent inside my app?[END_REF][START_REF] Landsiedel | Accurate prediction of power consumption in sensor networks[END_REF].

For all the SIR programs, CPU migrations and context switches are among the features selected. Both these features are known to cause overheads in terms of running time [START_REF] Li | Quantifying the cost of context switch[END_REF][START_REF] David | Context switch overheads for linux on arm platforms[END_REF]. CPU clock and/or task clock are also selected since the time spent in the CPU by the program (CPU clock) and its threads4 (task clock) is high.

Features related to LLC cache and memory instructions in the source code (malloc/calloc/realloc and free) also appear in Table 1. This is because the programs frequently read and write data resulting in frequent accesses to the cache. Some of these cache accesses result in cache misses that cost extra clock cycles. Static software features are not selected for any of the SIR programs since for runs within each program, these features remain constant. Lasso shrinks the weight of these features to zero since they do not exhibit any deviation between observations.

Benchmark Families

We now discuss results from runs of all programs within each benchmark family.

SIR Benchmarks

Similar to our observation in individual SIR programs, NRMSE numbers are low across both prediction models (see Table 2), 0.00097 for linear, and Lasso is lower with 0.00082. The features selected with Lasso are marginally more effective in predicting energy than all the features in the linear model. Table 3 shows the coefficient values for the selected features. The coefficient value for execution time is 10 2 to 10 5 times larger than coefficient values for other features. Although, coefficient values in such models cannot be directly compared due to the different units of measurements, it provides a hint on the importance of execution time for energy prediction in the SIR benchmarks. To assess the importance of execution time for energy prediction, we compared LASSO prediction errors with and without execution time in the feature set. Table 4 lists the NRMSE for LASSO with "All" features,"All -Time", "Only Software", and "Only Hardware". As can be seen, NRMSE increases by 3 times when execution time is removed from the observations. execution.time is, thus, a key consideration, and cannot be approximated by any set of hardware or software features for SIR benchmarks. Table 4 also shows that prediction accuracy is approximately the same for "All -Time", "Only Software" and "Only Hardware" with "Only Hardware" being marginally better. For SIR programs, measuring either only the program characteristics or only the hardware features, along with execution time would suffice to predict energy.

A feature that is different from what we saw for individual SIR programs is the size of the program indicated by the Halstead metric, P rogram.level. This implies that the number of distinct operators and operands in the source code for the SIR programs has an effect on energy. As mentioned earlier, we did not see this static program metric for individual programs since it does not change across runs of the same program. cpu.clock and/or task.clock are selected for all individual SIR programs, but is not seen in the LASSO selection across all programs. The software metrics, P rogram.level, F unction, and calloc have effectively replaced cpu.clock and task.clock. This is confirmed again in Table 4 when we perform Lasso selection with Only Sof tware metrics which has the same prediction accuracy as Lasso using All -T ime.

EEMBC Benchmarks

For the 38 programs in the EEMBC benchmark,the Linear regression model performs better with an NRMSE of 0.0042 compared to the Lasso model with an NRMSE of 0.0055 (see Table 2). The prediction errors are, however, comparable and as a result, the features selected can be considered further for optimisations.

Table 5 shows the features selected by Lasso. As with the SIR benchmarks, execution time is selected and the coefficient value (without normalising) is larger than the other features. However, execution time is not as significant for energy prediction as in the case of SIR benchmarks. This is evident from Table 6 where the prediction error of Lasso using All features is comparable to Lasso using All -T ime features. Only Sof tware and Only Hardware features also have comparable accuracy in energy prediction. This implies that targeting optimisations at one of these sets of features will be effective in achieving energy efficiency. cpu.clock and task.clock are among the other features selected. Contrary to the execution time -which includes wait time, these two clock features monitor time spent using the CPU. The CPU intensive nature of some of the EEMBC benchmarks drives these observations. Examples of such CPU intensive benchmarks are the image processing, and automotive applications. Branch misses is selected and this may be due to the extensive use of loops in all the EEMBC programs. We believe the feature, bus.cycles, was selected due to frequent communications between the CPU and the main memory. Programs in the telecommunications domain, Encoder, Decoder, and Bit allocation, make heavy use of such communications.

Parboil Benchmarks

For the Parboil benchmarks, Linear regression model does better with an NRMSE of 0.0518, as seen in Table 2. Lasso has a slightly higher error of 0.07484. Among the 3 benchmark families seen thus far, NRMSE is highest for Parboil across prediction models. We believe there are two reasons for the high NRMSE values for Parboil, (1) The number of observations available for Parboil is fewer than the other two benchmarks (51 for Parboil versus 304 for EEMBC and 270 for SIR), resulting in the dimensional feature space being much bigger. As a result, the effect of the curse of dimensionality is more significant in Parboil. (2) Parboil benchmarks have both the serial and parallel versions. N umber of threads is the only feature in our measurements that reflects the parallel nature of benchmarks. It may be the case that this single feature is inadequate in capturing the effects of parallelism on energy. Table 7 shows the features selected by Lasso and the absolute weights of the coefficients.

The coefficient value of execution time is significantly larger than that of the other selected features. As can be seen in Table 8, prediction error almost doubles when execution time is not included (All -T ime) in the observations, reflecting its importance for energy estimation

DISCUSSION

From our experiments, we find that the overall accuracy of the Lasso feature selection technique is comparable to the Linear regression model with all the features. The Lasso technique did not always outperform the Linear model and there was no consistent best model across all experiments. Given the high dimensional feature space, we believe comparable prediction accuracy using the Lasso model is a good start and the selected features can be used as a basis for discussion on potential optimisations for energy. It is worth noting that feature selection using Lasso takes correlation between measured features into account and eliminates redundancy. For instance, features like basic blocks and global variables have high coefficient values in the linear regression model but are not selected by Lasso since they are redundant with respect to execution time. When correlated features are selected, it implies that the features together better predict energy than any one of them (they are not redundant with respect to each other or a combination of other selected features).

We found that some hardware and program features were repeatedly selected across all our experiments. We list these features (or sets of features) and discuss their potential as energy optimisation targets. We also go on to discuss if the selected features and optimisations are any different from those already known for software performance.

Execution Time:

Execution time has often been used as a representative for energy [START_REF] Corral | Can execution time describe accurately the energy consumption of mobile apps? an experiment in android[END_REF][START_REF] Pathak | Where is the energy spent inside my app?[END_REF][START_REF] Landsiedel | Accurate prediction of power consumption in sensor networks[END_REF]. Lasso feature selection over all benchmarks resulted in coefficient values for execution time being 10 to 100 times larger than coefficient values for other features. Although, coefficient values in such models cannot be directly compared due to the different units of measurements, it provides a hint on the importance of execution time for energy. It is clearly valuable to target execution time for energy optimisation. However, it is important to bear in mind that energy is dependent on both execution time and power, and reducing one while increasing the other will offset the gains achieved.

Cache and Memory instructions: Our experiments consistently selected cache (L1, LLC, and TLB) features, and dynamic memory instruction features. Missed cache hits, on both the internal and external cache, as well as page faults slow the performance of a program [START_REF] Tiwari | Instruction level power analysis and optimization of software[END_REF][START_REF] Vijaykrishnan | Energy-driven integrated hardware-software optimizations using simplepower[END_REF] by significantly increasing memory latency and, therefore, execution time. Note, however, that the cache features being selected by Lasso implies they are not redundant with respect to execution time. The selection implies that it is potentially beneficial to optimise cache features in addition to optimising execution time. For instance, if we have a memory intensive process whose performance is limited by the available memory bandwidth(cache and memory access speeds are slower than processor speeds), we will gain limited execution time gains from increasing processor clock frequency.The increased clock frequency will result in increased power consumption that may offset the limited execution time gains. Thus, it may be beneficial to move memory intensive processes to lower frequency cores, while executing less memory intensive processes on higher frequency cores.

To reduce cache misses and memory latency, one can place related data close in memory and use algorithms and data structures that exploit the principle of locality. For instance, elements of std::vector in C++ are stored in contiguous memory and accessing them is more cache-friendly since it exploits spatial locality, than accessing elements in std::list that does not have this feature.

Compiler researchers have also proposed the use of reuse distance as a metric to approximate cache misses [START_REF] Beyls | Reuse distance as a metric for cache behavior[END_REF][START_REF] Pyo | Reference distance as a metric for data locality[END_REF]. [START_REF] Beyls | Reuse distance as a metric for cache behavior[END_REF] state reuse distance of a memory access as "the number of accesses to unique addresses made since the last reference to the requested data". In a fully associative cache with n lines, a reference with reuse distance d < n will hit, and with d ≥ n will miss. To improve data locality based on reuse distance within loop structures, loop transformations, namely loop tiling and fusion, have been proposed and implemented in compilers [START_REF] Beyls | Refactoring for data locality[END_REF][START_REF] Carr | Compiler optimizations for improving data locality[END_REF][START_REF]Polly LLVM library[END_REF].

We use the P olly data locality loop optimiser [START_REF]Polly LLVM library[END_REF] in LLVM over SIR and the automotive EEMBC benchmarks. The motivation was to assess the energy gains from optimising data locality within loops in these benchmarks. 9 that the energy gains achieved over SIR benchmarks using Polly for loop optimisations is relatively low, maximum being 6.36% (over printtokens2) This is primarily because in SIR programs, loops are used sparringly with relatively few data and array references within them. As a result, there is not enough opportunity for Polly to improve data locality. For instance, in the case of the tcas program where almost no energy gain was observed, loop structures are not present in the program and as a result Polly has no effect. printtokens, on the other hand, is a program which accepts a file containing a stream of characters and for each character (outer loop) it performs an expensive search to find the corresponding token (inner loop). This loop structure provides relatively more opportunities for Polly to optimise than in the case of tcas, resulting in the higher energy gain of 5.06%.

As seen in Table 9, energy gains follow execution time gains for most SIR programs. This is because, improved data locality and thus, reduced cache misses helps reduce execution time and not power. For schedule and tcas programs, we observe no gain in execution time, however negligible gains in energy because of power is observed. It is difficult to pinpoint the exact reason for the slight gain in power and can often be simply attributed to small fluctuations in the processor environment.

For the EEMBC benchmarks, we ran the Polly optimiser over the automotive domain comprising of 16 programs and associated workloads. 9 that energy gains are driven by execution time, rather than power, gains when using the Polly optimiser.

Context switches and CPU migrations. Both these features are relevant to energy consumption and are known to cause overheads in terms of running time [START_REF] Li | Quantifying the cost of context switch[END_REF][START_REF] David | Context switch overheads for linux on arm platforms[END_REF] and power [START_REF] Datta | Cpu scheduling for power/energy management on multicore processors using cache miss and context switch data[END_REF]. Switching a process context or migrating it to a different CPU core is a costly task and tends to generate many cache misses (since the process may not find valid data on the new migrated core's cache). CPU scheduling algorithms have been proposed to help tackle this problem to reduce the power and energy consumed [START_REF] Datta | Cpu scheduling for power/energy management on multicore processors using cache miss and context switch data[END_REF]. Some multi-core programming models (like OpenMP and MPI) allow developers to use environment variables that pin processes to CPU to prevent migration to a different core.

Program Level This halstead metric was selected for the SIR benchmark family. It is worth noting that for EEMBC, the linear regression model assigned the highest coefficient value to this feature. Lasso did not select this metric since it was, likely, redundant with respect to execution time. We hypothesize that reducing the number of operators, operands and function calls (that are used to compute this metric) in a program will help in reducing energy consumption. In a previous study, we found that optimising design patterns by reducing function calls improved energy consumption [START_REF] Noureddine | Optimising energy consumption of design patterns[END_REF].

Optimising [START_REF] Kandemir | Influence of compiler optimizations on system power[END_REF][START_REF] Pallister | Identifying compiler options to minimize energy consumption for embedded platforms[END_REF]. All of the existing optimisation techniques proposed for performance, either focus on power or on execution time, but not both. Existing performance optimisations are effective in reducing energy and this has been observed in several studies [START_REF] Pallister | Identifying compiler options to minimize energy consumption for embedded platforms[END_REF][START_REF] Tan | High-level software energy macro-modeling[END_REF][START_REF] Datta | Cpu scheduling for power/energy management on multicore processors using cache miss and context switch data[END_REF][START_REF] Ye | The design and use of simplepower: a cycle-accurate energy estimation tool[END_REF][START_REF] Miyoshi | Critical power slope: understanding the runtime effects of frequency scaling[END_REF][START_REF] Beyls | Refactoring for data locality[END_REF][START_REF] Noureddine | Optimising energy consumption of design patterns[END_REF]. It is, however, important to bear in mind that execution time gains do not always translate to energy gains. An example of this, is frequency scaling in processors that reduces execution time by running at full clock speed. This technique, however, proportionally increases power consumed as seen from the equation,

P = 1 2 CV 2 f ( 5
)
where C is capacitance, V voltage and f is the frequency. Miyoshi et al. observed that scaling CPU frequency, although reducing execution time, can cost more energy than running at a slower clock speed [START_REF] Miyoshi | Critical power slope: understanding the runtime effects of frequency scaling[END_REF]. Typical techniques for reducing power are power management software and dynamic voltage frequency scaling in processors. Our study does not consider these techniques since they focus on processors rather than a specific application. The features affecting energy selected in our study lead us to believe that existing performance optimisations will suffice if one looks to reduce energy by reducing either only power consumed or only execution time. To achieve energy gains that goes beyond existing optimisations, we need to explore techniques that target both power and execution time. We plan to explore this problem in our future research.

THREATS TO VALIDITY

Our experiments suffer from the following internal threats to validity,

• We did not enable and examine the effect of standard compiler optimizations on energy consumption. We did, however, use Polly for data locality optimisations in loops. Enabling compiler optimisations has been shown to reduce energy consumption by reducing program execution time [START_REF] Kandemir | Influence of compiler optimizations on system power[END_REF][START_REF] Pallister | Identifying compiler options to minimize energy consumption for embedded platforms[END_REF]. • In our experimental setup, we do not completely control the services, unrelated to the benchmark being measured, run by the operating system. We used the server version of the Ubuntu distribution in order to limit the number of applications and background services running concurrently. However, some operating system services might still be running (such as checking for -but not performing, new updates). We did not specifically disable these services. The external threat to validity in our experiment is using only a single hardware platform for running benchmarks and collecting observations. Our results cannot be generalized to other hardware architectures since the hardware and program specific features observed and measured will be very different. A similar experiment will have to be conducted to learn the features relevant to energy consumption for each hardware platform and each application domain. This is a consequence of the no free lunch theorem [START_REF] Murphy | Machine learning: a probabilistic perspective[END_REF] that states that "there is no single best model that works optimally for all kinds of problems". The reason for this is that a set of assumptions that works well in one domain or achitecture may work poorly in another.

CONCLUSIONS

We have studied energy consumption of programs and workloads from three different benchmark families measuring over 100 different software and hardware features. The feature selection technique, Lasso, effectively picks five to seven features for each of the benchmark families that are relevant to energy consumption. The accuracy of energy predictions with the selected features was comparable to energy predictions using a linear regression model with all the features. The features commonly selected in our experiments were execution time, cache accesses, memory instructions, context switches, CPU migrations, and program length (Halstead metric). All of these features are known to affect software performance, in terms of running time, power consumed and latency. As a result, we can use existing performance optimisation techniques that reduce power or execution time to also achieve energy gains. We confirmed with the use of Polly, a compiler optimisation for data locality, that significant energy gains were possible by reducing latency and execution time. We believe the future in energy optimisation lies in techniques that can reduce both power and execution time.

Figure 1 :

 1 Figure 1: Normalized Root mean square error (NRMSE) for SIR programs

Table 1 :

 1 Features selected by LASSO for individual SIR programs (when applying Lasso using all features)

		selected by LASSO
	Gzip	Printtokens	Printtokens2
	execution time	execution time	execution time
	cpu.clock	cache.misses	cache.misses
	task.clock	cpu.clock	task.clock
	context.switches	task.clock	page.faults
	cpu.migrations	page.faults	context.switches
	LLC.load.misses	context.switches	cpu.migrations
	LLC.store.misses	minor.faults	minor.faults
	free	LLC.load.misses	LLC.load.misses
	-	LLC.store.misses	LLC.store.misses
	-	malloc	free
	-	free	-
	Replace	Schedule	Schedule2
	execution time	execution time	execution time
	cache.misses	cpu.clock	cpu.clock
	cpu.clock	page.faults	context.switches
	task.clock	context.switches	cpu.migrations
	context.switches	cpu.migrations	LLC.load.misses
	cpu.migrations	LLC.load.misses	LLC.store.misses
	LLC.load.misses	LLC.store.misses	iTLB.load.misses
	LLC.store.misses	malloc	malloc
	-	free	free
	Sed	Tcas	Totinfo
	execution time	execution time	execution time
	cpu.clock	cache.misses	cpu.clock
	task.clock	cpu.clock	context.switches
	page.faults	task.clock	cpu.migrations
	context.switches	page.faults	major.faults
	cpu.migrations	context.switches	LLC.load.misses
	major.faults	cpu.migrations	malloc
	LLC.load.misses	minor.faults	free
	LLC.store.misses	LLC.load.misses	-
	malloc	LLC.store.misses	-
	realloc	read.access.memory	-
	free	write.access.memory	-

Table 3 :

 3 shows the features selected by Lasso. Features selected by LASSO for all SIR benchmarks Most of the features present in Table3, are also present in the selection for individual SIR programs (see Table1) and the reasons for the selection are similar. Table3 also

		Linear	LASSO
	SIR	0.000971891 0.000827693
	EEMBC 0.004287477 0.005514576
	Parboil	0.051841246 0.074844556
	Table 2: Normalized Root mean square error
	(NRMSE) for all benchmarks
	Features selected Absolute Weight
	execution.time	66.70251726
	cache.misses	0.000154405
	cpu.migrations	0.234642543
	realloc		0.001386825
	calloc		0.001374207
	Program.level	0.138383951
	Function		0.000190104

Table 5 :

 5 Features selected by LASSO for all EEMBC benchmarks

	Features selected Absolute Weight
	execution.time	4.834222931
	cpu.clock	0.004460450
	task.clock	0.004313552
	context.switches	0.040315249
	cpu.migrations	1.755253195
	branch.misses	6.10E-08
	bus.cycles	1.38E-08

Table 4 :

 4 NMRSE and feature selected by LASSO for SIR benchmarks

		All		All -Time			Only Software	Only Hardware
	NRMSE	0.000827685	0.003193454			0.003193454	0.003183806
	Selected features	execution.time,	cpu.migrations,	Pro-	Program.level,	calloc,	cpu.migrations,
		cache.misses,	gram.level,	cpu.clock,	Exit.point, Free	context.switches,
		cpu.migrations, realloc,	context.switches,			cpu.clock,	task.clock,
		calloc,	Program.level,	task.clock,		calloc,		LLC.load.misses,	mi-
		Function		LLC.load.misses,			nor.faults
				Exit.point
		All		All -Time			Only Software	Only Hardware
	NRMSE	0.005921402	0.005999306			0.006079861	0.006016273
	Selected features	execution.time,	cpu.migrations,	con-	Sloc, basic.blocks	cpu.migrations,
		cpu.clock,	task.clock,	text.switches, cpu.clock,		context.switches,
		context.switches,	task.clock				cpu.clock,	task.clock,
		cpu.migrations,					LLC.load.misses
		branch.misses,
		bus.cycles

Table 6 :

 6 NMRSE and feature selected by LASSO for EEMBC benchmarks

	Features selected	Absolute Weight
	execution.time	58.93799739
	cpu.clock	0.001014987
	task.clock	0.001215820
	L1.dcache.prefetches 6.34E-07
	dTLB.load.misses	8.24E-07

Table 7 :

 7 Features selected by LASSO for all Parboil benchmarksover Parboil programs. It is also worth noting that measuring Only Hardware features outperforms measuring Only Sof tware features. We can safely say that energy consumed by Parboil programs are characterised better by hardware features than software. Many of the Parboil programs are CPU intensive, resulting in cpu.clock and task.clock being selected. The programs use large input data sets. Frequent accesses to these large data sets without temporal and spatial locality result in data cache misses being an important feature for energy estimation.

Table 8 :

 8 NMRSE and feature selected by LASSO for Parboil benchmarks Beyls et al.

	All		All -Time		Only Software		Only Hardware
	NRMSE 0.074839977		0.11318387		0.277245127		0.11318387
	Features execution.time,		cpu.migrations,		Global.variables,	Goto,	cpu.migrations, task.clock,
	task.clock,	cpu.clock,	task.clock,	cpu.clock,	Function.call, rdx.written,	cpu.clock
	dTLB.load.misses,	dTLB.store.misses,	Pointer.dereferencing,
	L1.dcache.pref		dTLB.load.misses,	rcx.written, rdx.read, as-
			L1.dcache.pref,		signment
			LLC.load.misses,
			branch.misses

Table 9

 9

	lists

Table 9 :

 9 Energy gains in SIR benchmarks from Polly loop optimiserIt is evident from Table

Table 10

 10

	lists the energy gains with

Table 10 :

 10 Energy gains in EEMBC benchmarks from Polly loop optimiser

	Polly. In complete contrast to the SIR benchmarks, we ob-
	served massive energy gains with Polly, ranging from 45.74%
	to 83.94%. The large gains can be explained by the program
	structure of the EEMBC benchmarks, predominantly com-
	prising of statements in for loops and array accesses. Polly's
	loop tiling and loop fusion optimisations perform extremely
	well over such program structures. Polly's data locality op-
	timisations resulted in execution time gains that were sim-
	ilar to the energy gains observed, ranging from 44.96% to
	83.53%. Power gains over the EEMBC programs were rel-
	atively low, and even negative for 3 of the 16 programs.
	The observations in Table 10 supports our earlier inference
	from Table

  for Energy versus Performance. The features picked by our empirical study that affect software energy, namely execution time, cache misses, context switches, CPU migrations, program length (in terms of number of operators, operands and function calls) are no different from those known to affect software performance with respect to running time, memory latency, and power consumed. Datta and Patel propose CPU scheduling algorithms to mitigate performance loss, in terms of power, incurred from context switches, and CPU migrations[START_REF] Datta | Cpu scheduling for power/energy management on multicore processors using cache miss and context switch data[END_REF]. David et al. and Li et at. have also studied the performance overhead introduced by context switches[START_REF] David | Context switch overheads for linux on arm platforms[END_REF][START_REF] Li | Quantifying the cost of context switch[END_REF]. Cache misses are widely known to impact performance in terms of execution time[START_REF] Yu | Visualizing the impact of the cache on program execution[END_REF] and existing optimisations for data re-use like Polly achieve significant energy gains by reducing cache misses. Compiler optimisations built into existing compilers, like the GCC optimisation flags, attempt to reduce the code size and execution time of the program

Tail energy happens when a component, such as the GPS, continues to be active and consumes energy even after the application that triggered its usage has ended.

Features in our estimation model refers to the hardware and program related metrics

A Translation Lookaside Buffer (TLB) cache stores recent translations of virtual addresses to physical addresses, both for instructions and data, to enable faster retrieval of information.

We collected observations of energy and features for programs with their respective workloads in the three benchmark families as described in Section 3. The results are organised and analysed as follows, 1. Per SIR program. We conducted analysis separately for each of the 9 SIR programs.

This refers to threads created by the OS for multitasking, rather than user created threads in the program.

* This research is funded by EPSRC First Grant EP/L024624/1.


Jamie Daugherty

P Fraundorf
email: pfraundorf@umsl.edu

David Osborn

Jai Kasthuri

Exploring Boltzmann-Factor Distributions of Precipitation-Nuclei in the TEM

For nucleation in the solid-state, modern electron microscopes may allow one to examine precritical cluster distributions down to the size-scale of a single misplaced atom. A very specific challenge of this sort arises in the gigascale silicon integrated-circuit device industry, surrounding the important roles that oxygen in Czochralski silicon can play. We indicate here in particular that the number densities and sizes of precritical SiOx clusters in as-grown wafers, as estimated by elementary means, should be possible to quantify with modern techniques, provided that challenges associated with surface noise and thickness estimation can be overcome. Nucleation theory is predicated on evolution of the "precritical cluster distribution", something that in gas and liquid phase nucleation and growth studies is difficult to approach experimentally except perhaps statistically e.g. via a scattering technique. In solid-state nucleation and growth settings, however, the "quench" often allows one to freeze the distributions in place for a cluster-bycluster look.

Czochralski semiconductor-silicon is an interesting case in point 1 . Oxygen from the growth crucible, initially uninvited, has proven to be an ally to the device manufacturing process by strengthening the wafer and by precipitating to create defects capable of trapping electrically active impurities thus improving device yields. There is therefore practical interest, by the integrated-circuit and solar-cell industries, in control of oxygen-cluster behavior. Moreover, unclustered oxygen (in the 10-20 ppm range) may be mapped across a wafer via infrared absorption, while the very earliest stages of oxygen clustering (in the 450-550C range) are connected to thermal donors which, albeit avoided by the industry, may be used to characterize clusters via their effects on the bandgap with exquisite sensitivity.

In this note we use oxygen in semiconductor-silicon to discuss: (i) Boltzmann-factor visualizations of subcritical cluster distributions in the solid-state, and (ii) strategies for exploring them in the TEM.

II. SIMPLE ABUNDANCE MODELING

Figure 1 is a schematic of the Boltzmann probabilityfactors as a relative measure of the steady-state cluster number/unit-volume, versus cluster size, for (a) the hot silicon after solidification in blue, (b) the "as-grown" distribution in a given part of the ingot after gradual cooldown in the Czochralski puller. This is stepped simply because we lowered the temperature in 50C increments in the simulation, and (c) after one (left) or two (right) "growth steps", the last of these steps at 1000C to facilitate the diffusion needed to precipitate most of the wafer oxygen if post-critical clusters are available.

These schematic distributions evolve simply: Below critical radius tiny clusters grow or evaporate quickly to the Boltzmann steady-state, while above critical radius at the current temperature the distribution simply translates rightward as more oxygen is added. As you can see in Fig. 1, for instance, the 1000C treatment in the absence of an 800C growth step has found too few clusters above critical size at 1000C (the appropriate vertical line) to result in a detectable number of growing precipitates.

Fig. 1 also suggests that as-grown silicon is sure to contain a respectable number of clusters in the very-small size regime. Heat treatments like that at right (followed by significantly more growth time) is the standard way in which that subcritical distribution is characterized (followed by either TEM or etching), as well as how pre-cipitates are created for use in the device manufacturing process itself.

III. THE CHALLENGE OF QUANTITATION

To be quantitative in finding the number of grown precipitates (or "developed clusters") per unit volume, quantitative ways to measure specimen thickness are needed. In silicon ion-milled specimens, for instance, interstitial {111} stacking-faults (created by Si interstitial displacement during precipitation) which intersect specimen top and bottom provide a direct geometric measure (cf. Fig. 2). Other methods under development and use for silicon include single-crystal thickness-fringes, energyfiltered TEM, and (at lower spatial-resolution laterally) color-changes of transmitted light 2 .

You can see from Fig. 1, we should be able to examine the pre-critical nuclei (or "latent clusters") as their abundance is at least as great. The problem is that these clusters may be un-strained. With neither strain-fields nor a Z-contrast advantage, this means that searches of only very thin regions with minimal surface "noise" 3 will show promise. Hence the quest for specimen-preparation strategies, and instruments able to locate (and characterize) such tiny cluster-distributions in important materials, continues.

  FIG. 1. Boltzmann-factor cluster-distributions discussed in the text.

FIG. 2 .

 2 FIG. 2. Stacking fault associated with late stage oxygen precipitation, whose known habit plane and intersection with the top and bottom surfaces of the thinned silicon specimen allows for rather precise local thickness determination. The field-width of this 300[keV] electron image is about 3.98 [m], making the projected breadth of the stacking-fault truncations about 656 [nm]. Multiplying by Tan[54.7 o ] for the angle between {111} and the {100} beam direction gives us a (quite large) local specimen thickness of about 0.92 [µm].


P Fraundorf

The proper-force 3-vector

The distinction between proper (i.e. cell-phone detectable) and geometric (i.e. connection-coefficient) forces allows one to use Newton's 3-vector laws in accelerated frames and curved spacetime. Here we show how this is assisted by use of quantities that are either (i) frame-invariant or (ii) synchrony-free i.e. do not rely on extended-networks of synchronized-clocks. The acceleration four-vector's invariant magnitude, and quantities that build on the metric-equation's book-keeper frame to define simultaneity, point the way to more robust student understanding at both low and high speeds. In the process, we gain a simple (3+1)D flat-space workenergy theorem using the proper-acceleration 3-vector α (net proper-force per unit mass), whose integrals of the motion simplify with a hyperbolic velocity angle (rapidity) written as 2/(γ o + 1)ατ /c, where c is lightspeed and τ is traveler-time from "turnaround" when the Lorentz-factor is γ o . CONTENTS I. introduction 1 II. frame dependence & synchrony 1 III. low speed applications 2 IV. bringing in the metric 3 V. any speed applications 4 VI. discussion

I. INTRODUCTION

Relativists have long expressed unhappiness with coordinate-acceleration and coordinate-force (for good reason [START_REF] French | Special relativity[END_REF][START_REF] Cheng | Relativity, gravitation and cosmology[END_REF] ), but have also pointed out that generalrelativity makes a case for the local-validity of Newton's laws in all frames [START_REF] Misner | Gravitation[END_REF][START_REF] Hartle | Gravity[END_REF][START_REF] Cook | Physical time and physical space in general relativity[END_REF] provided that we consider geometric (curved-frame or "connection-coefficient") forces as well as proper-forces whenever we find ourselves in a non-"free-float" trajectory [START_REF] Taylor | Exploring black holes[END_REF] . The distinction has everday relevance to intro-physics students, because texts often introduce gravity as a real force but inertial forces as fake even though their cell-phones detect neither for the same reason: Accelerometers only detect proper-forces, while gravity and inertial (e.g. centrifugal) forces are geometric.

In this paper we explore an approach to accelerated motion designed to be: (i) the most frame-independent, and (ii) the least in need of synchronized-clock arrays.

a) pfraundorf@umsl.edu These latter might be difficult to come by on accelerated platforms and in curved spacetime.

The first proper-time derivative of an accelerated traveler's 4-vector position has lightspeed c as its invariant magnitude. Here we simply define simultaneity using bookkeeper coordinates and then examine the second proper-time derivative of position, as seen from the proper reference-frame 3 of that accelerated traveler.

In the process we show: (a) that the distinction between proper and geometric forces is already quite useful for introductory physics, (b) that via the metric equation a lot can be done with only a single extended mapframe of yardsticks and synchronized clocks, and (c) that the traveler's view of anyspeed-acceleration is less framevariant than the map perspective. We also exploit the frame-invariance of proper-force in an empirical observation exercise on the electrostatic origin of magnetism, which provides some visceral experience with lengthcontraction at the same time.

II. FRAME DEPENDENCE & SYNCHRONY

The value of frame-independence in the modeling of relativistic-motion and curved-spacetime goes without saying. The frame-invariance of lightspeed c (the magnitude of the velocity 4-vector U λ ≡ dX λ /dτ ) has been central to our understanding of spacetime from the beginning 7 . Proper-time (the magnitude of the displacement 4-vector X λ ) is finding increasing use by introductory text authors as we speak.

The Lorentz-transform view of proper-time, of course, is that it is time-passing on the synchronized clocks of a tangent but co-moving free-float-frame in flat spacetime. The metric equation's view of proper-time is simpler but more general, i.e. as a quantity measured on a single clock under any conditions i.e. accelerated or not, in curved space-time or not.

Proper-time is frame-invariant in the sense that its value may be agreed upon using any general-relativistic book-keeper coordinates that we choose. These book-TABLE I. Accelerated-motion definitions in flat (3+1)D spacetime. Note that acceleration/force magnitudes are spacelike, while the others are timelike along a traveler's worldline, and that we've defined x and y as spatial coordinates || and ⊥ to the direction of proper-acceleration 3-vector α.

4-vector magnitude time-components || to spatial 3-vector α ⊥ to spatial 3-vector α power/force ΣFo ≡ dpo dτ

P c = ( 1 c ) dE dτ F || ≡ dp || dτ F ⊥ ≡ dp ⊥ dτ acceleration α = ΣFo m c dγ dτ = P mc = γ P mc dw || dτ = F || m = γ f || m dw ⊥ dτ = F ⊥ m = γ f ⊥ m energy/momentum mc E c = γmc p || = mw || p ⊥ = mw ⊥ velocity c cγ ≡ c dt dτ = E mc w || ≡ dx dτ = p || dτ = γv || w ⊥ ≡ dx dτ = p ⊥ dτ = γv ⊥ coordinate cτ ct x y TABLE II.
Relationship between variables: Here τ is traveler-time elapsed from "turnaround" (when γ ≡ γo) for as long as proper acceleration α doesn't change, and γ± ≡ (γo ± 1)/2. The right arrow → denotes the non-relativistic limit.

4-vector invariant time-components/c

|| to spatial 3-vector α ⊥ to spatial 3-vector α accel.

α dγ dτ = α c γ+ sinh ατ cγ + → α c 2 τ dw || dτ = α cosh ατ cγ + → α dw ⊥ dτ = αγ-sinh ατ cγ + → 0 velocity c γ = γ 2 -+ γ 2 + cosh ατ cγ + → 1 w || = cγ+ sinh ατ cγ + → ατ w ⊥ = c √ 2γ-cosh ατ 2cγ + 2 → v ⊥ coord. τ t = γ 2 -τ + γ 3/2 + c α sinh ατ cγ + → τ x = γ 2 + 2c 2 α sinh ατ 2cγ + 2 → 1 2 ατ 2 y = γ+γ-cτ + γ+ c 2 2α sinh ατ cγ + → v ⊥ τ
keeper coordinates are alone used to define extended simultaneity (i.e. the global place and time of events), while the frame-invariance of proper-time drastically improves the transformation-properties of quantities differentiated with respect to it. The proper-velocity 3-vector w ≡ d x/dτ (which unlike coordinate velocity v ≡ d x/dt adds vectorially with appropriate rescaling of the "out-offrame" component) and the proper-acceleration 3-vector (discussed here) are cases in point. The topic of this paper is in particular the frameinvariant magnitude of the acceleration 4-vector, in standard notation 3 :

A λ := DU λ dτ = dU λ dτ + Γ λ µν U µ U ν (1)
and uses for this vector's components (as power/force) when they are multiplied by frame-invariant rest-mass m. Here free-float or geodesic trajectories have A λ = 0, so that we can think of coordinate acceleration dU λ /dτ as a sum of proper and geometric terms, the latter depending on local space-time curvature through the 64-component affine-connection Γ λ µν which gives rise to "apparent" forces in accelerated coordinate-systems and curved space-time. As usual greek indices run from 0 (time-component) to 3 (space-components) and obey the Einstein summation convention when repeated in a product. Because this proper-acceleration four-vector becomes purely space-like in a frame instantaneouslycomoving with our traveler, its physical interpretation is simply the proper-force/mass felt to be "pressing on" our traveler, as well as the 3-vector proper-acceleration 8-10 α seen by free-float observers in the co-moving frame.

In addition to a preference here for frame-invariance, the concept of simultaneity is a messy one in accelerated frames (e.g. using radar-time methods [START_REF] Dolby | On radar time and the twin paradox[END_REF] ) as well as in curved spacetime. Hence we take a "metric-first" approach to kinematics here by choosing a single "bookkeeper" coordinate-system in terms of which both "maptime" t and "map-position" x are measured. Simultaneity will be defined in terms of synchronized (but not always local e.g. in the case of Schwarzschild "far-time") clocks in this book-keeper frame.

In addition purely space-like vectors, along with frameinvariants, may be described as "synchrony-free" to use a word employed by William Shurcliff when discussing proper-velocity [START_REF] Sears | Introduction to the theory of relativity[END_REF][START_REF] Shurcliff | Special relativity: The central ideas[END_REF] w ≡ d x/dτ = p/m. These are quantities whose operational-definition does not require an extended network of synchronized-clocks, something of limited availability around gravitational-objects (like earth), and impossible to find on platforms (like spaceships) undergoing accelerated motion. The time-like energy of a moving object via its dependence on the Lorentz-factor γ ≡ dt/dτ is (like "mixed objects" such as coordinatevelocity v ≡ d x/dt) not synchrony-free, because it requires map-time t data from clocks at multiple locations.

The "traveler's point of view" that we argue offers the most direct way to communicate about an accelerated traveler is the frame that Misner, Thorne and Wheeler 3 refer to as "the proper reference frame of an accelerated traveler". One can always convert these to expressions written in terms of bookkeeper variables like map-time t and coordinate-velocity v, but we show here that the algorithmically-simplest way to describe the effects of the local space-time metric on motion (following the critera above) involves the parameterization described here.

III. LOW SPEED APPLICATIONS

For applications at low speed, telling students about proper-forces as distinct from geometric-forces (that act on every ounce of a object's being) is a good start in preparing them for the value of Newton's laws in both free-float and accelerated frames. The simple example (a) of a car leaving a stop-sign is illustrated by the screen capture from a wikimedia commons animation in the topleft of Fig. 1, which shows the red proper-force seen by observers in both frames as pressing on the driver's back while the car accelerates. This of course is canceled only in the car frame by a geometric force which (like gravity) acts on every ounce of the driver's being. Animation screen captures are also provided in that figure which show proper and geometric forces from two perspectives in the cases of (b) carousel motion, (c) the process of rolling off a cliff, and (d) the later stages of a bungie jump. The screen capture in Fig. 2 from the "real-time" animation of a 50[m] diameter rotating-wheel space-habitat with 1 "gee" of artificial gravity at its perimeter is similarly instructive.

We also recommend telling intro-physics students that time itself is dependent on a given clock's location and state of motion, with the "speed of map-time" relative to a traveler's clock (i.e. dt/dτ ) an important clue to the traveling-clock's energy (potential and/or kinetic). These things may be done at the outset, followed by the assertion that introductory physics texts by default refer to map-time (t) since traveler-time (τ ) differences at low speed are negligible, and they traditionally treat gravity as another proper-force even though we now know that it too is a geometric-force, caused not by a traveler's motion but by gravity's curvature of space-time around massive objects. Traditional treatments often further focus only on application of Newton's laws from "inertial-frame" perspectives, in which case geometricforces (other than gravity) can be ignored. With these minor "metric-first" changes to the introduction, traditional introductory physics treatments remain perfectly self-consistent and intact.

IV. BRINGING IN THE METRIC

In order for teachers to feel grounded when addressing introductory issues in context of an intimidating Riemann-geometry framework, it is crucial that the consequences of their assumptions be easy to for them to verify. Thankfully the metric-equation, unlike Lorentz transforms, requires only one bookkeeper frame whose time-variable may (or may not) be possible to associate with time's passage on clocks synchronized across a meaningful region of spacetime.

Our first step, namely choosing the metric parameterization to describe a specific problem, is especially important because it defines both the meaning of measurments and our (perhaps implicit) definition of simultaneity. This is good news for introductory teachers, since its bad enough to be talking about different times on different clocks, without having to also be juggling multiple definitions of simultaneity.

For general relativity applications in a world where time is measured on watches, and distances are measured with yardsticks, whenever possible we will seek metric parameterizations whose time-variable corresponds to clocks that can be synchronized. We therefore follow Newton in flat-space settings by choosing a set of freefloat (e.g. inertial or un-accelerated) frame variables like coordinate-time t and coordinate-position x to describe accelerated motion.

As teachers, once we have a metric and a corresponding definition of what simultaneity means, we are back on familiar territory. The caveat is that frameindependence may be attributed only to four-vector magnitudes, and no longer to time-intervals, distances, or rates of momentum-change. For the flat-space (1+1)D case, for instance, the proper time-interval δτ and derivatives with respect to τ yield the following frame-invariant magnitudes:

(cδτ ) 2 = (cδt) 2 -(δx) 2 , (2)
with the lightspeed constant c

c 2 = c δt δτ 2 - δx δτ 2 , (3)
and proper-acceleration α:

-α 2 = c δ 2 t δτ 2 2 - δ 2 x δτ 2 2 . (4)
Given this, the challenge of finding the integrals of the motion e.g. for constant acceleration is much like that challenge of showing that x = 1 2 at 2 via the same derivative relations, but using Newton's assumptions that coordinate-intervals and coordinate-acceleration a ≡ δ 2 x δt 2 are frame-invariant. Simple-form versions of the metricbased integrals are tabulated in context of the discussions to follow.

V. ANY SPEED APPLICATIONS

Table I defines notation for describing accelerated motion in (3+1)D flat spacetime. Table II shows the instantaneous relationship between these varables (also at low speed), as parameterized by the "traveler-time τ and Lorentz-factor γ o from turnaround" were the instantaneous proper acceleration to remain constant (cf. Appendix A). In both tables, only values in the "timecomponents" column rely on synchrony between mapframe clocks at more that one location. Values in the spatial-coordinate columns to the right are synchronyfree, while values in the column to the left are frameinvariant as well. Of course a map-frame observer's measurements of map-position as a function of map-time (along with deliverables like inferred coordinate-forces) will be parameterized in terms of synchrony-dependent map-time instead of frame-invariant traveler-time. Although map-frame observers can calculate synchrony-free quantities like momentum and proper-velocity in terms of synchronydependent parameters, it will take extra steps going to there from what they measure, and perhaps also going from there to what they want to infer.

If on the other hand the traveler measures their "felt proper-acceleration", as well as the rates at which they pass "map-landmarks" on their route, the equations to everything else are simpler and organically related as shown in Table II. Plus, everything that the traveler measures and reports on (except for elements in the timecomponent column of the table) will either be synchronyfree or frame-invariant.

The connection between the traveler controlparameters and Table II is reinforced if we imagine long-distance travel in a spacecraft with traveler control over thust (i.e. proper-force) magnitude and direction. The table connects proper-acceleration's magnitude and direction to instantaneous values of "proper-time from turnaround" and v ⊥ , which in turn are related via the same table to navigational objectives (like the x and y values for the turnaround-point itself).

Although variable-rearrangement is complicated relative to the low-speed case via "gamma-factor" coupling between directions, a wide range of puzzles involving high-speed navigation in free-space may be addressed with this table. Of most interest perhaps to beginning students are of course the possibilities that relativity opens up for constant proper-acceleration (e.g. 1 "gee") round-trips between distant locations. Not only are these equations even simpler than the (3+1)D case, but the real limiting factor (namely the payload to launch-mass ratio) is quite simple to calculate as well.

A practical classroom application of the frameindependence of proper-force in this context involves an

4-vector invariants time-components/c space-components acceleration

α ≡ ΣFo m dγ dτ = P mc 2 = γP mc 2 = α c sinh ατ c → α c 2 τ dw dτ = ΣF m = γΣf m = α cosh ατ c → α velocity c γ ≡ dt dτ = E mc 2 = 1 + ( w c ) 2 = cosh ατ c → 1 w ≡ dx dτ = p m = γv = c sinh ατ c → ατ coordinate τ t = c α sinh ατ c → τ x = c 2 α cosh ατ c -1 → 1 2 ατ 2
empirical observation exercise for students interested in the electrostatic origins of the magnetic force between moving charges. In essence, students are asked to take data in real time from animations (cf. Fig. 3) showing neutral-wire and moving-charge perspectives on the proper-force felt by the moving charge. Simple ratios (in either space or time) allow students to quantify the length-contraction, the currents and charge densities from these two perspectives, and a variety of other physical quantities. In order to see significant differences in these quantities from the two perspectives, of course, charge velocities have to be relativistic. Since velocities are also perpendicular to observed forces, a significant difference between the coordinate-force observed in the neutral wire frame, and the proper-force felt by the moving charge, also shows up.

VI. DISCUSSION

As mentioned above, extended arrays of synchronized clocks are difficult to come by in curved spacetime (cf. the relativistic corrections needed to make global positioning estimates accurate). They are perhaps even more difficult to come by on accelerated platforms (cf. discussions of accelerated-frame "Rindler coordinates").

"Lorentz-transform first" analyses of any-speed motion of course require at least two relativistically co-moving frames of synchronized clocks. No wonder accelerated motion is of little interest in that context.

"Metric-first" approaches require only one such mapframe, since proper-time on traveler clocks is a frameinvariant. The integrals of constant proper-acceleration, especially in (1+1)D e.g. as α = ∆w/∆t = c∆η/∆τ = c 2 ∆γ/∆x where η ≡ sinh[ w c ], are also quite manageable. As shown Table III, which is a (1+1)D version of Tables I and II combined, the general magnitude-inequality between coordinate-force f ≡ d p/dt (where we are using the relativistic momentum p) and proper-acceleration α, namely |Σ f | ≤ |m α|, also becomes the more familiarlooking signed-equality Σf = mα.

The approach also works in curved-spacetime. Table IV illustrates for the "radial-only" Schwarzschild case using the exact Lorentz-factor from Hartle 4 , even though the integration (even in the Newtonian case) is simplest if we can ignore variations of g with r. The competition between velocity-related, and gravitational, time-dilation e.g. for GPS-system orbits is nonetheless quite clear.

= P mc 2 = γP mc 2 ≃ α-g c sinh (α-g)τ c → α-g c 2 τ dw dτ = ΣF m = γΣf m ≃ (α -g) cosh (α-g)τ c → (α -g) velocity c γ ≡ dt dτ = E mc 2 = γr 1 + γr w c 2 → γr ≡ 1 1- rs r w ≡ dr dτ = p m = γv ≃ c sinh (α-g)τ c → (α -g)τ coordinate τ t ≃ c α-g sinh (α-g)τ c → τ r ≃ c 2 α-g cosh (α-g)τ c -1 → 1 2 (α -g)τ 2
Just as in flat-spacetime, the metric equation in general associates a set of {t, x, y, z} bookkeeper-coordinates with each event. In the Schwarzschild case, however, clocks can only be synchronized at fixed-r. Hence a radartime model [START_REF] Dolby | On radar time and the twin paradox[END_REF] (or some such) of extended-simultaneity might be needed to answer the question "What time is it now at radius r?"

The good news for the case of Schwarzschild (and other steady-state metrics) is that γ ≡ dt dτ = E mc 2 can be defined regardless of one's model for extended-simultaneity. Although in general momentum p ≡ d x dτ remains synchronyfree, definitions of synchrony-dependent energy may encounter significant complication when the bookkeeper time-derivative dt dτ becomes dependent on extendedsimultaneity.

We further show that frame-invariance (where all frames agree) is quite valuable for illustrations. The synchrony-free nature of proper-velocity and momentum, as well as of force-components described as derivatives using proper-time τ instead of map-time t, also lead to a simpler and more robust picture of accelerated motion when examined from the point of view of the accelerated traveler.

• simultaneity whose frame invariance may be (only temporarily) put aside by using the metric equation to select but one "book-keeper" definition of simultaneity, and

• force Σ F ≡ d p/dτ which we deal with by introducing the net felt or "proper-force" Σ F o (from the traveler's perspective) whose magnitude (like proper-time τ and lightspeed c) is frame-invariant.

Note that rates of energy-change dE/dτ are framevariant even at low speeds: For instance, dE/dτ is always zero in the rest-frame (as well as the "tangent free-floatframe") of an accelerated object even if energy is rapidly changing from the vantage point of other frames.

In curved-spacetimes and accelerated-frames, key concepts include the added ideas of:

• bookkeeper coordinates in the metric-equation which may be chosen for convenience but might not permit extended networks of synchronized clocks,

• vectors as locally-defined tangents 3 instead of as lines between points A and B,

• free-float (geodesic) trajectories and "tangent freefloat-frames" in particular, and

• geometric (connection-coefficient) forces as distinct from proper-forces.

As discussed in the article, of course, the latter are also not new to students of low-speed physics if "inertial forces" like centrifugal and Coriolis have been studied. These caveats in mind, familiar relations in scalar and/or 3-vector form can often be written with an additive (γ -1) term for the eifo-correction. For instance, the motion-related eifo-correction to frame-invariant restenergy mc 2 in flat spacetime is simply kinetic-energy (γ -1)mc 2 , coordinate-time dilation for proper-time interval δτ may be written as δt = δτ + (γ -1)δτ , and vector length-contraction for proper-length interval L o is

L = L o + (γ -1) γ L o || w , (A1)
where the subscript || w selects only that component of L o which is parallel to proper-velocity w.

More generally, for 4-vector {X t , X} the Lorentz boost to a primed-frame moving at proper-velocity w has timecomponent

X ′ t = X t -w c • X + (γ w -1)X t . The space- component is X ′ = X -w c X t + (γ w -1) X || w .
Since proper-acceleration is purely spacelike in the frame of the accelerated traveler, we can say that the time-component yields the flat spacetime work-energy expression dE/dτ = m α • w = Σ F o • w. The spacecomponent says that the frame-variant force can be expressed in terms of proper-acceleration [START_REF] Levy | A simple derivation of the Lorentz transform and of the related velocity and acceleration formulae[END_REF] and propervelocity as:

Σ F = d p dτ = m d w dτ = m α + (γ -1)m α || w , (A2)
The second term here is a correction to the net properforce Σ F o = mα that (like the only term in the workenergy expression since "proper-power" is always zero) allows one to determine the net-force Σ F ≡ d p/dτ from the map-frame perspective. Note that since proper-velocity uses a time-variable localized to the traveler (and hence does not require synchronized map-clocks along the traveler's trajectory), these 3-vector expressions may be useful locally in curved as well as flat spacetime settings, provided that we have a definition for γ ≡ dt/dτ (from the metric) and hence an effective value for traveler total energy E = γmc 2 .

In flat spacetime, where the metric tells us that γ ≡ dt/dτ = 1 + (w/c) 2 , one can obtain the energy-integral differential equation:

c 2 α γ = 1 + γ + ( c α γ) 2 1 + γ α (A3)
where the dot refers to differentiation with respect to proper-time τ , and w || = (c 2 /α)dγ/dτ . This integrates pretty quickly to the contents of Table II. Table III entries then follow directly for the (1+1)D case by letting γ o → 1.

For the Schwarzschild potential, dt/dτ becomes γ r (1 + (γ r w/c) 2 ) if γ r ≡ 1/(1 -r s /r) and r s is the event-horizon radius 2GM/c 2 . Application of equation A2 then only qualitatively yields the approximate relationships in Table IV.

Note also that the rescaled velocity-term in equation A2 is reminescent of the factor (γ BC + (γ AB -1) w BC || w AB ) that rescales (in magnitude only) the out-offrame proper-velocity w AB → ( w AB ) C when calculating relative proper-velocity 3-vectors by 3-vector addition:

w AC ≡ γ AC v AC = ( w AB ) C + w BC . ( A4
)
Thus a focus on frame-invariant and synchrony-free variables might help cautiously open the door to a wider range of "dimensioned 3-vector" relativistic explorations. Finally, let's examine the connection of these equations to the Lorentz-equation for electromagnetic proper-force, which underpins Fig. 3 as well as most proper-forces that we encounter in everyday life. It is also a prototype for the Maxwell-like equations that underpin field-mediated proper-forces in general. In terms of electric E and magnetic B fields in a frame with respect to which a charge Q is moving at proper-velocity w = γ v, we can use the Lorentz-transform equations (SI-units version [START_REF] Jackson | Classical Electrodynamics[END_REF] ) for the electric field in the "primed" frame of charge Q to write the proper-force as:

Σ F o = Q E ′ = Q E || w + γQ( E ⊥ w + v × B) (A5)
Although the force on our moving charge (as a rate of momentum change) is in general frame-variant, all observers (traveling at any speed even in curved spacetime) should be able to agree on the proper-force and properacceleration that the charge is experiencing. Putting this general expression, for the net frame-invariant properforce on a moving charge, into the expression for net frame-variant force above gives us:

Σ F ≡ d p dτ = γ d p dt = γQ( E + v × B) (A6)
This Lorentz-force expression, here obtained from the electrostatic definition of E and the field transformationrules, illustrates how a "magnetic field" that yields a force perpendicular to velocity may serve as a natural complement to any static "proper-force field".

FIG. 1 .

 1 FIG. 1. Two views of proper (red) and geometric (dark blue or brown) forces in some everyday settings.

FIG. 2 .

 2 FIG.2. Free-float and ship frame views of a pentagonal dropped-ball trajectory in a rotating-wheel space habitat, to illustrate the non-contact nature of the "cell-phone undetectable" centrifugal force.

FIG. 3 .

 3 FIG. 3. Two views of proper force on a moving charge from a neutral current-carrying wire, with 40 millisecond time-steps between after-images. The shorter light-arrow in the wire-frame is the coordinate-force f ≡ dp/dt = Fo/γ ⊥ . Effects of the depicted forces on the charge-motion are ignored, as is the B-field in the moving-charge frame which has no effect.

TABLE IV .

 IV Relationship between variables for acceleration in (1+1)D gravity: Here τ is traveler-time from "turnaround" for fixed proper acceleration, while as usual g ≡ GM r 2 and rs ≡ 2GM c 2 . Here ≃ neglects changes in g and → assumes that ατ ≪ c.

	4-vector invariants	time-components/c	space-components
	acceleration α ≡ ΣFo m	dγ dτ

ACKNOWLEDGMENTS

Thanks are due to: Roger Hill for some lovely course notes, Bill Shurcliff for his counsel on minimally-variant approaches, as well as Eric Mandell and Edwin Taylor for their ideas and enthusiasm.

Appendix A: 3-vector relativity By way of example, A. P. French 1 examines coordinateacceleration components with respect to coordinatevelocity, J. D. Jackson's relativity chapters [START_REF] Jackson | Classical Electrodynamics[END_REF] do an excellent job at showing both 3-vector and Lorentz-covariant (4-vector) versions of the way that electro-magnetic proper forces work, and D. G. Messerschmitt 15 has examined scaling relations for proper-acceleration from a modern engineering perspective. Each of these has focused on components relative to the direction of motion, rather than relative to the direction of proper acceleration e.g. of a rocketship which has local control of its direction of thrust.

One must of course use caution in using relativistic 3vectors (especially in curved-spacetime and acceleratedframes) because many implicit Newtonian assumptions are no longer valid. One may also encounter dissonance from uni-directional "simplifications", like the breakdown of relativistic-momentum p into a product of "relativistic-mass" γm and coordinate-velocity v ≡ d x/dt, rather than into a product of frame-invariant restmass m and synchrony-free proper-velocity w ≡ d x/dτ = γ v.

In flat spacetime, quantities demoted to the status of frame-variant or "effective for the indicated frame only" (eifo [START_REF] Shurcliff | Special relativity: The central ideas[END_REF] ) include:

• coordinate-time t in comparison to the frameinvariant proper-time τ elapsed e.g. on a traveling clock,