7 ms·
According to their normalized "global" results, something interesting i see: 1. Pascal, surprisingly, the most memory efficient of all. I should take a look at
by flavio81 9y ago
According to their normalized "global" results, something interesting i see:
1. Pascal, surprisingly, the most memory efficient of all. I should take a look at the implementation they used.
2. Rust a good alternative to C which leads in "energy efficiency" and speed.
3. Common Lisp most energy-efficient and fastest and smallest memory footprint of all the dynamic programming languages in the list -- like Python, Ruby, Lua, Perl, and even Racket (which fares pretty well)
4. PHP, JRuby, Ruby, Typescript, Perl, Python, being massively slow than the fastest languages, for example Ruby being 59 times slower than Rust or C.
I agree that these languages (in item 4) are "acceptably fast" for many applications, but we can't say they are "close to the speed" of the fastest languages, even more if we consider the fastest dynamic+interactive languages like Lisp (Python being 21 times slower than Lisp.)
5. I wonder which implementation of Lua they used. Lua can be pretty fast, one of the fastest dynamic languages out there.
- goatlover 9y agoI have noticed a significant speedup using LuaJit, similar to PyPy compared to normal Python. I'm guessing if LuaJit & PyPy were used, the performance for Lua & Python would be similar to JS in these results.
- mamcx 9y ago> 1. Pascal Pascal is a "hidden" gem in the area of languages. Sadly not enough pus for it, but imagine if it have the push that other languages have...
- agumonkey 9y agoNow I need to finish my lisp.pas
- open-source-ux 9y ago"Pascal is a "hidden" gem in the area of languages" I agree. Programmers won't look at it because they perceive it to be old and out-of-date. But the language hasn't stood still. It's a fast, low-memory language. FreePascal with the Lazarus IDE is one of the best cross-platform development toolkits for building native desktop apps. Sadly a lot of programmers can never see beyond the verbose (but readable) syntax.
- Kamgunz 9y agoMaybe somebody needs to create a more palatable language, that'll transpile (I know, I know, compile) into pascal?
- mamcx 9y agoThis guys made a pascal-like language: http://www.elementscompiler.com/elements/oxygene/ http://www.elementscompiler.com/elements/oxygene/ Exist various dialects of pascal (Modula, Oberon, etc) so is not something so far in the wind. But if you lose too much of the syntax you remove part of the charm.
- fasquoika 9y agoPalatable how? Pascal's syntax is not especially different from that of most scripting languages
- andrewflnr 9y agoEvery time I look at the syntax, it feels really verbose. IIRC some dialects require all caps or initial caps on keywords; at any rate that's how most examples are shown, and it's rather off-putting. Superficial, I know, but I'm probably not the only one.
- fasquoika 9y agoI don't know about other implementations but FreePascal is completely case insensitive. Identifiers are actually treated the same if the only difference is case. I don't particularly like this, but I've never seen it actually be an issue
- CoreXtreme 9y agoRuby also has gem.
- psyc 9y agoWhen I started programming in the early 90's, I remember Pascal being a serious contender, with C vs Pascal compilers being a pretty evenly matched contest.
- mac01021 9y agoBut why should it's memory utilization be so much lower? Pascal and C give the programmer basically the same control over memory layout, no?
- subwayclub 9y agoBasically, C's semantics assume too little - everything is a primitive type or a pointer dressed up to look like something else. Pascal has a stronger notion of types and this allows for additional automatic optimization where they're relevant - memory layout just happens to be one such area.
- addHocker 9y agoI miss the ability to pair structures as "antagonistic" - aka if one exists the other is not, thus allowing for unions of various datatypes who guarantee that if they exist- the shared memory they reside in is theirs and theirs alone.
- dmytrish 9y agoJust a wild guess: Pascal may use tightly packed structures without alignment by default?
- nine_k 9y agoMuch of Pascal (or, rather, Modula-2 and Oberon) is revived inside Go.
- continuational 9y agoWhat parts of Pascal do you recognize in Go?
- pjmlp 9y agoThe id type way instead of type id. The way methods are attached to types appeared first in Oberon-2. Type assertions are similar to Oberon. The unsafe package idea is similar to SYSTEM in Oberon or Pascal. The stronger type semantics forcing explicit casts.
- dom96 9y agoAnd even more so is revived in Nim.
- agumonkey 9y agoImaging if the world ran on SBCL instead :)
- equalunique 9y agoSBCL is one lisp that I intend to learn more about. It's apparently the lisp of choice for XMaxima, which is a program that I used a lot in high school.
- aaron-lebo 9y agoWhere are you getting that Pascal is the most memory efficient (edit: duh, under the "memory efficiency" table, mistakingly read this as "efficient")? It's firmly in the middle of the pack in every result, in their global result table it's slower and less energy efficient than Java (!). It's only advantage is that it's smaller than anything else. Don't mean to assume you are wrong, but what are you referring to?
- shock 9y agoIn the `Normalized Global Results` table, Pascal is used as the reference (for memory use) and everything else is reported relative to it.
- copx 9y ago>5. I wonder which implementation of Lua they used. Lua can be pretty fast, one of the fastest dynamic languages out there. I looked at the binary trees benchmark and while the Python version used multiprocessing to parallelize the code, the Lua version was not parallelized at all.. .. not that this is entirely unrealistic. Python comes with MP in the standard library while I am not aware of any "industrial strength" solution for Lua, whether MP or thread-based.
- igouy 9y agoFor an interested Lua programmer, there's a kind-of workable approach -- http://benchmarksgame.alioth.debian.org/u64q/program.php?test=mandelbrot&lang=lua&id=6 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
- wruza 9y agoIdk if it is industrial strong, but there is lanes and probably few more listed at lua-users. Do you have any experience to share on these? The choice of 5.3 is pretty strange, as Lua is known to split in two at 5.2, because LuaJIT was fixed to 5.1 variant with compat backports and is to my opinion an "industrial" Lua standard. 5.x are actually three different (but not absolutely superior to each other) languages with shared 5-like foundation and app-level code compatibility, so speaking about Lua in general is pointless in a sense. http://lualanes.github.io/lanes/ http://lualanes.github.io/lanes/ http://lua-users.org/wiki/MultiTasking http://lua-users.org/wiki/MultiTasking
- etiene 9y agoThe industry standard in Lua is to have multiple Lua states doing stuff. A different approach, but it is there
- shock 9y ago> 5. I wonder which implementation of Lua they used. There is a table with the versions they used¹, but they don't mention the implementation – in can be inferred for some: e.g. for Pascal they used the Free Pascal Compiler. ① - https://sites.google.com/view/energy-efficiency-languages/setup https://sites.google.com/view/energy-efficiency-languages/se...
- vvanders 9y agoOuch, they used Lua 5.3 LuaJIT is at least an order of magnitude(10x) faster.
- leggomylibro 9y agoTo the point where a lot of popular libraries (like Love2D) use LuaJIT by default. IIRC, Lapis (Lua-based web framework) can be easily configured for it as well. I'd be interested in seeing how it fared; Lua really is a nice language.
- etiene 9y agoLapis afaik also uses LuaJIT by default because it's built for openresty which does use LuaJIT
- ashark 9y ago> 4. PHP, JRuby, Ruby, Typescript, Perl, Python, being massively slow than the fastest languages, for example Ruby being 59 times slower than Rust or C. Take a look at some of the TypeScript code and compare it to the Javascript versions. At least some are way different, i.e. the TypeScript uses "modern" JS features and the JS version... looks about as much like C as it can.
- jsd1982 9y agoTypescript is not its own language in terms of having a distinct runtime from Javascript so it has no performance difference and does not make sense to appear in this comparison. I can see comparing different target versions of Javascript against one another (es2015 vs es2017 for instance), but it all depends on the VM chosen as well.
- ashark 9y agoExactly. The difference at least some of these tests is measuring between the two is idiomatic modern JS (promise, map, careful variable scoping) with fast & loose old-school c-like JavaScript (for loops, global vars galore). Typescript has little to do with it.
- sitkack 9y agoTypescript can use only of these, so it does make sense to have it on the list. Clearly it doesn't fall right next to JavaScript in the results. It is a benchmark of language implementations not runtimes. This is why JRuby, C# and F# are on the list, one uses the JVM and the latter two both use the CLR. Different languages.
- avodonosov 9y agoAnd Forth is missing.
- etiene 9y ago> 5. I wonder which implementation of Lua they used. Lua can be pretty fast, one of the fastest dynamic languages out there. Apparently 5.3, but I am very skeptical of these results. Also the way the data is organised is very weird. One should not compare a JIT compiled VM (JavaScript) with interpreters (Lua, Python, Ruby...). An honest approach would have used LuaJIT, PyPy etc. or separated the languages into "families" better. Not to mention the choice of algorithms they used. Some of the algorithms in the benchmark game have many flaws. As it was already stated in this thread, some of the Python ones were multithreaded but the ones in Lua weren't. Why? In a different benchmark I've seen algorithms using C wrappers for Python, but not in Lua. While I understand wrapping C and multithreading reflect the industry use in Python, so they do in Lua. Benchmarks are useless if you are not consistent in the implementations of the things you are comparing with. It disgusts me, to be honest, when I see benchmarks comparing JIT compilers with vanilla Lua just to say "hey we're faster", as LuaJIT does not even exist. It looks like pure dishonesty. In the case of this paper in particular, as they do not represent any language, it strikes me as lack of research / understanding.
- igouy 9y ago> … but the ones in Lua weren't. Why? No mystery: someone has made the effort to contribute all those multi-process Python programs; no one has made the effort to contribute all those multi-process Lua programs.
- etiene 9y agoOh yes, that is true. But the person making the benchmarks should be aware of that and either look for better matching algorithms or implement them themselves.
- igouy 9y agoWhy should a comparison be restricted just because the best Lua programs-contributed fail to use multi core? (Tail wagging the dog). If someone who didn't know Lua wrote those programs, then you'd complain that the programs weren't written by an expert. If Lua wasn't included then I think you'd complain about that too.