Okay, perfect. Okay, so thanks a lot for the invitation, first of all. I will report about

the work we are doing in the HEPIX benchmarking working group to benchmark WLHG resources.

So essentially, okay, this is the outline of my talk, so first I'll discuss why we need

Sorry Andrea, we see slide number seven currently.

Oh, sorry. I, yeah.

Sorry, I was on the wrong screen. Okay, sorry. So, okay, so I discussed the introduction,

so this is the outline of my talk, essentially I discuss why we need benchmarking, what was

the old approach and its limitation and what is the new approach, implementation, the status

and some outlook. So, in the previous talk, we already introduced, so Lucas already introduced

a bit CERN and the computing environment. So essentially, from the computing resources

point of view, the work that the LHC experiments at CERN are doing, essentially they execute

their jobs on the WLHG, which is the worldwide LHC computing grid. This is a distributed

resource infrastructure, which includes many countries and many sites, so hundreds of sites.

And so the job is distributed on different types of CPUs and there is a need to understand

which CPUs and how many they use. So you see here in this plot, there are essentially

one million CPU cores, but essentially each core is different from another, because some

are able to do more work than others and also, of course, the price is different for different

types of CPUs. So essentially, why we need to benchmark CPU resources for various reasons.

The first is accounting, in the sense that experiments request the amount of resources

they need for their computing, giving a number. So X CPU resources, the funding agencies and

the sites must provision this X and then the resource review boards must compare this X

which was used to the one which was requested. Related, but slightly different, is procurement

in the sense that then the site actually have to buy the resources to provide this X. And

these benchmarks in any case, they can also be used for other things like scheduling and

software optimization. Now, I should say, when I heard that I had to give this talk, I mean,

I'm going to discuss what we are doing, which is benchmarking of computing resources, which

is maybe not benchmarking of the software itself. Of course, it's very related, but

let's say the numbers we get are essentially to decide how much work a given software can

do on some different types of resources. So on the next slide, this is essentially the

benchmark that has been used so far in WLCG is called HEPSpec 06. So you can see here

a typical plot which is shown at the review board. You can see the evolution of how much

CPU power in terms of this HEPSpec 06 has been delivered over time to the four different

experiments. And then you can also see on the other plot essentially how much this compares

to actually what was used, how much was given with respect to what was pledged, what was

promised. Just as an approximate rule of thumb, then HEPSpec 06 corresponds to one core, essentially.

Now, HEPSpec 06 is derived from SPEC CPU 2006. SPEC CPU 2006 is a benchmark developed by

the Standard Performance Evaluation Corporation, and it's an industry standard since the late

80s. Since this is actually an open source software workshop, we should mention also

that SPEC CPU 06 is not open source software, so it's licensed software.

One of the main points about this benchmark is that it's based on real application. Now,

CPU benchmarks in general, let's say there are three kinds. There can be synthetic kernel

benchmarks, kernel benchmarks for real applications. This is based on real applications. However,

it's not based on applications from HEP. It's based on applications essentially from other

scientific domains. In particular, in this suite, there are seven benchmarks. You see

the details there, four of which are floating point benchmarks and three are integer benchmarks.

These are essentially the C++ benchmarks because our main language is C++.

On slide seven, I say why actually this was chosen back in 2009, so more than 10 years

ago. Essentially, two things. One is that it showed good correlation to the throughputs

of HEP workloads, essentially to how many events per second you can process on a given

resource. Essentially, there was a good correlation between the benchmark given by SPEC 06 and