1. В FF 3.1 будет динамический транслятор для JavaScript. Они его называют Tracing JIT. Принцип работы как и в HotSpot — нахождение и оптимизация критических кусков кода. На разных тестовых наборах ускорение от 2х до 22х раз.

2. Гугль таки делает свой браузер на основе WebKit — Google Chrome. Броузер будет включать в себя новую ВМ для JavaScript под названием V8 (немецкая разработка). Одна из причин его создания — малая приспособленность современных броузеров к исполнению web-приложений. На самом гугле о броузере есть комиксы. И нашлись не ленивые люди, сделавшие перевод комиксов на русский.

ЗЫ. Похоже, что IE8 — ничем интересным порадовать не сможет

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>(немецкая разработка).
Блин. Не из немеции, а из Дании. Простите. О V8 подробнее со слайда 13.

ANS>ЗЫ. Похоже, что IE8 — ничем интересным порадовать не сможет

Что не удивительно, учитывая, что МС с Интернетом постоянно "провтыкивала" момент

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>ЗЫ. Похоже, что IE8 — ничем интересным порадовать не сможет

ANS>Что не удивительно, учитывая, что МС с Интернетом постоянно "провтыкивала" момент

У МС для веб-приложений есть Silverlight. А подковывать в очередной раз хромую кобылу ...

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

AVK>У МС для веб-приложений есть Silverlight. А подковывать в очередной раз хромую кобылу ...

Имхо это они мимо тазика. Как и java-applets в своё время. Выход IE9 покажет

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

AVK>>У МС для веб-приложений есть Silverlight. А подковывать в очередной раз хромую кобылу ...

ANS>Имхо это они мимо тазика. Как и java-applets в своё время. Выход IE9 покажет

Аргументы за хромую кобылу в студию!

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>2. Гугль таки делает свой браузер на основе WebKit

Неверно.

Дословно: "используются элементы WebKit и FireFox"

We've used components from Apple's WebKit and Mozilla's Firefox, among others

http://googleblog.blogspot.com/2008/09/fresh-take-on-browser.html

ANS>1. В FF 3.1 будет динамический транслятор для JavaScript. Они его называют Tracing JIT. Принцип работы как и в HotSpot — нахождение и оптимизация критических кусков кода. На разных тестовых наборах ускорение от 2х до 22х раз.

JIT для typeless языков это технический non-sense.

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

CS>JIT для typeless языков это технический non-sense.

Во-первых, JavaScript — это не typeless язык, а динамически типизированный язык со слабой типизацией.
Во-вторых, взгляни на IronPython (который работает на .NET и, соответственно, использует дотнетовский JIT)

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

N>Во-вторых, взгляни на IronPython (который работает на .NET и, соответственно, использует дотнетовский JIT)

А там что, с прошлого года существенные изменения, или все как в старые добрые времена?

Автор: Klapaucius
Дата: 09.06.07

Потому, что JIT для скрипта и интерпретатор скрипта, код которого (интерпретатора) джитится это не одно и то же, n'est pas?

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

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

CS>>JIT для typeless языков это технический non-sense.

N>Во-первых, JavaScript — это не typeless язык, а динамически типизированный язык со слабой типизацией.

Если ты не можешь сказать "вот этот slot содержит только значения типа int" то
этот slot (variable) есть просто именованная typeless переменная. Нет там никакой ни сильной ни слабой типизации.
Это если гворить с математической строгостью.

N>Во-вторых, взгляни на IronPython (который работает на .NET и, соответственно, использует дотнетовский JIT)

А это причем здесь? Да, можно саму VM написать на managed языке и потом этот код отJITить, но к JIT самого bytecode это имеет почти никакое отношение.

JS это клеевой язык. Основное назначение: связка высокоэффектвных native функций между собой.
Писать на нем, скажем, попиксельную обработку изображний — себя не любить.
Правильно это делать примерно так: Image.brightness(0.7) но не так:

for(var px in Image.pixels)
{
  px.red *= 0.7;
  px.green *= 0.7;
  px.blue *= 0.7;
}

Ибо кроме JIT такая операция еще и GC нагружает по самое нихочу.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>2. Гугль таки делает свой браузер на основе WebKit — Google Chrome. Броузер будет включать в себя новую ВМ для JavaScript под названием V8 (немецкая разработка). Одна из причин его создания — малая приспособленность современных броузеров к исполнению web-приложений. На самом гугле о броузере есть комиксы. И нашлись не ленивые люди, сделавшие перевод комиксов на русский.

Хмм.. Ещё Firebug к нему, версию под Linux и, похоже, будет отличный браузер.

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

P.S. Posted by Google Chrome (:

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

CS>Если ты не можешь сказать "вот этот slot содержит только значения типа int" то
CS>этот slot (variable) есть просто именованная typeless переменная.
А какие проблемы так сказать?
Как только мы кладем в этот слот что-то не инт, мы просто обсолетим проджиттенный код. Делов-то.

CS>Нет там никакой ни сильной ни слабой типизации.

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

[cut]

WF>По крайней мере, для меня в нём куча полезных фич. Быстрый JS, большая независимость между табами..

А можно пояснить выделенное — это как?

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

WF>>По крайней мере, для меня в нём куча полезных фич. Быстрый JS, большая независимость между табами..

К>А можно пояснить выделенное — это как?

Падение одного таба в FF приводит к падению всего браузера.

Утечки памяти в одном табе и фрагментация памяти из-за них распространяется на все табы (надо перезапускать браузер при продолжительной работе с JS-приложениями).

Тормоза JS в одном табе подвешивают весь браузер.

Это то, что для меня наиболее критично.

WF>>По крайней мере, для меня в нём куча полезных фич. Быстрый JS, большая независимость между табами..

К>А можно пояснить выделенное — это как?

http://www.rsdn.ru/forum/message/3086930.1.aspx

Автор: Mamut
Дата: 02.09.08

— каждая закладка будет этаким отдельным браузером. Если что-то сломается, то упавшая закладка не повлечет за собой паение всего браузера

— браузер будет включать в себя Chrome Process Browser, который сможет указать, что именно тормозит/потребляет слишком много ресурсов и позволт это убить

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

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

CS>>Если ты не можешь сказать "вот этот slot содержит только значения типа int" то
CS>>этот slot (variable) есть просто именованная typeless переменная.
S>А какие проблемы так сказать?
S>Как только мы кладем в этот слот что-то не инт, мы просто обсолетим проджиттенный код. Делов-то.

Я тогда не понял что ты считаешь JITом.
Я так понимаю что в твоей интерпретации JIT это нечто наделенное супер-интеллектом.

Допустим есть такой код:

for( var i = 0; i < 10; ++i )
  count += 1;

Где count это global value.

Ты в принципе можешь отJITить вот это (var i = 0; i < 10; ++i) ибо здесь локальная переменная — может быть представлена как int в процессоре.
Но для count += 1 тебе уже этого сделать нельзя так как variable storage не может быть приведен к типу int
по определению самого языка. Т.е. результат твоего jit это будет в общем случае последоватльность
неких нативных function calls что в общем случае не сильно эффективне чем интерпретация байткода.

Т.е. на тестовых задачах ты в принципе можешь получить выигрыш но в реальном Web code... сильно сомневаюсь в стоимости выделки той овчинки.
В JS оптимизация должна быть не в байткода а именно runtime — состава и качества нативных функций.
Самая лучшая оптимизация это делать так чтобы меньше этого самого байткода писать и исполнять надо было.

В качестве примера: работа со строками в стиле генерации html source.
Я ввел понятие stream в JS:

var st = Stream.openString(); // in-memory stream.
st << "Something" << "anything"; // stream output.

Stream это высоко-эффективный StringBuilder если хочешь. В процессе работы он не использует GC heap.
Значит не нужно лишних GC cycles — одно это уже перебьет все что ты выиграешь на JIT.

Примерно так.

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

CS>Я тогда не понял что ты считаешь JITом.
CS>Я так понимаю что в твоей интерпретации JIT это нечто наделенное супер-интеллектом.

Ну, я ж не зря написал, что исходная идея как в HotSpot. А HotSpot ноги растут из динамического транслятора для Self. (Его переделали с начала под Smalltalk потом под Java). Напомню, что JavaScript прототипный как и Self.

Основная идея — до 90% call sites мономорфны

Автор: Andrei N.Sobchuck
Дата: 13.06.06

. Это значит что можно соптимизировать код исходя из известных типов параметров (информация о типах накапливается во время выполнения) и деоптимизировать если приходит "плохой" тип.

Судя по Комиксу у V8 неонка послабее. Выглядит будто они взяли интерпритатор ST и сделали компилятор из JavaScript в байткоды.

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

ANS>>Имхо это они мимо тазика. Как и java-applets в своё время. Выход IE9 покажет

__S>Аргументы за хромую кобылу в студию!

Жизнь так развивается. В общем, ждём в ближайшее время объявления, что IE8.1 или IE8 будет поддерживать крутезный JavaScript сделанный на основе .Net.

CS>Ты в принципе можешь отJITить вот это (var i = 0; i < 10; ++i) ибо здесь локальная переменная — может быть представлена как int в процессоре.
CS>Но для count += 1 тебе уже этого сделать нельзя так как variable storage не может быть приведен к типу int
CS>по определению самого языка. Т.е. результат твоего jit это будет в общем случае последоватльность
CS>неких нативных function calls что в общем случае не сильно эффективне чем интерпретация байткода.

В описании того же Trace Monkey написано, что они вычисляют типы переменных, а потом скармливают это JIT'у. То есть код/AST(?), скармливаемый JIT'у типизирован настолько, насколько это возможно

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

CS>Я тогда не понял что ты считаешь JITом.
CS>Я так понимаю что в твоей интерпретации JIT это нечто наделенное супер-интеллектом.
Нет, тупая штука с умениями выполнять спекулятивную оптимизацию.

CS>Ты в принципе можешь отJITить вот это (var i = 0; i < 10; ++i) ибо здесь локальная переменная — может быть представлена как int в процессоре.
CS>Но для count += 1 тебе уже этого сделать нельзя так как variable storage не может быть приведен к типу int
CS>по определению самого языка.
Ну почему же не может. Это же не global storage, это window.count.
Теперь такая штука возникает: мы выполняем спекулятивную оптимизацию, так что window.count+=1 превращается в
(window->knownVariables.count)+=1.
Этот байткод джиттится в натив, который по перформансу очень близок к, грубо говоря, С++ аналогу.
Как только кто-то присваивает в window.count не-инт, мы обсолетим сгенерированный код и откатываемся к старой байткодной версии, в которой было setMember(window, "count", getMemberAsInt(window, "count")+1).
Но фишка в том, что в корректно написанном веб-приложении такое бывает очень редко. Какой-нибудь behavior анимированной подсветки текущей строки в таблице выполняется сотни тысяч раз за время жизни экземпляра приложения, и при этом все типы всех объектов остаются теми же самыми.

CS>В качестве примера: работа со строками в стиле генерации html source.
CS>Я ввел понятие stream в JS:

CS>var st = Stream.openString(); // in-memory stream.
CS>st << "Something" << "anything"; // stream output.

CS>Stream это высоко-эффективный StringBuilder если хочешь. В процессе работы он не использует GC heap.
CS>Значит не нужно лишних GC cycles — одно это уже перебьет все что ты выиграешь на JIT.
Ну, я не настолько хорошо знаю движки, чтобы аргументированно рассуждать на тему GC vs JIT. Но пока что мне непонятно, почему нельзя применить приемы, хорошо зарекомендовавшие себя для статических языков, к языкам динамическим.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

ANS>>>Имхо это они мимо тазика. Как и java-applets в своё время. Выход IE9 покажет
__S>>Аргументы за хромую кобылу в студию!
ANS>Жизнь так развивается. В общем, ждём в ближайшее время объявления, что IE8.1 или IE8 будет поддерживать крутезный JavaScript сделанный на основе .Net.

Про жизнь мощно задвинуто. Но вопрос остается в силе — зачем мне javascript после релиза Silverlight? Всю клиентскую логику после этого можно реализовывать на C#, сохраняя кросс-вызовы со старыми js-функциями — дабы не пришлось переписывать все с нуля.
Это настолько же мощный ход, как выход .Net на десктопах/серверах, когда была сделана удобная поддержка вызовов C++ кода. Только в случае Silverlight все еще проще.