SoylentNews is people
SoylentNews
Both Facebook and Netflix implemented their eponymous apps with Web. Despite spending millions of dollars, neither of them could achieve an iPhone-like user experience (60 frames per second and less than 100ms response to user inputs) on anything less powerful than a system-on-chip (SoC) with four ARM Cortex-A9 cores.
In contrast, numerous products like infotainment systems, in-flight entertainment systems, harvester terminals and home appliances prove that you can achieve an iPhone-like user experience (UX) on single-core Cortex-A8 SoCs. Our above-mentioned manufacturer HAM Inc. (renamed for the sake of confidentiality) verified these results by building both a Web and Qt prototype.
In this white paper, Burkhard Stubert explains how he could save one of the world's largest home appliance manufacturers millions of Euros by choosing Qt over HTML. The secret? Qt scales down to lower-end hardware a lot better, without sacrificing user experience.
With a five times smaller footprint, four to eight times lower RAM requirements and a more efficient rendering flow than HTML, Qt provides faster start-up times and maintains the cherished 60fps and 100ms response time, where HTML would struggle. The calculations show that being able to just downgrade your SoC by just one tier like this, Qt can reduce your hardware costs by over 53%.
(Score: 5, Interesting) by maxwell demon on Thursday February 22 2018, @10:54PM (20 children)
Native compiled application is faster than interpreted JavaScript application. News at 11.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1, Informative) by Anonymous Coward on Friday February 23 2018, @12:09AM (15 children)
This reminds me of when Mozilla found out that writing their OS backend in c++ "magically" made their performance and memory woes vanish with FirefoxOS.
(Score: 0) by Anonymous Coward on Friday February 23 2018, @01:32AM (14 children)
I honestly thought you were joking, but looking through the information I can find, that claim seems true. I'm truly shocked at the level of surprise some of the developers communicated with the switch over. And their original plan was to basically have everything but the kernel and an init shim written in js.
(Score: 3, Touché) by driverless on Friday February 23 2018, @03:27AM (12 children)
I'm not. There really are people who think an interpreted scripting language can do everything, including running at the same speed as native code. And not just your canonical PHB, some programmers believe this crap as well. Having a high-visibility article written on this may help disabuse them of this insanity.
(Score: 1, Interesting) by Anonymous Coward on Friday February 23 2018, @09:13AM (2 children)
Back when Java bytecode was still interpreted (rather than JIT'ed), Java fans kept claiming that Java code could be *faster* than C code. Even though Java at the time was the slowest of all languages.
I tried arguing that if interpreted Java bytecode is faster than compiled C code, then write the Java runtime in Java, and show that it runs Java bytecode faster than the native Java runtime. Of course it would need to run on top of the native Java runtime, just like any other Java program.
Not only would that have to be faster if the claim is true, it would also mean that running the Java bytecode version of the Java runtime on top of itself is faster than running it on top of the native Java runtime. And as a consequence, you'd be able to keep stacking it on top of it self, making it faster every time, until you approach infinite speed.
Even that didn't convince them that there is no way an interpreted language is faster than a compiled one.
(Score: 0) by Anonymous Coward on Friday February 23 2018, @05:52PM
lmao!
(Score: 2) by Wootery on Friday February 23 2018, @07:40PM
But that's a straw man. Not even the silliest hard-boiled JVM advocates ever tried to claim that a 'pure' (non-JIT) interpreter could outperform traditional ahead-of-time compilation.
Thankfully, modern JVMs are not pure interpreters. They're far faster than pure interpreters... but, yes, they're reliably slower than highly optimised C code compiled with a serious C compiler.
(Score: 2, Insightful) by ptman on Friday February 23 2018, @09:53AM (4 children)
JIT compiled languages can be faster than C/C++ in some cases (Java has better memory allocator by default, the JIT compiler can optimize things based on what's going on when the program is run vs. what is predicted to happen when the program is compiled): https://stackoverflow.com/questions/4516778/when-is-java-faster-than-c-or-when-is-jit-faster-then-precompiled [stackoverflow.com] https://softwareengineering.stackexchange.com/questions/110634/why-would-it-ever-be-possible-for-java-to-be-faster-than-c [stackexchange.com]
But generally compiled languages are preferred for performance critical tasks by default: https://benchmarksgame.alioth.debian.org/ [debian.org]
(Score: 0) by Anonymous Coward on Friday February 23 2018, @11:57AM (1 child)
To the user the JIT compilation overhead when opening the program will still render it slower if it happens every time the program is opened. This slow down spread across many instances of usage (idiocracy such as writing CLI tools in Java that may be invoked millions of times per minute comes to mind) results in them wasting many more cycles than they would with a """slower""" precompiled binary. This is why .NET in windows is and always will remain garbage, despite it's per-system JIT compilation.
(Score: 2) by Wootery on Friday February 23 2018, @06:44PM
This isn't inherent to Java, it's an issue with the way current JVMs typically work. There are two possible solutions:
1. Use Nailgun, [github.com] which essentially turns your command-line invocations into fast operations in an already-warm, long-lived JVM
2. Use a JVM with AOT compilation. Excelsior JET can already do this, and it may soon be coming to HotSpot.
.Net has a JIT cache, and fast start-up. .Net isn't like your average JVM - there's no mixed-mode execution with an interpreter.
(Score: 2) by Wootery on Friday February 23 2018, @06:39PM (1 child)
Well, no. They're different. The JVM can do ultra-fast pointer-bump allocations, but it has to do garbage-collection. C/C++ have slower allocation and manual deallocation, but they don't have to run a garbage collector.
(Score: 1) by ptman on Monday February 26 2018, @02:22PM
True, only better in some cases.
(Score: 2) by darkfeline on Friday February 23 2018, @07:19PM (3 children)
That's not wrong though, with the magic of JIT. For example CL/SBCL is an "interpreted scripting" language that runs very close to C and in some cases faster.
It's just that much less work goes into developing JITs for interpreted languages than compiled languages.
(Just a reminder that language != implementation. I can damn well make Python run as fast as C if I write a good enough compiler for it.)
Join the SDF Public Access UNIX System today!
(Score: 2) by Wootery on Friday February 23 2018, @09:00PM (2 children)
No, this is absolutely not the case. For a start, there's no such thing as an 'interpreted language', but the differences between programming languages really do have consequences for their performance, and it's silly to pretend otherwise.
A vast amount of effort has recently been expended on accelerating dynamically typed languages, particularly (but not exclusively) JavaScript. It's still far, far slower than C/C++, and will continue to be. [debian.org]
Even if you use a C compiler that doesn't optimise well, like Tiny C Compiler, your C code will likely outperform JavaScript on V8. Why? Solid technical reasons - it's far harder to optimise dynamically-typed languages.
You can't. If you could, I'd be asking why on Earth you haven't published your techniques.
Google tried and failed. [wikipedia.org] Various people [google.com] have done PhDs on this kind of challenge. Dynamically typed languages remain far slower than C.
There's even a name for this fallacy: the Sufficiently Smart Compiler fallacy. [c2.com]
(Score: 1) by toddestan on Sunday February 25 2018, @07:18AM (1 child)
Google was building a just-in-time compiler. If you built a regular ahead-of-time compiler that took a Python script as an input and spit out a binary there's really no reason it couldn't be as fast as something written in C. In the same way a human could also take the same script, and understanding how it worked, rewrite it in C and fed the resulting code to a regular C compiler. Hey - I didn't say it would be easy.
(Score: 2) by Wootery on Sunday February 25 2018, @07:45PM
No. Language design does impact code performance. You really think Google were so stupid as to overlook the ahead-of-time option, before wasting thousands of hours?
There are differences between JIT and static compilation, but they're not generally total game-changers, and in this case, JIT might actually be a better strategy.
JIT compilers have the advantage of runtime information (regarding both program execution, and precise knowledge of the target architecture), but have the disadvantage that they can be more constrained in terms of how long they should execute for.
Also, an ahead-of-time compiler is a JIT compiler... if you happen to run it immediately before executing its output.
No. Efficiently handling dynamic typing is incredibly challenging. In C, the compiler knows precisely what is meant by the '+' operator, and which function is referred to by an identifier. (Well, ignoring its link model, at least.) This is because of C's static typing and simple dispatch rules. In Python, you know almost nothing at compile-time, so unless your compiler is very smart at handling these uncertainties, your generated code will handle this stuff at runtime, and performance will be disastrous. This, in brief, is why it's much harder to compile Python/Ruby/JavaScript to efficient machine code, than to compile the equivalent well-written C code.
If you want to read about how projects like JRuby speed up their interpretation, a good starting point might be this blog post. [headius.com] They have to put in a lot of work if they want to compete with static languages in terms of performance.
Yes, it's theoretically possible (in complexity theoretic terms), and perhaps compiler technology will get there eventually, but dynamically typed languages will remain slower for the foreseeable future.
(Score: 0) by Anonymous Coward on Friday February 23 2018, @04:09PM
There is a generation of "programmers" running around these days that have never touched anything but interpreted languages.
You will notice this in how they have no respect for memory footprints or cpu utilization, only "UX" and features (and maybe "security" theater when pushed).
(Score: 2) by Lester on Friday February 23 2018, @11:38AM (3 children)
But multiplataform development is easier with Javascript than with any compiled language.
(Score: 2) by pendorbound on Friday February 23 2018, @02:11PM (1 child)
Qt is actually pretty easy to work in. Try it before you knock it. It's a bit more complicated to write, but you miss a lot of the "write once, debug forever/everywhere" issue that Java & Javascript give you. It's a net gain from a development time perspective. The runtimes are a lot more consistent across platforms than web browsers are.
More importantly though, this article isn't even talking about multi-platform. The Qt example is talking about writing an app to target a specific piece of hardware. You need to pay for higher specs to run the same app more slowly when you write it in HTML/Javascript compared to a native GUI system.
(Score: 2) by Wootery on Friday February 23 2018, @06:52PM
Lester does have a point though - it's a very different skill-set. If I had a team of passable web-devs accustomed to writing passable JavaScript, and with no knowledge or understanding of C/C++, I wouldn't want them set loose.
Maybe QtQuick would help there.
(Score: 0) by Anonymous Coward on Friday February 23 2018, @03:44PM
JS isn't even consistent between browsers and the "standard" changes on a daily basis. Please try again.