- Anton, hello! Thank you for coming. - Hello.

- We know you as an expert in LLVM, first and foremost.

But I think we will not only talk about that today, but also about bioinformatics.

It's something I don't understand at all, but it's very interesting.

But first, a question about LLVM. Can you explain to our listeners who are not familiar with it, what it is?

- That's actually a very interesting question. About 5 or 10 years ago, we looked it up on Wikipedia.

It proudly stated that LLVM is a low-level virtual machine and everything else.

But as with all abbreviations, it is neither low-level nor a virtual machine.

Yes, that might have been some kind of initial idea, but to put it simply, it is a framework,

as they say in modern terms, for building compilers, for building tools,

for code analysis, code transformation. Over the last 25 years, it has grown quite a bit,

and it has covered, in principle, more or less all the tasks we might have around compilers,

around the relevant tools, code analysis technologies.

So it's a working tool, a workhorse, which, in principle, can be used,

and which is actually used by a lot of people, all over the world, in many products.

- I understand that it is primarily an intermediate language within the compiler?

- Well, that's part of LLVM, what is called LLVM IR, that is, the internal representation of LLVM,

but it is precisely that representation of code that we work with internally.

But you can't just work with the code as it is.

You need some tools for that, you need something that allows you to modify this code,

you need something that allows you to analyze this code, even in a basic way.

So we still won't work with the code in some natural representation.

We need to have the ability to have a representation in memory, we need to have a representation

in a serialized form to be able to do and save a file somewhere and so on.

So, in principle, that's part of it.

But, of course, on one hand, it is a fairly central part of all LLVM,

because it is this part that largely dictates the decisions that have been made,

the design that is built around all of this.

But it is not the only part of LLVM.

The innermost representation is quite, one could say, useless,

without the tools that can be used for its analysis and transformation.

So if I write a compiler for my new language, it is beneficial for me to use LLVM

as a framework that I rely on in my compilation methods and further code optimization.

This is one approach.

So it is clear that there is no silver bullet.

There are no universal solutions that work in all cases of life.

Plus, LLVM is quite Russian-level.

But if you need to quickly support a certain number of standard optimizations

or get working code generation right away for a bunch of platforms,

then LLVM is probably a pretty good default option,

where you can just take it, plug it in, and get something.

Again, there are things that LLVM does not handle very well.

This is, in principle, as always.

How did you get into this story?

How did you get lucky, or maybe, on the contrary, was it some kind of misfortune?

Why did you get into this development?

This is actually quite an interesting story, I guess.

So it was probably already 2025.

Well, I think it was 20 years ago. So it was around 2005 or 2006.

And it turned out that at that time there was a certain project,

for which code transformation needed to be done.

And for that, we actually needed some tool.

At the same time, various source-to-source transformation options,

that is, at the source code level, would definitely not work,

because the source language was CAC++.

Well, for that, it means that you actually need to raise a full-fledged CAC++ compiler.

So, naturally, that is not what we generally want for a semi-sequential project.

And then I started looking at what options we had.

What, where, how. We tried to make this structure at the BTC level, but it didn't work out.

There were some academic options, but again, there were problems with that too.

And then I stumbled upon LLVM, we looked at it, tried it, and it seemed like we were getting somewhere.

But there was an interesting problem.

The fact is that support for Windows was needed as a target platform at that time.

And LLVM's support for that was mediocre, to say the least.

So, primarily, my work around LLVM was about adding Windows support as a platform.

In fact, support for Windows as a host platform, where the compiler itself was running, was relatively okay.

In particular, the code was written quite platform-independent, all C++, and in that sense, there were no problems.

The problem was specifically that there was no support for Windows as a target platform.

That is, so that the generated code would work on Windows.

This includes calling conventions, all sorts of our favorite things around calling or importing functions from DLLs.

Well, in general, that's how it all started.

At that time, I even spent about five years, maybe a little less, making binary packages for Windows.

Well, then it went on with some things around Linux, LLVM, basically a bit of everything everywhere.

And at that time, was it a product of Apple?

No, that was before Apple, so Chris wasn't at Apple yet.

At that time, it was purely a research project at the University of Illinois in Champaign.

So it was a little-known open-source product at that time?

You could probably say that.

But given that it was made quite well, and I must give credit,

since then I have seen quite a lot of academic developments.

So compared to other academic developments, it was probably a head or two better in terms of points.

Design, usability.

Well, and still, despite the fact that it was an academic development,

there was already a group working on it led by Vikram Adve.

So Chris was leading that group.

But it was not a project of one person or one student or one graduate student.

There were, for example, about five or six people.

Everyone understands that Vikram had a whole grant for this.

So in that sense, there were some resources.

And not given.

I understand that they were trying to compete with GCC at that time?

Or was that not the main goal?

No. There was no competition goal.

Moreover, at that time, Chris came to the list of GCC developers.

He said, guys, let's be friends.

Here we have LLVM, let's try it as a representation.

Its builders were quite cool about it.

Partly due to licensing agreements, considerations.

Because at that time, GCC was not very well disposed towards any code

that was not under the GPL license in principle.

And plus, the architecture of GCC at that time did not really allow for any embedding.

On the other hand, it is impossible to build a framework for transformation analysis,

optimization of program code, and code generation.

Well, without getting a front-end.

The GCC framework is absolutely useless to us

if we cannot use it to compile any mainstream languages.

Then creating a front-end for some niche projects is great.

But still, in order to move further and take us to the next level,

we now need a front-end for some person

who depends on an industrial language.

And it is quite clear that developing a front-end even for C

is still a fairly non-trivial task.

The specifics of the language and those million little details that need to be taken into account.

And which are carefully specified or not specified in the standard.

Plus, it is clear that there is a large amount of everything spread around this with a thick layer.

Due to the various extensions that exist in different compilers and so on.

Therefore, the natural step is not to try to do everything from scratch.

To invent our own five-wheeled bicycles with square wheels.

But rather to simply reuse.

And thus, what we then called LIMGCC came into being.

That is, when we take the front-end, LIMGCC, and try to attach LIMG as a video

and back-end. And in a sense, a synergistic effect was achieved because, on one hand,

Ello Yan as a project received a full-fledged front-end with complete languages. Enthusiasts quickly emerged

who needed, for example, Ada as a front-end, and it seems that

according to rumors, it actually worked quite well. Some needed Fortran, and, in principle,

GFortran also worked somehow. I even fixed some things around that. Then it turned out that,

since ProJC already existed, it allowed, on one hand, for Ello Yan's community to get

something ready on which they could start building a ready-made melting. On the other hand, yes, the GC community received

a kind of obvious competitor that also spurred development in one way or another. And in the end, it won,

as I understand it. To put it mildly, it won. I would roughly compare it to a warm death.

If we talk about various proprietary things, then yes, I would probably say that Ello Yan uses

more often Perk and China, which is indeed a license. On the other hand, GC supports a much larger number of platforms,

including quite exotic ones. And they are there. Many things in GC are quite well

preserved and change very rarely. Therefore, you can create a back-end for some rare platform,

and it will live almost unchanged for 5-10 years within the codebase. Plus, historically, GC has had

front-ends for Fortran, front-ends for Ada, and some others. The code for which, in principle, was not available in Ello Yan,

but that was not the goal. That is, front-ends for Fortran are only being attempted with the third or fourth approach to the task.

So I would probably say that this is not a competition or something that will only win, but rather a coexistence.

Plus, again, many well-known open-source projects have actively used this, it’s probably not an expansion of CC,

but rather a specificity of work. Starting from HydroLinux and even including the standard library JellyPsy.

What was your main contribution after you helped with Windows?

Well, I mean, historically after that, I was quite involved in supporting the Elif platforms.

So, on one hand, it seemed like small things, but on the other hand, it couldn't have been done without them.

That is, all possible things we have were in the types of visibility, various weak symbols, binding details.

At some point, I was working on support for Dwarf, which is specifically about pitching the format for debugging and for Elif platforms.

We use Dwarf for exception support as well. So, support was needed from both the code generation side and the runtime side.

Probably the next thing was this. Along the way, there were a bunch of different small tasks.

At some point, I did something for fun, but also as a small documentation effort.

That is, as always, we have the problem of large open-source projects that are actively developing and moving forward, which naturally leads to gaps in documentation.

And if, for example, we need to write documentation for AR, because, in fact, it is a specification, and it cannot be done without it.

Well, plus AR as KTI changes very little.

So, on a separate part of the backend, having documentation that is up-to-date is quite painful and cumbersome.

If you don't have a dedicated technical writer who constantly tracks, updates, writes, and so on.

And it so happened that there was practically no documentation regarding the backend. Or it resembled that well-known meme about drawing an owl.

We start drawing an owl, like how it would be, and then, to show, "Hey guys, look, you have, I don't know, 250 thousand lines of code, this is x86 and the backend."

And there was nothing on the wall. I even had a couple of talks back then, in the series "How to build a backend in 24 hours."

As an example, I created a backend for MSP430, a humorous microcontroller that is still very much alive because it costs just a few cents and everything else.

That's why it is still being produced and sold, they are sold by weight. Plus, it has a very regular architecture, with 20-something instructions, which is basically nothing.

But at the same time, everything is there. There is memory, there is arithmetic, a thousand other things. So, I probably spent a few evenings on it. 24 hours, of course, was just for effect, but in principle, I managed to create a backend in a week of evenings, and it is still very much alive; I am still considered its maintainer, and I still support it, refine it, and review it for regressions.

And as far as I know, people are still using it, especially after the RAS community.

How do you assess the complexity of this project within LVM?

The complexity at the moment is actually quite small. I seriously doubt there is anyone who understands everything.

It's important to understand that LVM has evolved into an infrastructure over 25 years. Or, as we can say now, into an ecosystem.

In reality, we have completely different components, each of which does different things, because, in fact, Clang is part of LVM.

MLR is part of LVM, Clang is part of LVM, Debugger LDB is part of LVM, LD is part of LVM. So, all the components are, of course, an integral part if we are talking about building a full-fledged Intelluchain for something, but for someone to understand all the details and nuances—no.

On the other hand, in my opinion, it is quite important. Fortunately, the project has managed to maintain some transparency in its codebase. So, you can sit down and quickly figure out what is happening at some principle level.

The main thing is not to be afraid to dig wide rather than deep, probably. So, the project itself is quite large. Plus, it's clear that some time ago, development of the library began.

So, if we started, it would be impossible to imagine any compiler without the standard library for C++. But now, in addition, development of the standard library for C++ is also ongoing.

This, of course, adds code if we consider it in lines. But, on the other hand, what is important is that these are separate components, not just some mixed-up mess of packages.

Don't you think that after 25 years, any software product becomes morally outdated and it's time to consider rewriting everything from scratch? Is that not the case for you?

That's true. I won't even argue with that. But in a sense, MLR, that is, what we are observing, is a kind of radical approach to blow everything up and rewrite from scratch.

So, on one hand, it can be said that in LLVM, and I can talk quite a bit about this, there are some unfortunate design decisions that were good at one time but turned out to be quite unpleasant later.

And then, of course, as always, when we have something suboptimal at the foundation, we will have to live with that legacy because applying it endlessly is painful and not very clear what it's actually for.

We’ve lived with it for 20 years, endured it, and probably could endure it a bit longer. On the other hand, BMLR tried to address some of the design issues we have in LLVM, such as flexibility, extensibility, and some aspects related to the internal representation.

Plus, again, it should be understood that LLVM is not universal; LLVM is quite low-level, and as a consequence, in order to reflect all sorts of disk-level things that are specific to a particular language, it is quite inconvenient.

We are already used to doing and developing things on computers.

And if we were to be handed a rithometer now, it would probably also be painful and costly to deal with something like that.

On the other hand, it is clear that it is possible. History shows that people have dealt with all of this.

The question is about the ratio of effort to output.

Therefore, MLR, as an approach, is partly a way to solve the problems that have accumulated.

But what is important is that this is not an attempt to just throw everything away and rewrite everything from scratch.

We see that there are design problems that prevent us from doing certain things.

Let's take a look. We'll develop something that incorporates the good aspects we already have.

A classic example. There are quite a few various internal representations developed for compilers.

And somehow, in many cases, it turns out that, for example, this internal representation is not serializable.

That is, you can't just take the internal representation and export it to some file to read it manually and then load it back.

In my opinion, this is one of the main cornerstones: the internal state of the compiler should exist in three forms.

That is, in some serialized binary form, in the form of a file, in a textual representation, so that a mortal can read it and understand it in a reasonable time without needing complex serialization tools.

And of course, there is also the representation in memory, which allows them to export something from the program.

And it suddenly turns out that something that seems quite simple is, in many cases, an innovation for many representations.

Yes, there is a debug dump. No, we cannot read the dump back because we cannot set it up that way.

So in a sense, as I mentioned, Malaya was such an approach, and it continues to evolve as a project, as part of LLVM, as a signal that we have.

Well, on the other hand, as always, when we solve one problem, new ones arise. It seems that the law of conservation of energy has not been canceled.

I know that large companies often create their own versions of Clang or LLVM, including IAR, and branch off without returning to the main branch.

This happens often; I hear these stories. You have probably encountered such customization. You may have even participated in such projects.

Tell me what you think about this and whether it is good, and where it ultimately leads. Whether it is a problem or not, I probably can't say for sure.

But yes, such experience exists. And here, as always, since we are talking about industrial solutions, it is important to have the right balance between cost and what you get in return.

This is what is called cost-benefit. It is important to understand that any such forks, any downstream code we have, come with ongoing maintenance costs.

And the question is whether the company that created it is ready to provide that support.

Because there are completely different scenarios. You take something once and then live with it for the next 5, 10, 20 years, and then repeat the cycles.

For something, this might actually be a workable option. If we are talking about a target, such as a compiler for C++,

let’s say for some exotic platform, sooner or later users start asking where our features from C++38 or C++42 are.

Naturally, this requires synchronization back with the Mainline, at least in one direction.

Some companies have understood this quite well and have even learned to live and work with it.

The thing is that as soon as you give the code back to the Mainline, you relinquish its support. Someone else starts maintaining it for you.

Therefore, if it can be done this way, the company does it. There are precedents where companies have tried to create their own IR on top of LLVM IR for something.

So there are actually several examples. So far, all the examples I know of are related to compilers in one form or another for graphics coprocessors.

Because usually, when our target platform is a GPU, we do not generate code specifically for a particular piece of hardware.

Instead, our output is yet another internal representation, possibly even lower-level, which is then compiled by a specific graphics driver.

Depending on which specific graphics card a person has. We have already established some layer of abstraction from the platform, and the details are handled further.

There are precedents where someone is still living with a representation on top of LLVM 3.7. There are those who are living with a representation on top of LLVM 7, as far as I know.

They chose this path; it was their decision, and once they did that, they took the code, and it’s up to such a company to develop and maintain it, why not.

The license allows it, and moreover, it is in the spirit of open source.

Why are they doing this? Why do they take Clang, for example, and try to insert some additional features into it? What is lacking in the standard Clang?

And what is the business effect of expanding or improving the compiler? What could be wrong with the compiler?

Some of the issues may be related to the simple need for compatibility. Imagine that a company has had compilers for 30 years that were not based on Clang, not on GCC, but had their own custom-written compiler with some of their own wonderful extensions, say, for C or C++.

And then we need to, and naturally, such a company has its own codebase, and there is a user codebase that still needs to be compiled using these extensions.

So then we have the absolutely standard situation where we either tell the user, "No, guys, sorry, but starting from version N+1, your code will not compile, so you will have to rewrite it."

And the last time this code was touched was 10 years ago, and therefore the last person who knows how it works has long since retired.

Or we can add support for the compiler extensions. This is a classic example, that is, backward compatibility.

Somewhere, extensions are needed for the corresponding target platform. We are creating yet another, I don’t know, accelerator for something, for AI, for some kind of network traffic processing, or something else.

Yes, our goal is an incomplete C. For example, our goal is some subset of C. Well, that means we need to carefully trim away what we do not support.

Additionally, we need to enhance this by incorporating the features of our platform into the corresponding language.

Again, we get language extensions that are specific to a particular platform, a specific vendor, or something else.

Something like that. Plus, there are simply cases where we have what seems to be a fairly standard platform, but it is closed.

That is, you cannot just take it and start writing code for it. And don’t think that this is something exotic. All those gaming consoles that are out there, three and a half of them on the market,

they insert such a closed platform. Well, and we need to have, for example, basic support for this platform,

support for some built-in, I don’t know, macros, additional data types, platform descriptions. And companies somehow believe that this is their proprietary thing, that they are not ready to give it to the LLVM Mainline, so they have to support it downstream.

Probably, all those who write LLVM in an open-source format are in high demand in the market of such companies that need help in customizing these solutions?

Well, yes and no. That is, in fact, one could say that, in principle, the job market around compilers,

That is, it has been quite hot lately.

Partially, of course, this is related to the rise of

AI/ML compilers, that is, for things around artificial intelligence.

Because at some point, the realization came

that what was previously called a machine learning framework

is actually 80% of it is, in one way or another, a compiler

in one form or another. That is, with its own specifics,

that in the case of AI/ML workloads, we usually deal with dataflow,

rather than contraflow, as in regular languages.

But nevertheless, it is a compiler.

Thus, as soon as the explosive growth happened,

everyone became AI/ML engineers.

Naturally, there was a very high demand for people

who understand something about compilers,

what is happening with them, and, of course,

a certain expertise emerged in the market.

I want to move on to the topic of bioinformatics at this point.

What is it in a nutshell?

I find it very interesting, but I don't understand.

Perhaps it’s worth first explaining to the listeners,

And why did we move on to this topic?

Probably, we will do it that way, because it didn't work out like that,

that we are now going to start discussing ballet or modern jazz arts.

I also find it amazing,

that you are a specialist, on one hand, in compilers

and on the other hand, bioinformatics.

I can't connect these two topics.

In fact, the situation is very simple, on one hand.

Perhaps it’s worth starting with the fact that, unlike many people,

who are in this field, I do not have a specialized education specifically in computer science.

I have an education, essentially, in applied mathematics

and in university, I was essentially engaged in computational statistics.

On the other hand, actually, 25 years ago, it was a kind of hobby

or a way to switch gears, to do something different.

On the other hand, in reality, I have always been at a relatively low level

in terms of programming.

It's not that one was primary or secondary,

they are roughly parallel.

In fact, the understanding of how compilers work,

how data structures are organized, how to compute something accurately, correctly, and quickly,

it helps a lot because when we need to accelerate a computational method mathematically,

you start to understand a priori how it needs to be structured under the hood,

how to make it work quickly, well, accurately, and so on.

And, in principle, I still sit on that second chair

in terms of the same statistics, teaching, and so on.

My candidate thesis was specifically on computational statistics.

Then, at some wonderful moment, a little over 10 years ago, in 2012-2013,

I meet my former classmate, who says something like this.

We are opening a bioinformatics lab in St. Petersburg and would you like to join us?

My classmate at that time, we studied together in the first profession, was Kolya Vesetov.

He is currently mostly involved in an educational project.

It's also called edutech.

If you've read or heard about it, then Rozalint and Stepik are all his creations.

The feature of the educational laboratory was that, despite the fact

that it was supposed to focus on bioinformatics tasks,

it was built in a somewhat unconventional way.

That is, bioinformatics is essentially at the intersection of computer science and biology.

And there are roughly two approaches to building something here.

You can take, conditionally, biologists and scientific programmers.

Or you can take computer scientists, so to speak, people who have an education in computer science.

and teach the necessary things related to biology.

As you can guess, the results turn out to be completely different.

Because in one case, when we teach biologists,

the primary focus is on some deep aspects of data analysis.

And in the case of teaching computer scientists, it will probably be more about developing tools.

That is, when we take and write something, develop some methods, some programs for all of this.

At that time, it wasn't that there was a lot of time, but I saw some tasks in computer science that seemed interesting to me.

Plus, they also touched on aesthetic aspects.

So it all kind of came together, and I sort of stepped in with one foot.

And then, as always, it began.

I saw that there are some areas where I can be of help.

To explain how it should be structured in order to work well and quickly.

And for the listeners to understand, the main product of the software lab was a genome assembler called Space.

If we try to tackle the genome assembler, we can probably use a standard metaphor.

Imagine that we went to a printing house where they still print paper newspapers and took a pallet of newspapers that have just come out before tomorrow's issue.

After that, we carefully placed a couple of shredders under this pallet of newspapers so that everything would be torn into tiny pieces.

And then, having a set of these pieces, we need to try to reconstruct the original issue of the newspaper.

I understand that, firstly, we may have some fragments of phrases.

I realize that these pieces may have holes, slightly burned edges, and so on.

Nevertheless, we understand that we have some redundancy.

That is, we didn't just tear one newspaper into pieces, but an entire daily issue at once.

On one hand, this redundancy helps us because we can hope that a single error won't ruin everything.

On the other hand, naturally, this redundancy hinders us because we lack some clarity.

In other words, we are not assembling just one puzzle, but we are trying to assemble one puzzle from a bag that contains 50 or 100 mixed puzzles.

At the same time, all the puzzles are different, but the picture on them is the same.

The peculiarity of this is that the raw data is measured in gigabytes and terabytes.

And we need to extract something from them that will be correct and accurate.

Plus, we do not know the correct answer.

This is yet another aspect that is more or less standard for analyzing any data.

And it so happened that Space, as a tool, became one of the standard tools for genome assembly worldwide.

Due to its universality and the quality of its results.

And for some time, I was probably translating it into a programming language familiar to the listeners.

I was a tech lead in the team that was developing the assembler.

- And what does it ultimately assemble? I understood the newspaper metaphor.

- Genomes. We have something called a genome.

If we remember what someone was taught in school, we recall DNA, the spiral, and so on.

If we abstract from some biological aspects, we are dealing with long strings.

We have a string in the alphabet of 4 letters. The interesting strings for us are very long.

Bacterial genomes are several million nucleotides long, meaning several million letters.

And we need to reconstruct the complete sequence from individual fragments, from separate pieces.

To make it clear, our fragments are 100, 200, 300 letters long,

and from them, we need to reconstruct a string that is millions and billions of letters long.

- What does the practical task look like? Where do these genome fragments come from?

What is the output and how is it used later?

- Practically, this is actually a completely separate story.

It starts with what are called wet biologists, when, for example, bacterial or simply.

That is, a specific culture is taken. After that, a bacterial culture is isolated from it.

in large quantities. In principle, DNA can even be isolated at home,

there are videos on video platforms, on YouTube for sure, I don't know about others.

There were a bunch of videos on how to isolate DNA at home.

Usually, this is done with some polyploid berries, like strawberries.

In principle, it can be isolated at home using

fairy liquid, dishwashing detergent, and something that allows for

lysis of the cell wall. That is, practically, it’s a marinade that

allows us to mark some spot.

And upon arrival for isolation, large complex boxes

called separators are used, where everything is loaded and which try to...

They are built on different technologies, there are about three and a half technologies

that allow us to read the sequential verses in letters.

But the essence of the data, probably, is that the separator takes these long ones,

long, long sequences allow us to obtain shorter sequences.

Not always accurately, not always correctly. But nevertheless, this will be the outcome of the process.

Knowledge of sequences allows for many things.

That is, if we... So, this starts with...

Many things are determined, one way or another, by various

genetic traits. So, at this point,

it is already... That is, genome analyses in one form or another

have become quite routine.

We can analyze whether the strain of this bacterium is associated with any disease.

That is, does this bacterium have any plasmid?

or something else. That is, some separate element of the genome,

that determines increased antibiotic resistance.

We can talk about screening for various congenital conditions specifically.

genetically determined diseases. We have with you and all the listeners,

Fortunately, we have two copies of the genome, one from dad and the other from mom.

On one hand, this redundancy allows us to be more or less tolerant.

to many malfunctions. After all, the process of telomere replication is still not perfectly accurate.

But, in principle, this is the heaviest legacy in some cases,

when they are drawn in the sky in such a way during takeoff,

that some genetic anomalies or genome malfunctions, they come here.

Mom doesn't have it because it's written in one copy, dad doesn't have it,

because it's written in one copy. But, unfortunately, for the child, it so happened

that bad things came from both sides at once, and we don't have redundancy

and something doesn't work. In this sense, often for confirmation, for example,

they perform what is called a Trio analysis, where they read and screen the genomes of the parents

and the child to understand what actually happened.

Is it truly de novo? Or is it a recommendation from the parents?

So, in principle, this is more or less the mainstream at the moment.

And in various aspects, this has already become routine in analysis and in medicine,

and in biological research, that is, in a bunch of fields.

That is, it shouldn't be related to the studied disease.

People who are involved in agriculture in one way or another

are also interested in studying resistance

to the same pests of agricultural crops.

For example, all the bananas that exist in the world are actually clones.

They are one variety. So in the case of bananas, there is no species diversity.

Specifically, the industrial ones that we can go and buy in the store.

That is, if a wonderful pest appears,

for which the bananas become non-resistant,

we risk ending up in a situation where bananas simply cease to exist in the world.

And that's why this is one of the interesting areas where they are really trying

to develop significantly new varieties, but, of course,

without losing the qualities that we are used to.

No one wants to eat unappetizing bananas.

In fact, this has already happened more than once regarding the same bananas,

because the epidemic that wiped out the variety,

I might be mistaken, but it was around the 1930s of the 20th century.

Or, for example, a very interesting task is the attempt to analyze all sorts of,

what is called microbiomes, when things are analyzed in combination.

That is, right now in nature, everything is very interconnected.

We mentioned that there are things related to duplication.

In nature, on the contrary, duplication often occurs.

There is a situation of symbiosis, when certain living organisms lose a specific function,

simply because they have symbionts that perform that function for them.

I mean, if we look at all these guys individually,

they are not viable. We cannot grow them in a test tube or on Petri dishes separately.

It has to be a mandatory symbiotic colony, so that they actually support each other.

Well, for example, a very good example is when, say, in Russia there are areas of taiga,

which are called black taiga, which is very interesting because there is observed a phenomenon known as

plant gigantism. That is, in reality, there is grass growing taller than human height.

Without any additional factors.

Naturally, this raises an interesting question: what is the reason for this?

Because these are not some separate varieties; it is just the most ordinary.

Grass that grows in meadows and fields across the country, in this specific place, for some reason,

and it is specifically in the taiga areas, grows taller than human height. What is the reason?

If we understand this, we can immediately guess that it provides us with very significant,

what are called interesting applications for growing new crops,

for increasing yields and so on. So far, it is known that the reason is the soil.

But the exact cause is unclear. That is, if you take a bag of soil from there and plant something in it,

you get a simple radish that grows two to three times larger.

The reason is unknown. There is a hypothesis that it is a unique soil microbiome,

meaning that there is a specific family of soil bacteria present,

which perform some kind of magic, producing certain bioactive substances

that stimulate this. In general, there are many applications.

One could talk about them for hours, but all of this is impossible without...

Actually returning to bioinformatics and LLVM, it is impossible without tools.

If we don't have a hammer, we can't drive a nail. Driving nails by hand, especially with your head, is not very pleasant.

So we need tools. In the world of compilers, we have the complete LLVM.

One of the tools we developed was a dynamic assembler.

This is a tricky tool that researchers have used and continue to use all over the world.

And, perhaps without false modesty, one can say that this is a kind of Russian brand in bioinformatics.

Because the article in which the original assembler was published has been cited over 15,000 times.

And this article is among the top 50 most cited articles in the world.

So this is indeed something, as they say.

Fundamental.

Well, one could say that it is a widely known thing, but within narrow circles, which is fine.

That's great.

I would like to get your advice for the youth.

What should one focus on now in the field of compilers and bioinformatics to achieve such success in 10-20 years?

What do you think is still unexplored? What currently requires investment?

You know, I think that's the wrong approach.

Specifically, a list of 10 points. We saw that some time ago.

What you need to do to enter IT.

That's the wrong approach.

Yes, you can read a ton of books. About 10 things you need to do to be rich, happy, smart, kind, beautiful.

According to the text. But this approach is incorrect. The right approach is that you need to have the desire,

the opportunity. You probably need to learn, as cliché as it sounds. Everything is changing.

That is, what we were doing 10 years ago, 15 years ago, 20 years ago, is certainly sometimes relevant,

but often it is not. You cannot constantly live in the past. It remains in the past. You need to have

the ability to constantly understand what new things are happening, to be able to adapt.

to adapt and so on. Again, we see explosive growth in various things,

related to all sorts of agents, assistants, and everything else. Perhaps,

In about 10 years, what will actually be needed is, yes, the ability to strategize correctly.

questions in order to get the right answers. But on the other hand, this is also difficult.

That is, you need to learn to ask the right questions, and in my opinion, this is even more important.

Being able to assess the adequacy of the answers. Because automating routine tasks is great,

but when someone does something for you, you need to understand that how you received it, it is...

remains yours. And you start to be responsible for it. Perhaps you know what is currently lacking in that...

in the LLVM ecosystem, what one would like to do, but there is no strength, no manpower, and then the youth would get involved,

and that would make it happen. Some tool, maybe some methods, maybe some...

extensions, add-ons. The same MLIR, it appeared not so long ago. It was a new idea,

surely created by those who... The idea was new, but essentially, it was a deep

reworking of old ideas. That is, we are not saying that we invented something completely

new, something that had never existed before. The concept remains the same. We are just

reinterpreting them and learning from our own. In the same LLVM, there are small wagons, a cart, minor

tasks that can be taken on, and it's called figuring things out. That is, to understand how everything is arranged,

and then everyone finds something that suits them. Some people realize that they much prefer to work

very, very close to the machine code itself, with backends and everything else.

Others say, no, no, no, this is terrible, terrible, terrible, I don't want it, I don't want it. Leave your bits,

bytes, and registers to someone else. I'm interested in all sorts of high-level things, I don't know,

checking, yes, I don't know, checking protocol matching against a template, and similar things.

Everyone has their own variety. Moreover, if we talk about large projects, for example, in the same LLVM...

there is LLVM, actually, it has been around for a long time, since 2008, participating in the same Google Summer of Code,

that is, a program where large companies actually pay for such projects,

for summer projects, but they are done in open source. Unfortunately, Google Summer of Code is closed for

many listeners from Russia, from Belarus, but in principle, similar things exist, as it were.

open projects still remain, so in fact, no one prevents you from taking, for example,

take a project that no one has done, or that no one has taken, and try to create something free there.

Time, so that option also remains. And in general, how does the LLVM community relate to newcomers?

Aggressively? No, very well, as always. The community treats newcomers as it is treated.

actually, those who come to it. That is, the community tries to help newcomers by answering...

to reasonable questions, as long as people in front, so to speak, are good and reasonable. Well, in principle,

like any healthy community, where there is constant rotation. That is, it is necessary to...

to understand that the LLVM community, despite the fact that it is an open source project, is still somewhat...

about 60 percent consists of people who, one way or another, work somewhere for someone and receive...

a salary for it. So, in one way or another, there is a constant rotation, and it's not like that,

that the veterans sit for 30 years and don't let anyone into their sandbox. That simply doesn't happen due to natural...

reasons. Some say it's bad that 60% of the people drive what their companies need,

but there are no universally good things. That is, yes, there are people who, of course, do what...

that will benefit their employer. Yes, that's true. On the other hand, again, today one...

will lead, tomorrow something else, the day after tomorrow a third. This ensures a healthy rotation, people move on...

from one employer to another, meaning they remain, among other things, in the community, and that is also valuable.

Would you recommend young people to get involved in the LLVM project? Or is it too difficult and unpromising?

Well, promising, I would probably say the opposite, that it is very promising. That is, especially,

if adding a simple line to a resume, yes, that I was a Contributor in LLVM, I did this and that,

this and that, it often gives a significant boost in terms of quality right away.

resume, yes, in terms of quality of the series. Moreover, given that all development is currently being done on...

these platforms, yes, it's very easy to see what a person has done, yes. That is, this...

that is, in other words, it allows for independent verification of what is written in the resume, because...

it can absolutely be anything, yes, I don't know. The main lead, the maintainer of LLVM,

yes, you can write it like that, yes. So, we take it, check it, that is, it's quite a standard...

thing, so that if a person writes that they have experience with LLVM, okay, good, we take it, look at what they...

was working on, when they were working on it. What, and you can immediately see, among other things, the quality of their work, and how they...

for example, communicated with reviewers during their review time and similar things. In LLVM, this is quite...

promising, and, one way or another, this is what is, well, what is under the hood of many compilers,

which everyone uses every day. And there are tasks of different angles, different sorts,

that is, there are very small ones, yes, there are larger ones, yes, there are vast ones. Probably, for any, anyone...

there will be something that resonates with them. Well, that's great. Now, I want to ask the last question. Maybe...

let's give some kind of advice to those who listened to us, and to those who are interested in your...

areas. Maybe you need contributors, maybe you need help from those who are ready to get involved...

in bioinformatics, in these projects, maybe in LLVM, in your area within LLVM. Do you need such...

Do you need people? Is help needed? Yes, that is, plus, again, all these projects are open, so no one is...

is stopping anyone from taking a look at what problems exist, and there are probably always open hands available. That is, in this...

there is no such thing as "no, no, no, don't come, this is my sandbox." No. So, if...

if someone is interested, of course, then welcome. Everything is available, you can take it, get involved.

and fight, to do something. Well, okay, I hope our conversation inspires someone to...

to engage in this topic. Many are afraid of large open-source projects; they think it's difficult there,

there are indeed experienced people and huge codebases, and for a student to break into that, for example,

third-year students tend to feel very intimidated. It's true, but you really need to overcome that, yes, that is,

indeed, some people are afraid, yes, like, oh-oh-oh, this is all very big, I'm very scared, I don't know anything...

I understand. An important skill, in terms of skills, is that you need to learn to work in conditions of incomplete...

information. That is, you don't need to understand all of Chrome in order to contribute something to it. You don't...

you don't need to understand all of LWM in order to contribute something to it. You don't need to understand all of QC in order to...

to contribute something to it. And you shouldn't think that there is something unique about large open-source projects,

yes, but again, yes, at the university they only teach a small piece, so to speak, of those...

or other aspects of mathematics, yes, but at the same time we somehow are not afraid of all of this, right,

we say, oh, well, I don't know everything, so, like, I'm scared, I won't engage in this, yes, that is,

well, it's the same everywhere, yes, that is, it's impossible to know everything, and that's okay, yes, that is, but it's important to know...

it's good to know at least something around you, and that's enough. Thank you very much for your time,

I hope we helped someone, inspired someone, motivated someone. I hope so. That's it, Anton, goodbye. Yes,

Take care. Goodbye. Thank you to everyone who listened.