1

Cython is a superset of Python that can be complied into C modules that can be imported and used normally in Python code. This can be used to speed up parts of a Python program. In a recent project, I used this to make a heavy part of the code run 90x faster. A downside of Cython is that to get significant performance benefits, one needs to add type annotations to Python code with a special syntax, which may decrease readability.

Would a similar system be feasible for Javascript or Typescript to speed up NodeJS backends or Electron applications? Typescript already has syntax for typing, so ideally "Cypescript" wouldn't need any additional syntax.

I found some projects that transpile JS/TS to C or WebAssembly, but these are just one-directional - AFAIK you can't conveniently use the compiled modules from normal TS code. In the system I'm imagining, one could just save a computationally expensive part of their normal NodeJS or Electron project in a file with a distinct file extension, say .cts, and then import code normally from this file in any other JS or TS file. Surely some language features would need to be restricted in .cts files, but making an editor extension to warn about these restrictions shouldn't be too hard.

Is there some technical hurdle here that I'm not seeing?

  • Some would argue, V8 does this internally. I don't buy that. – Basilevs Jul 8 '18 at 20:27
  • Asm.js sounds like it would do what you want – Inverted Llama Jul 9 '18 at 0:50
  • WebAssembly is usable from Javascript – Basilevs Jul 9 '18 at 11:55
1

A downside of Cython is that to get significant performance benefits, one needs to add type annotations to Python code with a special syntax, which may decrease readability.

Note that Python 3+ does have type annotations. I believe the reason Cython doesn't use that syntax is that it pre-dates Python 3. It could be changed, however, to use it, but that wouldn't help much, as I will explain later.

Would a similar system be feasible for Javascript or Typescript to speed up NodeJS backends or Electron applications?

Yes.

Typescript already has syntax for typing, so ideally "Cypescript" wouldn't need any additional syntax.

As I explained above, Python also has syntax for type annotations.

However, Cython distinguishes between Python code and "C" code, between Python types and "C" types. In other words, Cython is a union of two separate sub-languages that share a common syntax: a language for writing Python, and a Python-syntax-influenced language for writing high-level portable C-semantics.

You would still need those two sub-languages in Cypescript.

Is there some technical hurdle here that I'm not seeing?

No. Someone just needs to do it.

Note that there is a social hurdle, though: CPython generates CPython extensions. It generally wouldn't work or at least not that well for users using PyPy, IronPython, Jython, Pyston, Pynie, or any other Python implementation. However, it is usually possible to convince a user to use a specific implementation, plus, the vast majority are using CPython anyway.

The same is not true for Typescript / ECMAScript. There is not a single ECMAScript implementation that dominates the market like CPython does, and users usually don't get a choice of their implementation. If I am using Edge, I am stuck with Chakra, if I am using Firefox, I am stuck with SpiderMonkey, if I am using Safari, I am stuck with Nitro. So, which one of those would Cypescript generate extensions for?

Personally, I don't buy this approach. If CPython is too slow running Python, the solution is not to make it easier to write C code, the solution is to make CPython faster so you don't have to.

The CPython developers ignore lots of research into building high-performance dynamic language implementations gathered over the last 60 years, sometimes with good reason, sometimes without, sometimes simply because of a lack of resources. (Compare the number of developers Oracle JDK or IBM J9 has with the number of CPython developers, for example.)

The Oracle HotSpot JVM is based on the Animorphic Smalltalk VM (just like V8, BTW), Azul Zing is based on HotSpot, IBM J9 is based on IBM's Smalltalk VM, and none of them actually make much use of the static type information in the bytecode, most of their optimizations are dynamic. There is little technical reason why a Python or ECMAScript execution engine shouldn't be at least as performant as HotSpot, Zing, or J9.

  • I think CPython does compile your .py to .pyc to help with execution times. This is similar to the way that the Dot Net runtime was initially designed. I'm still relatively new to Python, but sometimes it's just the differences in algorithms available to you in C that speeds it up so much faster than stock Python. Particularly if you are doing math heavy work, you'll have access to packed arithmetic functions if you dip into assembly. – Berin Loritsch Jul 9 '18 at 17:46
  • 1
    Caching the compiled bytecode only helps with startup times. The bytecode is still purely interpreted. The only difference to an implementation like YARV (the current mainstream Ruby implementation) is that YARV compiles to bytecode every time it loads the program, whereas CPython caches the compiled bytecode. The .NET runtime always only ever dealt with bytecode in the first place, where that bytecode comes from is considered to be a separate problem. In CPython, the source-code-to-bytecode and the execute-bytecode stage happen to be implemented in the same executable, in .NET, they are … – Jörg W Mittag Jul 9 '18 at 17:50
  • split across two executables (the C♯ / VB.NET / F♯ / Delphi / Eiffel.NET / Cobra / COBOL.NET / whatever compiler and the CLR). But the way the bytecode is executed is vastly different. In CPython, it is purely interpreted and only marginally optimized. In the CLR, it is heavily optimized once and compiled to native machine code. In a typical Java VM, it is interpreted for a short time, then heavily optimized based on profiling data collected during the interpretation, and compiled to native machine code, and sometimes even de-optimized back again to interpretation to collect new profiles. – Jörg W Mittag Jul 9 '18 at 17:54
  • Thanks, that does help. Having some sort of optimization cycle would help python in general. As to the OP's original question, I would imagine that modern JavaScript engines are highly optimized considering how they behave. Makes me wonder if the complexity of a C module would be only worth it in very specific circumstances, much like using native libraries in Java is only worth it in very specific circumstances. – Berin Loritsch Jul 9 '18 at 18:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.