You're looking at Less Wrong's discussion board. This includes all posts, including those that haven't been promoted to the front page yet. For more information, see About Less Wrong.

ShardPhoenix comments on June 2014 Media Thread - Less Wrong Discussion

5 Post author: ArisKatsaris 01 June 2014 03:04PM

You are viewing a comment permalink. View the original post to see all comments and the full post content.

Article Navigation

Comments (95)
Tags: resources media_thread recommendations books movies community media monthly

Comments (95)

You are viewing a single comment's thread. Show more comments above.

Comment author: ShardPhoenix 02 June 2014 11:22:43PM *  2 points [-]

Although at least in the case of Haskell, we really do have the promised 'sufficiently advanced compiler' in the form of GHC

The "sufficiently advanced compiler" I was referring to is one that makes high level languages as fast as hand-tuned C++ (thus eliminating the need for said hand-tuning), not just one that's faster than it used to be. Such a thing is probably possible but it doesn't exist now or in the immediately foreseeable future. Things like precise control of memory layout can make an order of magnitude difference to performance or more.

Haskell's pure functions, green threads, and STM are great for concurrency, so I think your argument may work in the other direction.

They might make it easier but they don't make it faster which is currently the limiting factor for performance-intensive servers. Making it easier would certainly help - apparently the latest Battlefield game has a lot of bugs due to hard-to-diagnose threading issues in the client. But it wouldn't be viable to write that game in Haskell due to GC and lazy eval, even if the basic performance was good enough which it probably isn't.

edit: Also as far as I know it's possible to avoid some of these issues in Haskell with careful optimization of the code, but of course the more you have to do that the less you benefit from things "just working".

I'm not saying we'll never see real-time performance-intensive apps commonly written in functional languages, I guess I'm just not as optimistic about it happening soon.

Comment author: gwern 03 June 2014 01:28:26AM 0 points [-]

They might make it easier but they don't make it faster which is currently the limiting factor for performance-intensive servers. Making it easier would certainly help - apparently the latest Battlefield game has a lot of bugs due to hard-to-diagnose threading issues in the client. But it wouldn't be viable to write that game in Haskell due to GC and lazy eval, even if the basic performance was good enough which it probably isn't.

What you can write determines how fast it will run. If you don't have green threads, but must use OS-level threads, that's going to be a problem. If you have to be constantly locking because of mutability and can't use STM, that's going to be a problem. And yes, correctness does matter so that's a problem too.

Comment author: ShardPhoenix 03 June 2014 01:47:07AM *  0 points [-]

Fast lock-free thread-safe mutable data structures (eg ConcurentLinkedQueue) have been written in languages like Java (and apparently even C++ but I'm less familiar).

Also, STM isn't necessarily much better than locks in practice eg quick Googled example: http://nbronson.github.io/scala-stm/benchmark.html (Don't know how the Haskell equivalent compares)

(where "medium" granularity locks were just as good perf. wise and STM's GC pressure was higher)

Powered by Reddit Powered by Reddit