Здравствуйте, Артём, Вы писали:
DM>>Их ответ простой — на ноде хрен сделаешь shared memory многопоточность. А на Го они поназапускали горутин, работающих с одними и теми же данными, и все в 10 раз ускорилось.
Аё>https://www.npmjs.com/package/node-worker-threads-pool — многопоточность в ноде.
Там шарить можно лишь примитивные массивы чисел. Обычные объекты, массивы и строки, которые и нужны компилятору, — фиг, надо туда-сюда сериализировать, будут одни тормоза вместо выигрыша.
Pzz>>Выглядит, как недо-JS...
M>Возможно. Только он весьма просто интегрируется в плюсовый или сишный проект, не уверен, что это легко можно сделать с JS
Здравствуйте, amironov79, Вы писали:
S>>Одно дело v8, другое компилятор на ts, т.е. tsc. A>Так tsc в итоге на node и работает. Тоже не понимаю, в чем отличие.
Каким образом он работает, он же вроде транслилирует в js, который в свою очередь выполняется node.js. Разве нет?
Похоже, что я напутал и это 2 независимых процесса. Пока, увы, с ts не сталкивался.
Здравствуйте, amironov79, Вы писали:
S>>он же вроде транслилирует в js, который в свою очередь выполняется node.js. Разве нет? A>Ну, если tsc написан на ts, значит его это тоже касается.
Ну тогда вернемся к исходному вопросу про отличие:
S>Одно дело v8, другое компилятор на ts, т.е. tsc.
A>Так tsc в итоге на node и работает. Тоже не понимаю, в чем отличие.
С одной стороны есть runtime\интерпретатр, который оптимизирован (v8), и есть программа, которую он
выполняет (tsc), которая не слишком оптимизирована. Короче, интерпретатор -- хороший, программа -- плохая.
Здравствуйте, Sharov, Вы писали:
S>С одной стороны есть runtime\интерпретатр, который оптимизирован (v8), и есть программа, которую он S>выполняет (tsc), которая не слишком оптимизирована. Короче, интерпретатор -- хороший, программа -- плохая.
То есть ты считаешь, что tsc плохо написан, поэтому медленно и работает? Тогда почему перенос tsc на go практически один в один увеличивает скорость работы на порядок?
Здравствуйте, Sharov, Вы писали:
S>С одной стороны есть runtime\интерпретатр, который оптимизирован (v8), и есть программа, которую он S>выполняет (tsc), которая не слишком оптимизирована. Короче, интерпретатор -- хороший, программа -- плохая.
Хейлсберг говорит, что сперва программу как могли оптимизировали, в профайлере уже не видно было ничего особенного, просто равномерные тормоза по всей площади. Потому тут именно интерпретатор плохой, и в первую очередь своей однопоточностью. Почти дословный перевод на другой язык+рантайм с задействованием параллелизма дал 10х ускорение.
Здравствуйте, amironov79, Вы писали:
S>>С одной стороны есть runtime\интерпретатр, который оптимизирован (v8), и есть программа, которую он S>>выполняет (tsc), которая не слишком оптимизирована. Короче, интерпретатор -- хороший, программа -- плохая. A>То есть ты считаешь, что tsc плохо написан, поэтому медленно и работает? Тогда почему перенос tsc на go практически один в один увеличивает скорость работы на порядок?
Ну значит я не прав. Для подобного рода задач v8 не годится.
R>Вы же в курсе, что Хейлсбрег переписал компилятор TypeScript (с TypeScript) на GO? Вот. Вопрос: почему не на C#? Ответ немного очевиден: с шарпом и дотнетом что-то не так, раз их папа предпочел изделие конкурента, а не догфудинг. Вощем, кирдык скоро вашей америке дотнетине
Ответ немного очевиден: с C# как раз всё так; он зрел, самодостаточен, бодр и здоров; соответственно целебный прикладываемый подорожник-Typescript, выращенный папой-Хейлсбергом сначала для исцеления JS, а потом и для Go, оба из которых (а) имеют явные проблемы с типизацией, и (б) были созданы не Хейлсбергом, для C# и нахой не нужон, ибо у C# (в) этих проблем нет, и (г) он создан Хейлсбергом.
Здравствуйте, zx zpectrum, Вы писали:
z> соответственно целебный прикладываемый подорожник-Typescript, выращенный папой-Хейлсбергом сначала для исцеления JS, а потом и для Go, оба из которых (а) имеют явные проблемы с типизацией, и (б) были созданы не Хейлсбергом, для C# и нахой не нужон, ибо у C# (в) этих проблем нет, и (г) он создан Хейлсбергом.
Можно как-то мысль развернуть? А то не совсем понятно, какую дырку голанга этим подорожником залепили
Здравствуйте, rudzuk, Вы писали:
R>Вы же в курсе, что Хейлсбрег переписал компилятор TypeScript (с TypeScript) на GO? Вот. Вопрос: почему не на C#? Ответ немного очевиден: с шарпом и дотнетом что-то не так, раз их папа предпочел изделие конкурента, а не догфудинг. Вощем, кирдык скоро вашей америке дотнетине
Я, кстати, подумав вообще не могу понять, в чём ценность этой деятельности. Может, мы что-то неправильно просто понимаем?
Комлилятор TS — это транспиллер из TS в JS, сам написанный на TS. JS вроде, в современном JIT-овском исполнении не такая уж и медленная штука. По некоторым слухам сравнимая с Go (который пройгрывает голому Си раза в два).
Т.е., казалось бы, если проблема в том, что TS недостаточно быстрый, то ее можно было бы решить, улучшив в нём кодогенерацию. Или даже сделав кодогенерацию в нативный код процессора (возможно, через какой-то промежуточный язык, который в конечном итоге умеет сносно компилироваться в нативный код).
От этого и сам компилятор бы ускорился, и прочие проекты, написанные на TS
Здравствуйте, Pzz, Вы писали:
Pzz> Я, кстати, подумав вообще не могу понять, в чём ценность этой деятельности. Может, мы что-то неправильно просто понимаем?
