18 ms·

JITs are un-ergonomic

145 points by awinter-py 7y ago

gentleman11 7y ago
As a nodejs developer: what is the best compiled server language to learn right now? Is it Java still, or is it better to look at go or rust?
- deleted 7y ago
  [deleted]
- csande17 7y ago
  Part of me wonders if ASP.NET will make a comeback. A lot of the historical reasons not to use it don't exist anymore (there's an officially-supported Linux port, for example), and a lot of the cool new JavaScript language features like async/await and arrow functions came from C#. Besides, most JavaScript programmers are already dependent on Microsoft products like TypeScript, NPM, and Visual Studio Code. What's one more?
  - sk5t 7y ago
    I imagine nobody knows what "ASP.NET" means nowadays as distinct from C# / .NET Core.
  - tluyben2 7y ago
    ASP.NET Core has been running fine on Linux and Mac OS X for years now. I have been building backends in it for those same years using Linux mostly. The ecosystem is nice and stable (been run high traffic APIs in production for years which never have any issues) and code written years ago simply works without issues after updating libs/runtime to the latest version (Even from 2.1 to 3.1 we had barely any work). Unlike RoR or JS projects I maintain which break quite a lot on update.
    - Nullabillity 7y ago
      It starts, yes, but the experience is still as miserable as on Windows. They just brought the Windows idiocies with them. The debugger (clrdbg) is still artificially restricted from running inside anything else than MS' IDEs. The global certificate store is still a thing. On that note, the cryptography support varies wildly between platforms, because they still insist on using SChannel on Windows. And I guess that means that they have to use SecureTransport on macOS, to avoid appearing to play favourites or something. The action at a distance that it encouragtes would make you think you're in a haunted house. Despite bringing the Windows mentality with them everywhere, there still isn't a competent migration story from Framework, so what's the point? Legacy code is still a pain to port, and you'd be crazy to actually want to write new code in this mess.
    - eitland 7y ago
      I've used it as well and it is really really nice, especially on Linux as it starts extremely much faster there which was important for my work. It is still not in the same league as Java when it comes to dev tools and the Java ecosystem keeps getting better as well, but at the moment I am torn between the two (or rather, I have two excellent options that I can choose depending on circumstances.)
      - tluyben2 7y ago
        I agree: I also work with Java and JVM languages and I was a fulltime Java dev for 10 years before but the first client (a bank) on our product insisted on .NET 7 years ago and we had some .NET expertise already and went all in. .NET Core is nice enough to do very large projects in though so I cannot see many reasons of moving away from it (especially from F# which I mostly use now).
  - gentleman11 7y ago
    Is it open source?
    - csande17 7y ago
      I think so! They have a repo called "ASP.NET Core" on GitHub with an Apache license: https://github.com/dotnet/aspnetcore https://github.com/dotnet/aspnetcore . ("Core" here means that it's the version of .NET that can run on Linux.) The "dotnet" organization also has repositories for the C# compiler and runtime.
    - leosarev 7y ago
      Yes! Compiler, sdk, runtime and framework.
    - Nullabillity 7y ago
      Kind of? Vital parts are still closed (like the debugger), and the tooling still assumes a closed-source world (for example, with OmniSharp, jump-to-definition to dependencies just gives you a synthetic source file that only contains method signatures). It's also not exactly run like a community project. The issue tracker feels more like a customer support system: "can you try updating to the newest release now?" abound, with no mention of what the actual problem or fix was.
  - pjmlp 7y ago
    Comeback? It never went away. From where I am standing it has always been either Java or .NET since the last 20 years, while we keep seeing stuff coming and going every couple of years.
- tehlike 7y ago
  C# is pretty decent. Has been since the get go.
- wvenable 7y ago
  Best is highly subjective and entirely dependent on what you want to build. I find a lot of joy in working in C# and the .NET core. It's very pleasant to work in and might be worth a look.
  - wildduck 7y ago
    Very interesting. I have heard that from some people as well. Any tips on how to get started in *nix/FreeBSD/Mac ecosystem? Last I tried was in mono. Any tips appreciated.
    - wvenable 7y ago
      It's super easy to download and get started on Linux/Mac: https://dotnet.microsoft.com/download/dotnet-core/3.1 https://dotnet.microsoft.com/download/dotnet-core/3.1 I even managed to get it to run on an Android tablet via Termux by downloading the ARM64 binaries.
- jitl 7y ago
  It depends on a lot of factors. I’m a typescript Dev and I’m really enjoying working in Kotlin. I certainly enjoy how expressive it is compared to Go, and I picked it up in a couple of days in an existing codebase, so it’s much easier than Rust. I think you can’t undersell how good the JetBrains IDE makes the programming experience with code completion, auto-imports, corrections, or how great it is that Kotlin interfaces with Java seamlessly.
  - spockz 7y ago
    Funnily enough Scala provides the same feature set. However, because it is even more powerful than Kotlin there are also more ways to achieve the same goal. Doing any of the advanced stuff makes it hard to use that Scala code from Java. Using java from scala is easy. And still kotlin appears to be gaining ground on scala.
    - mwcampbell 7y ago
      In my limited experience, Kotlin seems to have smoother Java interop than Scala. For example, last time I checked, Java getter/setter methods automatically become Kotlin properties, and vice versa, whereas Scala has its own convention for getters and setters. Is that not the case now?
- gaogao 7y ago
  To learn for what goal? For education, for enterprise, for speed? To which my shortlist is Haskell, C#, and Rust.
- didibus 7y ago
  Java is still the largest and most in use server side language at 39%. It is followed by C# at 32%. After that, you have Go at 9%, Kotlin (also a JVM Lang) at 6.6% and Scala (also a JVM Lang) at 4%. Finally, you get Elixir and Clojure both at 1.5% Source: https://insights.stackoverflow.com/survey/2019 https://insights.stackoverflow.com/survey/2019 So yes, I think learning Java and the JVM ecosystem is a good investment, considering Java dominates, and if you tally up JVM langs you get something like 51% of professional developers using a JVM based language for work.
  - jimmaswell 7y ago
    This up-to-date one seems to be putting PHP in a large lead with C# then Java following: https://w3techs.com/technologies/overview/programming_language https://w3techs.com/technologies/overview/programming_langua... We've drifted from just compiled languages here, but the most important server-side language to know is probably PHP. Personally I've really enjoyed working with Drupal.
    - gentleman11 7y ago
      I always thought php was just a templating language. Any recommended books or resources?
    - didibus 7y ago
      Sorry, I assumed parent meant backend and web services, like REST, GraphQL or RPC APIs, and not server side HTML rendering, that's why I excluded certain languages like PHP. I also skipped over interpreted languages like Python and Ruby since they mentioned compiled. Also, that doesn't look like a great metric, since it's just the number of website using a particular technology. That's going to be massively skewed by prefab solutions like WordPress and all. I liked that the StackOverFlow survey asked people what language they used professionally. I feel that's much more relevant.
      - jimmaswell 7y ago
        PHP is used for REST and all that just fine. Why are you excluding it from "backend and web services"?
- _delirium 7y ago
  Maybe I'm missing the intended distinction, but in normal usage, Java is also a JITted language. It's almost the canonical one... JITs are much older, but HotSpot really popularized the concept in mainstream production.
  - kizer 7y ago
    Java’s bytecode is JITted, which is a subtle distinction since there is an AOT translation step capabale of optimizations etc.
    - _delirium 7y ago
      Technically yes, but the AOT step in practice does almost no optimizations and is just a direct translation, at least if you're using the mainstream javac. It's there just to simplify the VM/JIT, so the latter can read bytecode instead of textual source code. There have been attempts at AOT compiling Java, but afaict they have very little usage. GCJ, now dead, was the main one for years. There's also a newer experimental compiler jaotc: https://openjdk.java.net/jeps/295 https://openjdk.java.net/jeps/295.
      - kizer 7y ago
        You seem to have more familiarity than me with Java :). So I guess V8 JITs some kind of p-code then? If V8 allowed full AOT comp. to the internal bytecode, then the perf would theoretically be around Java’s avg perf?
        earenndil 7y ago
        Nope, because java is statically typed.
        laurencerowe 7y ago
        Avoiding the source parsing step would only provide a startup time performance win. JS engines tend to be faster than Java here already since it's something they've been heavily optimized for. It's difficult for JS engines to match Java's performance without type information to work with. This is only discovered at runtime and the JIT'ed code for a function requires traps in case it is later called by parameters of a different type.
- on_and_off 7y ago
  kotlin is pretty neat to work with. In the end it is all bytecode (so java, or rather both java and kotlin output bytecode), but kt removes a lot of the ceremony, boilerplate, and altogether ideas that have proven to do not be that great in the years since java's inception.
  - vips7L 7y ago
    This is no longer true. Java has eaten a lot of the features Kotlin once had. The only things not provided by java are nullable reference types and coroutines (coming).
    - pjmlp 7y ago
      Some people on Android bubble keep mistaking Android Java for the real deal.
    - on_and_off 7y ago
      meh, java has indeed eaten a lot of the features that kotlin has (why do you use past tense ??). However, the java version is not necessarily as convenient, concise or powerful than Kotlin. E.G. I strongly prefer data class to records. No named parameters -> no default params -> way more boilerplate
- DethNinja 7y ago
  In my experience Go is amazing for webserver development. Very easy to learn and you can build things very quickly. However, I still use C++ for extremely complex networked applications where performance matters, unfortunately Rust doesn’t have battle tested crypto libraries, so I wouldn’t personally use it for networked applications.
  - gameswithgo 7y ago
    just use the c libraries from rust?
    - boulos 7y ago
      Or use rustls, if you just need modern TLS. I found this back and forth of rustls vs native-tls (which picks up openssl/your favorite system ssl) helpful: https://users.rust-lang.org/t/any-reasons-to-prefer-native-tls-over-rustls/37626 https://users.rust-lang.org/t/any-reasons-to-prefer-native-t...
    - ilammy 7y ago
      There a few wrapper libraries that provide safe Rust interface for a limited feature set on top of system's crypto libraries like OpenSSL, so the applications can benefit from decades of testing and get security updates without timely rebuilds. I'm maintaining one, for example, which has Rust bindings among 12 other platforms.
  - eatonphil 7y ago
    Go's lack of generics makes it better for write-once, run-forever systems like proxies. It's not as ideal for application servers that will otherwise need a lot of code duplication via code generation (to be type safe) or nil interfaces (to throw away static typing). Code generation isn't so bad. Even JOOQ (Java's awesome ORM) will suggest you do it. And similarly, Java's generics aren't that great themselves. But you come to expect more from a newer language with so much history to learn from and they missed the ball on generics. (In contrast they got right: gofmt, go test, cross platform builds, go get, etc.)
- Skunkleton 7y ago
  If you are are looking for a mature high performance language to keep in your back pocket for the cases where you can't use node, Java seems like a fair bet. Go would also be useful. Neither are too much fun IMO, but that would fit the bill. There are newer languages that are more interesting, but picking one of those is more about either attempting to anticipate where the industry is going, or just plain wanting a more fun language. Rust is an example here. Personally I think rust is worth learning, and has a fair shot at taking over a large chunk of software development that would have previously gone to C or C++. Learning rust might make you a better programmer because lots of poor-programming-hygiene type things are compiler errors in rust. If you just want a way to wring maximum performance out of a piece of hardware, then I would caution you to consider your choice carefully. Writing high performance code requires a complete understanding of the stack underneath you. If you want to see my point in practice go check out the programming languages shootout. Specifically notice that there are benchmarks implemented in "fast" languages that are outperformed by better optimized code written in "slow" languages. I would recommend against C++ unless you are planning on devoting a very large amount of time to learning it well. I also don't personally like C++. Too many footguns.
  - saagarjha 7y ago
    Java has a JIT too…
    - pjmlp 7y ago
      And AOT as well.
  - acqq 7y ago
    > notice that there are benchmarks implemented in "fast" languages that are outperformed by better optimized code written in "slow" languages. I haven't observed that, at least not where one can't write a "better optimized" code in the "fast" language too. Can you give any specific examples?
    - Skunkleton 7y ago
      Sorry, I wasn’t clear. On shootout they have multiple implementation of each benchmark in the same language. The fastest implementations are always fast languages, but there are lots of implementations in fast languages that are bested by better implementations in slow languages[1]. The point I was trying to make is that picking a fast language isn’t enough to write truly fast programs. 1. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- smabie 7y ago
  I would say Scala, or maybe F#.
- fulafel 7y ago
  JS is also frequently a compiled language these days. What makes you qualify the question this way?
- sideeffffect 7y ago
  Check out Scala! It has modern features and the tooling around it is mature. If you like books, this should be a good intro: https://underscore.io/books/essential-scala/ https://underscore.io/books/essential-scala/ (you should use IntelliJ IDEA instead of Eclipse, though) And you can also use it for frontend development: https://www.scala-js.org/doc/sjs-for-js/es6-to-scala-part1.html https://www.scala-js.org/doc/sjs-for-js/es6-to-scala-part1.h... (having one language for both backend and frontend leads to great synergy)
pizlonator 7y ago
This post is extremely V8-centric. For example it uses terminology like “deopts” which means nothing in JavaScriptCore (we distinguish between exits, invalidations, jettisons, and recompiles). The post also assumes that there is only one JIT (JSC has multiple). And that’s where you’ve lost me. Not sure how you expose anything about how the JIT is operating without introducing a compat shitshow since JIT means different things in different implementations. If you really want to know that something gets compiled with the types you want, use a statically typed and ahead of time compiled language. If you have to use a JIT but you find that it doesn’t do what you like then remember that it’s meant to be stochastic. The VM is just trying to win in the average. Which functions get compiled and with what type information can vary from run to run. Probably the best thing that could happen is that developer tools tell you more about what the JIT is doing. But even that’s hard. There are some specifics that I disagree with: - I don’t think all JIT architects for JS claim that the perf is about competing with C for numerical code. I don’t explain it that way. I would say: JITs are about doing the best job you can do under the circumstances. They can make JS run 4x faster than an interpreter if things really go well. “Between Python and Java” is a good way to put it and that’s exactly what I would expect. So if that’s your experience then great! The JIT worked as expected. - It’s usually foolish to want your code compiled sooner. Compilation delay is about establishing confidence in profiling. I’m pretty sure we’d JIT much sooner if it wasn’t for the fact that it would make the EV of our speculation go negative. TL;DR. the JIT can’t unfuck up JavaScript.
- csande17 7y ago
  The post is likely V8-centric because it's discussing server-side JavaScript. As far as I know, pretty much everyone uses V8 for server-side JS because that's what Node is based on. And compatibility seems to be much less of an issue there as well, at least if all the "dropped support for Node version X" changelogs I read are any indication. Not to say server-side JavaScript is necessarily a good idea. But if people are determined to make it work, I could see these sorts of changes happening that wouldn't make sense in a web browser.
- deleted 7y ago
  [deleted]
- 7y ago
banachtarski 7y ago
This article has a number of issues. JS with JIT is waaay faster than Python. Not “between python and java” as purported. Second, generalizing jits as “un-ergonomic” seems silly given that what’s being specifically looked at is benchmarking. But what makes this claim ridiculous is that nothing is easy to benchmark. Even native code is hard to profile and this is literally my day job. If the JIT makes your code that much faster, this strikes me as a pretty suspect complaint
- pizlonator 7y ago
  I think that by “between python and java” they meant “faster than python and slower than java”. I think Java still beats JS unless you get lucky. You’re totally right that benchmarking and profiling is hard even for native code. I think this post fetishizes whether or not a piece of code got JITed a little too much. Maybe the author had a bad time with microbenchmarks. There’s this anti pattern in the JS world to extract a small code sample into a loop and see how fast it goes - something that C perf hackers usually know not to do. That tactic proves especially misleading in a JIT since JITs salivate at the sight of loops.
  - shawnz 7y ago
    That still doesn't make sense to me.. how can JIT in general be slower than Java when Java is JITed?
    - throwaway894345 7y ago
      The claim wasn’t about JIT in general, but rather about JS.
      - deleted 7y ago
        [deleted]
      - pizlonator 7y ago
        Then it’s problematic to be so JS and V8 centric. Also the post specifically talked about JS being faster than Python and slower than Java so that’s what this thread is about.
connor4312 7y ago
As someone who's been writing a lot of JavaScript, Go, and a handful of other languages for a while, I feel this. In Go, I can basically know what's going to happen when I write a function. This operation will read from the stack, these instructions will be run, and I can take a peek at the assembly if I'm not sure (though I've developed a pretty good feel for what Go will do without needing that). I can benchmark it and know that the performance I see on my machine will be the performance when I ship this bit of functionality into production, barring hardware differences. In JavaScript, it's a black box. I know some constructs might deoptimize functions when run on Wednesdays because I read them on a blog published in 2018 that's _probably_ still accurate. In my benchmark running on Node 12.14.1 on Windows this seems to be true. But then who knows if it'll be the same thing in production, and it might 'silently' change later on. JavaScript in V8 is incredibly fast these days, but I find it much easier to write optimal code in Go.
- _bxg1 7y ago
  It's really no different from native compiler optimizations, which are also mysterious and always changing, except for one key aspect: when recording timings to compare against other timings, you can control whether optimizations are turned on or off, to remove that variable from the comparison.
  - lpghatguy 7y ago
    Thankfully, with a native compiler you don't have to deal with your JIT warming up, or some other code causing your function to get deoptimized, or subtle JIT trace aborts. :(
    - fctorial 7y ago
      > or some other code causing your function to get deoptimized Why doesn't the optimizer generate different compiled implementations of a function for different pieces of code?
      - notamy 7y ago
_bxg1 7y ago
> if your economics are such that servers are a bigger cost than payroll Sorry, and I may be oversimplifying the author's situation, but this really sounds like a case where you need to not be using JS for your server. On the client you don't have much choice, but on the client the pure-JS performance rarely gets tight enough to warrant this degree of micro-optimization work. Author makes some good points - it would be great if the JIT were more profiler-friendly - but I have to question a little bit how important it actually is, the way the use-cases line up.
- erik_seaberg 7y ago
  When someone realized you pay a lot for cycles at the server, but you pay nothing for cycles at the client, that was the moment the world-wide web began to die.
  - dimgl 7y ago
    Well this is hyperbolic.
  - deleted 7y ago
    [deleted]
  - _bxg1 7y ago
    This is baseless mudslinging. The bottleneck on the client is virtually never the cycles consumed by the actual running of the actual app's JS code. It's usually, in order starting with the most common: - Piles of ads/analytics scripts which have no motivation not to slow down the page - Reflow; i.e. needlessly many elements on the page causing the browser to do extra work calculating layout - The initial loading and JIT-ing time of a needlessly heavy JS bundle
- pjmlp 7y ago
  They are, Common Lisp, Java/Android and .NET all provide very developer friendly graphical profiling tools.
  - caleb-allen 7y ago
peterkelly 7y ago
If you were to get the information you were after it would be specific to a particular implementation, and a particular version of that implementation. The nature of how JIT is done for JavaScript is not defined in the spec and varies a lot (starting from totally nonexistant many years ago). To have useful performance measurement tools that are going to help your code run across multiple implementations would require a) all of those implementations to work the same, forever, and b) the semantics of this to be specified in the standard.
lpghatguy 7y ago
An anecdote from a non-JS JIT, but similar: I once spent a summer working on a game engine with a couple others where the host language was LuaJIT. It started out great. The iteration cycles were incredibly short, performance was competitive, the code was portable, and we could do wild metaprogramming nonsense that was still fast. If you haven't worked with LuaJIT, its C FFI is also incredible! As we started scaling though, the wheels fell off the wagon. We'd add a new feature and suddenly the game wouldn't run at interactive framerates. One time, it was the 'unpack' function, which would trigger a JIT trace abort. We would drop from 12ms frames to 100ms frames. I wrote a length-specialized version that didn't abort and moved on. Another time, it was calling Lua's 'pairs' method (iterator over a map). Okay, so we can't do that, or a few other things that made Lua productive before. The other problem we hit was GC predictability being impossible. We tried to mitigate it by using native data structures through the C FFI, taking control over the GC cycle to run it once or twice per frame, etc. In the end, like the JIT problem, we weren't writing Lua at the end, we were writing... something else. It wasn't maintainable. That summer ruined dynamic languages for me. I didn't really want to be writing C or C++ at the time. I ended up picking up Rust, which was predictable and still felt high-level, and the Lua experience ended up getting me my current job.
- samatman 7y ago
  'pairs' was jitted recently by the RaptorJIT crew, fwiw. I've hit fewer snags with LuaJIT, but they're definitely there. Really wish Mike Pall had written that hyperblock scheduler before retiring...
  - stephen82 7y ago
    He did not retire; he is still quite active and improving LuaJIT [1]. [1] https://github.com/LuaJIT/LuaJIT/tree/v2.1
    - samatman 7y ago
      Well, both are true: https://www.freelists.org/post/luajit/Looking-for-new-LuaJIT-maintainers https://www.freelists.org/post/luajit/Looking-for-new-LuaJIT... It's more of an emeritus situation than anything, he's still active on the list as well. I'd be ecstatic if hyperblock scheduling, or the quad-color garbage collector, were to drop onto the 2.1 trunk, but I'm not counting on it.
samatman 7y ago
LuaJIT, true to form, has a sort of solution for this, in the form of a profiler cheap enough to run in production. You do have to change how you think about performance analysis, but in return, you get to actually answer the question you're trying to reason about, namely, how does this run in production. Pacifying the JIT is a bit of a dark art, but the whole thing is pretty transparent with good tooling. I've yet to regret building on LuaJIT.
- thu2111 7y ago
  Worth noting that the JVM has this feature as well, under the name of "flight recorder".
lispm 7y ago
> Interpreters, which read the program line by line as it runs Byte code interpreters do that? That would be surprising. Programs are represented with 'lines' in byte code? Things he wants, let's look at SBCL, a Common Lisp implementation (see http://sbcl.org http://sbcl.org ): > compile short bits to native code quickly at runtime -> that's done by default > identify whether a section is getting optimized -> we tell the compiler and the compiler gives us feedback on the optimizations performed or missed > know anything about the native code that’s being run in a benchmark -> we can disassemble it, some information can be asked > statically require that a given section can & does get optimized -> done via declarations and compilation qualities > compile likely sections in advance to skip warmup -> by default > bonus: ship binaries with fully-compiled programs -> dump the data (which includes the compiled code) to an executable
- smabie 7y ago
  >Byte code interpreters do that? That would be surprising. Programs are represented with 'lines' in byte code? kdb+/q has a bytecode compiler and each line is turned into bytecode and run, line by line. Also the performance is as good as C, most of the time.
- eatonphil 7y ago
  Yes, I thought of SBCL when I was reading this too. A JS frontend for SBCL could be nice...
  - pjmlp 7y ago
    Or at very least improve browser developer tools to give us what Lisp compilers have been doing the last half century. Why should we need to hand compile special versions of JavaScript VMs, just to get (decompile ....)?
claytongulick 7y ago
The thing is, javascript performance is mostly "good enough", and honestly that's what really matters. When you have workloads that are mostly io bound, having syntactic sugar like js async/await to avoid blocking is really a huge strength. When we write systems, we operate under constraints, and frequently the largest constraint is time to market rather than pure performance. Dynamic typing can be a huge strength for TTM. If performance was the only concern, we'd all be in straight C with inline asm.
- saagarjha 7y ago
  What’s TTM?
  - gok 7y ago
    Time to market I'd guess?
  - jgu 7y ago
    Time To Market
- smabie 7y ago
  I'm not convinced that dynamic typing helps productivity. In my experience, an expressive type system allows one to deploy code much more quickly. The key word, of course, is expressive. Neither Go, nor Java, btw, qualify as having expressive type systems.
  - Chyzwar 7y ago
    My guess is that productivity is really from the ecosystem. It is easier to create and use modules in JS than Java/C#. You do not need to mend your codebase to use modules. Once you have all these third party modules it easier to move fast with the product. Structural typing fit really nicely with existing JS. Typescript have all expressiveness of JS and granular control of type safety. Given this, there is a lot of sharp edges.
    - 7y ago
inglor 7y ago
Hey Node/bluebird person here: You want to run Node with --teace-opt and --trace-deopt and --allow-natives-syntax with %OptimizeFunctionOnNextCall before benchmarking.
gok 7y ago
Dead on. JITs are high interest credit card technical debt when it comes to performance. It says a lot that all the performance-sensitive parts of widely deployed JITs are themselves implemented with AOT compilation.
- saagarjha 7y ago
  > It says a lot that all the performance-sensitive parts of widely deployed JITs are themselves implemented with AOT compilation. …not really? Managed languages with a substantial runtime tend to make for poor ergonomics when writing JITs.
cjfd 7y ago
The high level point that is of great importance is that if one wants a computer program to function in a reliable way one needs simple and understandable algorithms/components. Nowadays even the processor is no longer simple and assembly has become a high level language and it got us 'nice' things like spectre. For the practical day to day work the KISS principle that has been the corner stone of effective programming for half a century is now more important than ever. Yes, there is a nice library available to do such and such and maybe you need it, but are you also thinking about the dangers that any additional moving part may increase unpredictability? Let me give one very stupid example that I ran into this very week. The agreed-upon answer according to https://unix.stackexchange.com/questions/29608/why-is-it-better-to-use-usr-bin-env-name-instead-of-path-to-name-as-my https://unix.stackexchange.com/questions/29608/why-is-it-bet... is that it is better to do #!/usr/bin/env bash than #!/usr/bin/bash. I say: absolutely not! You have just increased the number of moving parts involved by one for an immeasurably small benefit. And if you are worrying about bash versions then just stop using any bash features that are less than a decade old. I also say that unless it is necessary for the core problem that you are trying to solve stay away from any features of anything that are less than 5 years old. And if you actually need the new and fancy stuff, and maybe you do, expect to pay a hefty price for it. Every new tool that you introduce has its own peculiarities that you will spend hours of debug time on and one should err on the side of just saying no.
BorisTheBrave 7y ago
This article contains a logical error. The premise is JITs are hard to benchmark and keep good performance on. That's true. But the alternative is bad performance all the time (the JITS fall back to interpretation, after all). What's the value in having clearly understood bad performance? If you care enough about performance that you need to understand it, surely you care about the absolute level of performance.
- patrec 7y ago
  False dichotomy. No one should be using shitty byte code interpreters like (c)python for real production work. Or at least stop whining about global warming. The real alternative is AOT. Also in many cases having it's much better to trade off average performance for lower variance.
  - pjmlp 7y ago
    The real alternative is using toolchains that offer both, JIT/AOT.
    - patrec 7y ago
      Well, as long as we can agree that shitty bytecode interpreters are not the way to go ;) I think AOT/JIT as a dichotomy is stupid, for what it's worth. Why shouldn't I have e.g. both profile guided optimization and JIT in the same program?
      - pjmlp 7y ago
        That we surely agree, interpreters are only good as one is ramping up a language. or doesn't plan to use it beyond basic scripting or learning activities. You can have both on the same toolchain, and plenty language do have them. However in some scenarios, like constrained embedded devices, you are left with AOT only. By the way, modern Android is all three, interpreter, AOT and JIT with PGO.
  - jashmatthews 7y ago
gridlockd 7y ago
I completely agree, it's possible to do some tracing of what the V8 JIT does, but the workflow is awful. Microbenchmarks don't represent the real world. Instead of running a single microbenchmark, I suggest running a host of them, but all of them "at the same time" (not serially). They'll get in each others ways and total performance will be far worse. This happens with AOT code as well of course, because caches are being trampled no matter what, but JIT code only exarcerbates the issue because it is larger.
pron 7y ago
The OpenJDK JVM (aka Hotspot) addresses both issues: control [1] and monitoring [2] (there are built-in compilation and deoptimization events emitted to the event stream). You can also compile methods in advance [3], and inspect the generated machine code when benchmarking [4]. You can even compile an entire application ahead-of-time [5] to produce a native binary. [1]: https://docs.oracle.com/en/java/javase/14/vm/compiler-control1.html https://docs.oracle.com/en/java/javase/14/vm/compiler-contro... [2]: https://docs.oracle.com/en/java/javase/14/jfapi/why-use-jfr-api.html https://docs.oracle.com/en/java/javase/14/jfapi/why-use-jfr-... [3]: https://docs.oracle.com/en/java/javase/14/docs/specs/man/jaotc.html https://docs.oracle.com/en/java/javase/14/docs/specs/man/jao... [4]: http://psy-lob-saw.blogspot.com/2015/07/jmh-perfasm.html http://psy-lob-saw.blogspot.com/2015/07/jmh-perfasm.html [5]: https://www.graalvm.org/docs/reference-manual/native-image/ https://www.graalvm.org/docs/reference-manual/native-image/
- amelius 7y ago
  The GC is still nondeterministic though.
  - tomp 7y ago
    So is malloc
    - amelius 7y ago
      True, but the bounds are much better.
    - pkolaczk 7y ago
      It is much easier to avoid malloc writing C than to avoid new in Java.
      - tomp 7y ago
        Nothing to do with GC though. It's also fairly easy to avoid `new` in Go and C#.
anthk 7y ago
I'd love a jit for DosBOX-X, or Qemu. I know, KVM, but think about emulating non-native archs. Or systems without KVM support.
- remexre 7y ago
  Doesn't QEMU already JIT? I guess, depends how much [1] counts. [1]: https://wiki.qemu.org/Documentation/TCG https://wiki.qemu.org/Documentation/TCG
  - anthk 7y ago
    Is not marvellously fast, albeit x86 it's a crawl with these CPU context switches. MIPS emulation seems faster, much faster.
dahart 7y ago
A JIT is just another cache, like memory. Yes, it’s hard to predict, but not fundamentally that different from caching in any language. It does mean perf tests have to be end-to-end and match real-world loads, but it doesn’t mean it’s “impossible” at all, it means you need to measure. Is this a real problem? I’ve been profiling my JS for years and never actually run into a mysterious problem where some important code I profiled was way way slower in prod than when I was profiling. Has that happened for you? How often does this happen? I take it as an assumption that profiling is something you mostly do on inner loops & hot paths in the first place. I mean, I profile everything to look for bottlenecks, but I don’t spend much time optimizing the cold paths. > Get notified about deopts in hot paths Studying the reasons for de-opts help you know in advance when it might happen. If you avoid those things, do-opts won’t happen, and you don’t need notifications. For example, ensure you don’t modify/add/delete keys in any objects, make sure your objects are all the same shape in your hot path, don’t change the type of any properties, and you’re like 90% there, right? > statically require that a given section can & does get optimized [...] compile likely sections in advance to skip warmup While these don’t exist in V8, it’s maybe worth mentioning that the Google Closure compiler does help a little bit, it ensures class properties are present and initialized, which can help avoid de-opts.
remexre 7y ago
Lancet [1] seems like it fixes at least some of the unpredictability. (Haven't used it though, only read about it on another site.) [1]: https://github.com/TiarkRompf/lancet https://github.com/TiarkRompf/lancet
arkanciscan 7y ago
Not a big deal if you're mainly writing client-side JS. You're never gonna know how fast something will run in a browser anyway.

145 points by awinter-py 7y ago

As a nodejs developer: what is the best compiled server language to learn right now? Is it Java still, or is it better to look at go or rust?

deleted 7y ago
[deleted]
csande17 7y ago
Part of me wonders if ASP.NET will make a comeback. A lot of the historical reasons not to use it don't exist anymore (there's an officially-supported Linux port, for example), and a lot of the cool new JavaScript language features like async/await and arrow functions came from C#. Besides, most JavaScript programmers are already dependent on Microsoft products like TypeScript, NPM, and Visual Studio Code. What's one more?
- sk5t 7y ago
  I imagine nobody knows what "ASP.NET" means nowadays as distinct from C# / .NET Core.
- tluyben2 7y ago
  ASP.NET Core has been running fine on Linux and Mac OS X for years now. I have been building backends in it for those same years using Linux mostly. The ecosystem is nice and stable (been run high traffic APIs in production for years which never have any issues) and code written years ago simply works without issues after updating libs/runtime to the latest version (Even from 2.1 to 3.1 we had barely any work). Unlike RoR or JS projects I maintain which break quite a lot on update.
  - Nullabillity 7y ago
    It starts, yes, but the experience is still as miserable as on Windows. They just brought the Windows idiocies with them. The debugger (clrdbg) is still artificially restricted from running inside anything else than MS' IDEs. The global certificate store is still a thing. On that note, the cryptography support varies wildly between platforms, because they still insist on using SChannel on Windows. And I guess that means that they have to use SecureTransport on macOS, to avoid appearing to play favourites or something. The action at a distance that it encouragtes would make you think you're in a haunted house. Despite bringing the Windows mentality with them everywhere, there still isn't a competent migration story from Framework, so what's the point? Legacy code is still a pain to port, and you'd be crazy to actually want to write new code in this mess.
  - eitland 7y ago
    I've used it as well and it is really really nice, especially on Linux as it starts extremely much faster there which was important for my work. It is still not in the same league as Java when it comes to dev tools and the Java ecosystem keeps getting better as well, but at the moment I am torn between the two (or rather, I have two excellent options that I can choose depending on circumstances.)
    - tluyben2 7y ago
      I agree: I also work with Java and JVM languages and I was a fulltime Java dev for 10 years before but the first client (a bank) on our product insisted on .NET 7 years ago and we had some .NET expertise already and went all in. .NET Core is nice enough to do very large projects in though so I cannot see many reasons of moving away from it (especially from F# which I mostly use now).
- gentleman11 7y ago
  Is it open source?
  - csande17 7y ago
    I think so! They have a repo called "ASP.NET Core" on GitHub with an Apache license: https://github.com/dotnet/aspnetcore https://github.com/dotnet/aspnetcore . ("Core" here means that it's the version of .NET that can run on Linux.) The "dotnet" organization also has repositories for the C# compiler and runtime.
  - leosarev 7y ago
    Yes! Compiler, sdk, runtime and framework.
  - Nullabillity 7y ago
    Kind of? Vital parts are still closed (like the debugger), and the tooling still assumes a closed-source world (for example, with OmniSharp, jump-to-definition to dependencies just gives you a synthetic source file that only contains method signatures). It's also not exactly run like a community project. The issue tracker feels more like a customer support system: "can you try updating to the newest release now?" abound, with no mention of what the actual problem or fix was.
- pjmlp 7y ago
  Comeback? It never went away. From where I am standing it has always been either Java or .NET since the last 20 years, while we keep seeing stuff coming and going every couple of years.
tehlike 7y ago
C# is pretty decent. Has been since the get go.
wvenable 7y ago
Best is highly subjective and entirely dependent on what you want to build. I find a lot of joy in working in C# and the .NET core. It's very pleasant to work in and might be worth a look.
- wildduck 7y ago
  Very interesting. I have heard that from some people as well. Any tips on how to get started in *nix/FreeBSD/Mac ecosystem? Last I tried was in mono. Any tips appreciated.
  - wvenable 7y ago
    It's super easy to download and get started on Linux/Mac: https://dotnet.microsoft.com/download/dotnet-core/3.1 https://dotnet.microsoft.com/download/dotnet-core/3.1 I even managed to get it to run on an Android tablet via Termux by downloading the ARM64 binaries.
jitl 7y ago
It depends on a lot of factors. I’m a typescript Dev and I’m really enjoying working in Kotlin. I certainly enjoy how expressive it is compared to Go, and I picked it up in a couple of days in an existing codebase, so it’s much easier than Rust. I think you can’t undersell how good the JetBrains IDE makes the programming experience with code completion, auto-imports, corrections, or how great it is that Kotlin interfaces with Java seamlessly.
- spockz 7y ago
  Funnily enough Scala provides the same feature set. However, because it is even more powerful than Kotlin there are also more ways to achieve the same goal. Doing any of the advanced stuff makes it hard to use that Scala code from Java. Using java from scala is easy. And still kotlin appears to be gaining ground on scala.
  - mwcampbell 7y ago
    In my limited experience, Kotlin seems to have smoother Java interop than Scala. For example, last time I checked, Java getter/setter methods automatically become Kotlin properties, and vice versa, whereas Scala has its own convention for getters and setters. Is that not the case now?
gaogao 7y ago
To learn for what goal? For education, for enterprise, for speed? To which my shortlist is Haskell, C#, and Rust.
didibus 7y ago
Java is still the largest and most in use server side language at 39%. It is followed by C# at 32%. After that, you have Go at 9%, Kotlin (also a JVM Lang) at 6.6% and Scala (also a JVM Lang) at 4%. Finally, you get Elixir and Clojure both at 1.5% Source: https://insights.stackoverflow.com/survey/2019 https://insights.stackoverflow.com/survey/2019 So yes, I think learning Java and the JVM ecosystem is a good investment, considering Java dominates, and if you tally up JVM langs you get something like 51% of professional developers using a JVM based language for work.
- jimmaswell 7y ago
  This up-to-date one seems to be putting PHP in a large lead with C# then Java following: https://w3techs.com/technologies/overview/programming_language https://w3techs.com/technologies/overview/programming_langua... We've drifted from just compiled languages here, but the most important server-side language to know is probably PHP. Personally I've really enjoyed working with Drupal.
  - gentleman11 7y ago
    I always thought php was just a templating language. Any recommended books or resources?
  - didibus 7y ago
    Sorry, I assumed parent meant backend and web services, like REST, GraphQL or RPC APIs, and not server side HTML rendering, that's why I excluded certain languages like PHP. I also skipped over interpreted languages like Python and Ruby since they mentioned compiled. Also, that doesn't look like a great metric, since it's just the number of website using a particular technology. That's going to be massively skewed by prefab solutions like WordPress and all. I liked that the StackOverFlow survey asked people what language they used professionally. I feel that's much more relevant.
    - jimmaswell 7y ago
      PHP is used for REST and all that just fine. Why are you excluding it from "backend and web services"?
_delirium 7y ago
Maybe I'm missing the intended distinction, but in normal usage, Java is also a JITted language. It's almost the canonical one... JITs are much older, but HotSpot really popularized the concept in mainstream production.
- kizer 7y ago
  Java’s bytecode is JITted, which is a subtle distinction since there is an AOT translation step capabale of optimizations etc.
  - _delirium 7y ago
    Technically yes, but the AOT step in practice does almost no optimizations and is just a direct translation, at least if you're using the mainstream javac. It's there just to simplify the VM/JIT, so the latter can read bytecode instead of textual source code. There have been attempts at AOT compiling Java, but afaict they have very little usage. GCJ, now dead, was the main one for years. There's also a newer experimental compiler jaotc: https://openjdk.java.net/jeps/295 https://openjdk.java.net/jeps/295.
    - kizer 7y ago
      You seem to have more familiarity than me with Java :). So I guess V8 JITs some kind of p-code then? If V8 allowed full AOT comp. to the internal bytecode, then the perf would theoretically be around Java’s avg perf?
      - earenndil 7y ago
        Nope, because java is statically typed.
      - laurencerowe 7y ago
        Avoiding the source parsing step would only provide a startup time performance win. JS engines tend to be faster than Java here already since it's something they've been heavily optimized for. It's difficult for JS engines to match Java's performance without type information to work with. This is only discovered at runtime and the JIT'ed code for a function requires traps in case it is later called by parameters of a different type.
on_and_off 7y ago
kotlin is pretty neat to work with. In the end it is all bytecode (so java, or rather both java and kotlin output bytecode), but kt removes a lot of the ceremony, boilerplate, and altogether ideas that have proven to do not be that great in the years since java's inception.
- vips7L 7y ago
  This is no longer true. Java has eaten a lot of the features Kotlin once had. The only things not provided by java are nullable reference types and coroutines (coming).
  - pjmlp 7y ago
    Some people on Android bubble keep mistaking Android Java for the real deal.
  - on_and_off 7y ago
    meh, java has indeed eaten a lot of the features that kotlin has (why do you use past tense ??). However, the java version is not necessarily as convenient, concise or powerful than Kotlin. E.G. I strongly prefer data class to records. No named parameters -> no default params -> way more boilerplate
DethNinja 7y ago
In my experience Go is amazing for webserver development. Very easy to learn and you can build things very quickly. However, I still use C++ for extremely complex networked applications where performance matters, unfortunately Rust doesn’t have battle tested crypto libraries, so I wouldn’t personally use it for networked applications.
- gameswithgo 7y ago
  just use the c libraries from rust?
  - boulos 7y ago
    Or use rustls, if you just need modern TLS. I found this back and forth of rustls vs native-tls (which picks up openssl/your favorite system ssl) helpful: https://users.rust-lang.org/t/any-reasons-to-prefer-native-tls-over-rustls/37626 https://users.rust-lang.org/t/any-reasons-to-prefer-native-t...
  - ilammy 7y ago
    There a few wrapper libraries that provide safe Rust interface for a limited feature set on top of system's crypto libraries like OpenSSL, so the applications can benefit from decades of testing and get security updates without timely rebuilds. I'm maintaining one, for example, which has Rust bindings among 12 other platforms.
- eatonphil 7y ago
  Go's lack of generics makes it better for write-once, run-forever systems like proxies. It's not as ideal for application servers that will otherwise need a lot of code duplication via code generation (to be type safe) or nil interfaces (to throw away static typing). Code generation isn't so bad. Even JOOQ (Java's awesome ORM) will suggest you do it. And similarly, Java's generics aren't that great themselves. But you come to expect more from a newer language with so much history to learn from and they missed the ball on generics. (In contrast they got right: gofmt, go test, cross platform builds, go get, etc.)
Skunkleton 7y ago
If you are are looking for a mature high performance language to keep in your back pocket for the cases where you can't use node, Java seems like a fair bet. Go would also be useful. Neither are too much fun IMO, but that would fit the bill. There are newer languages that are more interesting, but picking one of those is more about either attempting to anticipate where the industry is going, or just plain wanting a more fun language. Rust is an example here. Personally I think rust is worth learning, and has a fair shot at taking over a large chunk of software development that would have previously gone to C or C++. Learning rust might make you a better programmer because lots of poor-programming-hygiene type things are compiler errors in rust. If you just want a way to wring maximum performance out of a piece of hardware, then I would caution you to consider your choice carefully. Writing high performance code requires a complete understanding of the stack underneath you. If you want to see my point in practice go check out the programming languages shootout. Specifically notice that there are benchmarks implemented in "fast" languages that are outperformed by better optimized code written in "slow" languages. I would recommend against C++ unless you are planning on devoting a very large amount of time to learning it well. I also don't personally like C++. Too many footguns.
- saagarjha 7y ago
  Java has a JIT too…
  - pjmlp 7y ago
    And AOT as well.
- acqq 7y ago
  > notice that there are benchmarks implemented in "fast" languages that are outperformed by better optimized code written in "slow" languages. I haven't observed that, at least not where one can't write a "better optimized" code in the "fast" language too. Can you give any specific examples?
  - Skunkleton 7y ago
    Sorry, I wasn’t clear. On shootout they have multiple implementation of each benchmark in the same language. The fastest implementations are always fast languages, but there are lots of implementations in fast languages that are bested by better implementations in slow languages[1]. The point I was trying to make is that picking a fast language isn’t enough to write truly fast programs. 1. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/mandelbrot.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
smabie 7y ago
I would say Scala, or maybe F#.
fulafel 7y ago
JS is also frequently a compiled language these days. What makes you qualify the question this way?
sideeffffect 7y ago
Check out Scala! It has modern features and the tooling around it is mature. If you like books, this should be a good intro: https://underscore.io/books/essential-scala/ https://underscore.io/books/essential-scala/ (you should use IntelliJ IDEA instead of Eclipse, though) And you can also use it for frontend development: https://www.scala-js.org/doc/sjs-for-js/es6-to-scala-part1.html https://www.scala-js.org/doc/sjs-for-js/es6-to-scala-part1.h... (having one language for both backend and frontend leads to great synergy)

pizlonator 7y ago

This post is extremely V8-centric. For example it uses terminology like “deopts” which means nothing in JavaScriptCore (we distinguish between exits, invalidations, jettisons, and recompiles). The post also assumes that there is only one JIT (JSC has multiple). And that’s where you’ve lost me. Not sure how you expose anything about how the JIT is operating without introducing a compat shitshow since JIT means different things in different implementations. If you really want to know that something gets compiled with the types you want, use a statically typed and ahead of time compiled language. If you have to use a JIT but you find that it doesn’t do what you like then remember that it’s meant to be stochastic. The VM is just trying to win in the average. Which functions get compiled and with what type information can vary from run to run. Probably the best thing that could happen is that developer tools tell you more about what the JIT is doing. But even that’s hard. There are some specifics that I disagree with: - I don’t think all JIT architects for JS claim that the perf is about competing with C for numerical code. I don’t explain it that way. I would say: JITs are about doing the best job you can do under the circumstances. They can make JS run 4x faster than an interpreter if things really go well. “Between Python and Java” is a good way to put it and that’s exactly what I would expect. So if that’s your experience then great! The JIT worked as expected. - It’s usually foolish to want your code compiled sooner. Compilation delay is about establishing confidence in profiling. I’m pretty sure we’d JIT much sooner if it wasn’t for the fact that it would make the EV of our speculation go negative. TL;DR. the JIT can’t unfuck up JavaScript.

csande17 7y ago
The post is likely V8-centric because it's discussing server-side JavaScript. As far as I know, pretty much everyone uses V8 for server-side JS because that's what Node is based on. And compatibility seems to be much less of an issue there as well, at least if all the "dropped support for Node version X" changelogs I read are any indication. Not to say server-side JavaScript is necessarily a good idea. But if people are determined to make it work, I could see these sorts of changes happening that wouldn't make sense in a web browser.
deleted 7y ago
[deleted]
7y ago

banachtarski 7y ago

This article has a number of issues. JS with JIT is waaay faster than Python. Not “between python and java” as purported. Second, generalizing jits as “un-ergonomic” seems silly given that what’s being specifically looked at is benchmarking. But what makes this claim ridiculous is that nothing is easy to benchmark. Even native code is hard to profile and this is literally my day job. If the JIT makes your code that much faster, this strikes me as a pretty suspect complaint

pizlonator 7y ago
I think that by “between python and java” they meant “faster than python and slower than java”. I think Java still beats JS unless you get lucky. You’re totally right that benchmarking and profiling is hard even for native code. I think this post fetishizes whether or not a piece of code got JITed a little too much. Maybe the author had a bad time with microbenchmarks. There’s this anti pattern in the JS world to extract a small code sample into a loop and see how fast it goes - something that C perf hackers usually know not to do. That tactic proves especially misleading in a JIT since JITs salivate at the sight of loops.
- shawnz 7y ago
  That still doesn't make sense to me.. how can JIT in general be slower than Java when Java is JITed?
  - throwaway894345 7y ago
    The claim wasn’t about JIT in general, but rather about JS.
    - deleted 7y ago
      [deleted]
    - pizlonator 7y ago
      Then it’s problematic to be so JS and V8 centric. Also the post specifically talked about JS being faster than Python and slower than Java so that’s what this thread is about.

connor4312 7y ago

As someone who's been writing a lot of JavaScript, Go, and a handful of other languages for a while, I feel this. In Go, I can basically know what's going to happen when I write a function. This operation will read from the stack, these instructions will be run, and I can take a peek at the assembly if I'm not sure (though I've developed a pretty good feel for what Go will do without needing that). I can benchmark it and know that the performance I see on my machine will be the performance when I ship this bit of functionality into production, barring hardware differences. In JavaScript, it's a black box. I know some constructs might deoptimize functions when run on Wednesdays because I read them on a blog published in 2018 that's _probably_ still accurate. In my benchmark running on Node 12.14.1 on Windows this seems to be true. But then who knows if it'll be the same thing in production, and it might 'silently' change later on. JavaScript in V8 is incredibly fast these days, but I find it much easier to write optimal code in Go.

_bxg1 7y ago
It's really no different from native compiler optimizations, which are also mysterious and always changing, except for one key aspect: when recording timings to compare against other timings, you can control whether optimizations are turned on or off, to remove that variable from the comparison.
- lpghatguy 7y ago
  Thankfully, with a native compiler you don't have to deal with your JIT warming up, or some other code causing your function to get deoptimized, or subtle JIT trace aborts. :(
  - fctorial 7y ago
    > or some other code causing your function to get deoptimized Why doesn't the optimizer generate different compiled implementations of a function for different pieces of code?
    - notamy 7y ago

_bxg1 7y ago

> if your economics are such that servers are a bigger cost than payroll Sorry, and I may be oversimplifying the author's situation, but this really sounds like a case where you need to not be using JS for your server. On the client you don't have much choice, but on the client the pure-JS performance rarely gets tight enough to warrant this degree of micro-optimization work. Author makes some good points - it would be great if the JIT were more profiler-friendly - but I have to question a little bit how important it actually is, the way the use-cases line up.

erik_seaberg 7y ago
When someone realized you pay a lot for cycles at the server, but you pay nothing for cycles at the client, that was the moment the world-wide web began to die.
- dimgl 7y ago
  Well this is hyperbolic.
- deleted 7y ago
  [deleted]
- _bxg1 7y ago
  This is baseless mudslinging. The bottleneck on the client is virtually never the cycles consumed by the actual running of the actual app's JS code. It's usually, in order starting with the most common: - Piles of ads/analytics scripts which have no motivation not to slow down the page - Reflow; i.e. needlessly many elements on the page causing the browser to do extra work calculating layout - The initial loading and JIT-ing time of a needlessly heavy JS bundle
pjmlp 7y ago
They are, Common Lisp, Java/Android and .NET all provide very developer friendly graphical profiling tools.
- caleb-allen 7y ago

peterkelly 7y ago

If you were to get the information you were after it would be specific to a particular implementation, and a particular version of that implementation. The nature of how JIT is done for JavaScript is not defined in the spec and varies a lot (starting from totally nonexistant many years ago). To have useful performance measurement tools that are going to help your code run across multiple implementations would require a) all of those implementations to work the same, forever, and b) the semantics of this to be specified in the standard.

lpghatguy 7y ago

An anecdote from a non-JS JIT, but similar: I once spent a summer working on a game engine with a couple others where the host language was LuaJIT. It started out great. The iteration cycles were incredibly short, performance was competitive, the code was portable, and we could do wild metaprogramming nonsense that was still fast. If you haven't worked with LuaJIT, its C FFI is also incredible! As we started scaling though, the wheels fell off the wagon. We'd add a new feature and suddenly the game wouldn't run at interactive framerates. One time, it was the 'unpack' function, which would trigger a JIT trace abort. We would drop from 12ms frames to 100ms frames. I wrote a length-specialized version that didn't abort and moved on. Another time, it was calling Lua's 'pairs' method (iterator over a map). Okay, so we can't do that, or a few other things that made Lua productive before. The other problem we hit was GC predictability being impossible. We tried to mitigate it by using native data structures through the C FFI, taking control over the GC cycle to run it once or twice per frame, etc. In the end, like the JIT problem, we weren't writing Lua at the end, we were writing... something else. It wasn't maintainable. That summer ruined dynamic languages for me. I didn't really want to be writing C or C++ at the time. I ended up picking up Rust, which was predictable and still felt high-level, and the Lua experience ended up getting me my current job.

samatman 7y ago
'pairs' was jitted recently by the RaptorJIT crew, fwiw. I've hit fewer snags with LuaJIT, but they're definitely there. Really wish Mike Pall had written that hyperblock scheduler before retiring...
- stephen82 7y ago
  He did not retire; he is still quite active and improving LuaJIT [1]. [1] https://github.com/LuaJIT/LuaJIT/tree/v2.1
  - samatman 7y ago
    Well, both are true: https://www.freelists.org/post/luajit/Looking-for-new-LuaJIT-maintainers https://www.freelists.org/post/luajit/Looking-for-new-LuaJIT... It's more of an emeritus situation than anything, he's still active on the list as well. I'd be ecstatic if hyperblock scheduling, or the quad-color garbage collector, were to drop onto the 2.1 trunk, but I'm not counting on it.

samatman 7y ago

LuaJIT, true to form, has a sort of solution for this, in the form of a profiler cheap enough to run in production. You do have to change how you think about performance analysis, but in return, you get to actually answer the question you're trying to reason about, namely, how does this run in production. Pacifying the JIT is a bit of a dark art, but the whole thing is pretty transparent with good tooling. I've yet to regret building on LuaJIT.

thu2111 7y ago
Worth noting that the JVM has this feature as well, under the name of "flight recorder".

lispm 7y ago

> Interpreters, which read the program line by line as it runs Byte code interpreters do that? That would be surprising. Programs are represented with 'lines' in byte code? Things he wants, let's look at SBCL, a Common Lisp implementation (see http://sbcl.org http://sbcl.org ): > compile short bits to native code quickly at runtime -> that's done by default > identify whether a section is getting optimized -> we tell the compiler and the compiler gives us feedback on the optimizations performed or missed > know anything about the native code that’s being run in a benchmark -> we can disassemble it, some information can be asked > statically require that a given section can & does get optimized -> done via declarations and compilation qualities > compile likely sections in advance to skip warmup -> by default > bonus: ship binaries with fully-compiled programs -> dump the data (which includes the compiled code) to an executable

smabie 7y ago
>Byte code interpreters do that? That would be surprising. Programs are represented with 'lines' in byte code? kdb+/q has a bytecode compiler and each line is turned into bytecode and run, line by line. Also the performance is as good as C, most of the time.
eatonphil 7y ago
Yes, I thought of SBCL when I was reading this too. A JS frontend for SBCL could be nice...
- pjmlp 7y ago
  Or at very least improve browser developer tools to give us what Lisp compilers have been doing the last half century. Why should we need to hand compile special versions of JavaScript VMs, just to get (decompile ....)?

claytongulick 7y ago

The thing is, javascript performance is mostly "good enough", and honestly that's what really matters. When you have workloads that are mostly io bound, having syntactic sugar like js async/await to avoid blocking is really a huge strength. When we write systems, we operate under constraints, and frequently the largest constraint is time to market rather than pure performance. Dynamic typing can be a huge strength for TTM. If performance was the only concern, we'd all be in straight C with inline asm.

saagarjha 7y ago
What’s TTM?
- gok 7y ago
  Time to market I'd guess?
- jgu 7y ago
  Time To Market
smabie 7y ago
I'm not convinced that dynamic typing helps productivity. In my experience, an expressive type system allows one to deploy code much more quickly. The key word, of course, is expressive. Neither Go, nor Java, btw, qualify as having expressive type systems.
- Chyzwar 7y ago
  My guess is that productivity is really from the ecosystem. It is easier to create and use modules in JS than Java/C#. You do not need to mend your codebase to use modules. Once you have all these third party modules it easier to move fast with the product. Structural typing fit really nicely with existing JS. Typescript have all expressiveness of JS and granular control of type safety. Given this, there is a lot of sharp edges.
  - 7y ago

inglor 7y ago

Hey Node/bluebird person here: You want to run Node with --teace-opt and --trace-deopt and --allow-natives-syntax with %OptimizeFunctionOnNextCall before benchmarking.

gok 7y ago

Dead on. JITs are high interest credit card technical debt when it comes to performance. It says a lot that all the performance-sensitive parts of widely deployed JITs are themselves implemented with AOT compilation.

saagarjha 7y ago
> It says a lot that all the performance-sensitive parts of widely deployed JITs are themselves implemented with AOT compilation. …not really? Managed languages with a substantial runtime tend to make for poor ergonomics when writing JITs.

cjfd 7y ago

The high level point that is of great importance is that if one wants a computer program to function in a reliable way one needs simple and understandable algorithms/components. Nowadays even the processor is no longer simple and assembly has become a high level language and it got us 'nice' things like spectre. For the practical day to day work the KISS principle that has been the corner stone of effective programming for half a century is now more important than ever. Yes, there is a nice library available to do such and such and maybe you need it, but are you also thinking about the dangers that any additional moving part may increase unpredictability? Let me give one very stupid example that I ran into this very week. The agreed-upon answer according to https://unix.stackexchange.com/questions/29608/why-is-it-better-to-use-usr-bin-env-name-instead-of-path-to-name-as-my https://unix.stackexchange.com/questions/29608/why-is-it-bet... is that it is better to do #!/usr/bin/env bash than #!/usr/bin/bash. I say: absolutely not! You have just increased the number of moving parts involved by one for an immeasurably small benefit. And if you are worrying about bash versions then just stop using any bash features that are less than a decade old. I also say that unless it is necessary for the core problem that you are trying to solve stay away from any features of anything that are less than 5 years old. And if you actually need the new and fancy stuff, and maybe you do, expect to pay a hefty price for it. Every new tool that you introduce has its own peculiarities that you will spend hours of debug time on and one should err on the side of just saying no.

BorisTheBrave 7y ago

This article contains a logical error. The premise is JITs are hard to benchmark and keep good performance on. That's true. But the alternative is bad performance all the time (the JITS fall back to interpretation, after all). What's the value in having clearly understood bad performance? If you care enough about performance that you need to understand it, surely you care about the absolute level of performance.

patrec 7y ago
False dichotomy. No one should be using shitty byte code interpreters like (c)python for real production work. Or at least stop whining about global warming. The real alternative is AOT. Also in many cases having it's much better to trade off average performance for lower variance.
- pjmlp 7y ago
  The real alternative is using toolchains that offer both, JIT/AOT.
  - patrec 7y ago
    Well, as long as we can agree that shitty bytecode interpreters are not the way to go ;) I think AOT/JIT as a dichotomy is stupid, for what it's worth. Why shouldn't I have e.g. both profile guided optimization and JIT in the same program?
    - pjmlp 7y ago
      That we surely agree, interpreters are only good as one is ramping up a language. or doesn't plan to use it beyond basic scripting or learning activities. You can have both on the same toolchain, and plenty language do have them. However in some scenarios, like constrained embedded devices, you are left with AOT only. By the way, modern Android is all three, interpreter, AOT and JIT with PGO.
- jashmatthews 7y ago

gridlockd 7y ago

I completely agree, it's possible to do some tracing of what the V8 JIT does, but the workflow is awful. Microbenchmarks don't represent the real world. Instead of running a single microbenchmark, I suggest running a host of them, but all of them "at the same time" (not serially). They'll get in each others ways and total performance will be far worse. This happens with AOT code as well of course, because caches are being trampled no matter what, but JIT code only exarcerbates the issue because it is larger.

pron 7y ago

The OpenJDK JVM (aka Hotspot) addresses both issues: control [1] and monitoring [2] (there are built-in compilation and deoptimization events emitted to the event stream). You can also compile methods in advance [3], and inspect the generated machine code when benchmarking [4]. You can even compile an entire application ahead-of-time [5] to produce a native binary. [1]: https://docs.oracle.com/en/java/javase/14/vm/compiler-control1.html https://docs.oracle.com/en/java/javase/14/vm/compiler-contro... [2]: https://docs.oracle.com/en/java/javase/14/jfapi/why-use-jfr-api.html https://docs.oracle.com/en/java/javase/14/jfapi/why-use-jfr-... [3]: https://docs.oracle.com/en/java/javase/14/docs/specs/man/jaotc.html https://docs.oracle.com/en/java/javase/14/docs/specs/man/jao... [4]: http://psy-lob-saw.blogspot.com/2015/07/jmh-perfasm.html http://psy-lob-saw.blogspot.com/2015/07/jmh-perfasm.html [5]: https://www.graalvm.org/docs/reference-manual/native-image/ https://www.graalvm.org/docs/reference-manual/native-image/

amelius 7y ago
The GC is still nondeterministic though.
- tomp 7y ago
  So is malloc
  - amelius 7y ago
    True, but the bounds are much better.
  - pkolaczk 7y ago
    It is much easier to avoid malloc writing C than to avoid new in Java.
    - tomp 7y ago
      Nothing to do with GC though. It's also fairly easy to avoid `new` in Go and C#.

anthk 7y ago

I'd love a jit for DosBOX-X, or Qemu. I know, KVM, but think about emulating non-native archs. Or systems without KVM support.

remexre 7y ago
Doesn't QEMU already JIT? I guess, depends how much [1] counts. [1]: https://wiki.qemu.org/Documentation/TCG https://wiki.qemu.org/Documentation/TCG
- anthk 7y ago
  Is not marvellously fast, albeit x86 it's a crawl with these CPU context switches. MIPS emulation seems faster, much faster.

dahart 7y ago

A JIT is just another cache, like memory. Yes, it’s hard to predict, but not fundamentally that different from caching in any language. It does mean perf tests have to be end-to-end and match real-world loads, but it doesn’t mean it’s “impossible” at all, it means you need to measure. Is this a real problem? I’ve been profiling my JS for years and never actually run into a mysterious problem where some important code I profiled was way way slower in prod than when I was profiling. Has that happened for you? How often does this happen? I take it as an assumption that profiling is something you mostly do on inner loops & hot paths in the first place. I mean, I profile everything to look for bottlenecks, but I don’t spend much time optimizing the cold paths. > Get notified about deopts in hot paths Studying the reasons for de-opts help you know in advance when it might happen. If you avoid those things, do-opts won’t happen, and you don’t need notifications. For example, ensure you don’t modify/add/delete keys in any objects, make sure your objects are all the same shape in your hot path, don’t change the type of any properties, and you’re like 90% there, right? > statically require that a given section can & does get optimized [...] compile likely sections in advance to skip warmup While these don’t exist in V8, it’s maybe worth mentioning that the Google Closure compiler does help a little bit, it ensures class properties are present and initialized, which can help avoid de-opts.

remexre 7y ago

Lancet [1] seems like it fixes at least some of the unpredictability. (Haven't used it though, only read about it on another site.) [1]: https://github.com/TiarkRompf/lancet https://github.com/TiarkRompf/lancet

arkanciscan 7y ago

Not a big deal if you're mainly writing client-side JS. You're never gonna know how fast something will run in a browser anyway.