1 |
On Wed, Aug 23, 2017 at 6:29 PM, R0b0t1 <r030t1@×××××.com> wrote: |
2 |
|
3 |
> As an example, I am interested in characterizing the power consumption |
4 |
> of rendering a PDF document. I would hopefully only need to run the |
5 |
> renderer once. |
6 |
|
7 |
|
8 |
The catch with that goal is that a) rendering a PDF is likely as much of a |
9 |
ram and disk intensive process as it is cpu intensive, b) the computational |
10 |
complexity of it is *completely* dependent on the source's complexity, and |
11 |
c) the actual power draw of the system will even vary based on external |
12 |
environmental factors. For a specific document, you could measure it by |
13 |
pre-loading everything into ram (so disk and ram i/o for the executable and |
14 |
data to process aren't factors), ensure the system is truly idle (i.e. no |
15 |
background processes, including scheduled tasks), take a power usage |
16 |
measurement (preferably with an external, physical, power meter) as a |
17 |
baseline, then run the process N times in a loop, and take a measurement of |
18 |
both the total run time and the change in power draw. From there, you can |
19 |
divide the run time by N, the multiply by the change in power draw, to get |
20 |
the result. That'll tell you roughly how much power you would draw every |
21 |
time you rendered that particular document, from ram, on that system, with |
22 |
those exact settings, in a room at roughly that temperature and humidity. |
23 |
That's potentially useful for profiling during optimization of a very |
24 |
specific workflow in controlled conditions, but it's really of questionable |
25 |
usefulness beyond that. |
26 |
|
27 |
-- |
28 |
Joshua M. Murphy |