Print

Print


James and John, this is a very relevant and interesting - and non-trivial - part of the problem (in the sense that any proper numerical analysis is non-trivial - I can't quite resist referring to the classic Goldberg paper [1]).

On the science side, it'd have to be thought out carefully, like sometimes when you're fishing for eigenvalues, you may just need low accuracy on the highest magnitude ones and then selectively pick the ones for which you need more accuracy. I guess you could do the tyre-kicking approach, try reducing precision and see if your calculation goes awry, like in Sue's presentation.

The strategic question would be what a CSP should offer in this respect: would it make sense to offer faster/greener calculations in 32 bit floats, 16 bit, 8 bit? (8 bit "floats" for neural networks) - some programming languages offer up to four different kinds of reals natively but mostly (historically) to reduce the storage requirements.

Cheers
--jens

[1] http://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf

________________________________
From: UK Cloud Computing Special Interest Group [[log in to unmask]] on behalf of James Thorne [[log in to unmask]]
Sent: 09 January 2018 13:51
To: [log in to unmask]
Subject: Re: Initial thoughts on cloud strategy


The Computational Science Centre for Research Communities (CoSeC) https://www.scd.stfc.ac.uk/Pages/CoSeC.aspx has been helping the UK’s Collaborative Computational Projects (www.ccp.ac.uk<http://www.ccp.ac.uk>) and High-End Computing Consortia to look into this. The CoSeC’s Software Outlook Project will soon be launching a training course on the use of different precisions within codes, considering both on computational time and energy consumption. Software Outlook recently gave a talk at the RSE17 Conference on this area of work https://epubs.stfc.ac.uk/work/34840371

James.

On 09/01/18 11:18, John Hearns wrote:
Jens,
   you make some very relevant points.

Also let me add choice of precision of the mathematics in the problem.
If I am not wrong, an arbitrary limit on 30MW has been proposed for an Exascale machine.
By tthat I mean that at the moment an exascale machine is perfectly possible - but it would just consume a huge amount of electrical power.
I read a very good paper a few years ago which discussed the choice of arithmetic precision for problems: "picowatts per flop"
I believe software authors will have to pay more attention to the coice of presicion (or integer) computation.
For instance we see that Machine Learnign workloads on GPUs quite happily use single precision.
I have lost the reference to this paper (sorry)


On anther note, I believe that Formula 1 teams were consideting a limit of the power budget for CFD simulations.
Of course there is much dancign on pins going on there - do you consider the power to the rack (which you can measure easilty at the PDU)
But how about the power used for cooling?  I guess you have to consider your entire data centre as an adiabatic box and meter the overall power in.
checking the 2017 FIA regulations though there is still a FLOPS cap.































On 9 January 2018 at 11:58, Jensen, Jens (STFC,RAL,SC) <[log in to unmask]<mailto:[log in to unmask]>> wrote:
Hi all,

Following up from yesterday's workshop, where Phil invited suggestions
for thoughts on strategy, here's one of mine.

In the future, publicly funded research will get two grants: one in
money and one in CO2. Think of when you book your flight and they tell
you about the CO2 "you" will produce by travelling, to make you feel bad
and donate to their carbon offset fund, so you can forget all about it
and just travel.  Maybe in the future cloud data centres will be forced
to do the same (i.e. advertise CO2 cost and let customers offset it
against their budget or by a carbon offset levy) - we're already seeing
stories in the media about how much of the world's electricity goes into
data centres.

People have researched lots of ways to greenify computing - off the top
of my head:

  * FP7 and H2020 projects have looked into selecting "greener" cloud
    services (OPTIMIS springs to mind, it was one of four basic parameters)
  * Custom-programmed FPGAs, lower powered (and slower) devices for less
    urgent results (e.g. results which would wait for dependencies in
    the workflow anyway); tapes for cold data, and MAID for cool data.
  * Transiently powered computing (e.g. solar)
  * CMS looked at event processing by kW instead of by hour.
  * Choose a different region (far away) and let them have the CO2 ;-P
  * (or rather a region with greener power or cooling, like the Iceland
    data centres.

We saw yesterday how a cluster in the cloud could grow on demand up to a
limit but its aim for doing so was to keep the cost (£ or € or $) down,
not the carbon.

So which is the right kind of green - it can't just be a raw CO2 budget,
or can it?  But finding the roadmap to the right shade of green should
be a strategic objective, so we have a response when they come and ask.

Cheers
--jens

--
Dr Jens Jensen
Mad Scientist, Scientific Computing Department, STFC (www.stfc.ac.uk<http://www.stfc.ac.uk>)
Rutherford Appleton Laboratory, Harwell Oxford Campus, OX11 0QX, UK
T/F +44(0)1235 446104<tel:%2B44%280%291235%20446104>/5945



--
James Thorne
Senior Computer Systems Administrator
Diamond Light Source Ltd
Tel: 01235 778306 (Duty Sysamin can be reached on x8596)



--

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom