4 ms·

> Theoretically, I would assume those to be very close, since one compiles to the other. I don't think that's a safe assumption. The Javascript results would

> Theoretically, I would assume those to be very close, since one compiles to the other. I don't think that's a safe assumption. The Javascript results would be a lower bound (assuming the same algorithm, etc.), but there's no telling what "extra" Javascript (and thus overhead) might be inserted by the Typescript compiler. As far as individual results go, there's no point jumping to conclusions when the results and code are available online and easy to try for yourself: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/typescript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Typescript is still 2-3x slower than Node in several of the benchmarks, and the results could have been different in May 2018 when the article was written.

markmark 8y ago
Typescript is a superset of Javascript, you can literally submit the faster JS programmes as the TS ones.
- TallGuyShort 8y ago
  This may be a dumb question as I know nothing about Typescript, but is it idiomatic to do that, though? You can, for the most part, use C in C++. But if C was beating the pants off of C++ in benchmarks it wouldn't tell me anything useful if someone submitted a C program as the C++ benchmark. If I wanted to use idiomatic C, I'd use C. I expect a C++ vs. C comparison to compare the encouraged features of C++ with what's available in C.
  - alangpierce 8y ago
    Idiomatic TypeScript and idiomatic JavaScript are nearly the same; it's not like the C vs. C++ situation. A design goal of TypeScript is to make it possible to define types for idiomatic JavaScript programs, and I think they meet that goal pretty well. It's one reason the type system is much more advanced and flexible than, say, Java. You might see little differences here and there due to limitations in typechecking and the enum feature, but fundamentally TypeScript is just about adding structure and safety to your code rather than changing the way you code.
  - rienbdj 8y ago
    The benchmark is flawed. It should compare the fastest possible C++ implementation and a more idiomatic C++ implementation. The entire purpose of the language is to allow both to coexist in the same code-base. I would be very surprised if the fastest C++ and C are actually different.
    - igouy 8y ago
      If the benchmark claimed to be perfect then "flawed" would be an important criticism. You can see 4 or 5 C++ fannkuch-redux programs "compared" https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
deleted 8y ago
[deleted]
kbenson 8y ago
> but there's no telling what "extra" Javascript (and thus overhead) might be inserted by the Typescript compiler. That's true, but the fact we're talking about an order of magnitude running time difference is what lead me to think it's not as easily explained as that. > there's no point jumping to conclusions Respectfully, I don't think I did. I put out a theory, with my reasoning, fully acknowledging where it might be wrong. As someone that doesn't use TypeScript (and I wouldn't consider myself in expert in JavaScript either), I don't feel qualified to assess the respective algorithms for those languages in the benchmarks game, so I brought the issue to a larger audience so someone else might take a look if so inclined. > Typescript is still 2-3x slower than Node in several of the benchmarks, and the results could have been different in May 2018 when the article was written. That doesn't really invalidate my theory, as it's possible those are also instances where it's lagging in a good submission. Given that there are several tests where it actually beats the fastest JavaScript algorthim submitted, that seems at least plausible.
alangpierce 8y ago
> there's no telling what "extra" Javascript (and thus overhead) might be inserted by the Typescript compiler TypeScript doesn't do this. With only a few exceptions, the way to turn TypeScript into JavaScript is to remove the type annotations, which leaves you with JavaScript. This is an important design goal of TypeScript: it doesn't change your code, it's just JavaScript with types. Like Babel, TypeScript can be used to compile to earlier JS versions like ES5, but I'd consider that a misconfiguration in an environment like this. Saying that TypeScript is slower than JavaScript is almost as silly as saying "C++ with comments is slower than C++ without comments". If you see a C++ program with comments that's slower than another one without comments, it's almost certainly because they're different programs, not because the comments have any effect. From a glance through your links, it seems likely that all of the running time differences are just because it's different code being run.

markmark 8y ago

Typescript is a superset of Javascript, you can literally submit the faster JS programmes as the TS ones.

TallGuyShort 8y ago
This may be a dumb question as I know nothing about Typescript, but is it idiomatic to do that, though? You can, for the most part, use C in C++. But if C was beating the pants off of C++ in benchmarks it wouldn't tell me anything useful if someone submitted a C program as the C++ benchmark. If I wanted to use idiomatic C, I'd use C. I expect a C++ vs. C comparison to compare the encouraged features of C++ with what's available in C.
- alangpierce 8y ago
  Idiomatic TypeScript and idiomatic JavaScript are nearly the same; it's not like the C vs. C++ situation. A design goal of TypeScript is to make it possible to define types for idiomatic JavaScript programs, and I think they meet that goal pretty well. It's one reason the type system is much more advanced and flexible than, say, Java. You might see little differences here and there due to limitations in typechecking and the enum feature, but fundamentally TypeScript is just about adding structure and safety to your code rather than changing the way you code.
- rienbdj 8y ago
  The benchmark is flawed. It should compare the fastest possible C++ implementation and a more idiomatic C++ implementation. The entire purpose of the language is to allow both to coexist in the same code-base. I would be very surprised if the fastest C++ and C are actually different.
  - igouy 8y ago
    If the benchmark claimed to be perfect then "flawed" would be an important criticism. You can see 4 or 5 C++ fannkuch-redux programs "compared" https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

deleted 8y ago

[deleted]

kbenson 8y ago

> but there's no telling what "extra" Javascript (and thus overhead) might be inserted by the Typescript compiler. That's true, but the fact we're talking about an order of magnitude running time difference is what lead me to think it's not as easily explained as that. > there's no point jumping to conclusions Respectfully, I don't think I did. I put out a theory, with my reasoning, fully acknowledging where it might be wrong. As someone that doesn't use TypeScript (and I wouldn't consider myself in expert in JavaScript either), I don't feel qualified to assess the respective algorithms for those languages in the benchmarks game, so I brought the issue to a larger audience so someone else might take a look if so inclined. > Typescript is still 2-3x slower than Node in several of the benchmarks, and the results could have been different in May 2018 when the article was written. That doesn't really invalidate my theory, as it's possible those are also instances where it's lagging in a good submission. Given that there are several tests where it actually beats the fastest JavaScript algorthim submitted, that seems at least plausible.

alangpierce 8y ago

> there's no telling what "extra" Javascript (and thus overhead) might be inserted by the Typescript compiler TypeScript doesn't do this. With only a few exceptions, the way to turn TypeScript into JavaScript is to remove the type annotations, which leaves you with JavaScript. This is an important design goal of TypeScript: it doesn't change your code, it's just JavaScript with types. Like Babel, TypeScript can be used to compile to earlier JS versions like ES5, but I'd consider that a misconfiguration in an environment like this. Saying that TypeScript is slower than JavaScript is almost as silly as saying "C++ with comments is slower than C++ without comments". If you see a C++ program with comments that's slower than another one without comments, it's almost certainly because they're different programs, not because the comments have any effect. From a glance through your links, it seems likely that all of the running time differences are just because it's different code being run.