Un Cypescript simile a Cython sarebbe un'idea fattibile?

Question

Un Cypescript simile a Cython sarebbe un'idea fattibile?

#1 da (1 voti)

1

Cython è un superset di Python che può essere compilato in moduli C che possono essere importati e usati normalmente in codice Python. Questo può essere usato per accelerare parti di un programma Python. In un progetto recente, l'ho usato per far eseguire una parte pesante del codice 90 volte più velocemente. Uno svantaggio di Cython è che per ottenere notevoli vantaggi in termini di prestazioni, è necessario aggiungere annotazioni di tipo al codice Python con una sintassi speciale, che potrebbe ridurre la leggibilità.

Sarebbe possibile per Javascript o Typescript un sistema simile per velocizzare i backend NodeJS o le applicazioni Electron? Typescript ha già la sintassi per la digitazione, quindi idealmente "Cypescript" non avrebbe bisogno di alcuna sintassi aggiuntiva.

Ho trovato alcuni progetti che traspongono JS / TS per C o WebAssembly , ma questi sono solo unidirezionali: AFAIK non è possibile utilizzare comodamente i moduli compilati dal normale codice TS. Nel sistema che sto immaginando, si potrebbe semplicemente salvare una parte computazionalmente costosa del loro normale progetto NodeJS o Electron in un file con un'estensione di file distinta, diciamo .cts , e quindi import codice normalmente da questo file in qualsiasi altro File JS o TS. Sicuramente alcune funzionalità linguistiche dovrebbero essere limitate in .cts file, ma fare un'estensione dell'editor per avvertire di queste restrizioni non dovrebbe essere troppo difficile.

C'è qualche ostacolo tecnico qui che non vedo?

performance compiler

posta Waiski 08.07.2018 - 10:30

fonte

1 risposta

Leggi altre domande sui tag performance compiler

Annotazione per definire i valori per l'argomento del metodo Quali sono le buone strategie da utilizzare per apprendere il funzionamento di sistemi più grandi? [duplicare]

score 1 · Accepted Answer

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.

Si noti che Python 3+ fa ha annotazioni di tipo. Credo che la ragione per cui Cython non usa quella sintassi è che è pre-scaduta con Python 3. Potrebbe comunque essere cambiato, ma non sarebbe di grande aiuto, come spiegherò più avanti.

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

Sì.

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

Come ho spiegato sopra, Python ha anche la sintassi per le annotazioni sul tipo.

Tuttavia, Cython distingue tra codice Python e codice "C", tra tipi Python e tipi "C". In altre parole, Cython è un'unione di due sottoclassi separate che condividono una sintassi comune: un linguaggio per scrivere Python e una lingua Python- syntax -influenced per scrivere C- portatile di alto livello < strong> semantica .

Avresti ancora bisogno di quelle due sottoclaste in Cypescript.

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

No. Qualcuno deve solo farlo.

Si noti tuttavia che esiste un ostacolo sociale: CPython genera estensioni CPython. Generalmente non funzionerebbe o almeno non così bene per gli utenti che usano PyPy, IronPython, Jython, Pyston, Pynie o qualsiasi altra implementazione Python. Tuttavia, di solito è possibile convincere un utente a utilizzare un'implementazione specifica, in più, la maggior parte sta comunque utilizzando CPython.

Lo stesso non è vero per Typescript / ECMAScript. Non esiste una singola implementazione ECMAScript che domina il mercato come CPython, e di solito gli utenti non ricevono una scelta della loro implementazione. Se sto usando Edge, sono bloccato con Chakra, se sto usando Firefox, sono bloccato con SpiderMonkey, se sto usando Safari, sono bloccato con Nitro. Quindi, quale di questi sarebbe Cypescript generare estensioni per?

Personalmente, non compro questo approccio. Se CPython è troppo lento con Python, la soluzione non è quella di rendere più semplice scrivere codice C, la soluzione è rendere CPython più veloce, quindi non è necessario.

Gli sviluppatori di CPython ignorano molte ricerche sulla costruzione di implementazioni linguistiche dinamiche ad alte prestazioni raccolte negli ultimi 60 anni, a volte con buone ragioni, a volte senza, a volte semplicemente a causa della mancanza di risorse. (Confrontare il numero di sviluppatori Oracle JDK o IBM J9 con il numero di sviluppatori CPython, per esempio.)

Oracle HotSpot JVM è basato su Animorphic Smalltalk VM (proprio come V8, BTW), Azul Zing è basato su HotSpot, IBM J9 è basato su IBM Smalltalk VM e nessuno di loro fa veramente molto uso del tipo statico le informazioni nel bytecode, la maggior parte delle loro ottimizzazioni sono dinamiche. C'è un piccolo motivo tecnico per cui un motore di esecuzione Python o ECMAScript non deve essere almeno performante come HotSpot, Zing o J9.