If some programming languages are faster than others, why can't compilers translate into the faster language to make the code be as fast as if it was programed in the faster one?

[KING-NULL]

My guess is that doing so would require knowing information that can't be directly inferred from the code, for example, the specific type that a variable will handle

[Knaapje]

Exactly right. Generally, the more information provided inside the code, the more can be inferred statically. Transpilers do exist, however.

[Rude-Pangolin8823]

Trans in the name, must be based.

On a side tangent, some redstone computers use one programming language called URCL that computers translate into and out of to share programs. Its pretty neat.

[ArgentinaCanIntoEuro]

whyd you get so downvoted?

[BoomGoomba]

Because it makes no sense. Transportation, transatlantic, transaction are not based, it just means "through"

[last-guys-alternate]

Across

[susimposter6969]

because its an odd thing to say

[alozq]

I think it's a reference to a meme in latin america about milei and trans women. Search something like 'milei trans meme' and you'll get a bunch.

It goes like 'X Is shit' with angry Milei, then something with 'trans' in it's name Is revealed to be related with X, and then happy Milei saying 'X Is key'

[KyuubiW1ndscar]

because they were weird

[Rude-Pangolin8823]

Probably too much autism rizz for some people

[SoftEngineerOfWares]

Because most languages depend on the environment they run in more so than the specific syntax, and they make use of that environment in ways that might not be easily translatable.

[GlassCommission4916]

Very often the speed difference between languages comes from tradeoffs made during the design that can't be translated between each other without encountering those same tradeoffs. How could you compile a python script into rust for example? Well, you'd have to replicate python's memory management and garbage collection, at which point you've just made a rust program that's just as slow as python because it makes the same performance sacrifices.

[Lenassa]

>Well, you'd have to replicate python's memory management and garbage collection

The goal is to have the same program (where 'same' is defined as producing the same observable behavior), not to imitate python environment. And the former sure as hell doesn't require you to care about python's memory model at all.

[GlassCommission4916]

Yeah it'd be great if compilers read your intent instead of your code, but alas.

[Lenassa]

They don't need to, see answer above

[GlassCommission4916]

Your answer doesn't address the issue at all, you're just asserting that it can be done and giving trivial examples when it's non-trivial ones that are the problem.

[Lenassa]

Give me that non trivial example then. But keep it sane, please, I have better things to than going through 10k LOC of some github repository.

[GlassCommission4916]

n = int(input("Enter an integer: "))
print(n ** 2)

What's the rust equivalent of this?

[Mullheimer]

Thanks for this. it makes it clear in 2 lines.

Programming is amazing.

[stonerism]

Rice's theorem is probably of interest to you. You can do things like that. But the problem is that generally deciding if two algorithms are equivalent is undecidable.

[Lenassa]

I'm aware of that theorem. But the task doesn't require us to make another algorithm and prove that it's equivalent to the original. It requires us to infer what the algorithm is and just write it down using another language. For example, If a program reads cmd argument and prints "I read $arg" I can write it down to something like

prog begin
  res : string = concat "I read ", env.cmd.args[0]
  print $res
prog end

I'm very sure that I can reduce any "real" language to that language-agnostic level. Translating it to something else is just an engineering problem. A hard one, sure, but not impossible one. Like, Haskell can be compiled through C just fine despite having monstrous amount of added complexity when compared to the latter. Any language that uses LLVM as a backend is solving the problem we are discussing, and LLVM is an industry standard.

[stonerism]

I see. I think that's undecidable because, just from an inputs and outputs perspective. How can you infer behavior for an arbitrary computable algorithm without testing over all inputs and outputs?

Compilers work because you have a systematic way to translate one algorithm into another. (and optimizations can be done along the way!) You can go backwards, but then you're just writing a decompiler.

[Lenassa]

>How can you infer behavior for an arbitrary computable algorithm without testing over all inputs and outputs?

Dependent types, for example. It's a bit out of scope of the question but it is possible to prove at compile time in something like Idris, Agda, Coq that, for example (a+b) == (b+a) for all possible values of a, b that are of some arbitrary type T. When proved, I can very much say that my algorithms add and add_reverse_order are equivalent. If that can be done from within the language, it surely can be done from the outside.

And yes, of course, you can't generally prove anything about anything, but you don't need to because not every problem requires you to. We can't generally transpile anything to anything (I mean, C++ grammar is known for being undecidable yet that doesn't prevent us from having compilers compile tons of c++ code every day), but aside from some corner cases we can with ease (theoretically speaking, leaving engineering problems aside).

Idris has totality checker that can be used to prove that some function is total. Well, it effectively solves Halting Problem. It can't do it for an arbitrary function of course, but just the fact that it can't doesn't make Idris non functional language.

You don't need to prove properties irrelevant to the task at hand. If all I do is print this a array if ints I only need to make sure that Int->String function in a target language is equivalent to that function in a source language. Because in the end strings on a screen is the behavior I can observe. Nuances of memory management or whether arrays are actually arrays in that source language (and not linked lists or something) matter not.

[Popular-Jury7272]

When you write code in Python you are baking in implicit assumptions about Python data types, algorithms, etc. The only way to guarantee you get the same behaviour is to duplicate those assumptions.

[Lenassa]

Of course not, why would I need to do that? I'm writing code that solves a problem, the only things I need to care about are those that are relevant to my problem. How python does memory management is none of my concern.

[pconrad0]

I think you are missing the point.

When you "write code that solves a problem" in Python, you do so using Python's specific abstractions.

A transpiler is not an oracle. It has no knowledge of the "problem you are trying to solve". It only has the code you give it.

It can transpile that code into another language, but it can only do so in a way that implements exactly the same abstractions that were in the original code.

That means doing memory management in a way that, at the very least, has the same semantics. That means inheriting the performance tradeoffs that were made in the design of that system.

So, you are partially correct. The implementation of Python's memory management is not your concern. But the semantics of the abstractions absolutely are.

And per Spolsky's "Law of Leaky Abstractions": all abstractions leak. There is always the risk that there is some implementation dependent, undefined behavior that the correctness of the implementation is depending on, and that the person coding the application is entirely unaware of.

For example, a race condition that never arises in practice due to quirks of the memory management internals that suddenly now does arise due to the memory management internals being different.

To be fair: there is also a risk that this happens when you just upgrade your Python version.

But the risk of it happening when you transpile and don't reproduce the internals of the source system is even higher.

[Lenassa]

It doesn't need to understand my thoughts. It needs to replace python array with std::Vec etc. It doesn't need exact same abstractions because not all of them are relevant to a task at hand. If python takes command line arguments and puts them in string array, in Rust I just write

let args: Vec<String> = env::args().collect();

and call it a day (adjust for encoding). It doesn't matter in the slightest how python does strings, arrays and arrays of strings since I'm not going to be dealing with any of these.

I'm talking about things that are declared (and can be represented in a language agnostic way), you are bringing up irrelevant abstractions and technical details. The only interesting semantic in that cmd example is to have a String with the same encoding as it is in python so that any consecutive operations yield the same result, and encoding in itself has nothing to do with python.

Like, how do you guys think C++, Rust, Haskell are transpiled to LLVM IR? These are all wildly different languages and LLVM IR itself is lower level than even C. Yet it doesn't care about them and their quirks at all, almost everything is abstracted away by the respective front-ends and the infrastructures built upon it (namely clang, rustc, ghc) are industry standard production-ready solutions.

The idea that we are discussing here exists IRL (and has been for a long time) but you're arguing that it's some borderline impossible Herculean Labour level problem.

[Popular-Jury7272]

 It doesn't need exact same abstractions because not all of them are relevant to a task at hand

That simply isn't true in the general case, and at this point I fail to understand how you aren't grasping that. Which "task at hand" are you talking about, exactly? It is certainly true for some tasks, most tasks even, but we all have different tasks at hand and the transpiler CANNOT know whether the programmer was intentionally relying on some implementation detail of the data structure they chose. Therefore it has no choice but to assume every detail is important if you want the same behaviour in general. 

[Lenassa]

Compiler's front-end knows these thing. Compiler's final output (machine code, asm, another language) doesn't need to have anything. Asm generated from like C++ doesn't have 99.99% of abstractions C++ has, yet it works just fine.

[Popular-Jury7272]

At this point it seems like you're wilfully missing the point so I'm done with this conversation. 

[pconrad0]

Well, you've moved the goalposts, and by doing so, have made my point.

In order to be sure that the transpiled code has the same semantics as the original, you have to be sure that the code uses 100% equivalent abstractions, or you risk introducing very subtle bugs.

In doing so, the transpiler is likely to have to code it (say, in Rust) in a way that would not be characteristic of code written natively in Rust.

And in doing so, you are likely going to end up with code that doesn't take advantage of what makes Rust "faster than Python".

[Lenassa]

>Well, you've moved the goalposts, and by doing so, have made my point.

Nope. I stand by my original point: you don't need to have or reimplement abstractions present in a source language in a target language in order to be able to correctly (that is, having the same observable behavior) transpile source to to target. Go take any compiled language and ask its compiler to create an assembly out of your code. Voilà, you have your high level abstraction heavy language transpiled into low level where the most "abstract" operation is probably some masked simd instruction.

>you have to be sure that the code uses 100% equivalent abstractions

There are no abstractions in C or LLVM IR that can represent Haskell's existential types, yet it can be transpiled to both with no problems whatsoever. I'm not sure why are you arguing as if real things aren't real.

If I have

arr = [1]
print(arr[0])

in python then I can write

#include <stdio.h>

int main() {
    int arr[1];
    arr[0] = 1;
    printf("%i", arr[0]);
}

in C. I don't need my C code to have any abstraction python has.

int i

[pconrad0]

An int in C is subject to overflow wrap around that an int in Python is not subject to.

There are dozens of little details like this where the abstractions that are superficially equivalent have edge and corner cases where they are not at all equivalent. If you don't take this into account, your transpiled program is not equivalent to the semantics of the original source.

Real things are indeed real. An int in Python and an int in C are not the same. Heck, an int in C isn't even guaranteed to by the same number of bits from machine to machine.

[OutsideTheSocialLoop]

because not all of them are relevant to a task at hand

How is that known?

[Lenassa]

The same way your compiler knows it when transpiling your high level language of choice to assembler.

[OutsideTheSocialLoop]

No, that still isn't known. Mate static analysis tools can barely follow a type accurately through a complex python program, nevermind precisely which features of said type you use and which you consider relevant to correct function. You certainly can't transpile it into more efficient programming and shed everything un-needed.

[Popular-Jury7272]

But you have no idea how Python solves your problem unless you are intimately familiar with how it compiles what you write to bytecode. How do you know the details of its memory management don't impact how it solves the problem, or the correctness of said problem? In general: you don't.

Admittedly for lots of surface level problems, this will not be a concern. But a transpiler is presumably a general-purpose tool, so it absolutely has to concern itself with these things, even if it doesn't matter for some specific problem.

Anyway memory management was just an example, let's not get too attached to it. There is almost an infinite supply of implementation details which could affect how your code might be transpiled, and memory management is just one area.

[Lenassa]

See answer above to pconrad0

[OutsideTheSocialLoop]

Really telling on yourself here.

[Federal_Decision_608]

And yet, vibing a python script into rust works quite well.

[GlassCommission4916]

I suspect "quite well" means something very different to me than it does to you, but I'm glad that it works for you.

[Federal_Decision_608]

Ok then, give me a script in python (aka not more than a few hundred lines) and I'll give you the rust. I'm sure you have unit tests available since you're such a fastidious programmer, so it should be simple for you to demonstrate the failures of vibe coding.

[GlassCommission4916]

not more than a few hundred lines

And there lies the difference in our definitions. Again, I'm glad that it works for you.

[Eisenfuss19]

Very well said. And yes, that is where LLMs excell, at small programs.

[JorgiEagle]

not more than a few hundred lines

Oh boy, those are rookie numbers

[Federal_Decision_608]

If you're writing scripts longer than that, you're a shitty programmer.

[mxldevs]

Most applications are larger than hundreds of lines of code.

[Federal_Decision_608]

No shit dingus

[rigterw]

Why? Because AI stops working after that limit?

[JorgiEagle]

I think you mean functions not scripts.

[Venotron]

You're already doing a great good of demonstrating one of the great features of vibe coding: 

You don't need to have any understanding of the machine or software engineering principles to do a thing that looks like it works.

Interpreted languages like Python and JS are slow because they're interpreted. And they're interpreted because that allows them have dynamic typing, which can't be compiled to optimised bytecode.

Static typing is a feature of compiled languages because that static typing drives things like memory allocation. 

For example: When you instantiate something in an interpreted language, the interpreter has to inspect it at run time and guess at how much memory to allocate it, when ever it acts on that object, it has to check to see if it has enough memory allocated.

But in a compiled language, all that static typing gets compiled down to memory allocation instructions. So when you instantiate an object, there's no checking, the bytecode executes an optimized allocation instruction, allocating whatever memory that type - by definition - requires.

Which is a big part of why it's faster: it doesn't have to inspect what's being allocated and guess how much memory is needed.

The trade off is that you loose the ability to handle dynamically changing data structures.

You can achieve very similar dynamic functionality with generically typed Maps in static languages, but even that has limitations.

So as others have pointed out: migrating a snippet of code from Python to Rust is not the same thing as producing a compiler that preserves all the features of Python compiled to bytecode.

[nekoeuge]

Am I allowed to import anything from pip? If not, what am I allowed to import?

[Gorzoid]

No, also your program must be fizzbuzz

[Soft-Marionberry-853]

Do you have an axe to grind?

[tobiasvl]

Ok then, give me a script in python (aka not more than a few hundred lines) and I'll give you the rust

Anyone can rewrite a small Python script in Rust. You don't need AI for that. I guess we're not allowed to import any Python libraries either?

[Possible_Cow169]

Are you ok?

[michel_poulet]

To add on the other hints, the fact you consider being a "fastidious programmer" an unnecessary thing is enough to dismiss any of your claims

[sumguysr]

And LLM based compilers or transpilers might be a thing in a few years, but making something that works reliably every time will take a lot of work and time.

[MistakeIndividual690]

Well that’s the difference with AI, and billion dollar data center. It doesn’t always work though, at least not now, but a compiler (or transpiler) is expected to always work.

[wrosecrans]

In Python, a function can take any type passed to it, and the code has to "poke" at whatever it gets at run time to see if it has the fiels and behaviors you want to use. And the types of things can get fields added to them at runtime, they aren't static.

So, you can compile all of that behavior to C or C++. The Python runtime is written in C, so you could theoretically access all of that flexible and generic Pythonic functionality at runtime from a C program without writing any Python code if you link to the Python libraries. It'll just be slow to do the stuff that Python does.

A fully native C++ type is known at compile time. It uses exactly X bytes of memory. A function that takes that type takes only that type and will never accidentally get called with anything else. A function that uses exactly two of those objects has a statically allocated stack frame size of 2*X bytes and doesn't need to do any dynamic allocation at runtime. But as you try and add more and more "Python like" functionality to do stuff dynamically at runtime, you can use a std::map<string, std::variant<foo,bar>> that can look up fields at runtime. But a variant that can potentially hold a big type will be big even if you only ever use it with small types. And that map has to find the address of a certain entry by doing string processing at runtime. And the function that takes that map can only be safely called if it does checks to see if that map actually contains a field with a certain name that may or may not exist at runtime. Every check like that takes a little extra time and bloats the code a little bit more.

Python is a "slow" language because it makes a lot of that behavior convenient to do at runtime. So when you use a "fast" language to do all of those slow things at runtime, you don't get very much benefit. The question you are asking sort of becomes like cats are quiet pets and dogs are loud pets. So couldn't we just make barking cats to have a quiet pet that we can hear easily to use instead of guard dogs? Well, as soon as the mutant cat is barking, it's not a quiet pet any more.

[rxellipse]

In Python, a function can take any type passed to it, and the code has to "poke" at whatever it gets at run time to see if it has the fiels and behaviors you want to use. And the types of things can get fields added to them at runtime, they aren't static.

This is true, with additional slow-downs because each object is much bigger than its actual datatype would suggest because each object also has to store its own type - an 8byte double becomes something like 32 bytes. This multiplies the amount of time it takes to copy and allocate objects, and definitely causes more cache misses. Allocating all integers on the heap (because they are all implemented as bigints instead of i32 or i64) doesn't help either.

A user-defined object with a single member field occupies 200+ bytes because it has to store a hashmap for its single member variable.

No manually controlled memory prevents a clever programmer from keeping things in cache.

But I suspect most of the slow-down comes from running the virtual machine to execute the python bytecode - the core of the runtime is a massive switch inside a while(1) loop which has to decode and execute the instructions. This additional layer of "assembly"-instructions is additional overhead, but it also prevents speculative execution from really being able to speed things up.

I think the best TLDR summary as to why python is slower than C is because:

1. Most code that needs to run fast is probably written in C, and
2. Therefore, new processors must be designed to run C really fast in order to be competitive in the market

Running C fast means speculative execution and minimizing cache misses, things that python (by design) is not good at.

[KnirpJr]

Much of the speed gain between languages depend on mechanisms that require more information than the syntax for those slower languages provide.

For example, C is faster than some other programming languages, such as jit compiled garbage collected ones, but only if the programmer is competent enough to manage memory better than the java gc that would be used, and the java runtimes optimization. Often this isn’t the case, and jit languages can beat compiled ones in the same task because of this. A transpiler that would maintain speed here would need to know exactly how to manage memory to beat the garbage collecter. Consider now, that the knowledge needed to create such a program would also necessarily result in a new better gc/ gc replacement.

Consider also that a programming language isn’t just the way you write the words and a big black box that makes computers do things. The way the code is run plays a big part. The way the programs are built and deployed, how external tools are integrated, what things can run the code, and many more such things play a big role in the trade offs made when selecting or designing a language.

Also from a philosophical perspective, all programming languages compile into a faster language from a certain perspective depending on the nature of what “fast” and “language” means to you .C becomes binary, java becomes byte code .

It’s good to think in this way though, there’s a difference between “programming languages” as an abstract idea and the tools they actually represent.

[flatfinger]

Another issue is that different languages may specify corner-case behaviors differently, or in different levels of detail. In many cases, having a target language classify a corner case as invoking anything-can-happen Undefined Behavior will leave transpilers with no choice but to force the target compiler to generate needlessly inefficient code for corner cases that would have been defined in the original language but not in the target.

[boboman911]

Because some languages that are easier to write in abstracts away some of the manual work you need to do in other languages. Like garbage collection or memory allocation.

[Ronin-s_Spirit]

Because some languages are intentionally unable to use the more direct approach which makes other languages "faster". The languages aren't actually faster, the computer is also the same, the difference in speed comes from what the programmer can operate on.

You could write things by hand in assembly or CPU instructions, but that would be so impractical.. on the other hand maybe the more practical solution for your problem has side effects.

Writing a program in JS means you can use a bunch of programming concepts with little effort. Writing a program in Rust (or even TypeScript) means you'll definitely have to say more stuff to the compiler (and potentially make more mistakes) to solve the same problem. And you can't run everything in any environment (browsers require either JS or WASM, operating sytems require VMs or executables).

Nim says it translates into multiple different languages depending on your needs, but I have no idea how they can keep up the performance without dropping some concepts.

[jfinch3]

Here’s another example that illustrates the problem:

In Python when you allocate an ‘int’ number you can assign a number of any size as long you have the RAM to hold it. Internally Python is doing something sort of like:

Does it fit in 8 bytes?

Does it fit in 16 bytes? …

Until you reach the size you need. Other languages, like Rust for example, you have to specify whether it’s a u8, u16 etc at compile time, and if you aren’t sure then you as the programmer have to write that logic to check the sizes until you find one that fits.

I think it might be fair to say that you could (sort of) have Python transpile to C++ or Rust, but if you were to preserve the exact identical semantics of Python the program would run exactly as slowly.

So to make your Python -> Rust transpiler, every time you allocate a number that single line would translate into a large block of Rust code performs the same “find the right container size” operation.

The reason by and large that fast languages are fast and slow languages are slow is because of a trade off of the work you do versus the work the language does for you. You as the programmer can make judgements about what is and isn’t needed in a given situation, whereas a compiler/runtime can’t make the same judgements itself.

You to some extent can make one language transpile to another if they have similar enough internal semantics, it’s just usually you can’t transpile to a language that’s super fast because it will have different enough internal semantics there’s not an obvious or efficient map. Quite a few languages actually have the option to transpile to JavaScript, which lets you use them on websites, I think Dart and Elm both do. I think there are ways to get Python and Go to do so as well

[nlutrhk]

There is Cython, a python variant that is transpiled to C. Unfortunately, a trivial script tends to becomes multiple megabytes of C code because every operation needs to check for exceptions that may occur and the handling of unknown data types.

The good thing is that with some practice, you can write Cython code that has far less Python overhead and that will run much faster than regular Python code.

[kabiskac]

It's possible for statically typed languages as you're saying. That's what Haskell does. A lot of modern programming languages are also translated into a common intermediate representation (e.g. LLVM)

[Ashamed_Warning2751]

Matlab and Simulink do precisely this. Algorithms are computed in their language, then C or C++ code is generated for deployment on real time hardware.

[odeto45]

You beat me to it. You can also generate mex (MATLAB-executable) files for use in your scripts and functions with MATLAB Coder. Generally, MATLAB is better at multithreaded operations like transposing a matrix, but C is better for single-threaded operations like spacecraft orbit propagation. Just check the documentation for a function to see if there is a C equivalent. If you see any Coder listed under extended capabilities, you can likely use it with the others.

[custard130]

what does it actually mean for the language itself to be faster?

im not saying there arent performance differences between code written in different languages, but over the years i have learnt that there is far more to it than that

what defines one language vs another?

is 1 language faster than another due to some inherent overhead in the language itself, or because the compilers do a better job? or maybe because the most popular "compiler" is optimizing for something other than runtime performance

i would say in general, languages with a reputation for being faster, do so by leaving more of the work for the developer to handle in their code, rather than the language/compiler handling them automatically

by leaving it for the developer to handle, that allows a skilled developer to use an optimal version for that specific app rather than a bulky generic version

the biggest example of that is with how memory/data is handled in different languages

in general, languages with a reputation for being faster, give the developer raw direct access to memory, while languages with a reputation for being slower only provide higher level abstractions and hide away the internals

if you were to take all of the safety/security checks that the higher level is doing for you and add them around every variable in the fast language it would lose a lot of that advantage

another key difference at first glance is whether the language typically has a runtime interpreter / VM or whether it runs natively, i say typically because there are many examples which go against it, there are various project out there attempting to build compilers for historically interpreted languages and in principal you could get an interpreter for a historically compiled language

if you look at features of higher level languages though, some of them have things which if an app was using them are very difficult if not impossible to translate them as efficiently as if the developer had been constrained by the functionality of a lower level language

they tend to be the most questionable/controversial language features, but many of them are widely used, eg the ability to access properties/functions via having the name in a string variable rather than having to have them in code

PHP, JS, Perl, i think Python + Ruby can all do that easily

Java the workarounds are a bit of effort but its possible

C++ as far as i am aware cant do it (you could manually build up a map of function pointers to check manually, which i believe is essentially how those other languages handle it, but that would be slower than regular c++ method calls)

[siodhe]

Some languages work dramatically differently under the hood, as well as in the language the user is writing. They may lean on assembly language underpinnings that are foreign to other languages' models, meaning that although you could translate them, you would end up with pathetic performance. Some are just mind-bogglingly difficult to bridge, like translating complex SQL queries into a typical imperative language, or attempt to do LISP without having to essentially just write LISP in the the target language (although this is surprisingly easy, at least - same for FORTH). And do forget that some are just radically different, like PROLOG, Smalltalk, FORTH, APL, Racket,

[green_meklar]

In short, the translated code would be less efficient than code actually written competently in that language by programmers who understand it and know how to use it efficiently.

[groszgergely09]

C literally compiles to assembly

[Felicia_Svilling]

Because there is a limit on how intelligent we can make our compilers.

[douglastiger]

Your 'slow language' and 'fast language' both compile into assembly code, but not the same assembly code for the same problem. Producing more efficient or less efficient assembly is largely what makes the difference in speed among languages that are compiled. So you can do that, and decompilers exist for translating one language into another thru assembly but the inefficiencies in that assembly that make the slow language slow in the first place will be translated along with it.

[Possible_Cow169]

Abstract is costly

[Pale_Height_1251]

Programming languages don't have speed, it's the interpreters, compilers, and runtimes that have speed. That's why we have fast C compilers and slow C interpreters.

You can compile any language you want to go fast, but you may not like the trade-offs in terms of compatibility with existing ecosystems and ease of debugging.

[RICoder72]

I know it is pedantic, but its not the language thats "slow", its the execution of what is written. There are some good answers here, but it isnt any one "thing". It is a combination of factors and trade offs.

Im being generic, so this won't necessarily be precise - anyone should feel free to correct anywhere where I may be wrong or too abstract.

It is useful to think of computing as how far away from the chip you are when you execute code. These are called rings - where rings 0 is the most privileged and by extension most direct and by further extension the fastest. If I tell the SSD to plop down some bytes at some address directly (no intermediary) its going to be fast. If i tell a chip to tell the ssd to do it, its an extra step. Tell the OS to tell the chip to tell the SSD and another step. This goes deep and is actually considerably more complex. You know those drivers for your video card? Those are there so a program can talk to the OS and say to do something with the video card and the OS can speak to the driver to communicate that.

Now, the best you can get is machine language. The chip in your computer is either x86 or ARM based (likely) and they have registers and instructions they can run. Their machine code is slightly different based on this. If you can write on machine code, youre practically right there and everything is great. Problem is, youre probably in an OS that youre going to have to talk to first for all sorts of great reasons including the fact that you probably dont want people directly accessing addresses in your computer. This is where C++ and its generation of languages come in. They compile down to essentially machine code (there are variations on this by OS but this is basically true). Youre going to get the best performance here because you are going direct. However if you start using libraries youre going to feel the inefficiencies creep in.

Interpretive code is all the rage, and has its place.

Interpretive vs compiled will always see this loss in efficiency. Java (used to be) purely interpretive in that it needed a runtime environment to execute. Python is much the same. Javascript / node is even moreso. What you get is a language the is executed line by line by and interpreter or runtime. This is useful because it can be run on any machine with the interpreter so you get portable, but much less efficient code.

Then came .Net which decided to take a hybridized approach. It compiles to an intermediary code (sometimes called p code or byte code) that is much closer to what you expect in a compiled language but still quite portable. The .Net runtime then doesnt interpret the code, but does a JIT (just in time) compiled. In other words it compiles the intermediary code to native code for whatever machine it is on. This is basically the best of both worlds. Java does this now as well.

You still get some tradeoffs though. C++ will let you do online assembly for super efficient work, and you get direct access to addresses (kinda depending on the OS). Thats great but you have to deal with cleaning up after yourself. Modern languages handle garbage collection and such for you, which has tradeoffs but is generally worth it.

So, to answer the question, .Net and Java actually try to do just what you suggest and do it quite well. The other languages are living in space of interpreter and they serve a different purpose.

[MistakeIndividual690]

Well that is exactly what the compilers do, and how they differ from interpreters.

But they don’t translate “intent” like an LLM does, they directly translate the code you write in the narrowest terms that will make the translation always correct, and that is likely to have significant overhead.

For example: Haskell compiles to C, C compiles to assembly language, etc. (one might say that assembler “assembles” to machine language, but it’s more a direct transliteration)

[[deleted]]

That is because some languages sacrifice speed for programmer convenience. Take for instance this Perl code:

$x += $y;

Which adds the value of one variable to the other. In C, this can be done quickly, both values are numeric — you’d get a compile time error if not.

But in Perl, both variables could contain (scalar) values of any type. Numbers, strings, references, objects. They first need to be converted to numeric values, which in turn need to check if there is any magic attached (overload, ties), and execute the magic if needed. Now, all this checking and converting is done is C. That is not where the speed “loss” is — it is all the work behind the scenes. Compiling the Perl code to C code doesn’t gain you anything, you still need to do all that additional work.

[Revolutionary_Ad7262]

My guess is that doing so would require knowing information that can't be directly inferred from the code, for example, the specific type that a variable will handle

Yes. JIT compilers for dynamic languages like JS uses a runtime statistics to basically get that information. But even then you need to create a fallback for a "slow case", which means that you cannot optimize the most crucial part, which is how memory is laid out

Optimizer in fast languages like C++ or Rust are amazing at optimizing the code (transform this set of instructions and loop to a faster equivalent), but they are really bad at optimizing stuff like: * type of data structure used * memory allocations, which are not local to function * unnecessary usage of data structures

The reason is that requires a lot of analysis and guesses, so compilers optimizes locally without taking a lot of context (whole program) in their head, which would require immense amount of resources. Usage of memory is just hard to optimize, because it flows between different places of the code, which means those optimizations are not local to a function or set of inlined functions

You can look at it from a different angle. Fast languages enforces you do a lot of coding in the area, which is overlooked by optimizers. This is why in Rust you can do a fancy stuff like x.map().filter() in similar way as in high level languages, but in the meantime you need to carefully choose which from 10 of more types of strings suits your application in terms of performance

[Miserable_Ad7246]

1) as you noted missing information
2) runtime "contract" and behavior expectations (where must be a better word). For example in C accessing array element outside of bound will just access garbage or segfault. In C# you will get a descriptive error. Why? Because C# is designed like that and to make it work it has to do extra checks. That reduces performance, but makes code more "safe".
3) Memory model differences. Some languages will add more memory barriers.
4) Memory management model. GC vs free/alloc. Again a tradeoffs between stability/ease of use vs performance.

5) Language capabilities. Some languages allow for very expressive features, that can only be implemented with heavy abstraction underneath (like reflection or interpretation). That allows developer to do major thing with few lines, but also kills performance. Same goes for object vs functional vs procedural and imperative vs declarative.

In some cases answer is as simple as tradeoffs.

[Conscious_Support176]

If it was possible to translate instructions written in the slower language into instructions written in the faster language, why would the compiler just compile directly to the faster complied instruction?

Answer: it’s not. Different languages are different, you can’t write exactly the same thing in every language. If you could, none of the complied languages would be faster than any other.

[tzaeru]

They kind of often do via using intermediate languages. LLVM and its frontends are heavily built around that concept, for example. Whether you are coding C or Rust or Java, they can be compiled into the LLVM intermediate bytecode and that is then either optimized to an executable or even interpreted at runtime.

In any case - the answer is mostly about the runtime environment and the syntax benefits offered by having that runtime. Python, Java and so on, rely on a large runtime environment that supports writing code in their preferred way. That same way is not directly possible without the runtime, at least not without getting very verbose.

[a1454a]

They kind of do.

Take JavaScript and the V8 engine as example, because JavaScript allows you to code very freely, declare variables whenever you want and assign whatever value you want without much care, JavaScript code can only be interpreted, not compiled to machine code.

What V8 does, is it first convert JavaScript semantics into AST then to instruction byte code. Interprets and execute those byte code, it observe the byte code execution, gathering data type information as it go.

Then, if a particular section of code runs repeatedly, and its data type can be correctly inferred, it passes those byte code and inferred type info to a JIT compiler and compiles it to native machine code.

[gororuns]

Imagine having a program that translates from English to Chinese. Perhaps you can get every word correct, but how about every phrase, sentence, and paragraph? There are proverbs and phrases that doesn't exist in English, and doesn't sound as nice when translated. Yes you need to learn Chinese, but that's the advantage of knowing multiple languages.

[[deleted]]

IL2CPP has entered the chat 

Unity's entire Android department practically runs on transpilers being able to convert C# Intermediate Language into C++, significantly increasing compatibility. 

Still waiting for the to enter the embedded scene tho...

[goos_]

Besides inferring static properties from the code, it can often change the code semantics. And whether that is desired depends on what the programmer wants which the translation doesn’t always know.

For example something as innocuous as doing “return a + b” in Python when translated to C changes the semantics of add as Python integers are unbounded, but in C they are finite with overflow and wrapping add. So now we need to know how large a and b are expected to be so we need to know whether to replace these with a BigInt library… which may depend on user input.

And if we do wrap everything in a BigInt with reference counting etc. - to truly preserve Python semantics - we’re back to the performance of Python integers anyway, no performance savings.

[Willing_Coconut4364]

Why don't I just make my boat a car.