4 ms·
So many were wrong that by Moore's law we will have plentiful ram and inexpensive CPU to run bloated Java or C# programs. In 2016, desktop applications are stil
by frik 11y ago
So many were wrong that by Moore's law we will have plentiful ram and inexpensive CPU to run bloated Java or C# programs. In 2016, desktop applications are still 99% C/C++ and fast mobile apps in C/C++/Object-C. Languages like Rust and leaner new languages with JIT that care more about resources like Go, Julia, Lua, Swift, PHP7, Hack or even newer iterations like C++14 are certainly good way to go.
- pcwalton 11y ago1. I don't see any reason why Lua (presumably you mean LuaJIT?) and PHP 7 would be faster than Java or C#. The compilation techniques are the same, except that Java and C# have more mature JITs. 2. Java and C# JITs perform many more optimizations than Go 6g/8g do. 3. Objective-C message passing is a lot slower than method calls in Java and C#.
- chc4 11y agoNot defending the grandparent's post, but LuaJIT is actually faster than Java or C#. Hell, it's faster than raw C in certain cases because it can optimize better due to being a simpler language. Mike Pall is a god amongst man. I think it's due to LuaJIT being one of the very few tracing JITs that are still in development, since they are notoriously difficult to write and maintain.
- xxs 11y agoTracing compiler might add a bit of performance in the naive cases where the developers don't know how the JIT optimizes. If I care about performance I'd check the generated assembly and modify accordingly till I get decent result. Baring that: do you have any reputable source claiming LuaJIT outperforms C#/java/C?
- chc4 11y agoUnfortunately the Benchmarks Game seems to have removed LuaJIT in favor of Lua 5.3, but https://stackoverflow.com/questions/2588071/is-luajit-really-faster-than-every-other-jit-ed-dynamic-languages https://stackoverflow.com/questions/2588071/is-luajit-really... mentions it as being an order of magnitude faster. I've seen it said multiple times that LuaJIT is the gold standard of JITing, but can't find very many concrete benchmarks anymore.
- xxs 11y agoAnything saying 'order of magnitude' can't be taken seriously. That would imply a horrid baseline in order to get it that fast. Merely I don't believe a tracing JIT would have a great impact in a real world scenario.
- frik 11y agoOutdated knowledge. PHP with its shared nothing design makes it very scalable, the 2016 implementations are very fast and consume little memory. LuaJIT see other post. Object-C (there is C underneath, read https://en.wikipedia.org/wiki/Object-C https://en.wikipedia.org/wiki/Object-C ). Check out Julia, it's great. You can write pretty low level code in modern languages like Go, Rust without loosing everything (don't come with Sing# and Java related misc things, yada yada). Also my point was that these languages consume less memory. I have yet to see a Java or dotNet application that doesn't consume too much memory for my feeling (not to mention the GC idioms). When I read that people put monolithic Java enterprise apps in Docker containers or wonder why the new Startmenu crashes that often, it reminds me why I care about computer resources. After all we are still stuck with 3.8GHz single core performance, same as 2004! (memory bandwith,etc got faster, I know) Give me a 10 GHz single core CPU and we can start talking.
- kuschku 11y agoYou know, I’m developing Android apps. And you wanna know what eats the most RAM? The UI and the binary itself. Most of the RAM of my application is used by the app and the goddamn UI and its fancy xxxhdpi and xxhdpi and xhpdi and hpdi and mdpi images, and because Android doesn’t support svg everywhere yet, we have to package tons of ressource twice and thrice and five times.
- orf 11y ago> desktop applications are still 99% C/C++ In the Windows world especially that's not even slightly true.
- frik 11y agoIn Windows world you are very wrong. Run "Process Explorer", Options -> Color Selection -> check ".Net Processes" (Yellow). In all consumer Windows up to Windows 7 no dotNet processes run (by default) at all. [Longhorn was meant to bring a dotNet shell (explorer, etc) but failed big time.] I have lots of common applications and all are coded in C/C++ with the exception of IDEs (VS/Eclipse/IDEA) which eat memory like no tomorrow. I couldn't care less about the brave Win8/10 world.
- Aleman360 11y ago> I couldn't care less about the brave Win8/10 world. Still supports C++ ;)
- orf 11y ago> In all consumer Windows up to Windows 7 So XP and Vista then. Most of the software that comes pre-installed on Windows machines (by the OEM) is .NET. That fact by itself means the amount of software written in .NET is far far far above 1%. > In Windows world you are very wrong. So you're saying after the shedloads of money, effort and development Microsoft has pumped into .NET it hasn't even amounted to 1% of applications running it? That's preposterous.
- frik 11y agoI almost wanted to include the exclaimer of "crap software preloaded by hardware vendors like HP, Lenovo, Dell, etc". Who (in the right mind) doesn't reinstall Windows and install only the "device drivers" but not the crap UI software that is of very little use anyways? The device driver is always in C and sometimes in C++. Nvidia/AMD/Intel drivers work fine without the crap "experience" or "control panel". And even if you install keep all the preloaded software, it's the first action to remove them from autostart, isn't it? Otherwise don't blame your hardware or Windows why your computer is that slow and takes ages to start... DotNet and Java are very big in enterprise software and server software. Java is also big in open source thanks to Apache foundation (if you need a full text search engine, Lucene is still the only feature complete in town; and all the projects based around Lucene like Hadoop, Solr, etc) There was an C++ port of Lucene (CLucene) that was a lot faster and used little memory and compatible with Lucene file format. Though no native fork of Lucene keep up with the development speed of Apache Java Lucene.