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

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

S>>Как только мы кладем в этот слот что-то не инт, мы просто обсолетим проджиттенный код. Делов-то.

VD>Проблемы очевидные. Есть вывод типов и языки под него заточенные. В них можно добиться отсутсвия явной типизации и при этом наличие полной информации о типах. А есть скрипы которые конечно позволяют в некоторых местах вывести типы, но они не проектировались для этих целей и в результате не позволяют добиться серьезного повышения производительности и надежности. Это демонстрируют и PyPy для Питона, и ХотСпот для Смортока, и все потуги в области оптимизации ЯваСкрипта.

В принципе JavaScript2 (ActionScript/flash) добавил типизацию в JS.

Т.е. вот на это:

var i:int = 0;
i += 1;

действительно можно напустить JIT который будет эффективно работать т.е. a) быстро производить native code и b) быстро его исполнять.
Кстати пункт "a" не менее важен чем пункт "b" в свете наличия атрибутов onclick или onmouseenter в DOM.

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

Z>Здравствуйте, c-smile, Вы писали:
CS>>Не эквивалентны в том смысле что local t (LUA) в JS записывается следующим образом:
CS>> var t = {count:0};
CS>>т.е. ты тестировал на самом деле следующий вариант:
CS>>$global.t = {count:0};
CS>>что как ты понимаешь несколько иной компот.

Z>Это, наверное, моя опечатка:
Z>

Z>bash$ cat jit-test.tis
Z>// jit-test.tis -- TScript

Z>var t = {count:0};
Z>for(var i = 0; i < 10000000; ++i){
Z>   t.count += 1;
Z>}

Z>stdout.printf("%d\n",t.count)
Z>bash$ time tiscript jit-test.tis
Z>10000000

Z>real    0m7.177s
Z>user    0m0.031s
Z>sys    0m0.000s
Z>

Ты не понял. Вот это:

var t;

в JS в зависимости от контекста это либо global t в LUA либо local t.
То как ты объявил это дело это именно global t (т.е. slot в global table в терминах LUA)
А вот так:

{ var t; }

эта t будет уже local t для этого блока. Доступ к local variables в lua и tiscript должен быть примерно равнозначным +/- оптимизируещие опции С++ компилятора. Ибо доступ к local variables это фактически frame[varidx] где varidx это константа расчитываемая в момент компиляции.


CS>>Ну и по делу. Что-то мне говорит что даже если JIT на реальных задачах поднимет быстродействие в два раза то
CS>>пользователи этого не заметят. Я честно говоря не видел сайтов для которых JS это bottleneck.
CS>>Есть у кого примеры?
Z>Во первых, пока java-script, будет тормозом все будут избегать писать на нем что-то интересное, но прецеденты есть:
Z>http://www.flapjax-lang.org/
Z>Всякие большие библиотеки вроде script.aculo.us или Dojo Toolkit — наверняка.

Вот тесты более менее приближенные к реальности: http://v2.dromaeo.com/
Результаты не особенно впечатляют, сравнивал Chrome и FF3.
Где-то быстрее Chrome где-то FF3.
Например на операциях DOM Query типа getElementsByTagName FF3 впереди планеты всей.
А на операциях типа base64 encoding (в скрипте) Chrome в два раза быстрее.
Но в то же время на операциях работы с массивами (splice shift и пр.) FF3 в два раза быстрее.
Ну т.е. так на так выходит. Как я уже говорил — основная оптимизация в JS это не исполнение байткода самого а именно эффективность и состав native функций. Это то что работает most of the time.

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

VD>Здравствуйте, c-smile, Вы писали:

VD>Согласен со всем сказанным.

VD>На мой взгляд решение — это переход от разработки на скриптах обратно к идее аплетов создаваемых для ВМ вроде Явы или дотнета.

VD>МС вроде бы даже для этого сделал WPF, но что-то снова заколбасило в МС и вместо того чтобы сделать переносимую коммерческую машину дотнета для всех ведущих платформ их снова поперло к скриптам и копированию чужих идей (это я про Силверлайт и его прототип Флэш).

VD>Явщики революцию похоже вообще проспали...

Имею возможность наблюдать online приложение которое существует одновременно в двух ипостасях — как Java Applet и как Web2 приложение (ASP.NET + Ajax). Очень навороченное. Основная проблема в том что пользователи не хотят уходить с Java. Java Applet тактильно работает на порядок быстрее.
Ну собственно и не мудрено — UI доставляется один раз на клиента — потом только данные туда сюда ходят.

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

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

Z>>Здравствуйте, c-smile, Вы писали:
CS>>>Не эквивалентны в том смысле что local t (LUA) в JS записывается следующим образом:
CS>>> var t = {count:0};
CS>>>т.е. ты тестировал на самом деле следующий вариант:
CS>>>$global.t = {count:0};
CS>>>что как ты понимаешь несколько иной компот.

Z>>Это, наверное, моя опечатка:
Z>>

Z>>bash$ cat jit-test.tis
Z>>// jit-test.tis -- TScript

Z>>var t = {count:0};
Z>>for(var i = 0; i < 10000000; ++i){
Z>>   t.count += 1;
Z>>}

Z>>stdout.printf("%d\n",t.count)
Z>>bash$ time tiscript jit-test.tis
Z>>10000000

Z>>real    0m7.177s
Z>>user    0m0.031s
Z>>sys    0m0.000s
Z>>

CS>Ты не понял. Вот это:
CS>

CS>var t;
CS>

CS>в JS в зависимости от контекста это либо global t в LUA либо local t.
CS>То как ты объявил это дело это именно global t (т.е. slot в global table в терминах LUA)
CS>А вот так:
CS>

CS>{ var t; }
CS>

CS>эта t будет уже local t для этого блока. Доступ к local variables в lua и tiscript должен быть примерно равнозначным +/- оптимизируещие опции С++ компилятора. Ибо доступ к local variables это фактически frame[varidx] где varidx это константа расчитываемая в момент компиляции.

Как все сложно Теперь правильно? Минус 1.5 секунды — мне кажется непринципиально, разница все равно в разы.

bash$ cat jit-test.tis
// jit-test.tis -- TScript
{
    var t = {count:0};
    for(var i = 0; i < 10000000; ++i){
        t.count += 1;
    }

    stdout.printf("%d\n",t.count);
}

bash$ time tiscript jit-test.tis
10000000

real    [b]0m6.056s[]
user    0m0.015s
sys    0m0.031s
bash$

Хотел V8 протестировать — проклятый scons не хочет собирать.

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

CS>

CS>var i:int = 0;
CS>i += 1;
CS>

CS>действительно можно напустить JIT который будет эффективно работать т.е. a) быстро производить native code и b) быстро его исполнять.

На это можно напустить jit без всякой типизации и получить ускорение на порядок. Т.е в luajit код будет по скорости как Debug build C.

Здравствуйте, z00n, Вы писали:
Z>Хотел V8 протестировать — проклятый scons не хочет собирать.

Потестировал — очень быстро, между Neko и Luajit. Т.е. они не врут (я еше пару примеров посмотрел) — на вычислительных тестах V8 на порядок быстрее Spidermonkey, проимерно раз в 5-6 медленнее С.

Здравствуйте, VladD2, Вы писали:
VD>Скрипты используют идиомы вроде "ООП на безе прототипов" которые принципиальноне совместимы с компиляцией в нэйтив-код.

Есть такой малоизвестный язык Lisaac (http://en.wikipedia.org/wiki/Lisaac). Он prototype-based как Self, и при этом бескомпромиссно быстрый, как С.

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

Проверил под Windows

LUA:

local t = {count = 0}
for i=1,1E7 do
    t.count = t.count + 1
end
print(t.count)

TIScript:

{
  var t = {count:0};
  for(var i=0; i < 10000000; ++i)
    ++t.count;
  stdout.printf("%d\n",t.count);    
}

Время (меньше-лучше)

LUA : 1016 ms
TIScript : 2515 ms (TIScript собран с optimize for speed) и 2641(с optimize for size))

Что в общем-то ожидаемо.
TIScript поддерживает property (что есть функции описанные в классе). Это привносит некий overhead при get/set property.

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

Z>Здравствуйте, c-smile, Вы писали:

CS>>

CS>>var i:int = 0;
CS>>i += 1;
CS>>

CS>>действительно можно напустить JIT который будет эффективно работать т.е. a) быстро производить native code и b) быстро его исполнять.

Z>На это можно напустить jit без всякой типизации и получить ускорение на порядок. Т.е в luajit код будет по скорости как Debug build C.

Это можно отJITить tckb сохранять и анализировать traces.
C наличием информации о типах ты можешь построить статический jit по типу ngen.exe из .NET.
В этом случае у тебя вместо BYTECODE_ADD будет BYTECODE_ADDI, BYTECODE_ADDF и т.д. Т.е. нечто что напрямую отображается на машинные инструкции.
Т.е. оверхед самого JIT становится минимальным. А так, в контексте Web страницы ты фактически вносишь еще одну временную неопределенность (время разгона).

Здравствуйте, VladD2, Вы писали:
VD>Проблема только в том, что толку от HotSpot удалось добиться только в Яве. Хотя Смолтоковцы и кричат о крутости HotSpot-а для Смолтока, но кроме криков ничего серьезного предъявить не могут.
Ну почему — могут. Они добились впечатляющих результатов еще до того, как их позвали окучивать джаву.
Просто сейчас смолток настолько невостребован, что никакой хотспот его не спасает.

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

Z>Здравствуйте, VladD2, Вы писали:
VD>>Скрипты используют идиомы вроде "ООП на безе прототипов" которые принципиальноне совместимы с компиляцией в нэйтив-код.

Z>Есть такой малоизвестный язык Lisaac (http://en.wikipedia.org/wiki/Lisaac). Он prototype-based как Self, и при этом бескомпромиссно быстрый, как С.

Кросс компиляция одного языка в С это еще не значит что итоговая скорость имплементации некоего алгоритма будет быстрее чем то же самое на голом C.
Я с таким же успехом могу байткод сконвертирвать в C. Только это не великий смысл имеет. Архитектура объектов и памяти остается той же.

И вообще чем оно такое в принципе отличается от Objective-C http://en.wikipedia.org/wiki/Objective-C#Dynamic_typing ?

CS>это я к тому что все свою цену имеет.

CS>Сам знаешь что на некоторых тестах C# уделывает С++. Но в реалии чудес не быват.

Мне вот во всех этих Яваскриптовых JIT'ах интересна на самом деле оптимизация рекурсии. Будем писать все в функциональном стиле?

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

CS>>это я к тому что все свою цену имеет.

CS>>Сам знаешь что на некоторых тестах C# уделывает С++. Но в реалии чудес не быват.

M>Мне вот во всех этих Яваскриптовых JIT'ах интересна на самом деле оптимизация рекурсии. Будем писать все в функциональном стиле?

А зачем "все"?
Если есть проверенное императивное решение для задачи, то не обязательно его на ФП переписывать просто "ради идеи" по-моему

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

AVK>Это к вопросу о том, что Гугль сказал какое то новое слово в разработке веб-приложений при помощи Chrome. Тут одно из двух — либо он ничего нового, кроме улучшенной производительности, не предлагает, тогда ничего особенного и не произошло, либо там появляются какие то новые возможности, но это автоматом ограничивает приложения, которые их используют, исключительно хромом.

здесь есть мнение, что выиграть войну броузеров это совсем не цель для гугла, цитирую:

Its real goal, embedded in Chrome's open-source code, is to upgrade the capabilities of all browsers so that they can better
support (and eventually disappear behind) the applications.

чуствую, что мужик где-то недалек от истины добавляя в хром всякие обычные и необычные возможности для поддержки приложений (в первую очередь своих же), гугл неявно будет подстегивать разработчиков остальных браузеров более активно двигаться в том же направлении. В конце концов это может превратить браузер в что-то типа web os, причем некоторые конкуренты (не будем называть их громкие имена ), если не пошевелятся, рискуют сильно сдать позиции. А так в общем-то да, ничего особенного не произошло...

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

ANS>>Кстати, эта самая ВМ для St разрабатывалась фирмой Animorphic сейчас это Strongtalk.

VD>Объясни, плиз, окружающим что означает "Strong" в названии "Strongtalk". А потом поговорим дальше... если желание к тому времени не отпадет само собой.

Не знаю. А что обозначает слово "morphic" в "Animorphic"? Если ты намекаешь на статические типы, то связи между статической типизацией и ВМ там нет. Там есть опциональная валидация типов, которая не используется ни при трансляции в байткод, ни при трансляции байткода в машкоды. Т.е. проставляются аннотации типов, их непротиворечивость можно проверить, а можно и не проверять. Теоретически туда можно прикручивать разные системы типов.

Если интересует теория устройства ВМ, то там на сайте лежат:

* Optimizing Dynamically-Dispatched Calls with Run-Time Type Feedback Proceedings of ACM SIGPLAN `94: Describes the basic principles of type-feedback. This paper is for the Self system, not Strongtalk, but the basic technology is the same.

* Adaptive optimization for Self: Reconciling High Performance with Exploratory Programming Ph.D. thesis, Computer Science Department, Stanford University. This is even more detail on type-feedback for Self

* Optimizing Dynamically-Typed Object-Oriented Programming Languages with Polymorphic Inline Caches ECOOP '91 Conference Proceedings

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

CS>Есть у кого примеры?

Так потому и нет, что JS тормозит. А примеров будет больше.

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

G>добавляя в хром всякие обычные и необычные возможности для поддержки приложений (в первую очередь своих же), гугл неявно будет подстегивать разработчиков остальных браузеров более активно двигаться в том же направлении.
Даже более того, на одной из страниц коммикса очень подчеркивается что Хром -- опенсорс и если его фича понравится другим разработчикам браузеров они могут взять эту функциональность из Хрома.

Но я согласен с АндреемВК, что не нужно делать костыли хромой кобыле. HTML, CSS, Javascript должны умереть (никаких войн ).

СУВ, Aikin

Здравствуйте, c-smile, Вы писали:
CS>Кросс компиляция одного языка в С это еще не значит что итоговая скорость имплементации некоего алгоритма будет быстрее чем то же самое на голом C.
CS>Я с таким же успехом могу байткод сконвертирвать в C. Только это не великий смысл имеет. Архитектура объектов и памяти остается той же.
Я не понимаю, к чему вы про кросскомпиляцию, извините. Он по результатам тестов быстрый.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gcc&lang2=lisaac
На оф-сайте есть сравнение скорости Мпег-декодеров на нем и С.
CS>И вообще чем оно такое в принципе отличается от Objective-C http://en.wikipedia.org/wiki/Objective-C#Dynamic_typing ?
Как язык — очень отличается, например классов нет, очень 'чистый', как Smalltalk. Бумаги там затруднительно читать — очень много французского .

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

VD>МС вроде бы даже для этого сделал WPF

Нет. Упоминания Silverlight появились много позже упоминаний WPF (PDC 2003).

VD>, но что-то снова заколбасило в МС и вместо того чтобы сделать переносимую коммерческую машину дотнета для всех ведущих платформ их снова поперло к скриптам и копированию чужих идей (это я про Силверлайт и его прототип Флэш).

Silverlight 2.0 содержит внутри себя переносимый JIT-компилятор дотнета.

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

VD>Гугль пока что тоже ничем новым не порадовал. Его броузер, пока что — это просто новый ГУЙ для Мозилы 5.0

http://en.wikipedia.org/wiki/Webkit