cade metz alert
The Next Big Programming Language You’ve Never Heard Of
51–60 of 75 posts
Re: The Next Big Programming Language You’ve Never Heard Of
#52The phrase "C++ is an extremely fast language -- meaning software built with it runs at high speed" needs to be changed to "It's possible to build high speed software with C++". I take any performance claims made by a particular language with a pretty big grain of salt (particularly those made vs Java/JVM) unless they're accompanied by some reasonably sophisticated benchmarks and source that actually show a performan…
Here's one: https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H... And yes, languages are not slow or fast. The JVM could be as fast or even faster than native (AOT) because JIT can in theory optimize better than AOT. There are fixes planned for performance issues. Things have improved since the benchmark. It's only one particular benchmark. One specific implementation of VM/compilers/etc. Let me show you so…
Well, a JIT-compiled program can be substantially faster than an AOT-compiled one, given that running time is large enough. Which it is for services on 24/7 (that's more throughput, but you get my drift)
Re: The Next Big Programming Language You’ve Never Heard Of
#53The phrase "C++ is an extremely fast language -- meaning software built with it runs at high speed" needs to be changed to "It's possible to build high speed software with C++". I take any performance claims made by a particular language with a pretty big grain of salt (particularly those made vs Java/JVM) unless they're accompanied by some reasonably sophisticated benchmarks and source that actually show a performan…
Here's one: https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H... And yes, languages are not slow or fast. The JVM could be as fast or even faster than native (AOT) because JIT can in theory optimize better than AOT. There are fixes planned for performance issues. Things have improved since the benchmark. It's only one particular benchmark. One specific implementation of VM/compilers/etc. Let me show you so…
> fundamentally you can do anything a JIT does AOT
False. Amongst the things that JITs can do that AOTs cannot are optimisation based on profiling of the program executing with its actual inputs, interprocedural optimisation of dynamically linked code, interprocedural optimisation of code generated at runtime, and runtime specialisation [1].
I'm not sure there's a bright line between runtime profile-guided optimisation and runtime specialisation; however, i think most of the optimisation that production JITs do today is more reasonably classed as the former, rather than the latter. However, the other three are all happening right now in JVMs around the world.
[1] http://en.wikipedia.org/wiki/Run-time_algorithm_specialisati...
Re: The Next Big Programming Language You’ve Never Heard Of
#54Earlier quoted context omitted.
Here's one: https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H... And yes, languages are not slow or fast. The JVM could be as fast or even faster than native (AOT) because JIT can in theory optimize better than AOT. There are fixes planned for performance issues. Things have improved since the benchmark. It's only one particular benchmark. One specific implementation of VM/compilers/etc. Let me show you so…
> fundamentally you can do anything a JIT does AOT False. Amongst the things that JITs can do that AOTs cannot are optimisation based on profiling of the program executing with its actual inputs, interprocedural optimisation of dynamically linked code, interprocedural optimisation of code generated at runtime, and runtime specialisation [1]. I'm not sure there's a bright line between runtime profile-guided optimisati…
I apologize for trying to be a little too clever here. There are two things that I'm trying to say:
1. If you want to you can use the same techniques JIT employs in your AOT program. You can basically embed a JIT in your program if you think that's beneficial for some specific scenario.
2. Whatever the JIT comes up with as an optimal solution for some specific run-time scenario, assuming it's really optimal, can be used in an AOT compiled program. I think the reality today is that JITs very rarely come up with an optimal solution anyways but if they did you can still embed that solution in an AOT compiled program so therefore they have no fundamental advantage.
There's no getting away from the fact that as you add more and more layers to the onion you are losing fine control and you are giving up performance. Assembly beats C (disallowing inline assembly) beats JIT (disallowing embedded native code). It could be argued that a human writing assembly can't match what tools can generate but that's not actually really true (given enough time) and even if it is true there's nothing stopping the human from using tools where appropriate.
Re: The Next Big Programming Language You’ve Never Heard Of
#55Earlier quoted context omitted.
Here's one: https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H... And yes, languages are not slow or fast. The JVM could be as fast or even faster than native (AOT) because JIT can in theory optimize better than AOT. There are fixes planned for performance issues. Things have improved since the benchmark. It's only one particular benchmark. One specific implementation of VM/compilers/etc. Let me show you so…
Well, a JIT-compiled program can be substantially faster than an AOT-compiled one, given that running time is large enough. Which it is for services on 24/7 (that's more throughput, but you get my drift)
The proof is in the pudding.
Implement FFT using a JIT that over any length of time/samples is faster than FFTW [1] or an h.264 encoder faster than x.264 [2] .
[1] - http://www.fftw.org/
Re: The Next Big Programming Language You’ve Never Heard Of
#56Man, Facebook has a lot of hookups with Wired. You always see articles on Wired about Facebook projects and tech.
relevant: Co-creator of D works at Facebook.
Re: The Next Big Programming Language You’ve Never Heard Of
#57Re: The Next Big Programming Language You’ve Never Heard Of
#58Let me put on my tinfoil hat for a second.
Two companies that love user data are making "languages" for us to write our applications with (Facebook with Hack and React, Google with Dart and Go)
The NSA worked backdoors into RSA encryption. Could the Facebook/Google compilers provide a similar backdoor for them to syphon data?
/tinfoilhat
Re: The Next Big Programming Language You’ve Never Heard Of
#59Earlier quoted context omitted.
Well, a JIT-compiled program can be substantially faster than an AOT-compiled one, given that running time is large enough. Which it is for services on 24/7 (that's more throughput, but you get my drift)
The proof is in the pudding. Implement FFT using a JIT that over any length of time/samples is faster than FFTW [1] or an h.264 encoder faster than x.264 [2] . [1] - http://www.fftw.org/ [2] - http://www.videolan.org/developers/x264.html
The proof is not in the pudding in this case. You say "In my opinion JIT is always going to be slower than native (AOT)" and I say that you're wrong. The optimizations that can be done ahead of time are a subset of the optimizations that can be done at runtime. That it's hard to write a really good JIT compiler has nothing to do with it. Neither has the size of the problem. Always is a dangerous word. But I can hear myself being pedantic; for problems of small sizes where start-up time is important (most problems) AOT will be better.
Re: The Next Big Programming Language You’ve Never Heard Of
#60Earlier quoted context omitted.
> Maybe the gap will close but fundamentally you can do anything a JIT does AOT at zero run-time cost but not the other way around. You can't inline virtual functions, which is the number 1 optimization done by the JVM (as it enables most other advanced optimizations). You can try achieving it with a profile-guided optimizing compiler, but a JIT can adapt its optimizations based on changes in the inputs (which trigge…
You mentioned that on the other discussion. Can you tell us a little bit more about inlining of virtual functions? It doesn't sound like something hugely valuable because if you're performance driven you're already not using virtual functions for places where that overhead is unacceptable (and generic programming is what lets you do that). I've done lots of multi-threaded programming in C++ some of it with lock-free…
> Can you tell us a little bit more about inlining of virtual functions?
Virtual method inlining is the "mother of all optimizations". See:
* http://parleys.com/play/514892260364bc17fc56be1d/chapter6/ab...
* (more advanced) http://www.azulsystems.com/blog/cliff/2011-04-04-fixing-the-...
> if you're performance driven you're already not using virtual functions for places where that overhead is unacceptable
Well, that can only be true for some very localized computations. Virtual method calls are the basis for polymorphism (virtual method calls can even be used when implementing functional languages' pattern matching -- the functional form of polymorphism), and polymorphism is the basis for most programming abstractions. If your code is interesting enough, it will have lots of virtual calls. If it doesn't, then you're probably doing something very specific, and C/C++ might be a better option indeed.
> Can you expand on how GC would make my life easier in general?
Sure (I guess you mean re concurrent data structures; otherwise it simply saves you the pain of manual memory management). The basic principle of most (all?) lock-free data structures is that multiple threads might be reading a single node of the DS (which may contain stale data) and then try to CAS a new node into the DS. Without GC, it's very hard to determine when all threads have stopped examining a given node so that it can be safely deallocated.
See the following discussions on the difficulty of implementing lock-free data structures in C++ (b/c of lack of GC):
* http://www.drdobbs.com/lock-free-data-structures/184401865
* https://software.intel.com/en-us/forums/topic/295279
Without a GC, you'd need hazard pointers[1] or RCU[2], both are rife with issues, and are either not general enough or perform worse than a GC.
> Surely it depends on the nature of the task you're trying to solve, locks aren't always the bottleneck
True.
> and there's not always concurrent solutions.
Right, but if your code isn't concurrent/parallel there's a hard (and low) limit on how fast it can run.