Здравствуйте, ·, Вы писали:

P>>Ага, ты про это. Собственно, я уже забыл что там в том треде. Может и ошибся.
·>Ок. Хорошо, но уже лучше. Продолжаем. Ты этот ошибочный аргумент использовал для доказательства "та самая дырка есть почти что во всех мейнстримных языках, а в Си/Си++ это вообще норма жизни.". К C это не применимо, там вообще типов нет таких.

У тебя здесь логическая ошибка — к Си это применимо еще ширше, т.к. там полноценных типов нет и нормой является использование указателей, которые фактически int. В динамических языках весь язык состоит позволяет такие дыры.

·>Может тебе, привычному к динамике, это и не помеха, но когда заявляют static typing язык, то это уже неприемлимо. Суть в том, что ты перестаёшь доверять коду — написано одно, а там совершенно неожиданно совсем другое, т.к. где-то совсем в другом месте что-то не так сделали.

Ты продолжаешь рассматривать статическую типизацию как способ анального огораживания, как в джаве. При этом всё, что ты накопал, это проблема с одной единственной фичей
Похоже, ты делаешь из мухи слона.

P>>На самом деле сама структурная типизация вещь вообще призрачная, т.к. Forum можно легко присвоить в Item, если у них структура совместимая.
·>Так ведь проблема в том, что в ts оказывается Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая, а вылезет проблема совсем в другом месте.

Проверяем твоё утверждение. Присвоим {name: string} в {name: 'something'} и видим, что твоё утверждение невалидно. То есть, проблема всё еще в одной единственной фиче, как будто это какая то обязательная вещь. На самом деле тебе религия мешает найти тикет в гитхабе и увидеть что спроса на эту фичу нет.

P>>Рефлексия дешовая.
·>Погоди, в сабже есть рефлексия?.. Или ты имеешь в виду node javascript?

А как ты думаешь сериализатор работает? Нужно перебрать свойства рефлексией, получить значения той же рефлексией. Понасоздавать всякие временные и промежуточные объекты, самому склеивать строчки, делать кучу приседаний для конверсии и тд, т.к. платформа ничего другого не умеет. В жээсе всё делается легче и проще.
Не все вычисления такие эффективные, т.к. в жээсе хуже локальность, т.е. вместо кеша и регистров будем чаще работать с памятью. Но и в джаве есть похожая проблема — если джит компактификацию не сделает, получишь почти то же.

·>Впрочем, в java рефлексия не такая уж медленная, а ещё и MethodHandle есть. Скорее всего odata-либы в java на перформанс не особо заморачивались. Неясно зачем в такой области вообще о перформансе беспокоиться, всё равно json большую часть времени сожрёт.

Во первых, медленная. Во вторых, если ты к 10мс добавишь еще 10мс, то платить за железо тебе придется вдвое бОльше.

P>>Мне не сильно понятно, начорта там воркертреды
·>Ну ты сам эти бенчмарки притащил. И сказал, что хорошие бенчмарки, и выводов из них понаделал.

Я всего то отсортировал и показал, что именно в этих бенчмарках.

·>заметь вот это: тут ворктредов нет, и оно вообще жуть тормозит по всем параметрам.

Вообще то я сам сказал, что здесь жээс отстает где то в 5 раз. Что нового ты добавил? Я вот могу добавить — в данном примере, по твоей ссылке, ошибка — замер интерпретатора, а не джита.

Далее, цитирую себя:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html

Java быстрее
fannkuch-redux — менее 10%
n-body — менее 25%
pi-digits — около 50%
fasta — 50%
reverse-complement — около 50%

mandelbrot — ноздря в ноздрю

Node быстрее
spectral-norm — менее 10% <- похоже, ошибка на сайте, джава обгоняет на 10%
regex-redux — в три раза

Многопоточный код, джава выруливает
k-nucleotide — почти в трое
binary-trees — где то в 5 раз

Итого — в большинстве случаев джава имеет сравнимый перформанс с жээсом, кроме тех случаев, где многопоточность.

Здравствуйте, ·, Вы писали:

P>>Ага, ты про это. Собственно, я уже забыл что там в том треде. Может и ошибся.
·>Ок. Хорошо, но уже лучше. Продолжаем. Ты этот ошибочный аргумент использовал для доказательства "та самая дырка есть почти что во всех мейнстримных языках, а в Си/Си++ это вообще норма жизни.". К C это не применимо, там вообще типов нет таких.

У тебя здесь логическая ошибка — к Си это применимо еще ширше, т.к. там полноценных типов нет и нормой является использование указателей, которые фактически int. В динамических языках весь язык состоит позволяет такие дыры.

·>Может тебе, привычному к динамике, это и не помеха, но когда заявляют static typing язык, то это уже неприемлимо. Суть в том, что ты перестаёшь доверять коду — написано одно, а там совершенно неожиданно совсем другое, т.к. где-то совсем в другом месте что-то не так сделали.

Ты продолжаешь рассматривать статическую типизацию как способ анального огораживания, как в джаве. При этом всё, что ты накопал, это проблема с одной единственной фичей
Похоже, ты делаешь из мухи слона.

P>>На самом деле сама структурная типизация вещь вообще призрачная, т.к. Forum можно легко присвоить в Item, если у них структура совместимая.
·>Так ведь проблема в том, что в ts оказывается Forum можно легко присвоить в Item, даже если у них структура совсем не совместимая, а вылезет проблема совсем в другом месте.

Проверяем твоё утверждение. Присвоим {name: string} в {name: 'something'} и видим, что твоё утверждение невалидно. То есть, проблема всё еще в одной единственной фиче, как будто это какая то обязательная вещь. На самом деле тебе религия мешает найти тикет в гитхабе и увидеть что спроса на эту фичу нет.

P>>Рефлексия дешовая.
·>Погоди, в сабже есть рефлексия?.. Или ты имеешь в виду node javascript?

А как ты думаешь сериализатор работает? Нужно перебрать свойства рефлексией, получить значения той же рефлексией. Понасоздавать всякие временные и промежуточные объекты, самому склеивать строчки, делать кучу приседаний для конверсии и тд, т.к. платформа ничего другого не умеет. В жээсе всё делается легче и проще.
Не все вычисления такие эффективные, т.к. в жээсе хуже локальность, т.е. вместо кеша и регистров будем чаще работать с памятью. Но и в джаве есть похожая проблема — если джит компактификацию не сделает, получишь почти то же.

·>Впрочем, в java рефлексия не такая уж медленная, а ещё и MethodHandle есть. Скорее всего odata-либы в java на перформанс не особо заморачивались. Неясно зачем в такой области вообще о перформансе беспокоиться, всё равно json большую часть времени сожрёт.

Во первых, медленная. Во вторых, если ты к 10мс добавишь еще 10мс, то платить за железо тебе придется вдвое бОльше.

P>>Мне не сильно понятно, начорта там воркертреды
·>Ну ты сам эти бенчмарки притащил. И сказал, что хорошие бенчмарки, и выводов из них понаделал.

Я всего то отсортировал и показал, что именно в этих бенчмарках.

·>заметь вот это: тут ворктредов нет, и оно вообще жуть тормозит по всем параметрам.

Вообще то я сам сказал, что здесь жээс отстает где то в 5 раз. Что нового ты добавил? Я вот могу добавить — в данном примере, по твоей ссылке, ошибка — замер интерпретатора, а не джита. Может не совсем корректно, но код деоптимизируется, что видно если указать флаг --trace-deopt. Т.е. мы сравниваем деоптимизированый вариант жээс с оптимизированым джава.

Далее, цитирую себя:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html

Java быстрее
fannkuch-redux — менее 10%
n-body — менее 25%
pi-digits — около 50%
fasta — 50%
reverse-complement — около 50%

mandelbrot — ноздря в ноздрю

Node быстрее
spectral-norm — менее 10% <- похоже, ошибка на сайте, джава обгоняет на 10%
regex-redux — в три раза

Многопоточный код, джава выруливает
k-nucleotide — почти в трое
binary-trees — где то в 5 раз <- если речь про максимально быстрый вариант, то писать нужно несколько иначе

Итого — в большинстве случаев джава имеет сравнимый перформанс с жээсом, кроме тех случаев, где многопоточность.