Здравствуйте, Mamut, Вы писали:
M>Ты спашиваешь: объясните, а то в TP все просто M>Тебе дают ссылку на дизайн V8, где все показано даже картинками. M>Ты спрашиваешь (не глядя на картинку): объясните, а то в TP все просто M>Тебе отвечают, расписывая архитектуру браузера, пробелмы, возникающие при реализации всего этого дела и т.п. M>Ты спрашиваешь (не читая): объясните, а то в TP все просто M>Ну и т.п.
И т.п.
Понимаешь, все эти аргументы бледнеют перед одним простым фактом — компиляторы, которые работают в 1-2 Мб, сделать можно. Я не знаю , что они там в v8 сделали, и, честно говоря, мне это не слишком интересно. И разбираться в их исходниках, чтобы сказать, где там можно затраты памяти подскоратить, я не буду. Тем более, что, возможно, для этого нужен полный пересмотр всей архитектуры, а я не в силах такое сделать. Я вообще не специалист в построении компиляторов, а поэтому отнюдь не собираюсь ни анализировать существующие реализации, ни давать советы. Я просто констатирую факт — пока памяти было мало, они занимали эту малую память и работали с приличной скоростью. Значит, это можно сделать. Я бы понял, если бы речь шла о языке, на порядки более сложном. Но этого нет. Вот и все.
Что касается броузера и применимости js — см. мой сегодняшний ответ Владимиру.
Извини, но я действительно устал от этой дискуссии.
Здравствуйте, Pavel Dvorkin, Вы писали:
>Я не знаю , что они там в v8 сделали, и, честно говоря, мне это не слишком интересно. >Я бы понял, если бы речь шла о языке, на порядки более сложном. Но этого нет. Вот и все.
Задачи стали на порядки более сложными, а не языки.
О чем ведь и речь — нынче объектов в хипе JS больше, чем байтов в том же хипе Turbo Pascal.
На Турбо Паскале никогда не решались задачи такой же сложности.
И ты никак не хочешь, именно не хочешь, сунуть нос в картинки про JS V8 что бы понять, насколько сложная задача.
это ж шедевр просто
PD>Понимаешь, все эти аргументы бледнеют перед одним простым фактом — компиляторы, которые работают в 1-2 Мб, сделать можно.
и в лучшем случае они будут иметь такой же процент функционала от сегодняшних компиляторов, какой имеет линукс среди десктопов
PD>Я не знаю , что они там в v8 сделали, и, честно говоря, мне это не слишком интересно. И разбираться в их исходниках, чтобы сказать, где там можно затраты памяти подскоратить, я не буду. Тем более, что, возможно, для этого нужен полный пересмотр всей архитектуры, а я не в силах такое сделать. Я вообще не специалист в построении компиляторов, а поэтому отнюдь не собираюсь ни анализировать существующие реализации, ни давать советы.
да, "не специалист", "не буду", "не интересно", но у них всех кривые руки.
PD>Я просто констатирую факт — пока памяти было мало, они занимали эту малую память и работали с приличной скоростью. Значит, это можно сделать.
ставить скорость сборки выше скорости выполнения результата это суметь надо
PD>Я бы понял, если бы речь шла о языке, на порядки более сложном. Но этого нет. Вот и все.
это типа здесь сказано, что сложность компилятора зависит исключительно(или в большей мере) от сложности языка?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да нет. Миллиарды строк кода без нее написаны. По существу, все серьезное ПО написано на статически типизируемых языках. И никаких особенно проблем не было при этом. Значит, вполне можно было бы и без нее обойтись.
Не всё. Очень большая часть написана на динамически типизируемых.
M>>Ты спашиваешь: объясните, а то в TP все просто M>>Тебе дают ссылку на дизайн V8, где все показано даже картинками. M>>Ты спрашиваешь (не глядя на картинку): объясните, а то в TP все просто M>>Тебе отвечают, расписывая архитектуру браузера, пробелмы, возникающие при реализации всего этого дела и т.п. M>>Ты спрашиваешь (не читая): объясните, а то в TP все просто M>>Ну и т.п.
PD>И т.п.
PD>Понимаешь, все эти аргументы бледнеют перед одним простым фактом — компиляторы, которые работают в 1-2 Мб, сделать можно. Я не знаю , что они там в v8 сделали, и, честно говоря, мне это не слишком интересно.
Оно и заметно. Три человека тебе тут уже сказали, что есть большая разница между единоразовой компиляцией статического языка и JIT'ом динамического.
PD>И разбираться в их исходниках, чтобы сказать, где там можно затраты памяти подскоратить, я не буду. Тем более, что, возможно, для этого нужен полный пересмотр всей архитектуры, а я не в силах такое сделать. Я вообще не специалист в построении компиляторов, а поэтому отнюдь не собираюсь ни анализировать существующие реализации, ни давать советы. Я просто констатирую факт — пока памяти было мало, они занимали эту малую память и работали с приличной скоростью.
Нет такогопонятия, как сферовакуумная скорость. Примеры тебе привел Владимир. JS'ный интерпретатор 10-летней давности не способен быстро работать с полумиллионом загруженных в него объектов.
PD>Значит, это можно сделать. Я бы понял, если бы речь шла о языке, на порядки более сложном. Но этого нет. Вот и все.
Нет, не значит. Владимир тебе на пальцах, максимально доходчиво разъяснил проблемы.
PD>Извини, но я действительно устал от этой дискуссии.
Ну если ты не прилагаешь никаких усилий, чтобы в ней участвовать, потому что тебе не интересно, то
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Т.е., с другой стороны я наблюдаю применение динамического языка в настолько критичной и нагруженной, а главное реальной системе, что мой разум отказывается принимать доводы, которые приводят сторонники статической типизации. Да, возможно, железки первого типа были блестяще спроектированы и реализованы педантичными шведами, а второго — делали индусы по заказу корейцев, нанятых японцами, выполняющими госзаказ китайцев. Может быть. Но факт остается фактом и его тяжело игнорировать.
Тут протевостояние ни статика vs динамика, а строгая динамическая типизация vs слабая статическая.
В С++ слишком просто наплевать на типы и все нахрен порушить. О многопоточности С++ так же ничего не знает и за ней не следит.
В ерланге (ты ведь о нем?) таких проблем нет.
Так что проблема тут не в стаке, а в том что автор С++ не сумел сделать качественную сатику.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Но если уж они есть, то не надо из них монстра делать. Переменные могут менять свой тип, но типы-то не могут!
Ты не поверишь. Могут! И меняют!
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Но если уж они есть, то не надо из них монстра делать. Переменные могут менять свой тип, но типы-то не могут! WH>Ты не поверишь. Могут! И меняют!
M>Нет такогопонятия, как сферовакуумная скорость. Примеры тебе привел Владимир. JS'ный интерпретатор 10-летней давности не способен быстро работать с полумиллионом загруженных в него объектов.
PD>>Значит, это можно сделать. Я бы понял, если бы речь шла о языке, на порядки более сложном. Но этого нет. Вот и все.
M>Нет, не значит. Владимир тебе на пальцах, максимально доходчиво разъяснил проблемы.
Дима, все же ответь на один вопрос, который я Владимиру задавал. Если бы в 2000 году увеличение скорости процессора и объема памяти прекратилось — означало бы это, что создание средств для просмотра HTML с неким управлением внутри этого HTML невозможно было бы ? При 256 Кб и 667 MHz.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Но если уж они есть, то не надо из них монстра делать. Переменные могут менять свой тип, но типы-то не могут! WH>>Ты не поверишь. Могут! И меняют!
PD>Ну и пусть.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mamut, Вы писали:
M>>Нет такогопонятия, как сферовакуумная скорость. Примеры тебе привел Владимир. JS'ный интерпретатор 10-летней давности не способен быстро работать с полумиллионом загруженных в него объектов.
PD>>>Значит, это можно сделать. Я бы понял, если бы речь шла о языке, на порядки более сложном. Но этого нет. Вот и все.
M>>Нет, не значит. Владимир тебе на пальцах, максимально доходчиво разъяснил проблемы.
PD>Дима, все же ответь на один вопрос, который я Владимиру задавал. Если бы в 2000 году увеличение скорости процессора и объема памяти прекратилось — означало бы это, что создание средств для просмотра HTML с неким управлением внутри этого HTML невозможно было бы ? При 256 Кб и 667 MHz.
PD>Да или нет ?
История не терпит сослагательных наклонений. Если бы рост не продолжился, то, боюсь, мы бы остались на уровне http://thedesigned.com/2009/09/22/electronic-retail-store-websites-in-the-year-2000/ А тогда что-либо сложнее, чем выпадающая менюшка, безбожно тормозило (это к вопросу об «адекватности» скорости тогдашних интерпретаторов яваскрипта).
Потому что нынешний веб-сайт — это не только JavaScript. Это и быстрый яваскрипт, сособный манипулировть сотнями тысяч объектов в доли секунды. Как минимум.
Потому что нынешний веб-сайт — это не только HTML 3.2/HTML 4. Это и HTML 4 + XHTML 1.0 + XML + XSLT + CSS 2.1 + CSS 3. Как минимум.
Потому что нынешний веб-сайт — это не только JPEG + GIF, это и JPEG + GIF + PNG + Canvas + SVG + Flash + Silverlight + CSS3 Transforms (применимо к видео тоже). Как минимум.
Потому что нынешний веб-сайт — это не только Flash 5, это Flash 10 (3D Transforms, HD Video, Dynamic Sound Generation и т.п.). Как минимум.
И т.д. и т.п.
Это все требует скорости и памяти. И в каждый данный момент времени может быть затребовано на любом из открытых сайтов и должно быть готово к манипулированию тем же JavaSscript'ом.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>При изменении типа , возможно, изменится размер, понадобится реаллокация. C>>А layout кто менять будет или расширять блок памяти для новых членов? PD>А реаллокация — это не расширение блока памяти ?
Каким образом ты его расширишь, если у тебя рядом соседний блок? Тебе придётся передвигать объект, и всё на него указывающее (что в С++ невозможно). Или резервировать по худшем случаю заранее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Но если уж они есть, то не надо из них монстра делать. Переменные могут менять свой тип, но типы-то не могут! WH>>Ты не поверишь. Могут! И меняют!
PD>Ну и пусть.
Динамически типизируемые переменные:
var a = {
v: 1,
method: function() { return this.v; }
}; // какой тип у a?var b = a; // какой тип у b?
a.new_method = function(){ return this.method(); }; // какой тип у а? у b?var с = a; // какой тип у c?
a.old_method = a.method; // какой тип у а? у b? у c?var d = a; // какой тип у d?
a.method = function(){ новая_логика(); this.old_method(); } // какой тип у а? у b? у c? у d?var e = a; // какой тип у e?
Динамически типизируемые типы:
var a = "string"; // переменная типа String
String.prototype.f = function(){ alert(this) }; //
a.f(); // переменная осталась типа String, но сам тип ВНЕЗАПНО поменялся
А теперь все вместе
var a = function(){}; // какой тип у a?var b = new a(); // какой тип у b?
a.prototype.f = function(){ alert(this); }; // у a ВНЕЗАПНО поменялся тип... оставшись тем же
// какой тип у a? а у b?
b.aa = function(){ alert(this); }; // какой тип у b?
Здравствуйте, Mamut, Вы писали:
M>Динамически типизируемые переменные:
[skip]
M>Динамически типизируемые типы:
[skip]
M>А теперь все вместе
M>
M>var a = function(){}; // какой тип у a?
M>var b = new a(); // какой тип у b?
M>a.prototype.f = function(){ alert(this); }; // у a ВНЕЗАПНО поменялся тип... оставшись тем же
M> // какой тип у a? а у b?
M>b.aa = function(){ alert(this); }; // какой тип у b?
M>
Никогда не имел дела ни с чем подобным. Код на JS, да? И часто встречаются такие конструкции?
Сдается мне, что после чтения такого кода Brainfuck покажется детскими сказками на ночь.
M>Что ты там говорил про TP?
Я ничего не говорил про TP, у меня к Паскалю еще в институте идиосинкразия появилась.
M>>Динамически типизируемые переменные: P>[skip]
M>>Динамически типизируемые типы: P>[skip]
M>>А теперь все вместе
M>>
M>>var a = function(){}; // какой тип у a?
M>>var b = new a(); // какой тип у b?
M>>a.prototype.f = function(){ alert(this); }; // у a ВНЕЗАПНО поменялся тип... оставшись тем же
M>> // какой тип у a? а у b?
M>>b.aa = function(){ alert(this); }; // какой тип у b?
M>>
P>Никогда не имел дела ни с чем подобным. Код на JS, да? И часто встречаются такие конструкции?
Очень часто. Большинство JS-фреймворков на таком построено. Более того, не важно, как часто такие конструкции встречаются. Важно, что интерпретатор/компилятор должен быть готов к таким финтам ушами в каждую миллисекунду существования и выполнения срипта, и должен выполнить такое очень и очень быстро. Имея на руках сотню-другую тысячу объектов, каждого из которых эта операция может затронуть. При чем не факт, что можно быстро угадать, затронет или не затронет. Вернее можно, но опять же за счет памяти.
Более того, JIT может собрать статистику о вызовов методов (кстати, потратив память) и на основе этой статистики вывести типы данных и скомпилировать сверхмегабыстрый код (с ветвлением==память, естественно, куда без него, но все же). А тут с сервера приедет eval('Object.prototype.x = y') и весь код можно выкидывать на свалку и собирать статистику по новой. Или запускать эвристику (==память) и угадывать, надо выкидывать код, или не надо.
Ну и т.п.
P>Сдается мне, что после чтения такого кода Brainfuck покажется детскими сказками на ночь.
Ничего сложного, все предельно понятно, нсли разработчик не идиот, конечно
M>>Что ты там говорил про TP?
P>Я ничего не говорил про TP, у меня к Паскалю еще в институте идиосинкразия появилась.
Угу. «Паскаль враз компилится» и т.п. А выше тебе примеры того, с чем современным реализациям яваскрипта надо работать постоянно, на сотнях тысяч объектов. А ты говоришь ну и пусть
PD>>Понимаешь, все эти аргументы бледнеют перед одним простым фактом — компиляторы, которые работают в 1-2 Мб, сделать можно. A>и в лучшем случае они будут иметь такой же процент функционала от сегодняшних компиляторов, какой имеет линукс среди десктопов
Да ну ? Ну-ка, расскажи, что имеет компилятор VC++ 2008 С++ сверх того, что было в BC 5.5. Кроме оптимизации. Впрочем, она и там была, вот только сравнивать не берусь.
PD>>Я просто констатирую факт — пока памяти было мало, они занимали эту малую память и работали с приличной скоростью. Значит, это можно сделать. A>ставить скорость сборки выше скорости выполнения результата это суметь надо
Где это я ее ставил ? Выделил специально для тебя.
PD>>Я бы понял, если бы речь шла о языке, на порядки более сложном. Но этого нет. Вот и все. A>это типа здесь сказано, что сложность компилятора зависит исключительно(или в большей мере) от сложности языка?
Именно так. Компилятор (я не оговорился) с Бейсика на Ямахе работал в 64 Кб. С VB6 его там не разместить.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>При изменении типа , возможно, изменится размер, понадобится реаллокация. C>>>А layout кто менять будет или расширять блок памяти для новых членов? PD>>А реаллокация — это не расширение блока памяти ? C>Каким образом ты его расширишь, если у тебя рядом соседний блок? Тебе придётся передвигать объект, и всё на него указывающее (что в С++ невозможно).
Господи, Alex, ну уж от тебя я такого не ждал. Неужели ты впрямь считаешь, что в С++ я не найду способа переместить объект ? Какое мне дело до соседних блоков, что за чепуха ? Эта проблема сто лет назад решена. Используется двойной указатель, на место, где лежит указатель на объект.
object* pObject; // в действительности ему место тоже в куче, где-нибудь в специальном массиве указателей на перемещаемые объекты
object** ppObject;
pObject = new Object;
ppObject = &pObject;
pObject = ReallocateAndResize(pObject); // вот он и переехал, старое место освобождено.
// а *ppObject все равно показывает на объект. ppObject и храним везде.
Это решение использовалось, если мне не изменяет память, еще в Windows 3.1 для хендлов — то есть хендл был там двойной указатель, а поэтому объект можно было перемещать в пространстве. В Windows 3.1 все задачи сидели в общей памяти, она там фрагментировалась и компактировалась.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да ну ? Ну-ка, расскажи, что имеет компилятор VC++ 2008 С++ сверх того, что было в BC 5.5. Кроме оптимизации. Впрочем, она и там была, вот только сравнивать не берусь.
Неужели BC 5.5 умеет некоторые фичи из C++0x или умеет компилить для дотнета ? Или может он умеет x64 или IA-64 ?
Какие то оптимизации BC 5.5 умел, но сдаётся он и близко не сможет сгенерить хотя бы такой код как VC, не говоря уже про ICC.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да ну ? Ну-ка, расскажи, что имеет компилятор VC++ 2008 С++ сверх того, что было в BC 5.5. Кроме оптимизации. Впрочем, она и там была, вот только сравнивать не берусь.
Попробуй при помощи BC 5.5 собрать boost.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Но тут я повторяюсь
