3 ms·

This paper is relevant: Energy Efficiency across Programming Languages: How Does Energy, Time, and Memory Relate? https://greenlab.di.uminho.pt/wp-content/up

• misja111 4mo ago
  Why didn't they include assembly? IMO this should be the benchmark, not C
  • LoganDark 4mo ago
    Assembly has no idiomatic way to do things. Creating an optimized assembly comparison is another paper in itself.
• lionkor 4mo ago
  Any comparison with Lua that doesn't include LuaJit also shouldn't include any JavaScript (or rather, should test it with some super inefficient ancient runtime instead of V8)
• Zababa 4mo ago
  This paper is not really relevant, it's based on the "Computer Language Benchmark Game", so what it measures is a mix of the efficiency/speed of the language and the attention that practitioners of that language gave to the Computer Language Benchmark Games. What is measured in that table is neither naive code nor the absolute limit you can reach with each language, which means you can't really then compare languages between themselves the way the paper implies. I think picking professionals at random that practice those languages and ask them to write Computer Language Benchmark Games code would be maybe a bit more representative, but even there you face huge biases.
  • benj111 4mo ago
    > neither naive code nor the absolute limit you can reach with each language Maybe a nit pick. But this isn't a basis to say you can't compare the code. The 'average' code is going to be somewhere between your two extremes. Assuming on average, the code was written by the average programmer, you can get an insight in to what the average programmer of a programming language should expect. Now it may be that populations of programmers favour different things (speed, memory usage, ease of implementation) but that still forms a valid comparison.
    • heijmans 4mo ago
      We are talking about the benchmark game here. The code for different languages was written by different programmers. For some languages, there were multiple implementations and many iterations. In this case, the researchers used the fastest one. Some of the implementations are extremely optimized and took a lot of effort. Some implementations are not. So you might be comparing highly optimized JavaScript code with naive, below-average TypeScript code. You cannot compare those. It would be much better if they used the same level of optimization for each language, but they didn't. Furthermore it is called a "Game" (it used to be called a "Shoot-out") because you shouldn't take it seriously. So it shouldn't be the basis of serious research.
      • Capricorn2481 4mo ago
• qsort 4mo ago
  I don't know what this table is supposed to measure but it doesn't check out. (C, C++) and (JS, TS) are almost source-compatible, chances are you can rename test.c to test.cpp and test.js to test.ts and you're done. Yet they're showing massive differences? Also most of the compiled languages with no runtime should get results that are very close to each other: good compilers should produce similar object-code for this type of microbenchmark. Not to mention this is really measuring the implementation, you can't measure a language. Mike Pall wouldn't be down there, and JS/TS wouldn't be up there without V8 and friends.
  • atiedebee 4mo ago
    I imagine you would want to test "idiomatic" code for these comparisons. It doesn't make much sense to compile with C++ and write everything in C.
    • Capricorn2481 4mo ago
      That doesn't explain why Typescript is insanely less efficient.
• piokoch 4mo ago
  I have to say I am surprised that Java is better than Go in terms of energy/time.
  • faangguyindia 4mo ago
    How can that be possible, in my experience Equivalant service in Java idles around 400mb of ram when Go service might use 70mb.
    • Capricorn2481 4mo ago
      Because it allocates RAM up front by default. You can reduce that yourself with a single flag. You'd be surprised how far you can tune down modern Java and still run faster than Go. I did this on the benchmark games and some of those programs that used so much RAM didn't need any of it. There's little about Go's design that is more "Ram efficient." That's not what it was made for. It's for low latency, and if you want that in Java, there are other GC's that can do that (with similar tradeoffs to Go).
• DanRosenwasser 4mo ago
  The methodology used in this paper was extremely bad. There is no reason there should be any disparity between a TypeScript and JavaScript benchmark. Unfortunately it has continued to make the rounds for about a decade now and gets re-posted every year or so.
  • benj111 4mo ago
    Isn't that like saying X compiles to assembly as so should be as efficient as assembly? I'm not an expert on the internals of typescript. But your comment doesn't indicate you are an expert either.
    • heijmans 4mo ago
      You don't have to be an expert in TypeScript to know that the TypeScript compiler just strips the types from the code and leaves the rest as-is (if you are targeting a somewhat modern JS engine). The runtime performance of a TypeScript program is the same as that of the equivalent JavaScript program. But of course, a TypeScript program could be much slower than a different JavaScript program, as is probably happening in this case. I agree with others that the difference in results between JavaScript and TypeScript makes the quality of this paper highly suspect.
      • benj111 4mo ago
        Well you need to know enough to know whether it's doing run time checks also. And also whether it's generating less efficient code to satisfy the type safety requirement.
        • Thiez 4mo ago
          It isn't. Typescript is basically javascript with type annotations. There is a shorthand for class member initialisation and for defining enums, but that's basically it. There are no extra safety checks inserted. You get compile-time typechecking and nothing else.
    • 4mo ago