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: 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.