TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Parallel ray tracing benchmark for functional programming languages

96 pointsby marclealmost 5 years ago

4 comments

cs702almost 5 years ago
These are the most interesting bits for me:<p><i>&gt; Rust is the fastest CPU language. This is not terribly surprising, as it has a mature compiler, and its default behaviour of unboxing everything is exactly what you need for this program.<p>&gt; What is not visible from the above table is that most of the implementations were significantly slower in their original formulation. Only Futhark, MPL, and Rust are essentially unchanged from their first straightforward implementation. For the others, most of the performance comes down to various low-level tweaks, in particular avoiding boxing and allocations. This is not exactly unexpected, but I still find it sad that when it comes to performance in functional languages, we must think about the compiler more than we think about the language.</i>
评论 #23776213 未加载
评论 #23777473 未加载
marclealmost 5 years ago
This is an interesting benchmark comparing parallel functional programming languages, including Rust, Parallel OCaml and MPL. MPL is &quot;a parallelism-oriented fork of MLton for Standard ML&quot; which is described as being &quot;definitely the star&quot; (see also <a href="http:&#x2F;&#x2F;www.cs.cmu.edu&#x2F;~swestric&#x2F;20&#x2F;popl-disentangled.pdf" rel="nofollow">http:&#x2F;&#x2F;www.cs.cmu.edu&#x2F;~swestric&#x2F;20&#x2F;popl-disentangled.pdf</a>). This benchmark was inspired by Jon Harrop&#x27;s ray tracer benchmark (<a href="https:&#x2F;&#x2F;www.ffconsultancy.com&#x2F;languages&#x2F;ray_tracer&#x2F;index.html" rel="nofollow">https:&#x2F;&#x2F;www.ffconsultancy.com&#x2F;languages&#x2F;ray_tracer&#x2F;index.htm...</a>).
评论 #23776609 未加载
blackrockalmost 5 years ago
The CPU and the von Neumann architecture itself is procedural. High level code is mapped to assembly code, which is then mapped to binary machine code.<p>Given that, then higher level languages are merely another layer of abstraction. C is procedural, and while it can be functionally separated, it still maps down to assembly, and then to machine code.<p>Same goes for Lisp, or Haskell, or any other functional language. It still follows the chain down, and maps to assembly and machine code.<p>Given that, then what is the ability for a purely functional language, like Haskell, or whatnot, to utilize the full feature of today’s multi-core CPUs?<p>For example, a common functional approach, is to use a map() function, and apply a specific function, against a set of data. Say, you have a list of 1000 strings, and you want to capitalize it all, and return the new list of all capitalized strings. Then, you’d have another function called upper() that will apply to each element in that list.<p>So, your function call might look something like:<p><pre><code> capped_list = map( upper, my_list ) </code></pre> And your return data, capped_list, will contain the list of all strings, capitalized. Simple enough.<p>So, the question is, do functional languages automatically have the ability to take this instruction, and spread the data over multiple cores, or multiple processors, in order to return the final answer, in a faster or more efficient process than a regular procedural language?
评论 #23778085 未加载
评论 #23777388 未加载
评论 #23778274 未加载
评论 #23778803 未加载
评论 #23778049 未加载
评论 #23778539 未加载
reikonomushaalmost 5 years ago
Now, debug the same programs at runtime. :)