Здравствуйте, VladD2, Вы писали:
VD>А вот зачем он на сервере?
Сейчас есть очень быстрые интерпретаторы JS.
Вот недавно запустили эмуляцию Linux, прямо в браузере.
Потом, разве Nemerle не показывает нам, что и без большого количества аннотаций типов может получаться быстрый статически типизированный код?
Вот и интерпретаторы JS так поступают. Выводят типы, применяют всякие эвристики для ускорения.
01.06.11 19:56: Перенесено модератором из 'Nemerle' — VladD2
Здравствуйте, Аноним, Вы писали:
А>Потом, разве Nemerle не показывает нам, что и без большого количества аннотаций типов может получаться быстрый статически типизированный код? А>Вот и интерпретаторы JS так поступают. Выводят типы, применяют всякие эвристики для ускорения.
Все эти эвристики это здорово, они помогают оптимизировать. Только вот контроля, который дает компиляция не дают Приходится либо забить на этот контроль либо писать дикое количество тестов, которые делает компилятор при компиляции статически типизированного языка.
Здравствуйте, Аноним, Вы писали:
VD>>А вот зачем он на сервере? А>Сейчас есть очень быстрые интерпретаторы JS. А>Вот недавно запустили эмуляцию Linux, прямо в браузере.
Шутку понял. Смешно!
А>Потом, разве Nemerle не показывает нам, что и без большого количества аннотаций типов может получаться быстрый статически типизированный код? А>Вот и интерпретаторы JS так поступают. Выводят типы, применяют всякие эвристики для ускорения.
Надеюсь ты это не всерьез говоришь. Потому что если это сказано всерьез — это клинический случай некомпетентности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Скорость JavaScript
От:
Аноним
Дата:
01.06.11 14:06
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Аноним, Вы писали:
VD>>>А вот зачем он на сервере? А>>Сейчас есть очень быстрые интерпретаторы JS. А>>Вот недавно запустили эмуляцию Linux, прямо в браузере.
VD>Шутку понял. Смешно!
А>>Потом, разве Nemerle не показывает нам, что и без большого количества аннотаций типов может получаться быстрый статически типизированный код? А>>Вот и интерпретаторы JS так поступают. Выводят типы, применяют всякие эвристики для ускорения.
VD>Надеюсь ты это не всерьез говоришь. Потому что если это сказано всерьез — это клинический случай некомпетентности.
Другой аноним. Скорость джаваскрип составляет в среднем 80% от С++(-О2) если не пользоваться аналогами "вычислить"
Здравствуйте, Аноним, Вы писали:
А>Другой аноним. Скорость джаваскрип составляет в среднем 80% от С++(-О2) если не пользоваться аналогами "вычислить"
Орлы вы несете несусветную чушь. Даже Java в Хотспотом не дает 80% производительности хороших С++-компиляторов. А жабаскрипт просто по архитектуре не может тягаться с компилируемыми языками. В лучшем случае вы получите ускорение отдельных операций (которые сводятся к статически-типизируемым). Как только вы начнете использовать ООП или ФП вы тот час же получите 5 и более раз проигрыша. В среднем более 10.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Скорость JavaScript
От:
Аноним
Дата:
01.06.11 15:07
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Шутку понял. Смешно!
Над собой смеетсеь. (c)
VD>Надеюсь ты это не всерьез говоришь. Потому что если это сказано всерьез — это клинический случай некомпетентности.
Абсолютно серьезно. Пора уже выйти из сумрака и осознать, что на JS вполне себе пишут серверные приложения достаточно критичные к скорости.
Здравствуйте, VladD2, Вы писали:
VD>Даже Java в Хотспотом
Классическая, если не сказать, Epic, ошибка.
Надеюсь вы понимаете, что Java и JavaScript совершенно разные технологии.
VD>А жабаскрипт просто по архитектуре не может тягаться с компилируемыми языками.
Это вопрос не архитектуры, а вложений в интерпретатор-компилятор.
Условный Nemerle может быть сколь угодно хорош по архитектуре, но если его развивают три человека за бесплатно, суперпроизводительности он демонстрировать не будет. А если в разработку JS вкладываются миллионы от гугла, MS, Apple, то даже будь он безногий инвалид от рождения, с такой поддержкой он начнёт ставить рекорды.
Re[2]: Скорость JavaScript
От:
Аноним
Дата:
01.06.11 15:23
Оценка:
Здравствуйте, Ziaw, Вы писали:
Z>Все эти эвристики это здорово, они помогают оптимизировать. Только вот контроля, который дает компиляция не дают Приходится либо забить на этот контроль либо писать дикое количество тестов, которые делает компилятор при компиляции статически типизированного языка.
Тесты пишутся абсолютно такие же, что и для статически типизированного языка
Здравствуйте, Аноним, Вы писали:
А>Абсолютно серьезно. Пора уже выйти из сумрака и осознать, что на JS вполне себе пишут серверные приложения достаточно критичные к скорости.
Так. Просьба к фанатам этого недоязыка покинуть палубу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, VladD2, Вы писали:
VD>>Даже Java в Хотспотом А>Классическая, если не сказать, Epic, ошибка. А>Надеюсь вы понимаете, что Java и JavaScript совершенно разные технологии.
Если бы ты внимательно читал, то понял бы, что именно это я и подчеркиваю. У Java есть хоть какие-то шанся тягаться с плюсамип. У жабаскрипта ни малейших.
VD>>А жабаскрипт просто по архитектуре не может тягаться с компилируемыми языками. А>Это вопрос не архитектуры, а вложений в интерпретатор-компилятор.
Это вопрос понимания в теме обсуждения. Если оно есть, то такие эпические глупости говорить не будешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
А>>Другой аноним. Скорость джаваскрип составляет в среднем 80% от С++(-О2) если не пользоваться аналогами "вычислить" VD>Орлы вы несете несусветную чушь. Даже Java в Хотспотом не дает 80% производительности хороших С++-компиляторов. А жабаскрипт просто по архитектуре не может тягаться с компилируемыми языками.
Хмм....
Здравствуйте, Cyberax, Вы писали:
C>http://bellard.org/jslinux/ — здесь на JavaScript эмулируется PC, в котором работает Линукс.
Ну, и что это доказывает? Я тебе командную строку и на PHP нарисую.
У меня 15 лет назад Линкус пахал на 486-ом проце который наверно раз 1000 медленнее чем мой современный процессор. Это куда более большая разница чем десятикратный проигрыш, который в среднем дают интерпретаторы.
C>https://developer.mozilla.org/en-US/demos/detail/doom-on-the-web/ — здесь на JS портирован оригинальный Doom.
Веб-страница недоступна
C>Так что пока рано говорить о том, что JS никогда не сможет тягаться с компилируемыми языками.
Надо быть вообще полным неучем чтобы не понимать этого. Любой скрип принципиально не может добиться скорости прямых вычислений.
Фокусы вроде компиляции скриптво дают только локальные результаты на частях кода которые могут быть статически типизированы (путем вывода типов).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, VladD2, Вы писали:
А>>>Другой аноним. Скорость джаваскрип составляет в среднем 80% от С++(-О2) если не пользоваться аналогами "вычислить" VD>>Орлы вы несете несусветную чушь. Даже Java в Хотспотом не дает 80% производительности хороших С++-компиляторов. А жабаскрипт просто по архитектуре не может тягаться с компилируемыми языками. C>Хмм....
C>http://bellard.org/jslinux/ — здесь на JavaScript эмулируется PC, в котором работает Линукс. https://developer.mozilla.org/en-US/demos/detail/doom-on-the-web/ — здесь на JS портирован оригинальный Doom.
гм, а что это поделка от мозилы захлопнула мне лиса без всяких предупреждений? кстати, оригинальный дум шел на очень слабом железе и сейчас его можно и на полном программном эмуляторе запустить, так что это ничего не доказывает.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, VladD2, Вы писали:
C>>http://bellard.org/jslinux/ — здесь на JavaScript эмулируется PC, в котором работает Линукс. VD>Ну, и что это доказывает? Я тебе командную строку и на PHP нарисую.
Это не командная строка. Это полноценный эмулятор PC — в нём Win3.11 можно даже запустить.
VD>У меня 15 лет назад Линкус пахал на 486-ом проце который наверно раз 1000 медленнее чем мой современный процессор. Это куда более большая разница чем десятикратный проигрыш, который в среднем дают интерпретаторы.
Трассирующие интерпретаторы пока ещё в самой молодости, но они уже сократили разрыв между интерпретаторами и компиляторами с сотен раз до десятков.
C>>Так что пока рано говорить о том, что JS никогда не сможет тягаться с компилируемыми языками. VD>Надо быть вообще полным неучем чтобы не понимать этого. Любой скрип принципиально не может добиться скорости прямых вычислений. VD>Фокусы вроде компиляции скриптво дают только локальные результаты на частях кода которые могут быть статически типизированы (путем вывода типов).
Трассирующие компиляторы позволяют не только динамически выводить типы, но ещё и перекомпилировать использующий их код при смене структуры типов.
Собственно, локальный вывод типов для JS вообще отстойно работает из-за того, что самый частый объект манипуляции — это узлы DOM.
VD>>>А вот зачем он на сервере? А>>Сейчас есть очень быстрые интерпретаторы JS. А>>Вот недавно запустили эмуляцию Linux, прямо в браузере. VD>Шутку понял. Смешно!
<КО>
Никаких шуток. Только не эмуляцию Linux, а собственно, Linux, на жаваскриптовом эмуляторе x86 железа. http://bellard.org/jslinux/ http://bellard.org/jslinux/tech.html
</КО>
Если уж совсем неверится — там есть простенький C компилятор — tcc — мона написать свою прогу и скомпилять и она даже будет работать. Есть и vi чтобы прогу написать и даже клипборд (/dev/clipboard) который представляет собой копию того что вкопипастено в окошко справа.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Cyberax, Вы писали:
C>Трассирующие компиляторы позволяют не только динамически выводить типы, но ещё и перекомпилировать использующий их код при смене структуры типов.
Чудес не бывает. Если что-то делается динамически, то мы за это платим временем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
C>>Трассирующие компиляторы позволяют не только динамически выводить типы, но ещё и перекомпилировать использующий их код при смене структуры типов. VD>Чудес не бывает. Если что-то делается динамически, то мы за это платим временем.
Бывают, бывают. Динамика лёгким движением руки превращается в статику с помощью трассирующих компиляторов. Конечно, будет некоторый оверхед — так как код таки сначала нужно протрассировать, но не такой уж огромный.
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, Аноним, Вы писали:
А>>Сейчас есть очень быстрые интерпретаторы JS.
_>JS быстрее C# _>Я серь-хи-хи-ёзно! :троллфейс:
Это ты сравнил mutable строку в C++ с immutable строкой в C#
Тем более со стороны C# там mono работает, над рантаймом которого работают не как над js и Microsoft .NET.
Здравствуйте, gandjustas, Вы писали:
G>Это ты сравнил mutable строку в C++ с immutable строкой в C#
стрингбилдер не умеет +=, не удобно
G>Тем более со стороны C# там mono работает, над рантаймом которого работают не как над js и Microsoft .NET.
Проблемы MS и .net
java медленнее http://ideone.com/evyrW результат: успешно время: 2.03s
js рулит.
Хотя по выделенной памяти заметно, что js оптимизирует(забивает на) освобождение памяти