Okay, so, hello everyone.
Thank you for letting me present today at first them.
I would like to talk today about unify full stack performance analysis
and automated computer assistant design at the same.
In relation to the recent project, which we have started,
called Adaptest.
So, to start things off, a few introductory words about myself.
So, hello.
I'm Max.
Currently, a junior performance research engineer,
working for nearly three years at a time.
And I will be shown a PhD student actually in April this year,
starting at a time and a PhD student.
And when it comes to my background, I'm a computer scientist by training.
I graduated with a master's degree from Imperial College in 2002.
With a thesis dedicated to performance analysis closer to hardware and very short words.
And my interest involved about everything related to software and hardware,
specifically at the boundary of software and hardware.
So, performance analysis, computer architecture, compilers,
operating systems, FPGA, et cetera.
Especially in the context of applications to physics and space research,
which is one of the main reasons why I work at the moment.
And to this time as to my site,
this is my first form ever.
So, apart from presenting Adaptest, I'm also here to learn and network.
And I will be happy to hear constructive feedback from you after the presentation.
And the second disclaimer, I'm not a physicist.
So, if you have any questions related to physics we do at certain,
I may not be the guide person to answer this.
Even though I will try to explain some physics we do in our organization,
if time allows.
And, but what I can recommend to you is actually going to the same open source
stand we have at first them in building K.
So, I would like to ask you a question, who knows what sign is?
Wow, that's a lot.
So, I have this slide, explanatory slide, just for those of you who are not familiar with our organization.
So, sir is the European Laboratory for particle physics,
which is the world leading particle physics facility,
located in Geneva in Switzerland.
Specifically, it's literally at the border between Switzerland and France,
next to Geneva.
And particle physics wise, it's best known for the large pattern collider,
which is one of the biggest scientific machines in the world,
where particles are accelerated and collided with each other,
with more than 99.99% of speed of light.
And this is where the Higgs boson was discovered in 2012,
which explains the origin, which is in the origin of mass.
But it's also known as the birthplace of the World Wide Web,
for example, computer science wise in the 1990s.
And while we, our main research involves a particle physics,
we also do some research in related fields like astrophysics and cosmology.
But if you think that computing is just a small after-for-at-sang,
even that we are at physics lab, you cannot be more long than that.
Actually, computing is one of the three main pillars at cell,
alongside accelerators and detectives.
And there is a photo, this is very simple.
Just take a look at the diagram on the guide,
showing our accelerator complex.
This is a multitude of machines, where particles are accelerated
and collided not just with each other,
but also against a fixed target in case of smaller accelerators.
And at many collision points in these accelerators,
I will all talk here about the latch that are collided here.
We have installed particle detectors,
which collect information about interesting physics happening
at the time when accelerated particles collided with each other.
And because, again, in the context of the LFC,
we have one particle collision, every 25 nanoseconds.
This means that this particle detectors generate an enormous amount of data.
Not to mention the fact that the complexity of the machines we have
means that controlling, monitoring and operating and
synchronizing everything with each other,
so that all the particles know where to go inside the accelerators.
It's not a straightforward task.
So all of this creates computing challenges at
virtually all levels from embedded and real-time computing
up to high-performance computing and distributed computing.
And just I want to show you the four major experiments
with particle detectors installed on the LFC.
So we have CMS, LFCB, Atlas, and Alice.
So because this is the last of the performance dev group,
I want to talk about performance.
So obviously performance is very important for us,
and we do several performance analysis tasks,
but it's not without problems.
So this list is just the tip of the iceberg,
and it's not an exhaustive list in no particular order.
So for example, we encounter notoriously
deflagmentation of performance analysis tools.
We have a very, we use a variety of platforms.
And essentially for inter CPUs, you have inter-video.
For AMD CPUs, you have AMD Upro.
For Nvidia GPUs, you have Nvidia insight.
For AMD GPUs, you have rock profiler and similar tools.
For some other exotic architecture,
you have some other exotic fancy profiler.
And many of these tools are either proprietary,
not user-friendly, or not compatible with each other.
And this makes life difficult for us,
especially when we want to make comparisons between various platforms,
in order to decide how to optimize our software,
or for example, what hardware to buy.
And in some cases, we don't even have any nice performance analysis tools at all.
For example, in the context of some accelerator control systems,
embedded computing.
Another problem is the necessity of optimizing
and porting codes for architecture,
especially in the context of how technology is computing,
which becomes more and more popular in our cycles.
And with how technology is computing,
you have a variety of programming models.
You have CUDA, GoCAM, you have also more unified programming models,
like Cococic, there's also an MP, for example.
And the thing is that our software used for processing data
from the Large Hadron Collider and other experiments is very large.
We are talking about the magnitude of millions of lines of code.
So you can imagine that porting and optimizing everything,
so that it works flawlessly on various architectures,
is not easy, let's say.
Another thing is related to our complexity of systems,
and a mixture of programming languages and models
across the entire complex.
And this means that analyzing everything in one go,
or at all, performance-wise, is either difficult or close to impossible.
Not to mention problems with resource limitations,
like developer hardware, network bandwidth, memory developer code, etc.
strict time constraints in real-time systems,
for example, deployed in accelerator controls,
or data filtering systems at the Large Hadron Collider,
which I hope I will be able to talk about
an slightly more detailed talk at the end of the presentation.
And the last point is probably obvious,
but there might be some optimizations,
because the entire stack, like in software hardware,
or systems in general, which we are not aware of yet.
And maybe this would unlock some very big performance gains
that would allow us to discover more physics,
but we are not aware of these optimizations.
And this is also a problem by itself.
And by performance, I don't mean just runtime.
Now, I also mean stuff like energy efficiency,
because sustainable computing is a big topic
in our own sectors at some.
Not to mention some more trivial stuff,
like power and cooling constraints we have.
And given the recent trends in the technology world,
like the slowdown of most slow and then at scaling,
only algorithmic, only hardware, or only system optimizations
are not enough in isolation.
So you cannot do just one of these alone.
You need to look at the big picture and do everything together nowadays.
So as a response to these challenges,
please say hello to adapters.
And early phase, comprehensive and architecture,
agnostic performance analysis tool,
addressing your software, hardware, and system needs,
all at once, both today and tomorrow.
And adapters was born as part of the cycles project,
funded by the European Union,
and it has four main characteristics.
The first one is the modular design,
which makes adapters always up to date with the market,
and it makes us adapt this,
able to analyze performance of any workflow you can imagine,
and any hardware and any system combination you can imagine,
as long as there is support provided forward by contributors,
either from our team or even from some of you in the future.
And this is provided for modules for system and hardware components,
and plugins, in case of workflows.
But plugins are currently not supported in an artist,
but the support for these plugins will be available soon.
And don't worry, if there is something which is not 100% clear yet,
I will have an explanatory diagram about modules,
plugins, and there are adapters workflow in a few moments,
and I hope this will clear out any confusion you may have at the moment.
The second characteristic is architecture agnosticism.
So it doesn't matter whether you have an Intel CPU, AMD CPU,
ARM, R, R, R, R5, and VGA GPU, something else,
like an FPGA, or a customer accelerator,
adapters gets you covered, as long as there is a module for that.
And the fact characteristic is related to one of the modules we already provide,
and it's related to analysis of on CPU and of CPU activity
of all of your code running on Linux.
And this is applicable to all threats and processes found by your code,
along with any low-level software hardware interactions
that may happen when your code is run.
For example, paid falls, cash messages,
retired instructions, et cetera.
And last but not least,
I was given that it's for them, we are open source,
coming from saying for the benefit of all,
and our project is open to contributions from you guys.
And I will talk about how you can help us out,
closer to the end of the presentation.
So, an update is meant to tackle the challenges I just mentioned,
and help advance computing at saying,
and obviously beyond, because one of the missions of saying
is contributing back to the society.
And given that we have the variety of platforms,
along with various use cases,
the eventual goal of adopters is becoming not just a performance analysis tool,
unifying performance analysis,
applications and APIs,
but also becoming a full-stack system design and compilation,
along with software hardware,
co-designed tool across the entire computing spectrum.
And by this computing, up to XSK and HPC computing.
So, to get started with adopters,
you have basically this flow here,
and you start with defining your computing workflow to be analyzed.
And this is where plugins come into play,
but the current version, just but one caveat here,
is that the current version of adopters only supports
running commands as part of your workflow.
So, if you have a program which has already been compiled,
and you want to run it and profile it,
this is what running commands is about.
But in the future, it will be possible to construct
most sophisticated workflows,
consisting of several plugins,
such as plugins for running code,
compiler, to some intermediate representation,
like LLVMIR.
And on the other side, you define a computer system,
which your workflow should be analyzed against.
And this could be the system consists of notes and entities.
Notes can be imagined as computer peripherals
with modules attached to it,
and these are responsible for modeling
and or profiling your hardware assistant component,
like GPU, CPU, FPGA, memory,
persistent storage or something else.
And the generality of notes can be changed
without any issues here.
It's all depends on the availability of modules.
So, if you want, for example, to speed CPU into several parts,
like one for cartridges, one for instructions,
and one for something else,
you can do it if there are modules available for this.
And similar for example, similar for other notes.
And entities can be imagined as computer servers,
consisting of these, consisting of these notes.
And these entities can be, for example,
connected by, by nets, I'm networking,
or some other connection here.
And once you define these two things,
the workflow gets converted to the adaptive intermediate representation,
which is at the moment and form of state-full,
multiflow data graphs,
researched by the scalable parallel computing lab
at ATH2G.
There was actually one talk about,
about the day-situna company,
yesterday in the AI Planberg's dev room,
where SDFGs were also used.
So, if you want to know more information about SDFGs,
I also invite you to watch that talk once it becomes available.
And when the AI is ready from the workflow,
the modules come into play,
and start doing performance analysis of this,
of this AIR.
So that you can extract your performance insights
about your workflow.
And one important thing about,
also about modules, is that they decide
how their performance analysis results
should be displayed to the user afterwards,
because it's not enough to do just performance analysis.
You want to browse these results
and infer some conclusions from this.
And for this, we have a dedicated program called
Adaptive Analyzer, which produces an interactive website
that you can browse to view your analysis results.
And I have a demo video that I will show you in a few seconds.
And I mentioned that Adaptive is meant to be
an automatic computer system design tool.
And this will be achieved in the future,
in the course of my PhD research,
by constructing the system graph automatically
with hints from a user,
and where obviously with a workflow.
So for example, if you provide just a workflow
and a partial system graph here,
which is in this case,
an alternative of two CPUs, CPU1 and CPU2,
connected to a GPU and optionally to a custom accelerator,
then Adaptive will determine automatically.
What CPU should be picked,
either CPU1 or CPU2,
and whether a custom accelerator should be connected
to your system.
And what parts of your workflow should be done
on what compute you need?
Like CPU, GPU, custom accelerator et cetera.
And this particular system graph
always contains only compute units.
But for example, Adaptive will be able to construct
automatically, memory characteristics,
storage solutions, networking solutions et cetera.
Basically everything depends on the,
everything depends on the work being done on modules.
And this is our ambitious roadmap
for the next several years.
But we already provide some modules now
for performance analysis.
We have Linux, which is based on
as an instance on Linux path, with our own custom patches.
But in order to have better maintainability of the module,
we are moving soon to an in-house equivalent,
based on path event opens the score,
or EBPF soon.
And the functionality of Linux path
is sampling on CPU and of CPU activity
of all threats and processes spawned by your code.
Well, minimizing the risk of getting broken profile stacks,
as long as your programs are compatible
with phone numbers, phone now.
Linux path also performs cache aware of offline profiling.
Thanks to the integration with the current tool
from NSKD, which is one of our academic collaborators
in Lisbon and Portugal.
And it supports custom something-based path events
for profiling more intricate interactions
like paid sources, I said.
And we also have one more module and VGPU
for tracing CUDA API calls at the moment,
driver and runtime API to be specific.
But more features are coming soon as time passes
and users provide their feedback,
because we have several use cases
at certain utilizing and VGPUs.
And we have two more modules, which are either working progress
or planned.
One is about analysis of any metrics obtained
at the performance channel tools, like power consumption
or custom other custom metrics.
And one is about analysis of environmental software,
running without any operating systems on systems on trips,
like selling sources with CPUs and FPGAs.
So what are the things we analyze already at San,
or we want to analyze at San overall?
For example, latency, throughput,
usage of memory and other resources,
parallelization opportunities,
so that we can deploy GPUs or other accelerators.
Utilization of low-level hardware features,
like pipelining or vectorized instructional CPUs,
performance of code compilation and GIT, if used,
and this is more about compilation,
configuration and options,
rather than optimizing compile implementations for now.
But we are open to investigating
regarding compilers to some point,
maybe in the five future, let's say.
And last but not least,
energy and higher consumption,
in the context again of sustainable computing
and cooling constraints we have.
And when it comes to the state of adaptive features,
related to these metrics we want to analyze,
we can already do latency
and to the usage of low-level hardware features.
Energy and higher consumption can be done
already, I would say,
because it supports a profiling energy consumption,
so the Linux performance should be
might be able to advance some profiling
related to energy consumption as well,
but I didn't market as supported by adaptive
because I have never tested it,
and so I'd rather play safe for now
and say that it's not supported yet.
But all the blue texts mean that,
I mean that basically the support of adaptive
for these metrics is either already planned,
or we can be added in the future.
Again, thanks to the modules.
So you want to get started with adaptive
in practical times.
Easy, easy.
It's open-source, of course.
And you can get it from here from our website,
adaptus.web.cent.ch.
But if you don't want to read
polling documentation,
etc, you can just go to GitHub and see
our repositories.
And this is also fine.
But you will probably want to visit our website anyway,
because it's the website,
which has the installation instructions
and that's already available as an early development version.
So it's not production yet yet.
And form of a source code,
but other variants are coming,
like pre-built binary.
Because obviously we want adaptive to be as accessible,
as possible, to as many people as possible.
And once you set up adaptive,
getting started with which, as I said, is easy.
So we want adaptive to be as accessible,
as possible, to as many people as possible.
And once you set up adaptive,
getting started with which, as I said, is easy.
Let's start with defining a one entity system graph.
Which has a CPU node,
with the Linux-perf module attached to it,
and then now with the node being placed inside
an entity called entity one.
So your only need to do is to define a system graph
in a YAML file here using the syntax.
I will not dive into too much detail about
how to guide the syntax.
You can check the documentation from this.
And once you save this file,
you're going to adapt this by saying,
by running adapt this dash s,
system requirements,
which points out to adapt this dot.
Okay, my system graph file is in system requirements.
Dash D, which means,
okay, I want to provide a comment on me
because this is the only option which is supported at the moment.
Followed by double dashes,
and the comment to be profiled without any quotes.
And once you earn it,
you wait until it produces something along these lines.
With the performance analysis result,
I get to hear.
And afterwards, you move this result directory
to some empty directory of your choice.
For example, result underscore div,
and then you can adapt this analyzer
while pointing it to result underscore div.
And then you just open the website in your web browser,
like you do with Jupyter node books,
and you are done.
Have fun.
So I have the demonstration video,
which I will play to you right now,
because I will start not to do live demos.
So no live demos today, so okay.
So this demonstration presents adaptis analyzer
with two performance analysis sessions,
then on some snippets of the good framework,
which is a widely used analysis framework
for experimental data at sound.
Please don't confuse this with good accounts.
This is a completely different thing.
If you want to check out good,
you can scan the QR code here to visit
our, to visit the good web site,
or just visit go to dot set.
I think this is simple,
I just don't remember.
So yeah, so let's do the demo.
This is the initial screen of adaptis analyzer.
When you can select a performance analysis session,
look at the top cover books.
Once you make your selection,
you start with the system graph view
with empty different nodes.
Double click any node and select the module
to open its results.
In this case, we have little spills.
With the time and view of threads and processes,
with red parts corresponding to our CPU,
and blue parts corresponding to our CPU activity.
Right pick a thread to see its runtime,
spawning stack trace and available analysis types.
To open an analysis, just click it.
Here, with a flag laughs,
which allow you to quickly check the performance
of specific parts of code.
In this case, you can see information about
all the time of the main thread.
Flamethrfs are interactive.
You can zoom in, zoom out,
search with regular expressions,
switch between not time-outed and time-outed expressions,
et cetera.
In case of all time,
Flamethrfs are hotened code.
The cold envelopes closer to blue
are more off CPU,
while the hot envelopes closer to that
are more on CPU.
If available,
thank us for other metrics,
can be opened in the top left combo box
next to time-outed.
You can also view source code of a block
by right clicking it,
and pick it view the code details.
This opens a preview window with your code,
with most critical lines highlighted
in stronger shades of red,
or blue, in case of wall time.
You can hover over under right nine numbers
to see more information about
the contribution of keyword code lines.
If needed,
you can rename windows
to whatever you like,
or temporarily hide them.
Just click the relevant button
and a title bar.
You can open multiple windows at the same time
across multiple sessions.
This allows you to make side-by-side comparisons.
For example,
we have the root code snippet
where moving computation from CPU on a GPU
makes the code more eye-opout
by shrinking the highlighted compute flag of legends.
There is an option
of replacing text occurrences in flag graphs.
For example,
if you want to show them
very long function names,
you can use regular expressions here.
Text the placement
can be updated easily
by right clicking the find-and-read
place button and picking your replacement.
Some fling of elements
are compressed,
and shown as light-panker blocks
to save from entering the sources.
This can be expanded easily
just by clicking them.
The Linux-5 module features also
integration with the current tool.
Took on use cache and way to go
flight blocks along with points
corresponding to specific aircraft blocks
as shown on the guide.
Here's an example
of a slightly more complex system
and look with information shown
by the NVGPU module on the right.
Currently,
NVGPU supports tracing
CUDA API calls
for specific code legends
that are related displayed on the timeline.
To see detailed
collusion times,
write with a given region.
OK,
so that was the demonstration video
of Adapis on the Liza.
So now you may wonder
why another performance analysis tool?
Why another profile
or another tool of a similar nature?
So I have compiled
this nice and compact comparison table
between Adapis and other similar
and my tent profiles.
And I can also tell you
that Adapis also is not meant
to be just another profile.
It means it's meant to be a tool
which unifies
which tries to unify
the already existing ecosystem of performance analysis.
And I'll also have automated computer
system design, as I mentioned before.
I want to talk about the table itself.
I will only say that Adapis is
hardware vendor potable.
That's on this file.
Analyze software hardware interactions
to the extent supported by users
a computer architecture.
It's open source, of course.
It's supported of CPU profiling.
It has flexible support
of categorized and custom architectures.
Thanks to the modular design.
And it will have a flexible support
of multi-note systems soon.
Once the entity support of Adapis
will be expanded.
So now let's talk about computing.
As you may guess,
performance encompasses all of computing.
So we are sure that Adapis can help you
in your work.
So please try our tool out
and give us feedback.
And this will already make us happy.
But obviously we will also be happy
if we see code contributions from you guys.
And this is because your help will actually
push forward research and development
on automated software hardware
code design.
And in case of modules,
increase the visibility of software
system and hardware products.
Among users, such as CPUs, GPUs,
custom accelerators, etc.
And by contributing to Adapis,
you will also help address performance problems
we have at some.
And therefore help science.
And if you don't know what
or how to contribute beyond trying the tool out,
we have some ideas here.
We have some ideas here.
But these are obviously not,
not binding at any point.
If you have some other ideas,
just feel free to talk to us.
Or to send us a message.
Adapis dash contact at send.ca.
We read every email center,
unless it's obvious spam, of course.
And I can also tell you when it comes to
Adapis addressing performance problems at
send.
We already have one success story related to it,
even though it's an early face project.
And this is related to porting
some parts of the good framework from
CPU to GPU using this,
using this SQL programming model.
Basically Adapis proved that
the computation part of one of our benchmarks
was slashed by 92%.
When moved from CPU to GPU.
When the overhead of running Adapis
was less than 3% and the workload itself,
which was analyzed,
ran for several minutes.
Like on the GPU, a ran for three minutes
and on the CPU, it ran for more than 10 minutes
as far as I say remember.
So yeah, again, you feel free to contribute.
And talk to us if you are interested in
helping us out with Adapis.
So now I don't have much time left,
so I will basically quickly go through these slides
about what actually happens computing
wise when particles collide in the LHC.
So I will use the example of the Atlas
experiment here.
So here you can see a slice of a particle
detector.
Particles collide here and they create
another set of different particles,
which go through various trackers and
detectors meant to detect and map
various types of particles.
And as these events are detected by
the detectors, they are digitized
and send further down the pipeline for processing.
But we have one collision happening
every 25 nanoseconds.
So we have an enormous amount of data,
which cannot be all set and processed.
So this is why we have filtering systems.
So you can see that at the very beginning,
we are talking about data rates
of the magnitude of 60 telabytes per second.
So we need to have filtering systems.
And in this case we have the level 1 trigger,
which meets to make a decision
in a very short time frame,
whether an event should be saved for further processing.
And this is usually implemented using FPGAs.
And then we have high level trigger,
which decides in a slightly longer time frame,
whether an event should be saved for further processing.
And this uses more, let's say,
we can use more information about
a given event, thanks to the slightly longer time frame.
And this HRT usually uses a PC farm of CPUs and GPUs.
And then afterwards everything,
then everything which passed these two stages of filtering,
gets sent to our data centers for final analysis,
so that we can produce papers to be published
in scientific journals and conferences.
But this is only a very small part of the computing pipeline.
This is the, what happens in real time,
when data is collected from the LHC,
and these computing steps,
what happens outside of the real time data collection at the LHC?
We call this online computing,
and that offline computing.
And for offline computing,
we operate on more than 500 petabytes of data per year,
considering only the 2024, 2025 period,
not terabytes, not terabytes,
not megabytes petabytes.
So this means that we need at least one
million CPU calls to analyze everything,
not to mention IO and storage.
And this is why we have the worldwide LHC computing grid,
which is a grid of distributed computers,
with dedicated networking,
separated and through several tiers.
We have data centers in 10.
14 sites, most national labs in tier 1,
more than 130 sites in tier 2, most universities,
and tier 3, where computers have smaller responsibility
than in the first three tiers.
If you want to learn more about WLCG,
visit WLCG-public.sweb.sendlch,
or scan the QR code here.
So one collision every 25 nanoseconds
is actually not enough for us, science,
and science itself.
So we are upgrading the LHC to high luminosity LHC,
where the number of particle collisions
will increase by a factor of 5 to 7.5.
And this will raise significantly the computing demands.
So you can see predictions here,
made by the Atlas experiment.
Unfortunately, I'm slowly running out of time,
so I'm not able to explain this gap in more detail,
but you can check the slides in your own convenience,
because I've already uploaded them to the false network site.
And data processing from the large hydrogen collider
is not the only area where we have performance challenges.
We also have accelerator control systems,
posting and monitoring the accelerators in real time,
as I mentioned at the beginning.
But we also have simulations of beams inside the accelerators,
where the x-sweb framework.
And this is also this is related to upgrading
a building new accelerators and upgrading our accelerator complex,
so that we can, for example, again increase our number of particle collisions.
So to finish things off, if we did insufficient performance,
tasks and upgrades can't be finished on time or at all.
And this means that our physics program is delayed,
and we get fewer physics results,
which is absolutely not what we want to achieve.
We want to achieve good performance,
and as many physics results as possible going forward.
And with this being said, thank you very much for your attention,
and you can visit our website at www.sens.ch,
or visit our website at www.sens.ch.
And once again, your contributions are more than welcome,
just get in touch with us, and we will be happy to talk.
Thank you so much.