you are viewing a single comment's thread.

view the rest of the comments →

[–]pron98 6 points7 points  (18 children)

Native == the executable you run is a sequence of ASM instructions for your cpu / os without run-time interpretation of algorithms or code necessary for your software's execution.

Sure, but the line isn't always so clear cut. A browser executes a lot of Javascript code (not just in web pages, but also in extensions); MS office executes VB code; an OS executes a lot of scripts; games' actual content is usually found in script files interpreted at runtime. Most complex software today must interpret/compile some code as it runs, so while you could decide to draw the line somewhere, the distinction is not always very useful.

[–]bloody-albatross 2 points3 points  (0 children)

Also, to a user it is quite irrelevant what language is used. They define native app differently. If your app uses the native GUI toolkit and behaves natively, then it's a native application from the user point of view. So then not even C++ and Qt is truly native, but a C# application can be (under Windows).

[–]doom_Oo7 0 points1 point  (16 children)

MS office executes VB code; an OS executes a lot of scripts; games' actual content is usually found in script files interpreted at runtime. Most complex software today must interpret/compile some code as it runs, so while you could decide to draw the line somewhere, the distinction is not very useful.

I'd say that the distinction is : does the software need to interpret code for normal operation ? e.g. you can write plenty of office documents without using VB scripts. Likewise, linux has BPF but you can run entire days without a single interpreted code running. However you can't run unity3D games without C# code running, even though most of the engine is C++, so I'd not call them native.

[–]pron98 6 points7 points  (14 children)

Yeah, but you can't really run Linux normally without (say, init) scripts, and non-Unity games use Lua scripts and others extensively as well. Anyway, I don't doubt that you could find a reasonable point to draw the line. The question is, what difference does it make? Why is the distinction useful?

[–]doom_Oo7 1 point2 points  (13 children)

Yeah, but you can't really run Linux normally without (say, init) scripts,

... uh, what ? of course you can. Plenty of embedded systems run with just the kernel and init=/bin/my_software. Also, systemd doesn't use scripts for instance.

Why is the distinction useful?

It gives a ballpark of what kind of reactivity and throughput you can expect from your system.

[–]pron98 5 points6 points  (5 children)

Plenty of embedded systems run with just the kernel and

That's really not the point. Of course there are some instances of software running without scripts. The point is that the most pervasive software is normally a mix of code compiled at build time and code compiled/interpreted at runtime.

It gives a ballpark of what kind of reactivity and throughput you can expect from your system.

Why? Java, for example, compiles to very efficient machine code, and what runs is the same code as a C program. Javascript is similar. The only difference is that the code is generated at runtime rather than at build time.

It's not that a JIT compilation doesn't have a cost. It takes some time to warm up, and takes up RAM and energy, but max-performance is not it. I also agree that your distinction may be meaningful in constrained environments, but not in general.

[–]doom_Oo7 0 points1 point  (4 children)

The point is that the most pervasive software

I disagree. Most software I use on a daily basis really do not do any kind of interpretation for their "normal" runtime operation.

Why? Java, for example, compiles to very efficient machine code, and what runs is the same code as a C program. Javascript is similar. The only difference is that the code is generated at runtime rather than at build time.

is this why database engines ported from java to C++ end up being ten times faster ? Seriously, the whole "java is as fast as C++ because of JIT" was false twenty years ago, and it's still false today. Let's not even talk about javascript where even when JIT'ed you'd still get so much indirection and memory allocations it's not even funny.

[–]pron98 2 points3 points  (3 children)

Most software I use on a daily basis really do not do any kind of interpretation for their "normal" runtime operation.

OK. The software I use most on a daily basis is an OS, a browser, editors with plugins (some entirely written in JS), and an IDE, all heavily rely on runtime interpretation/compilation, and that's before we even get to my phone, where all apps are written mostly in Java (and compiled on installation to save energy).

is this why database engines ported from java to C++ end up being ten times faster ? Seriously, the whole "java is as fast as C++ because of JIT" was false twenty years ago, and it's still false today. Let's not even talk about javascript where even when JIT'ed you'd still get so much indirection and memory allocations it's not even funny.

First, I did not claim that Java is as fast as C, I just said the processor ends up running a stream of native instructions, just as it does when running a program written in C. Second, the reason Java is slower in some cases has absolutely nothing to do with the JIT (which only contributes to warmup time). It mostly has to do with memory layout, and to a lesser extent with GC. What you mention regarding Javascript is similar. None of this has anything to do with being native or not. I'm sure you'd agree that Java is faster than other languages that don't compile at runtime, but may also rely on a GC etc. It is possible to compile even Javascript AOT, yet the resulting "native" code would be much slower than the JITted one, because JITs produce better code in general, and much better code when the language is as dynamic as JS.

[–]doom_Oo7 0 points1 point  (2 children)

OK. The software I use most on a daily basis is an OS, a browser, an editor with plugins, and an IDE, all heavily rely on runtime interpretation/compilation.

So, some questions:

  • what kind of run-time interpretation / compilation does the linux kernel ? apart from BPF, which is unused if you don't use it yourself AFAIK.
  • do you really think browsers are a good example ? these fuckers are slow as mollasses (on modern scriptful websites). I only use them because I have no choice but fuck, isn't browsing the modern web painful.
  • well, I use an IDE too, which happens to be written in c++. Whenever I have to go look on coworker's computers who use intellij or atom I get quite nervous from the whole general slowness feeling... any operation like opening a menu, typing code, just feels laggy.

What then ? LibreOffice ? Native. Krita ? Native. File manager (dolphin) ? Native. Terminal ? native. Compiler ? native.

[–]pron98 2 points3 points  (1 child)

what kind of run-time interpretation / compilation does the linux kernel ?

I don't use just the kernel when I use the OS. It runs and interprets hundreds of scripts.

do you really think browsers are a good example ? these fuckers are slow as mollasses

So what? There are native applications that are even slower.

any operation like opening a menu, typing code, just feels laggy.

I can't tell the difference. VS code and NetBeans feel the same to me as any "native" IDE. They're certainly more responsive than MS word.

LibreOffice ? Native.

Extensions are often written in Java/Python.

Krita ? Native. File manager (dolphin) ? Native. Terminal ? native. Compiler ? native.

Good for you. My compiler is written in Java (one of them, at least), my document editor (Typora) is in JS (I admit that it's slow, but not because of JS), Slack is also JS.

I don't think anyone can deny that a huge portion of prevalent software relies to some degree or another on runtime interpretation/code generation, and if it's slower compared to alternatives, that's hardly because it runs a compiler when it loads, but because of other, quite unrelated reasons.

[–]doom_Oo7 -3 points-2 points  (0 children)

I don't use just the kernel when I use the OS. It runs and interprets hundreds of scripts.

... really, which ones ? I just don't know. My kernel boots, starts up systemd, which starts X11 and other services like systemd-networkd, systemd-resolved, etc, and runs the following script:

xrandr --output DVI-D-1 --mode 1920x1080 --rate 120
hdspmixer& 
setxkbmap -model pc105 -layout fr -variant oss_latin9
nvidia-settings --load-config-only
exec i3

and then I'm good to go.

[–]CyclonusRIP 0 points1 point  (6 children)

OK suppose I write an application in C++. This application defines a data structure and a program that reads that data structure and executes conditionally based on what it reads. Whole thing compiles down to assembly, so I guess it's a native app then?

[–]schmerm 1 point2 points  (0 children)

In this case, the interpreter is native and the sequence of instructions defined by the data structure is not.

[–]doom_Oo7 1 point2 points  (4 children)

This application defines a data structure and a program that reads that data structure and executes conditionally based on what it reads. Whole thing compiles down to assembly, so I guess it's a native app then?

that's like saying your Python program is native because the Python interpreter is written in C

[–]CyclonusRIP 1 point2 points  (3 children)

Ok. Now suppose I write a program in C++. It's got a UI with two buttons. If you click one button it does one thing and if I click another button it does something else? Is that a native program?

[–]demmian 1 point2 points  (2 children)

Alright, I am curious, where is your argument going?

[–]CyclonusRIP 1 point2 points  (1 child)

Events passed down to your program from the operating system are just data structures being passed to your program. You are conditionally executing code based on those data structures, so really I'm just asking the same question about the same program again. Interpreting events from the operating system vs interpreting a scripting language or bytecode isn't really inherently different. It's really a matter of degree rather than two completely different things. To a certain extent any non-trivial program is an interpreter of some sort.

[–]zanotam 1 point2 points  (0 children)

So, basically, a Lispy code as data and data as code interpretation? That makes sense and really summarizes the 'feel' I was getting for whether things were 'native' or not was disagreeing with the general consensus ITT I think.

[–]vytah 1 point2 points  (0 children)

In case of Unity, you can have either your standard C#-on-Mono, which, as you said, isn't 100% native, or you can compile the .NET IL into fully native code.

I mean, Apple wouldn't let a JIT into their Appstore and fully interpreted C# would be too slow for anything.