I>>>А если генерировать код, что тогда ?
PD>>Тогда, извини, это не код. Это данные, которые обрабатываются специальным образом. Текст на JS — это не код, а данные для интерпретатора (или как он там) JS.
I>То есть памяти это не жрёт ?
Не надо передергивать. Картинка или фильм тоже жрет память, но это не код все же. Не надо смешивать код и данные.
I>>>Неправильно думаешь. Тебя должен интересовать один вопрос — какое направление оптимизации выбрали для написания флешгета.
PD>>Правильно думаю . Нечего там во flashget кешировать — 2 раза я один и тот же файл не качаю, а если и качаю, то все равно нельзя кешировать и незачем.
I>Ты не ответил на главный вопрос — "какое направление оптимизации выбрали для написания флешгета".
Ничего себе! Откуда мне знать — я не автор, а исходники его не открыты. Более того, там если и надо оптимизировать, то работу с сетью. Кешировать там, скорее всего, нечего — одни и те же данные там не появляются дважды.
I>Ты даже список фич не глянул, но решил что речь будто идет про кеширование
I>>>Вот когда ты это установишь наверняка и ознакомишься с кодом, тогда можно говорить, что де флешкгет расходует память зазря.
PD>>А он ее не расходует.
I>Ага, прям 0 байт занимает в памяти.
Опять передергиваешь. Я его сейчас посмотрел — при перекачке файла размером в 700 Мб при 10 потоках и скорости примерно 1000 Кбайт/сек он имеет Commit Size по Task Manager 20 Мб. Вполне прилично.
I>>>Будет летать, а программы на нем будут ползать по сравнению с современными JS-машинами на "нынешних Athlon/Dual/i7"
PD>>Каких еще программ ? Если имеем дело с чистым интерпретатором, то его работа и есть исполнение программы
I>Вот те программы, про которые ты говори " то его работа и есть исполнение программы " и будут тормозить по сравнению современными JS-машинами.
"Те программы" и есть эти самые интерпретаторы. И ты чуть выше согласился с тем, что они будут летать. Летать и тормозить одновременно нельзя
PD>>Да какой к черту спам! Я тебе ясно объяснил свою мысль — о том, что скорость процессора резко возросла, а поэтому старый интерпретатор должен работать в N раз быстрее, чем в 90-е годы. Вот и все.
I>Ты хорошо понимаешь, как сравниваются вещи ?
Ну если ты и впрямь решил демагогическим вопросами заняться, значит, пора кончать эту дискуссию. То я не знаю, что такое БД, то не понимаю, как сравниваются вещи. Скучно.
I>Но компе ставится два браузера — старый и новый. Всё. А твой текст про процессор это спам.
Неужели ? Сравнивать можно только на одном и том же процессоре (компе) ? А сравнить, скажем, скорость работы BC 3.1 на компе 10-летней давности и VC 10.0 на нынешнем компе запрещено законом ?
I>Новый браузер рвёт старый в пух и прах по перформансу того же JS.
I>Еще раз — процессор в обоих случаях один и тот же.
I>>>Особенного здесь тот факт, что JS-кода сейчас на порядки больше чем 10 лет назад, и работает он много быстрее относительно одного и того же процессора.
PD>>Что значит его больше ? На HTML-странице ?
I>Имеется ввиду тот который необходим для показа страницы на клиентской стороне
Это-то понятно, а вот с порядками дело не очень ясно.
>>На порядки — это что, в 100 или 1000 раз ? Если 10 лет назад на странице было 5 Кб, то сейчас 500 или 5000 ? Ты вообще много файлов .html видел размером в 500 Кбайт ?
I>Очнись и пой. 10 лет назад JS считай и не было вовсе, 5 кб — это слишком большая цифра. Сумасшедший рост начался где то с 2005го.
Не могу я петь, потому что с JS я имел дело еще в 1998 году, когда мы сайт делали по гранту фонда Сороса. И было там этого JS килобайт так 10-15. Писали его мои студенты, а я должен был отвечать на их вопросы, почему в IE 4 OnТо приходит раньше, чем OnЭто, а в NN 4.7 наоборот, и что же теперь делать
I>Щас только JS может быть на десятки и даже сотни килобайт. Добавь сюда css и окажется, что html уже давно не самая большая часть страницы.
Да пусть хоть html вместе с js и css и чем там еще хоть 5 Мб на страницу. Компиляция 5 Мб в BC 3.1 на стареньком компе шла со свистом лет 10 назад.
I>>>Это и есть крайне медленно. Во первых, язык был убог. Во вторых, оптимизаций считай никаких не делалось.
PD>>Язык Turbo Pascal с классами (object) был более убог, чем JS ? Не смеши!
I>Конечно убог. Сравить с турбопаскалем сложно, но можешь посмотреть сравнение с дельфи
Сравнил. Просто посчитал число плюсов у Delphi и JS. Крестики и +/- не учитывал
Delphi 33
JS 26
I>Проще и быстрее написать книгу и издать.
Пиши.
I>>>Ты в своем уме ? Каждая из этих оптимизаций прибавляет по n-байт в рассчете на объект или коллекцию.
I>>>По одной — ничего, все вместе — может и в 1000 раз.
PD>>И сколько нужно оптимизаций, чтобы увеличивая на n, получить увеличение в 1000 раз ?
I>Очевидно — в среднем 1000/n, и 1000 это частный случай
>>Пусть изначально было 100 байт.
I>Откуда ты взял 100 байт ?
Да просто для примера. Не хочешь 100, бери 1000, не имеет значения.
>>На первой оптимизации добавили, допустим, еще 100. Итого в 2 раза. На второй еще 100. Теперь в 3 раза.
I>Бред какой то. Вот, на вскидку
I>Допустим у тега есть n атрибутов и вложеные теги.
< все далее skipped, поскольку разбираться невозможно — нет нужной информации >
Бред не бред, а ты ясно сказал — "Каждая из этих оптимизаций прибавляет по n-байт в рассчете на объект или коллекцию". Это твои слова, я их выделил выше. Ну вот я по ним и посчитал. Исходный размер в 100 взят, конечно, с потолка, равенство n 100 — тоже, но в остальном я просто применил твой алгоритм. Не нравится 100 — возьми другие значения. Только не рассказывай мне про усиление коллекции или таблицы, а просто следуй своей формуле — добавить n байт на каждой оптимизации на каждый элемент. Задача для средней школы.
////////////////////////////////////
Дано : исходный размер элемента k
Дано : на каждом шаге прибавляем n
Получить — после какого количества шагов размер будет 1000k
Значения k и n задать самостоятельно.
////////////////////////////////////
Можешь ее просто решить с конкретными данными и привести результаты ? Без того, чтобы объяснять мне, чего я не понимаю.
PD>>Совокупность массивов указателей на общие данные.
I>А это память не потребляет, правильно ?
Немного. Не больше, чем размер самих данных — размер элемента данных едва ли меньше 4. А ты говорил, что собственно данных у тебя совсем немного, даже не 1 Мбайт.
PD>>Слушай, ты вообще серьезный человек или нет ? Ну что ты ерунду-то говоришь! Что я не знаю ? Или ты впрямь решил, что я никогла БД не видел ?
I>Когда речь о БД, ты вроде понимаешь из за чего расходуется пространство.
I>А когда о БД в памяти, ты начинаешь рассказывать что все программисты дураки ибо плохо пишут.
Дело в том, что я как раз писал БД в памяти. С чрезвычайно жесткими требованиями по скорости и с еще более жесткими требованиями по виду запросов. Фактически я должен был быть готов к запросу вида SELECT любая комбинация WHERE любая комбинация (пишу так для ясности, я не использовал SQL). Правда, было одно но — БД была R/O. И никаких огромных расходов памяти мне делать не пришлось. Да, резервировал я там порой сотни Мб, но коммитировал лишь сотни Кб. Так что не надо мне это объяснять.
PD>>Оптимизацию под быстродействие совсем не всегда необходимо сочетать с дополнительным расходом памяти. Можно изменить алгоритм, лучшим способом разместить данные и т.д.
I>Алгоритмы это долгосрочная стратегия и иногда даже проф. математики не могут предложить хорошего решения.
Проф. именно математики здесь не вполне к месту. Но вот если, вместо того, чтобы сесть и как следует подумать, проанализировать возможные узкие места заранее, подобрать наилучшие структуры данных, прокрутить все возможные действия в голове и оценить временнУю зависимость их мы будем при каждом случае усиливать таблицы, то добъемся только одного — большого расхода памяти и запутанной структуры.
У меня был момент при написании той БД, когда я просто никак не мог придумать хороший алгоритм. Две недели не написал ни одной строчки. Что ни придумаю, все не так, где-нибудь да вылезет узкое место. Читал книги (худ. лит). Развлекался. Вел свои занятия. Иногда мысль возвращалась к задаче, чтобы в очередной раз убедиться, что я ее решения не имею. И лишь когда я ее решение нашел, только тогда я сел за клавиатуру. Оказалось, что там надо что-то вроде графа сделать.
I>А заказчик просит хоть 10% но прямо сейчас.
И меня он просил. Я ему пообещал сделать к определенному сроку, но пока мне не стало ясно, как делать, я все же писать не стал. А в том, что я решение все же найду, я был уверен.
I>>>Да, примерно так. И меня абсолютно не удивляет, почему Хром жрет память. PD>>Дв и меня не удивляет. Только вот причины этого неудивления у нас с тобой различны
I>Да, я в курсе, все кроме тебя пишут неправильно.
Ты тут много риторических вопросов привел, можно мне теперь только один задать ? Ты и впрямь уверен, что такими аргументами можно добавить хоть какую-то убедительность твоим высказываниям ?
Павел, ты не поверишь. Я написал за пол-дня большую часть развернутого ответа тебе, а потом случайно закрыл янус Поэтому ниже его сокращенная часть, ибо задолбался и времени нет. По ходу разберемся
KV>>Павел извини, но то что я не программист еще не значит, что я не в курсе, чем физическое адресное пространство отличается от виртуального, спасибо PD>Речь шла не об этом отличии.
Ты писал:
PD>Ну а что касается процесса под вкладку — извини, но ты тут просто демонстрируешь незнание базовых механизмов.
Базовым механизмом является возможность CPU маппить страницы из ФАП в ВАП сразу нескольких процессов. Все, что поверх этого реализует винда, уже как-бы не очень базовое получается
KV>>а это не совсем массив данных (да и не очень большой, если честно) PD>Все есть массив данных
Фон-Нейман одобряэ
KV>>Павел, обрати внимание на понятия memory и virtual memory. PD>Вот отсюда я и остановлюсь. Дело в том, что никакого понятия memory в противовес virtual memory в Windows не существует. Что это такое — знает только хром, это его понятие, мне оно неизвестно, поэтому оценить твои последующие рассуждения не могу.
Извини, не пояснил сразу. Просто Memory (то, что я опрометчиво нарек "невиртуальной памятью", чем и ввел тебя в заблуждение) — это именно рабочий набор, т.е. те страницы, которые в настоящий момент присутствуют в ФАП и которые отображены в ВАП процессов. Virtual Memory — это общий объем страниц, как в ФАП, так и в свапе.
PD>(Если же речь идет о рабочем множестве (working set) — это вообще не показатель, так как может изменяться в очень широких пределах без какого либо участия процесса — просто потому, что Windows решила расширить РМ или , наоборот, отнять страницы).
Ну почему же не может? Есть такое понятие как "пик рабочего набора", есть "частный набор", по ним вполне можно оценить аппетиты хрома по отношению именно к ФАП. Нас ведь именно это интересует?
KV>>Смотри, на сколько увеличилось потребление невиртуальной памяти. PD>Не могу я спокойно на это смотреть — не на картинку, а на твои слова. Нет никакой невиртуальной памяти вообще у процесса, хоть он хром, хоть марганец
На тему химии я с тобой спорить не рискну, а остальное уже прокомментировал выше
>>Т.е. как бы той readonly о которой ты говоришь и которую можно было бы замапить в другие процессы, там не так уж и много. PD>Readonly память тоже виртуальная. Опять ты запутался. Ее не надо мапить в другие процессы — она сама мапится. Более того, это просто нельзя отменить. Хоть он хром, хоть черт лысый, а те страницы, которые readonly, все равно будут в ФП в одном экземпляре. И эти страницы там будут обязательно.
Я не запутался, а неправильно понял, что ты подразумеваешь под ридонли. А уже потом запутался
KV>>Т.о., как видишь, мультипроцессная модель управления памятью дает весьма приличный оверхед. Каждый процесс хрома (кроме одного — супервизора) оборачивается в песочницу, изолирующую его от остальных процессов куда более гибче, чем это делает та же винда
PD>Для того, чтобы любой процесс изолировать от остальных процессов, не надо никакой песочницы. Он и так изолирован. Наоборот, надо предпринять меры, чтобы иметь общую память.
В двух словах: процесс нужно изолировать не только от других процессов, но и от файловой системы, реестра, сети и т.п. Точнее не изолировать, а разграничивать доступ. Такой механизм появился только в висте — механизм целостности (http://msdn.microsoft.com/en-us/library/bb625963.aspx), а что делать с толпой юзеров, еще сидящих под XP? А под линукс? Песочница построена как обертка над уровнями целостности под вистой и семеркой и как собственная реализация аналогичного механизма под XP. Под линуксом возможен выбор между несколькими реализациями песочниц, включая использование SELinux или AppArmor. На выходе — прозрачное использование одного и того же API под всеми перечисленными системами.
PD>Тот факт, что readonly страницы присутствуют в ФП один раз, в этом плане ничего, абсолютно ничего не меняет. Никакой возможности изменить страницу в чужом процессе нет, пока не предприняты специальные действия. Если их не предпринимать, то нет , и все!
Ок, ок.
>>Все механизмы межпроцессного взаимодействия для этих песочниц реализованы руками PD>Все механизмы межпроцессного взаимодействия всегда реализуются руками.
Механизмы всегда реализуются руками или все же логика взаимодействия?
>>и их необходимо дублировать от процесса к процессу, чтобы повреждение памяти в одном (к примеру) не сказалось на всех остальных. PD>Повреждение памяти в каком бы то ни было процессе никогда не может сказаться на всех других процессах, если не используется не-readonly общая память.
Ты говоришь о процессах ОС и совершенно прав. Давай теперь введем такое понятие как "хромпроцесс", не имеющее отношения к процессам ОС? Таких хромпроцессов три: "браузер" — главный хромпроцесс, управляющий взаимодействием с пользователем, ОС, сетью и остальными хромпроцессами, "рендереры" — хромпроцессы создаваемые на каждый экземпляр сайта и обрабатывающие его контент и, наконец, "плагины" — хромпроцессы для запуска подключаемых модулей (типа gears, flash, acrobat и т.п). Поскольку расширения браузера, в отличии от плагинов, по сути, представляют собой веб-приложение, то они также обрабатываются в рендерерах. Очевидный, но важный момент — в песочницу может быть завернут именно процесс ОС, а не хромпроцесс. Плагины рассматривать не будем, они всегда запускаются в отдельных процессах ОС и единственное, чем можно рулить — это будут ли они запускаться вообще и оборачивать ли их в песочницу. А вот о том, как хромпроцессы соотносятся с процессами ОС, давай поговорим подробнее, т.к. это и есть те самые хромовские модели управления процессами о которых я говорил в прошлом сообщении:
С т.з. ОС, хромпроцесс (этот термин придумал я, если что) представляет собой либо процесс ОС, либо поток ОС (thread) в некоем процессе ОС. Это зависит от используемой модели:
1. Все-в-одном.
Недавно выпиленная (AFAIK) из хрома модель. Засовывала все хромпроцессы в один процесс ОС, включая и плагины, насколько я знаю. Расход памяти там был сравним с файрфоксовой, т.к. тот реализует ту же самую модель. Безопасность была на том же уровне, т.к. песочницей там и не пахло.
2. Процесс-на-каждую-вкладку.
Все понятно и прозрачно, на каждую открытую вкладку создается отдельный процесс ОС, являющийся хромпроцессом "ренедерер". Достоинство модели в ее интуитивности, все прозрачно и понятно. Недостаток — если в табе был открыт вредоносный сайт, успешно перекореживший процесс таба, то если ты откроешь в этом же табе интернет-банкинг, то ты ССЗБ.
3. Процесс-на-каждый-сайт.
Отдельный процесс ОС объединяет в себе несколько хромпроцессов, относящихся к одному и тому же верхнеуровневому сайту. Т.е., если ты откроешь в разных вкладках mail.google.com и reader.google.com их рендереры будут помещены в один процесс (что ты и наблюдал на фокусном скриншоте в моем предыдущем сообщении). Если ты внезапно откроешь там же rsdn.ru, то его рендерер будет помещен в другой процесс ОС. Эта модель хороша полной изоляцией различных сайтов друг от друга и тем, что по сравнению со второй и четвертой моделью значительно уменьшается оверхед памяти за счет сокращения количества создаваемых процессов ОС. Недостаток также очевиден, т.к. будучи потоками в одном процессе, рендереры могут друг-другу немножко мешать, вследствие чего будет падать производительность.
4. Процесс-на-каждый-экземпляр-сайта.
Модель, используемая в хроме по умолчанию. Создает процесс ОС на каждый экземпляр сайта. Экземпляром сайта считается набор т.н. "соединенных страниц", принадлежащих одному и тому же сайту. Страницы считаются соединенными, если пользователь открыл одну из другой (пройдя по ссылке) или если одна открыла другую, используя javascript. Соответственно, на каждую страницу создается свой рендерер. Модель дает максимальный уровень изоляции контента, но является самой жадной в плане затрат памяти за счет большого количества создаваемых процессов ОС.
А если учесть еще и то, что между некоторыми рендерами необходимо обеспечивать возможность доступа из javascript одного к DOM другого...
PD>В процессе A текст "Sample" хранится в R/O памяти,в некоей странице.
Я говорил о "хромпроцессах"
KV>>Но ведь это еще не все Javascript в хроме исполняется движком V8 одной из отличительных черт которого является способ представления объектов в памяти процесса. Вместо того, чтобы держать хэш таблицы для доступа ко всем динамическим членам объектов, V8 при каждом изменении какого-либо объекта (например, при добавлении в него нового поля) создает на базе этого объекта т.н. скрытый класс, унаследованный от текущей структуры объекта, который в дальнейшем используется в качестве прототипа при создании новых объектов и для доступа к его членам. Это позволяет избежать поиска динамических членов по всей цепочке иерархии и существенно ускорить доступ к членам (т.к. эти скрытые классы еще и джитятся в нативный код), за счет опять-таки, затрат памяти, т.к. всю эту иерархию нужно хранить на протяженнии всего жизненного цикла скрипта (ибо таков суровый мир динамических языков). Мне лень делать скриншоты (кому надо — проверят сами), но разница между открытым gmail в режиме html-only и его представлением по умолчанию измеряется не одним десятков мегабайт, именно за счет того, что броузеру не приходится плодить все эти скрытые классы:
PD>Вот именно. Вместо того, чтобы оптимизировать код и найти оптимальные алгоритмы, пошли по пути захвата лишней памяти.
Приняли взвешенное решение, скорее. Павел ты как будто меня не слышишь Они не принесли память в жертву, видя какой ужасный и неоптимизированный код у них получился. Они изначально спроектировали движок, делая упор на увеличение производительности за счет использования объема памяти, бОльшего нежели имевшего место в других движках. И, в результате, получился движок, порвавший в клочья все существующие по скорости выполнения скриптов. Видимо потому что там неоптимизированный код и неоптимальные алгоритмы?
Павел пойми, разрабатывался продукт для десктопов, знаешь, для тех маленьких коробочек, гигабайт оперативки для которых сейчас стоит где-то 600-800р. И пользователи которых весьма нервничают, когда всякие вконтактики и фейсбуки начинают адски тормозить на ровном месте. Впрочем, если ты так уверен в своих словах, может глянешь на код V8 (http://code.google.com/p/v8/source/browse#svn/trunk/src)? Там твои любимые плюсы и (если ты конечно не ошибаешься) простор для оптимизаций — только сядь и начни, остановиться не сможешь
PD>Сколько там этих объектов (переменных), в обычном файле на js ? Сотни ? Тысячи ? Ну пусть даже десятки тысяч!
А сколько объектов в обычном файле на С++?
PD>И на это нужны десятки Мб ? По Кбайту оверхеда на текстовую строку ?
А что ты хотел от динамического прототипного языка, который разогнали аки ту частицу в коллайдере?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Pavel Dvorkin, Вы писали:
KV>Павел, ты не поверишь. Я написал за пол-дня большую часть развернутого ответа тебе, а потом случайно закрыл янус Поэтому ниже его сокращенная часть, ибо задолбался и времени нет. По ходу разберемся
Кстати, а сколько янус жрет?
Здравствуйте, denisko, Вы писали:
D>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Здравствуйте, Pavel Dvorkin, Вы писали:
KV>>Павел, ты не поверишь. Я написал за пол-дня большую часть развернутого ответа тебе, а потом случайно закрыл янус Поэтому ниже его сокращенная часть, ибо задолбался и времени нет. По ходу разберемся D>Кстати, а сколько янус жрет?
Здравствуйте, Mamut, Вы писали:
PD>>Потому что, как правило, страницы HTML вместе с внедренным в него или иначе вставленным JS имеют размер, намного меньше. О том, что размер вырос на порядки, говорить все же не приходится. Вырос, не спорю, в несколько раз, но не на порядки.
M>Минимум на порядок
Ну на порядок — ладно. В 10 раз то есть. Кстати, встречный вопрос. На сколько (или во сколько раз) увеличились размеры исходного кода в C++ проектах со времен BC 3.1 ?
PD>>Между прочим. Компиляция обычных статических языков, как я уже не раз тут замечал, вполне может идти на нескольких Мб. Доказательство простое — она шла, и с весьма приличной скоростью при памяти в Мбайты и частоте в десятки-сотню MHz и без многоядерности. Это сейчас просто начали памятью бросаться. А Язык С++ от времен BC 5.0 до нашего времени не менялся практически. А тут, видите ли, чтобы откомпилировать 2.8 Мб сорсов, нужна сотня Мб. При том, что язык довольно простой. Что же это такое, кроме как халтурное программирование ?
M>Фигня, что этот скрипт не только компилируется, но и выполняется?
А что тут такого ? Интерпретаторы этим всю свою историю занимались, на то они и интерпретаторы. Даже какой-нибудь GW-Basic на 64 Кб это умел. Чистый интерпретатор берет строчку исходного текста, строит машинные команды, исполняет. Полукомпилятор хранит еще и кэш этих кусков машинных команд, чтобы повторно не интерпретировать. Из 5 Мбайт исходников на каком угодно языке (хоть на асме) этих машинных команд можно создать не более 1-2 Мбайт. В чем проблема-то ?
>Или мне надо взять Фотошоп, запустить его, увидеть, что он жрет немерянно памяти и сделать вывод о фиговом компиляторе?
Стоп-стоп-стоп! Не пойдет. Фотошоп оперирует действительно огромными размерами данных. Эти данные — не накладные расходы, а собственно данные. Картинку 3000*3000 32bpp — 36 Мб вынь да положь (сжатие не рассматриваем). А если на эту картинку да еще несколько слоев — считай сам.
M>Повторю во второй раз: «Фигня, что этот скрипт не только компилируется, но и выполняется?»
Отошлю к ответу выше.
PD>>Ай-яй-яй. На замыкания с eval нужно 100 Мб. А динамика — так она вроде как в любом интерпретаторе потенциально возможна, на то он и интерпретатор. К примеру, в той же FoxPro на 1 Мб в DOS-времена были переменные, тип которых изменялся во время выполнения. Что тут такого-то ?
M>Повторю в третий раз: «Фигня, что этот скрипт не только компилируется, но и выполняется?»
Еще раз отошлю тебя к ответу выше.
>Что тебя зациклило на компиляции? Компиляция на современных реализациях Яваскрипта занимает доли секунды, а то и быстрее.
А в чем тогда проблема ? На что вам время и память нужны ?
M>А те самые «вызовы» браузера — не настолько простая и нересурсоемкая операция, как тебе кажется. В том же GMail'е идет постоянная манипуляция DOM'ом (который сам по себе не является особо эффективной структурой для хранения). Банальный insert/show отожрет у тебя или память или процессор (а вернее, и то и другое), и Javascript тут вообще не причем. Курить reflow и redraw/repaint.
Хе-хе. JS тут верно, ни при чем. А вот что касается вызовов броузера — нечего было так качественно броузеры писать. Едва ли броузер сложнее ОС. Но ОС писали специалисты, умевшие обращаться с памятью (ее тогда мало было), поэтому там все продумано сначала, а потом написано. А IE писали сами знаешь кто, а Chrome писали , когда память перестала быть ресурсом. Ну и получите свое. А мы (пользователи) в результате получим ваше.
M>Повторю в четвертый раз: «Фигня, что этот скрипт не только компилируется, но и выполняется?».
И в третий раз отошлю тебя к ответу выше.
PD>>А сейчас так-таки сплошь и рядом 5 Мб ? Между прочим, на его загрузку нужно 5 сек у меня, а если скорость 1-2 Мбит ?
M>Не пять, но 3. На том же GMail'е. На том же facebook'е. на том же Твиттере. Ты думаешь, что, раз загрузив 100 килобайт на том все? Любой твой поиск в Google Instant бросает в тебя сотню-другую килобайтов яваскрипта. Любой чих на Фейсбуке — аналогично. Рассказать тебе, какие сайты сейчас самые популярные в мире или сам догадаешься?
Догадаюсь. Хорошо они сделаны, тоже догадаюсь.
PD>>Счастье-то какое! Помню, в 2000-м был у меня Пентиум-3, памяти 256 Мб, тактовая 667 MHz. И работал в ней Netscape Navigator 4.7. В одном окне была почта, в другом web, а еще был composer и не помню что еще. И ничего они не вешали. Вот поиска в гугле не было, потому что не было гугла. Но поиск на altavista (я тогда ей пользовался) или rambler — без проблем.
M>Угу. И почта, видимо была уровня GMail'а
Ты знаешь, я с тех пор ничего нового в почте так и не увидел. Я лично пользуюсь Thunderbird, он, конечно, получше, чем Netscape mail 1990-х, но не намного. Что там, в самом деле, радикально нового ? Почта она и есть почта.
>и поиск тоже был уровня Google Instant, ага.
Если не считать подсказки в строке Гугла, я тоже ничего нового не заметил. Набираешь слова, жмешь, получаешь ссылки
>Еще навреное уже тогда Facebook существовал в нынешней инкарнации — с динамикой, мгновенными нотификациями и т.п. Ага-ага, верю.
Вот тут не знаю, ибо им не пользуюсь.
PD>>А всего-то 256 Мб... Получается, что для того, чтобы от 5 Кб JS перейти к 500 Кб, надо объем ОП увеличить в 16 раз, тактовую в 5, ядер в 4 ! Да это просто чудовище какое-то, ваш JS .
M>Угу, только проблема сейчас уже не столько в JS, сколько DOM'е браузеров.
Ну так нечего было давать писать броузеры тем, кто это делать не умеет.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, denisko, Вы писали:
D>>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>Здравствуйте, Pavel Dvorkin, Вы писали:
KV>>>Павел, ты не поверишь. Я написал за пол-дня большую часть развернутого ответа тебе, а потом случайно закрыл янус Поэтому ниже его сокращенная часть, ибо задолбался и времени нет. По ходу разберемся D>>Кстати, а сколько янус жрет?
Ты специально разгонял или он всегда такой?
А он тоже создает рабочие места, т.е. потоки на каждый чих?
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>То есть памяти это не жрёт ?
PD>Не надо передергивать. Картинка или фильм тоже жрет память, но это не код все же. Не надо смешивать код и данные.
Код это все что можно выполнить процессорм. Откуда он берется — дело десятое.
I>>Ты не ответил на главный вопрос — "какое направление оптимизации выбрали для написания флешгета".
PD>Ничего себе! Откуда мне знать — я не автор, а исходники его не открыты. Более того, там если и надо оптимизировать, то работу с сетью. Кешировать там, скорее всего, нечего — одни и те же данные там не появляются дважды.
Список фич ты открой хотя бы Сразу найдешь, где там надо кеширование
PD>Опять передергиваешь. Я его сейчас посмотрел — при перекачке файла размером в 700 Мб при 10 потоках и скорости примерно 1000 Кбайт/сек он имеет Commit Size по Task Manager 20 Мб. Вполне прилично.
То есть "А он ее не расходует." == "Вполне прилично.", правильно я тебя понял ?
PD>"Те программы" и есть эти самые интерпретаторы. И ты чуть выше согласился с тем, что они будут летать. Летать и тормозить одновременно нельзя
Ты прыгаешь с одного на другое. JS-код для страницы будет тормозить на старом интерпретаторе, и будет летать на новом (для одно го и того же компьютера; такой бред надо добавлять каждый раз что бы не увилнул на процессоры)
I>>Ты хорошо понимаешь, как сравниваются вещи ?
PD>Ну если ты и впрямь решил демагогическим вопросами заняться, значит, пора кончать эту дискуссию. То я не знаю, что такое БД, то не понимаю, как сравниваются вещи. Скучно.
Нет, не знаешь. Потому что при сравнении JS vs JS у тебя вдруг появляется разница в процессорах.
I>>Но компе ставится два браузера — старый и новый. Всё. А твой текст про процессор это спам.
PD>Неужели ? Сравнивать можно только на одном и том же процессоре (компе) ?
Да, только так и можно сравнивать, что бы выяснить, какой интерпретатор работает быстрее.
Например, полезного кода одна комманда "MOV EAX, EBX". Интерпретатор для выполнения этого кода будет выполнть еще кучу всякого мусора, а JS-машина возьмет да заджитит и получится оверхед время джита поделить на количество вызовов.
Вот это и нужно сравнивать. А свои "BC тогда и VC сейчас" сравнивай сам.
I>>Очнись и пой. 10 лет назад JS считай и не было вовсе, 5 кб — это слишком большая цифра. Сумасшедший рост начался где то с 2005го.
PD>Не могу я петь, потому что с JS я имел дело еще в 1998 году, когда мы сайт делали по гранту фонда Сороса. И было там этого JS килобайт так 10-15.
И ты уверен что это был наиболее типичный случай ?
PD>Да пусть хоть html вместе с js и css и чем там еще хоть 5 Мб на страницу. Компиляция 5 Мб в BC 3.1 на стареньком компе шла со свистом лет 10 назад.
И какая связь между интерпретацией JS и компиляцией в BC 3.1 ?
PD>Сравнил. Просто посчитал число плюсов у Delphi и JS. Крестики и +/- не учитывал
PD>Delphi 33 PD>JS 26
А теперь выбрось из дельфи всё, чего не было в турбопаскале. Ну и учти, что JS — это сильный полиморфизм и функциональное программирование.
I>>Допустим у тега есть n атрибутов и вложеные теги.
PD>< все далее skipped, поскольку разбираться невозможно — нет нужной информации >
Интересно, каким образом ты хочешь что бы я тебе объяснил, если ты не можешь разобраться ?
PD>Бред не бред, а ты ясно сказал — "Каждая из этих оптимизаций прибавляет по n-байт в рассчете на объект или коллекцию". Это PD>Можешь ее просто решить с конкретными данными и привести результаты ? Без того, чтобы объяснять мне, чего я не понимаю.
1000 это был _частный_ случай и выяснилось, что разбираться для тебя это невозможная деятельность
В том конкретном случае где было в 1000 раз больше нужно было кешировать результаты всех основных операций примерно на 10-15 вариантов параметров.
В итоге потребление памяти выросло с 1,5мб (голые структурины) до 1.5 гб(+кеширование), все это единственно для того, что бы UI не тормозил.
Странный ты человек, сначала просишь примеры оптимизаций, возмущаешься, что я тебе не рассказываю, а потом вворачиваешь идиотское "разбираться невозможно"
I>>А это память не потребляет, правильно ?
PD>Немного. Не больше, чем размер самих данных — размер элемента данных едва ли меньше 4. А ты говорил, что собственно данных у тебя совсем немного, даже не 1 Мбайт.
Посмотри тот пример который ты скипнул и сделай рассчет прежде чем нести ахинею.
PD>Дело в том, что я как раз писал БД в памяти. С чрезвычайно жесткими требованиями по скорости и с еще более жесткими требованиями по виду запросов. Фактически я должен был быть готов к запросу вида SELECT любая комбинация WHERE любая комбинация (пишу так для ясности, я не использовал SQL). Правда, было одно но — БД была R/O. И никаких огромных расходов памяти мне делать не пришлось. Да, резервировал я там порой сотни Мб, но коммитировал лишь сотни Кб. Так что не надо мне это объяснять.
R/O это несерьезно. R/W + реактивная модель это совершенно другая задача.
PD>Но вот если, вместо того, чтобы сесть и как следует подумать, проанализировать возможные узкие места заранее, подобрать наилучшие структуры данных, прокрутить все возможные действия в голове и оценить временнУю зависимость их мы будем при каждом случае усиливать таблицы, то добъемся только одного — большого расхода памяти и запутанной структуры.
"подобрать наилучшие структуры данных" == "усиливать таблицы"
PD>У меня был момент при написании той БД, когда я просто никак не мог придумать хороший алгоритм. Две недели не написал ни одной строчки. Что ни придумаю, все не так, где-нибудь да вылезет узкое место. Читал книги (худ. лит). Развлекался. Вел свои занятия. Иногда мысль возвращалась к задаче, чтобы в очередной раз убедиться, что я ее решения не имею. И лишь когда я ее решение нашел, только тогда я сел за клавиатуру. Оказалось, что там надо что-то вроде графа сделать.
Это все пройденый этап.
I>>Да, я в курсе, все кроме тебя пишут неправильно.
PD>Ты тут много риторических вопросов привел, можно мне теперь только один задать ? Ты и впрямь уверен, что такими аргументами можно добавить хоть какую-то убедительность твоим высказываниям ?
Требуешь ответ, а пототм говоришь "разбираться невозможно "
Думаешь я буду с тобой церемониться после таких уловок ? Хрена с два.
>>Или мне надо взять Фотошоп, запустить его, увидеть, что он жрет немерянно памяти и сделать вывод о фиговом компиляторе?
PD>Стоп-стоп-стоп! Не пойдет. Фотошоп оперирует действительно огромными размерами данных. Эти данные — не накладные расходы, а собственно данные. Картинку 3000*3000 32bpp — 36 Мб вынь да положь (сжатие не рассматриваем). А если на эту картинку да еще несколько слоев — считай сам.
M>>А те самые «вызовы» браузера — не настолько простая и нересурсоемкая операция, как тебе кажется. В том же GMail'е идет постоянная манипуляция DOM'ом (который сам по себе не является особо эффективной структурой для хранения). Банальный insert/show отожрет у тебя или память или процессор (а вернее, и то и другое), и Javascript тут вообще не причем. Курить reflow и redraw/repaint.
PD>Хе-хе. JS тут верно, ни при чем. А вот что касается вызовов броузера — нечего было так качественно броузеры писать. Едва ли броузер сложнее ОС. Но ОС писали специалисты, умевшие обращаться с памятью (ее тогда мало было), поэтому там все продумано сначала, а потом написано. А IE писали сами знаешь кто, а Chrome писали , когда память перестала быть ресурсом. Ну и получите свое. А мы (пользователи) в результате получим ваше.
Угу. Давай, ты сначала напишешь браузер, а потом будешь их ритиковать Я как-то не собираюсь их критиковать, потому что примерно представляю фронт работ, что там нужен.
PD>>>А сейчас так-таки сплошь и рядом 5 Мб ? Между прочим, на его загрузку нужно 5 сек у меня, а если скорость 1-2 Мбит ?
M>>Не пять, но 3. На том же GMail'е. На том же facebook'е. на том же Твиттере. Ты думаешь, что, раз загрузив 100 килобайт на том все? Любой твой поиск в Google Instant бросает в тебя сотню-другую килобайтов яваскрипта. Любой чих на Фейсбуке — аналогично. Рассказать тебе, какие сайты сейчас самые популярные в мире или сам догадаешься?
PD>Догадаюсь. Хорошо они сделаны, тоже догадаюсь.
Гораздо лучше, чем ты можешь себе представлять.
PD>>>Счастье-то какое! Помню, в 2000-м был у меня Пентиум-3, памяти 256 Мб, тактовая 667 MHz. И работал в ней Netscape Navigator 4.7. В одном окне была почта, в другом web, а еще был composer и не помню что еще. И ничего они не вешали. Вот поиска в гугле не было, потому что не было гугла. Но поиск на altavista (я тогда ей пользовался) или rambler — без проблем.
M>>Угу. И почта, видимо была уровня GMail'а
PD>Ты знаешь, я с тех пор ничего нового в почте так и не увидел. Я лично пользуюсь Thunderbird, он, конечно, получше, чем Netscape mail 1990-х, но не намного. Что там, в самом деле, радикально нового ? Почта она и есть почта.
>>и поиск тоже был уровня Google Instant, ага.
PD>Если не считать подсказки в строке Гугла, я тоже ничего нового не заметил. Набираешь слова, жмешь, получаешь ссылки
Да-да. Прибегая к любимым здесь автомобильным ассоциациям: Разницы между фордом T и subaru outback'ом ты тоже не видишь. Ту же четыре колеса и руль, ага.
>>Еще навреное уже тогда Facebook существовал в нынешней инкарнации — с динамикой, мгновенными нотификациями и т.п. Ага-ага, верю.
PD>Вот тут не знаю, ибо им не пользуюсь.
не существовал, ибо существовать не мог. Любой браузер загнулся бы.
PD>>>А всего-то 256 Мб... Получается, что для того, чтобы от 5 Кб JS перейти к 500 Кб, надо объем ОП увеличить в 16 раз, тактовую в 5, ядер в 4 ! Да это просто чудовище какое-то, ваш JS .
M>>Угу, только проблема сейчас уже не столько в JS, сколько DOM'е браузеров.
PD>Ну так нечего было давать писать броузеры тем, кто это делать не умеет.
Могу предположить, что создававшие их люди слегка более компетентнее тебя в создании браузеров
Здравствуйте, Mamut, Вы писали:
>>>Или мне надо взять Фотошоп, запустить его, увидеть, что он жрет немерянно памяти и сделать вывод о фиговом компиляторе?
PD>>Стоп-стоп-стоп! Не пойдет. Фотошоп оперирует действительно огромными размерами данных. Эти данные — не накладные расходы, а собственно данные. Картинку 3000*3000 32bpp — 36 Мб вынь да положь (сжатие не рассматриваем). А если на эту картинку да еще несколько слоев — считай сам.
M>Пустой фотошоп спокойно отжирает 130 метров памяти. Компилятор С++ — гуано, однозначно.
У меня пустой фотошоп (CS5) отжирает чуть больше ста метров. Зато после открытия в нем 62х-килобайтного скриншота
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> А что тут такого ? Интерпретаторы этим всю свою историю занимались, на то они и интерпретаторы. Даже какой-нибудь GW-Basic на 64 Кб это умел. Чистый интерпретатор берет строчку исходного текста, строит машинные команды, исполняет. Полукомпилятор хранит еще и кэш этих кусков машинных команд, чтобы повторно не интерпретировать. Из 5 Мбайт исходников на каком угодно языке (хоть на асме) этих машинных команд можно создать не более 1-2 Мбайт. В чем проблема-то ?
Проблема прежде всего в том, что чем высокоуровневее язык, тем больше байт/маш-кода он будет порождать (разумеется, если система команд VM достаточно низкоуровневая). Один пример. Может ты знаешь, для Delphi был давно написан интерпретатор диалекта Паскаля — Interfuse PascalScript. Cейчас это RemObjects PascalScript. Так вот у него, из 4Mb скрипта получается 10Mb байткода
Здравствуйте, kochetkov.vladimir, Вы писали:
k> D>Ты специально разгонял или он всегда такой?
k> Ага, сидел, делать было нечего, дай, думаю — януса чутка погоняю, чтобы не расслаблялся
k> Просто запустил и снял скрин
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Pavel Dvorkin, Вы писали:
KV>Павел, ты не поверишь. Я написал за пол-дня большую часть развернутого ответа тебе, а потом случайно закрыл янус
Сочувствую
>Поэтому ниже его сокращенная часть, ибо задолбался и времени нет. По ходу разберемся
Может, это и к лучшему.
KV>Базовым механизмом является возможность CPU маппить страницы из ФАП в ВАП сразу нескольких процессов. Все, что поверх этого реализует винда, уже как-бы не очень базовое получается
Вообще-то я имел в виду именно базовые механизмы Windows, а не процессора. Но замнем для ясности.
KV>>>Павел, обрати внимание на понятия memory и virtual memory. PD>>Вот отсюда я и остановлюсь. Дело в том, что никакого понятия memory в противовес virtual memory в Windows не существует. Что это такое — знает только хром, это его понятие, мне оно неизвестно, поэтому оценить твои последующие рассуждения не могу.
KV>Извини, не пояснил сразу. Просто Memory (то, что я опрометчиво нарек "невиртуальной памятью", чем и ввел тебя в заблуждение) — это именно рабочий набор, т.е. те страницы, которые в настоящий момент присутствуют в ФАП и которые отображены в ВАП процессов. Virtual Memory — это общий объем страниц, как в ФАП, так и в свапе.
PD>>(Если же речь идет о рабочем множестве (working set) — это вообще не показатель, так как может изменяться в очень широких пределах без какого либо участия процесса — просто потому, что Windows решила расширить РМ или , наоборот, отнять страницы).
KV>Ну почему же не может? Есть такое понятие как "пик рабочего набора", есть "частный набор", по ним вполне можно оценить аппетиты хрома по отношению именно к ФАП. Нас ведь именно это интересует?
Опять ты запутался. Про рабочий набор смотри вот здесь
Там, конечно, не результат моих исследований, а компиляция из Соломона-Руссиновича. Если хочешь, прочти в оригинале.
Коротко — рабочий набор не является вообще характеристикой процесса, а является характеристикой поведения менеджера памяти Windows. При одном и том же размере выделенной памяти (commited) рабочий набор может отличаться в разы.
Пик рабочего набора тут тоже ни при чем. При определенных условиях Windows может дать процессу резко увеличенный РН. Подробности там же у Соломона-Руссиновича. А если процесс был давно неактивен, то его РН может быть равен 0.
Частный набор не имеет отношения к РН. Частный набор (черт бы побрал русскую терминологию здесь, она и на английском хорошо запутана) , если ты имеешь в виду Private Bytes — это объем коммитированной не-shared ВП.
Если коротко.
Private Bytes — управляю я. Без моего ведома ни один байт не освободить.
Shared Mem — управляю я, но отчасти и система (просто потому, что шарит хотя бы код системных DLL)
Working Set — я совсем не управляю, могу только рекомендовать, а Windows на мои рекомендации может наплевать.
Поэтому первые 2 — характеристика моего процесса, а третье — совсем нет.
PD>>Не могу я спокойно на это смотреть — не на картинку, а на твои слова. Нет никакой невиртуальной памяти вообще у процесса, хоть он хром, хоть марганец
KV>На тему химии я с тобой спорить не рискну, а остальное уже прокомментировал выше
Я ответил выше.
>>>Т.е. как бы той readonly о которой ты говоришь и которую можно было бы замапить в другие процессы, там не так уж и много. PD>>Readonly память тоже виртуальная. Опять ты запутался. Ее не надо мапить в другие процессы — она сама мапится. Более того, это просто нельзя отменить. Хоть он хром, хоть черт лысый, а те страницы, которые readonly, все равно будут в ФП в одном экземпляре. И эти страницы там будут обязательно.
KV>Я не запутался, а неправильно понял, что ты подразумеваешь под ридонли. А уже потом запутался
Все смотреть не стал, глянул начало первого документа и все стало ясно. Ничего тут нового нет. На уровне 3 кольца люди пытаются создать свою архитектуру.
It is tempting to extend the OS kernel with a better security model. Don't. Let the operating system apply its security to the objects it controls. On the other hand, it is OK to create application-level objects (abstractions) that have a custom security model.
The Windows sandbox is a user-mode only sandbox. There are no special kernel mode drivers, and the user does not need to be an administrator in order for the sandbox to operate correctly. The sandbox is designed for 32-bit processes
Все. Дальше можно не читать. При этих базовых посылках я заранее знаю, что они могут сделать. Они могут как угодно разделить те или иные действия или ответственность между своими процессами, создать механизмы взаимодействия, определить, кто чем занимается и т.д. На здоровье.
KV>В двух словах: процесс нужно изолировать не только от других процессов, но и от файловой системы, реестра, сети и т.п. Точнее не изолировать, а разграничивать доступ. Такой механизм появился только в висте — механизм целостности (http://msdn.microsoft.com/en-us/library/bb625963.aspx), а что делать с толпой юзеров, еще сидящих под XP? А под линукс? Песочница построена как обертка над уровнями целостности под вистой и семеркой и как собственная реализация аналогичного механизма под XP. Под линуксом возможен выбор между несколькими реализациями песочниц, включая использование SELinux или AppArmor. На выходе — прозрачное использование одного и того же API под всеми перечисленными системами.
Вот этот аргумент я понимаю. Поскольку модели безопасности XP, Vista и Linux действительно порядком отличаются, то их идею перенести весь этот контроль безопасности в свое приложение я понять могу. Правда, так и остается непонятным, почему тут нужны десятки и сотни Мб. Модель безопасности Windows осталсь практически неизменной от 3.1 до XP включительно. То есть она работала так же в 1994, как сейчас, при 16 Мб памяти. Едва ли она намного проще чем то, что они сделали в Хроме. Почему же там хватало 16 Мб под всю ОС, а тут нужно 100 под один броузер ?
Что касается механизма целостности — это лишь небольшая пришлепка к собственно механизму безопасности Windows, едва ли его реализация увеличила размер кода, отвечающегго за безопасность, очень уж заметно.
KV>Механизмы всегда реализуются руками или все же логика взаимодействия?
Еще раз цитирую из твоей ссылки
Do not re-invent the wheel: It is tempting to extend the OS kernel with a better security model. Don't. Let the operating system apply its security to the objects it controls.
Если они свои механизмы синхронизации сочинили вместо ивентов и семафоров, то я им сочувствую.
KV>Ты говоришь о процессах ОС и совершенно прав. Давай теперь введем такое понятие как "хромпроцесс", не имеющее отношения к процессам ОС?
>Таких хромпроцессов три: "браузер" — главный хромпроцесс, управляющий взаимодействием с пользователем, ОС, сетью и остальными хромпроцессами, "рендереры" — хромпроцессы создаваемые на каждый экземпляр сайта и обрабатывающие его контент и, наконец, "плагины" — хромпроцессы для запуска подключаемых модулей (типа gears, flash, acrobat и т.п). Поскольку расширения браузера, в отличии от плагинов, по сути, представляют собой веб-приложение, то они также обрабатываются в рендерерах. Очевидный, но важный момент — в песочницу может быть завернут именно процесс ОС
Поскольку ОС Windows ничего не знает о хромпроцессах, ей нет дела до этих песочниц. Можете заворачивать что угодно во что угодно — Windows на это плевать.
>а не хромпроцесс. Плагины рассматривать не будем, они всегда запускаются в отдельных процессах ОС и единственное, чем можно рулить — это будут ли они запускаться вообще и оборачивать ли их в песочницу. А вот о том, как хромпроцессы соотносятся с процессами ОС, давай поговорим подробнее, т.к. это и есть те самые хромовские модели управления процессами о которых я говорил в прошлом сообщении:
KV>С т.з. ОС, хромпроцесс (этот термин придумал я, если что) представляет собой либо процесс ОС, либо поток ОС (thread) в некоем процессе ОС. Это зависит от используемой модели:
<skipped>
Слушай, зачем ты мне банальные вещи рассказываешь ? Я это все 15 лет назад знал. Хочешь — открой несколько окон, запустив несколько процессов. Хочешь — открой несколько окон, запустив по потоку в процессе и по окну в потоке. В первом случае падение одного процесса не влияет на остальные. Во втором падает весь процесс со всеми потоками. Я это упражнение студентам лет так 10 даю (только вот окно не броузера), что тут за открытие Америки ?
KV>3. Процесс-на-каждый-сайт.
Ну вот в таком виде не даю — просто нет у меня в упражнении для студентов сайтов
KV>4. Процесс-на-каждый-экземпляр-сайта.
И в таком тоже. Но ничего принципиально нового здесь нет.
KV>А если учесть еще и то, что между некоторыми рендерами необходимо обеспечивать возможность доступа из javascript одного к DOM другого...
И что ? Для этого нужно 100 Мб ? LPC/RPC/OLE/COM уже отменили ? И при чем тут js ? Запрос в любом случае делают не из js. Что тут опять такого ? А запросы из Word в Excel тебя не удивляют ? А вставка таблицы из Excel в окно моего приложения не удивляет ? Что за открытия Америк, в конце концов ?
PD>>В процессе A текст "Sample" хранится в R/O памяти,в некоей странице.
KV>Я говорил о "хромпроцессах"
Если речь идет о Windows, то это все равно верно.
PD>>Вот именно. Вместо того, чтобы оптимизировать код и найти оптимальные алгоритмы, пошли по пути захвата лишней памяти.
KV>Приняли взвешенное решение, скорее. Павел ты как будто меня не слышишь Они не принесли память в жертву, видя какой ужасный и неоптимизированный код у них получился. Они изначально спроектировали движок, делая упор на увеличение производительности за счет использования объема памяти, бОльшего нежели имевшего место в других движках.
Вот в это поверю.
>И, в результате, получился движок, порвавший в клочья все существующие по скорости выполнения скриптов.
Что немудрено, если принять во внимание качество исполнения их.
>Видимо потому что там неоптимизированный код и неоптимальные алгоритмы?
Скорее потому. что код и алгоритмы там лучше, чем у других. А может, именно за счет увеличения объема памяти. Ее же не жалко.
KV>Павел пойми, разрабатывался продукт для десктопов, знаешь, для тех маленьких коробочек, гигабайт оперативки для которых сейчас стоит где-то 600-800р. И пользователи которых весьма нервничают, когда всякие вконтактики и фейсбуки начинают адски тормозить на ровном месте. Впрочем, если ты так уверен в своих словах, может глянешь на код V8 (http://code.google.com/p/v8/source/browse#svn/trunk/src)? Там твои любимые плюсы и (если ты конечно не ошибаешься) простор для оптимизаций — только сядь и начни, остановиться не сможешь
Спасибо
PD>>Сколько там этих объектов (переменных), в обычном файле на js ? Сотни ? Тысячи ? Ну пусть даже десятки тысяч!
KV>А сколько объектов в обычном файле на С++?
Да столько же
PD>>И на это нужны десятки Мб ? По Кбайту оверхеда на текстовую строку ?
KV>А что ты хотел от динамического прототипного языка, который разогнали аки ту частицу в коллайдере?
Скорее от телеги, на которую поставили паровой двигатель, потом сделали несколько топок, посадили по кочегару у каждой и теперь вполне довольны, видя, как эта колымага несется, распугивая лошадей
Здравствуйте, Ikemefula, Вы писали:
I>Код это все что можно выполнить процессорм. Откуда он берется — дело десятое.
И к чему это сказано ?
I>Список фич ты открой хотя бы Сразу найдешь, где там надо кеширование
Загадки мне не нужны, искать неизвестно что я там не буду. Содержимое закачиваемых файлов — не кешируется. А все остальные данные там по объему ничтожны, потому что там просто нечему быть.
PD>>Опять передергиваешь. Я его сейчас посмотрел — при перекачке файла размером в 700 Мб при 10 потоках и скорости примерно 1000 Кбайт/сек он имеет Commit Size по Task Manager 20 Мб. Вполне прилично.
I>То есть "А он ее не расходует." == "Вполне прилично.", правильно я тебя понял ?
Он ее не расходует — это твои слова, ты за них и отвечай. И про 0 тоже . Я просто написал, что расходует он вполне прилично.
I>Ты прыгаешь с одного на другое. JS-код для страницы будет тормозить на старом интерпретаторе, и будет летать на новом (для одно го и того же компьютера; такой бред надо добавлять каждый раз что бы не увилнул на процессоры)
Ладно, хватит. Прочти, что ты раньше писал насчет того, кто летать будет.
I>Нет, не знаешь. Потому что при сравнении JS vs JS у тебя вдруг появляется разница в процессорах.
И что ? Если я утверждаю, что один JS на процессоре 100 MHz работал быстрее, чем другой JS на процессоре 3 GHz — так вообще нельзя ?
I>Да, только так и можно сравнивать, что бы выяснить, какой интерпретатор работает быстрее.
I>Например, полезного кода одна комманда "MOV EAX, EBX". Интерпретатор для выполнения этого кода будет выполнть еще кучу всякого мусора, а JS-машина возьмет да заджитит и получится оверхед время джита поделить на количество вызовов.
Уф... Этому уже 15 лет, еще первая Ява это умела, а как бы и не Бейсик.
I>Вот это и нужно сравнивать. А свои "BC тогда и VC сейчас" сравнивай сам.
А почему все же ? Результаты не нравятся ?
PD>>Да пусть хоть html вместе с js и css и чем там еще хоть 5 Мб на страницу. Компиляция 5 Мб в BC 3.1 на стареньком компе шла со свистом лет 10 назад.
I>И какая связь между интерпретацией JS и компиляцией в BC 3.1 ?
Ох...
PD>>Сравнил. Просто посчитал число плюсов у Delphi и JS. Крестики и +/- не учитывал
PD>>Delphi 33 PD>>JS 26
I>А теперь выбрось из дельфи всё, чего не было в турбопаскале. Ну и учти, что JS — это сильный полиморфизм и функциональное программирование.
Выбрасывать нет времени. Заменяю Turbo Pascal на Delphi 1.0. Работала на 2 Мб. Язык практически тот же.
I>Интересно, каким образом ты хочешь что бы я тебе объяснил, если ты не можешь разобраться ?
PD>>Бред не бред, а ты ясно сказал — "Каждая из этих оптимизаций прибавляет по n-байт в рассчете на объект или коллекцию". Это PD>>Можешь ее просто решить с конкретными данными и привести результаты ? Без того, чтобы объяснять мне, чего я не понимаю.
I>1000 это был _частный_ случай и выяснилось, что разбираться для тебя это невозможная деятельность
Ладно. Пожалуй , хватит. То мне предлагается сравнить с Delphi, а потом оказывается, что коль сравнение не в твою пользу, то надо чего-то убирать из Delphi. То 1000, на которую ты уповал, вдруг оказалась частным случаем (это еще полбеды), но вот посчитать для этого частного случая ты упорно не желаешь, а вместо этого оказывается, что виноват я — я, видите ли, должен разбираться в каких-то тегах и укрепленных таблицах, не имея понятия, что это такое. Довольно. Продолжать не стоит.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Код это все что можно выполнить процессорм. Откуда он берется — дело десятое.
PD>И к чему это сказано ?
Сложно проверить вверх по ветке ? Речь про расход памяти в рантайме.
PD>Загадки мне не нужны, искать неизвестно что я там не буду. Содержимое закачиваемых файлов — не кешируется. А все остальные данные там по объему ничтожны, потому что там просто нечему быть.
В списке фич чуть не буквально написано
I>>То есть "А он ее не расходует." == "Вполне прилично.", правильно я тебя понял ?
PD>Он ее не расходует — это твои слова, ты за них и отвечай. И про 0 тоже . Я просто написал, что расходует он вполне прилично.
Фразы "А он ее не расходует." и ""Вполне прилично." принадлежат Павлу Дворкину в контексте флешгета.
Так понятно ?
I>>Ты прыгаешь с одного на другое. JS-код для страницы будет тормозить на старом интерпретаторе, и будет летать на новом (для одно го и того же компьютера; такой бред надо добавлять каждый раз что бы не увилнул на процессоры)
PD>Ладно, хватит. Прочти, что ты раньше писал насчет того, кто летать будет.
Будет ли интерпретатор летать, меня неинтересует. Меня интересует, что бы программы летали, который он будет выполнять.
PD>И что ? Если я утверждаю, что один JS на процессоре 100 MHz работал быстрее, чем другой JS на процессоре 3 GHz — так вообще нельзя ?
Нет. Сравнение процессоров отдельно, JS — отдельно. Хочешь, можешь учесть влияние процессора, но это не так как ты предлагаешь.
I>>Например, полезного кода одна комманда "MOV EAX, EBX". Интерпретатор для выполнения этого кода будет выполнть еще кучу всякого мусора, а JS-машина возьмет да заджитит и получится оверхед время джита поделить на количество вызовов.
PD>Уф... Этому уже 15 лет, еще первая Ява это умела, а как бы и не Бейсик.
JS 10 лет назад никто не джитил. Сейчас джитят, но не знаю, джитит ли хром.
I>>Вот это и нужно сравнивать. А свои "BC тогда и VC сейчас" сравнивай сам. PD>А почему все же ? Результаты не нравятся ?
Потому что ты не обозначил четкий проверяемый результат и ценность этого результата.
PD>Выбрасывать нет времени. Заменяю Turbo Pascal на Delphi 1.0. Работала на 2 Мб. Язык практически тот же.
В TP хорошо если была половина фич от Delpi, так что ему до JS как до небес.
I>>1000 это был _частный_ случай и выяснилось, что разбираться для тебя это невозможная деятельность
PD>То 1000, на которую ты уповал, вдруг оказалась частным случаем (это еще полбеды), но вот посчитать для этого частного случая ты упорно не желаешь,
Вообще то если ты не заметил, то ровно строчкой ниже было объяснение
В том конкретном случае где было в 1000 раз больше нужно было кешировать результаты всех основных операций примерно на 10-15 вариантов параметров.
В итоге потребление памяти выросло с 1,5мб (голые структурины) до 1.5 гб(+кеширование), все это единственно для того, что бы UI не тормозил.
Здравствуйте, Mamut, Вы писали:
M>Пустой фотошоп спокойно отжирает 130 метров памяти. Компилятор С++ — гуано, однозначно.
Слушай, не смеши. При чем тут компилятор ? У меня сейчас фотошоп не установлен, посмотреть не могу. Запусти на него dumpbin, а лучше Process Explorer, и посмотри, что там в этих 130 Мб. Там скорее всего несколько Мб кода (не считая, конечно, кода системных DLL), а остальное — либо массивы данных, либо ресурсы. Вот они там зачем в таком объеме для пустого фотошопа — это действительно вопрос, но уж никак не к С++, а к авторам фотошопа. Я тоже могу сделать приложение мастером VC++, добавить массив на 100 Мб и будет тебе 100 Мб памяти.
PD>>Хе-хе. JS тут верно, ни при чем. А вот что касается вызовов броузера — нечего было так качественно броузеры писать. Едва ли броузер сложнее ОС. Но ОС писали специалисты, умевшие обращаться с памятью (ее тогда мало было), поэтому там все продумано сначала, а потом написано. А IE писали сами знаешь кто, а Chrome писали , когда память перестала быть ресурсом. Ну и получите свое. А мы (пользователи) в результате получим ваше.
M>Угу. Давай, ты сначала напишешь браузер, а потом будешь их ритиковать Я как-то не собираюсь их критиковать, потому что примерно представляю фронт работ, что там нужен.
Тоже хорошая аргументация, ничего не скажешь. Есть работа, на которую нужны сотн человеко-лет. Возьми и сделай ее. А раз не можешь сделать — не смей критиковать то, что сделано.
PD>>Догадаюсь. Хорошо они сделаны, тоже догадаюсь.
M>Гораздо лучше, чем ты можешь себе представлять.
Ну уж если лучше, чем я могу себе представить — значит все, приехали.
M>Да-да. Прибегая к любимым здесь автомобильным ассоциациям: Разницы между фордом T и subaru outback'ом ты тоже не видишь. Ту же четыре колеса и руль, ага.
А все же можно без аналогий объяснить, что же такое особо ценноеза последние 10 лет появилось в почте ?
>>>Еще навреное уже тогда Facebook существовал в нынешней инкарнации — с динамикой, мгновенными нотификациями и т.п. Ага-ага, верю.
PD>>Вот тут не знаю, ибо им не пользуюсь.
M>не существовал, ибо существовать не мог. Любой браузер загнулся бы.
Хм. Я вообще с ним не знаком. Дай ссылку. Гд-то у меня валялся NN 4.7. Попробую под виртуалкой.
PD>>Ну так нечего было давать писать броузеры тем, кто это делать не умеет.
M>Могу предположить, что создававшие их люди слегка более компетентнее тебя в создании браузеров
Несомненно. Но это ровным счетом ничего не значит. Быть компетентнее меня в написании броузеров для их разработчиков — заслуга небольшая, потому что я броузеры не пишу. Это примерно то же самое, что быть компетентнее меня в области самолетостроения — этого слишком мало, чтобы делать самолеты
PD>> А что тут такого ? Интерпретаторы этим всю свою историю занимались, на то они и интерпретаторы. Даже какой-нибудь GW-Basic на 64 Кб это умел. Чистый интерпретатор берет строчку исходного текста, строит машинные команды, исполняет. Полукомпилятор хранит еще и кэш этих кусков машинных команд, чтобы повторно не интерпретировать. Из 5 Мбайт исходников на каком угодно языке (хоть на асме) этих машинных команд можно создать не более 1-2 Мбайт. В чем проблема-то ?
H>Проблема прежде всего в том, что чем высокоуровневее язык, тем больше байт/маш-кода он будет порождать (разумеется, если система команд VM достаточно низкоуровневая).
Несомненно. Вот тебе простой пример. Был когда-то язык Альфа, так в нем можно было матрицы перемножать вот так
a:= b*c;
при том, что это именно массивы, а никакие не классы. Понятно, что тут генерируется много кода.
Но к JS это вряд ли относится. Впрочем, я готов уступить. Пусть не 1-2, а 5-10. Это мало что изменит.
>Один пример. Может ты знаешь, для Delphi был давно написан интерпретатор диалекта Паскаля — Interfuse PascalScript. Cейчас это RemObjects PascalScript. Так вот у него, из 4Mb скрипта получается 10Mb байткода
Незнаком. Пусть так. Все равно так 100 Мб не сделать.
I>Конечно непродуктивная — у меня примерно 10 лет работы с вещами вроде DOM, а у тебя всего лишь "БД R/O в памяти".
Я думаю, не зная того, что я делал и не говоря толком ничего о том, что ты делаешь сам, едва ли стоит меряться.
I>Мне лично жалко что потерял на тебя время и это при том, что судя по Философии этого и следовало ожидать.
Ok. Давай больше дискутировать не будем. Ты не будешь терять время, я — тоже.
. Нечего там во flashget кешировать — 2 раза я один и тот же файл не качаю, а если и качаю, то все равно нельзя кешировать и незачем.
Поэтому ниже его сокращенная часть, ибо задолбался и времени нет. По ходу разберемся 
