101–110 of 143 posts
Earlier quoted context omitted.
> 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...
Much of Pascal (or, rather, Modula-2 and Oberon) is revived inside Go.
Earlier quoted context omitted.
The tests come from the benchmark game. If you want to see Forth, implement the tests in Forth: http://benchmarksgame.alioth.debian.org/
@igouy points out that while the old shootout site is gone, its language files are still available[1]. There are about 70 benchmarks, in about 70 languages. I remember them as interesting multilingual browsing. Unlike the old shootout, adding languages directly to benchmarksgame.alioth.debian.org is not an option. "Because I know it will take more time than I choose. Been there; done that."[2] :) Instead, the code is…
I can't believe they used the Computer Language Benchmarks Game. Those benchmarks don't reflect real-world workloads at all, and the contest has fairly arbitrary rules about implementations and widely differing implementation quality between languages. This should have been rejected by peer review.
The results are what I have expected but yes, mandelbrot and n-body in Ruby? Ruby's typical workload is getting some strings from a web server, building a SQL query, sending it to a database, get a resultset, creating a bunch of objects to represent the result and send back another string to the web server. That would be more energy efficient if done in C but not as much as doing a mandelbrot. Then factor in the ener…
No, it's almost always negligible because it's essentially a one-time cost, whereas the program's inefficiencies are multiplied by an unknown number of users over an unknown period of time (cf. Cobol programs still being in use today) - but for sure your goal is often to maximize both of these unknown numbers.
This fact is very obvious when you develop hardware/firmware combos. The firmware is often designed to minimize the hardware costs (RAM size, mass storage size,...) because the cost of producing the hardware is per piece, while the development cost is mostly a one-time cost that one rarely includes in the total cost of the product.
A real shame that Forth wasn't included in the tested languages. Chuck Moore has been an advocate for more energy efficient computation for a while now.
Earlier quoted context omitted.
Ouch, they used Lua 5.3 LuaJIT is at least an order of magnitude(10x) faster.
To 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.
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…
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.
Earlier quoted context omitted.
> Do you have any supporting evidence for this? For starters, by virtue of the construction of the benchmark alone, which mostly is about stress-testing allocation. There are also quite a few papers that benchmark allocators, such as [1], where you can see that such allocation rates aren't exactly ordinary. > Real-world programs can be pretty allocation heavy, I said "atypical", not "impossible". Obviously, I can con…
> Obviously, I can construct real-world programs with pretty much arbitrary allocation rates, but especially performance-sensitive code will avoid that, if only because it hurts memory locality. That's not actually true at all. Games, for example, can have high allocation rates. But they use custom allocators to make those allocations extremely cheap using things like arena allocators for the allocations for a frame.…
And for any synthetic microbenchmark, that's unlikely to reflect real-world workloads, as they tend to narrowly test just one aspect of the language (or rather, its implementation).
Remember, we're talking about a peer-reviewed paper here, where the burden to show relevance is upon the authors. Section 4 ("Threats to Validity") of the paper does not really address that adequately.
As the Computer Language Benchmark Game site itself quotes (and one reason why it calls itself a "game" and disavows usefulness for actual programming language comparisons):
Attempts at running programs that are much simpler than a real
application have led to performance pitfalls. Examples include:
...
* Toy programs, which are 100-line programs from beginning
programming assignments ...
* Synthetic benchmarks, which are small, fake programs invented
to try to match the profile and behavior of real applications
...
All three are discredited today, usually because the compiler
writer and architect can conspire to make the computer appear
faster on these stand-in programs than on real applications.
> You can do object pools in GC'd languages, too, for example.
No. The rules do not allow for that. I did mention how arbitrary they are, right? The regex-redux benchmark, for example, comes down to what the best external library is that you can link to under the rules. The gcc version wins in large part (being massively better than the g++ version, which relies on Boost regexes) because it uses the JIT version of libpcre. It's borderline absurd.
> generics? Not C++ specific.
You said templates, not generics. Generics alone are not necessarily sufficient to implement pool allocators. Plus, C++ is the only language that has major adoption that has both some form of generics and manual memory management.
> That example results in terrible fragmentation for everyone if M > N other than a compacting GC. It's not made particularly worse by an object pool.
This is false. Even a simple first-fit allocator can fare better, for example. Obviously, a compacting GC can avoid external fragmentation (almost) entirely, no matter the cause.
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…
>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"…
Earlier quoted context omitted.
> 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...
But why should it's memory utilization be so much lower? Pascal and C give the programmer basically the same control over memory layout, no?