Хочу я в этом сообщении, о байтофобах рассказать. О тех, кого камнями срать ресурсоемкость заставляет и ни на миг не отпускает их тяга все критиковать. Такой запустит хром внезапно и в тот же миг сорвется в крик: "Здесь только что был целый гиг!!! Куда падлюка хром (би-бип!) 100 метров кровных отожрал? Я ж ничего не открывал?! Ну почта, новости — не в счет... Вот с хера хром так много жрет?!". И невдомек ему что хром, о безопасности радея, приватность холя и лелея, процессы пачкой создает для каждой вкладочки, плагина и рендера, чтоб тот терпила не схлопотал руткит в ядро. Но байтофобу все равно, что безопасность на пределе, что разработчики сумели, достичь ее за счет затрат. Он никогда не будет рад, пока не сосчитает байты. Поштучно. В каждой планке, блджад. Ему насрать на безопасность, на компиляцию скриптов, на то, что хром один таков, что рвет на клочья файрфоксы, сафарей, опер и ослов. Для байтофоба нету слов "разумность", "целесообразность", он видит лишь во всем опасность для милых его сердцу байт, и пофиг что текущий сайт, чуть не воткнул ему трояна: тут байт осталось очень мало, а вы здесь про какой-то сайт... Ему бы в руки красну-книгу — он и туда вписал бы байт, чтоб разработчиков загномить, заставив байты экономить: "from night to night we pray in byte!". А гномить байтофоб горазд: он и по попе их, и словом, и даже яйца оторвать, грозится... и руки не даст, тому кто байты не считает, и байтоложством не страдает, и душу байту не продаст. И непонятно байтофобу, что цели есть и посветлей, разумней, чище и добрей, чем тупо экономить байты, чтоб через 10 лет издать, полудоделанную альфу, зато ужатую раз в дцать.
Скажи мне чудное виденье (раз предо мной явилось ты), готово ль ты нести кресты за появление согласных в рассаднике твоих идей, считающих "пхыпы с апачем" уделом истинных мужей? Ты ль спиногрыз потом за ними, полезешь баги подчищать? А уязвимости латать? Зачем вот так, на ровном месте, умы на байты разлагать? Нет, я не спорю, что культура работы с памятью должна, не побоюсь этого слова, привита всем в районе лба. Ведь я, как можешь ты заметить, про аську слова не сказал, а в адрес хрома свой оскал — засунь себе подальше в кучу, пока GC не оторвал...
Здравствуйте, Pavel Dvorkin, Вы писали:
М>>куда конкретно уходит память -- тут нужно смотреть сорцы. могу сказать, что в js много не уходит. во всяком случае сам двиг не сильно прожорливый. разве что запускают кучу его копий... PD>Смотреть сорцы я не буду. Подождем, пока кто-нибудь ответит на этот вопрос. Может быть
Я на этот вопрос ответил только в этом топике уже раза 4, навскидку Ок, еще раз, последний, очень подробно и по полочкам. Считай это ответом и на все остальные твои сообщения тут, на которые я не успел ответить.
Там нет магического "массива данных", который чудесным образом сжирает эти 100 мегабайт при 4 открытых вкладках. Там огромное количество объектов, каждый из которых, сам по себе не такой уж и тяжелый. Вот как выглядит "куча" для вкладки, в которой открыт gmail: http://files.rsdn.ru/24665/chrome_memory3.png (к сожалению, выгрузить это в какой-либо формат хром не позволяет, а скриншотить все раскрытое дерево — увольте. Поэтому если что, то ставь хром и сам смотри). "Куча" написал в кавычках, потому что это куча не в терминах С++, эта та часть плюсовой кучи (а если быть совсем точным, то куча TCMalloc(http://goog-perftools.sourceforge.net/doc/tcmalloc.html), которая содержит только объекты webkit и v8, непосредственно описывающие DOM и скрипты. Тем не менее, общее представление о том, куда уходит память она дает. Обрати внимание на бары со статистикой внизу.
Проще всего обвинить разработчиков хрома в криворукости и неумении разумно использовать ресурсы, ориентируясь при этом исключительно на собственный багаж знаний и опыта, в которых при этом нет, ни работы со структурами, хотя бы издалека похожими на DOM, ни реализации и даже понимания принципов функционирования современных сред исполнения динамических языков, ни, наконец опыта проектирования безопасных систем, судя по всему. Павел, я не пытаюсь принизить твой профессиональный уровень или поставить под сомнение само его существование. Никто не может постичь все и вся за столь короткую жизнь. Пусть меня поправит Козьма Прутков, если я не прав. Но имея весьма серьезный опыт в несколько другой области, с твоей стороны довольно странно так беаппеляционно утверждать, что хром весь из себя не оптимизированный и что подобные затраты памяти не могут быть оправданы в принципе. Ты не можешь дать адекватную оценку, но не потому что ты непрофессионал. Ты всю жизнь строил боллиды F1, но здесь мы обсуждаем вопросы проектирования агропромышленного комбайна, если позволишь провести аналогию
Знаешь что будет, если ты засядешь за разработку собственного браузера? Скорее всего, ты начнешь с движка рендерера страниц. Напишешь довольно быструю и нетребовательную (по сравнению с WebKit) к памяти версию, да. Но потом внезапно окажется, что строить DOM надо по еще не полученному до конца файлу. Упс. Особенно если учесть, что без закрывающего тэга строить дерево элементов, вложенных в текущий очень неудобно, особенно, когда не знаешь, где он появится. Особенно, если ты его так и не получишь, а изобразить в итоге хоть что-то будет надо (ибо конкуренты умеют). Возможно, тебе придется строить дерево откатов, содержащее поддеревья, находящиеся "под вопросом", возможно ты найдешь более оптимальное решение этой проблемы. Но "чутка" памяти ты себе под это заберешь. Не сможешь не забрать. А потом выяснится, что в большинстве случаев, получаемый тобой HTML код не является валидным с т.з. действующих стандартов (коих их вообще-то не один и конкуренты поддерживают каждый). Если ты будешь плевать на такой код, твоим движком просто никто не будет пользоваться. Тебе придется решать проблему того, как строить DOM из всего этого говнокода (причем динамически, в соответствии со сказанным в предыдущем пункте). Уже на этом этапе тебе придется переписывать все заново, если ты заранее не озаботился этой проблемой. И новая реализация будет еще более требовательной к памяти, либо еще более тормознутее на твой выбор. Чудес не бывает, платить приходится за все. А скорее всего, ты придешь к наблюдению в своей реализации обоих эффектов одновременно. Не потому что она плохая, а потому что корректное (с т.з. его автора) отображение среднестатистического HTML-кода — задача, достойная систем ИИ, между прочим.
И все бы ничего, но построить дом мало, надо еще посадить дерево и вырастить сына. Без поддержки скриптов твой DOM никому не будет интересен. Эта поддержка заключается по большей части в реализации API для доступа скриптов к событиям DOM и его свойствам (как на чтение, так и на запись). Ты набросаешь свою первую реализацию V8 в соответствии с озвученным тобой же принципом "интерпретатор берет строчку исходного текста, строит машинные команды, исполняет" и будет сильно удивлен, когда только инициализация jquery у тебя закончится, в лучшем случае, в течении 3-4 минут. Отпрофилировав все, что только можно, ты увидишь, что один из наиболее серьезных затыков у тебя возникает при вызове GetElementById из javascript. Ты заведешь в своем webkit'e оптимизированную напрочь в виде массива хэштаблицу с айдишниками всех элементов и указателями на их адрес в куче. И с ужасом осознаешь, что скрипты могут (и должны) выполняться не только после полной загрузки страницы, но и во время нее. Т.е. тебе придется если не перестраивать, то постоянно актуализировать эту таблицу по мере построения DOM. А ведь javascript будет выполняться совсем не в том же потоке, что и построитель DOM, на секундочку. А актуализация таблицы проходит слишком долго для того, чтобы все это время держать блокировку, не давая изменить там что-либо скрипту. Как ты будешь обеспечивать целостность?
Глядя на скорость выполнения скрипта в твоем движке, ты с тоской подумаешь о старых добрых временах, когда писал на паскале, который, по сравнению со всем этим, работал просто молниеносно. И начнешь искать пути компиляции скрипта в машинный код, чтобы добиться приемлемой производительности. А как ты скомпилируешь в машинный код скрипт на языке, в котором делать какие-либо предположения о типах ты можешь только в рантайме? В языке, где понятие "описание класса" отсутствует как класс (уж прости за тавтологию), где все объекты строятся динамически, а наследование представляет собой создание копии объекта и наполнение его новыми членами прямо на ходу, во время исполнения скрипта? В итоге ты придешь к тому, что тебе будет необходимо хранить кучу хэштаблиц для обеспечения более-менее приемлемого по времени доступа к членам объектов. Опять затраты памяти, опять не такие уж и несущественные. Но если тебе по-настоящему захочется порвать всех конкурентов по быстродействию, то ты будешь вынужден создавать снапшоты каждого объекта при каждом изменении и хранить хэштаблицу этих снапшотов для того, что при доступе к членам объекта (или внезапном создании наследника от него) быстро выбирать необходимый для этого снимок.
Ок, остается сын. Грош — цена твоему решению, если эксплуатация любой из допущенных тобой в коде уязвимостей (что неизбежно, учитывая сложность реализации всего написанного выше) приведет к компрометации если не системы пользователя, то хотя бы всего твоего браузера. И, почитав умные книжки и даже научные работы на эту тему, ты придешь к решению разделить приложение на две логические части: ту, которая будет работать с недоверенными данными, но обладать минимумом прав в системе и другую, которая должна обладать правами в системе, ибо браузеру без этого никак, но которая не будет работать с недоверенными данными. Тебе придется изолировать их друг от друга и реализовать механизм безопасного обмена данными между этими двумя частями. Заметь: безопасного, т.е. недоверенных данных по каналу обмена уже ходить не должно. Вот тогда тебе и придет в голову завернуть процесс, лишенный прав (ты же пошел грамотным путем и реализовал изоляцию этих частей через разнесение их по различным процессам?) в некую виртуальную среду, которая позволит разграничивать права этого неблагополучного процесса, в т.ч. и в части отправки информации по каналу обмена. Это если ты захочешь порвать конкурентов, а так да — конечно можно, как ты и предложил выше, запихать все в один процесс и уповать только на DEP и ASLR. Иного уровня безопасности в однопроцессной модели ты не можешь получить даже теоретически (скажи спасибо тому, кто придумал что "все является массивом данных"). А реализовав многопроцессную модель (и намучившись с принятием решения о том, как же именно разделять по процессам твой код), ты поймешь, что и данные, используемые различными "недоверенными" процессами тебе придется в них дублировать, иначе никакого толка от такого разделения попросту не будет.
И нет ничего странного в том, что затраты памяти в окончательной версии будет отличаться на порядок от твоего исходного, "оптимизированного" варианта.
Все сказанное выше — весьма неполная подборка проблем, которые должны решить те, кто занимается созданием современного браузера. Странно только, что это понимаю я, ни разу не программист, но не понимаешь ты. Я ведь даже не "разработчик языков программирования" я так, "пристально за ними наблюдающий" в лучшем случае.
PD>>Я же ясно сказал — серьезные программы. Для поделок (а тем более TSR, помнишь их ?) — могут в
I>С одной стороны, ты понимаешь, что программы различаются по серьезности.
I>С другой сторны, как только доходит до расхода памяти, ты вдруг отказываешься это понимать.
I>Как быть и не знаю.
PD>>Объем кода вообще ничтожен по сравнению с объемом данных. Написать 100 Кб кода — это ты быстро не сделаешь, это десяток тысяч строк. А массив в 100 Кб — пустяк, превратить его в 1 Мб массив, если понадобится — раз плюнуть.
I>А если генерировать код, что тогда ?
Тогда, извини, это не код. Это данные, которые обрабатываются специальным образом. Текст на JS — это не код, а данные для интерпретатора (или как он там) JS.
PD>>Что касается кеширования вместо вычислений — да, но далеко не везде есть это кеширование и вычисления тоже. Мне как-то трудно понять, что же там можно кешировать или вычислять, скажем, в flashget
I>Неправильно думаешь. Тебя должен интересовать один вопрос — какое направление оптимизации выбрали для написания флешгета.
Правильно думаю . Нечего там во flashget кешировать — 2 раза я один и тот же файл не качаю, а если и качаю, то все равно нельзя кешировать и незачем.
I>Вот когда ты это установишь наверняка и ознакомишься с кодом, тогда можно говорить, что де флешкгет расходует память зазря.
А он ее не расходует.
I>>>Быстродействие JS увеличилось примерно на порядок. Еще раз — быстродействие JS, а не процессора.
PD>>А процессора по сравнению с 90-ми — на 2 порядка. Плюс многоядерность. Так что прежний интерпретатор (если бы он был хорошо написан) должен был бы и без всякой компиляции на нынешних Athlon/Dual/i7 летать.
I>Будет летать, а программы на нем будут ползать по сравнению с современными JS-машинами на "нынешних Athlon/Dual/i7"
Каких еще программ ? Если имеем дело с чистым интерпретатором, то его работа и есть исполнение программы
I>>>Считаешь, что старый браузер супротив нового на том же компе будет зависеть от процессора ?
PD>>Не понял вопрос. Как можно зависеть или не зависеть от процессора на том же компе ?
I>Все ты понял. Нечего валять Ваньку.
Глупо. Я действительно не понял.
I>Если сравнение JS vs JS, то очевидно, остальные параметры эквивалентны или их влиянием можно пренебречь.
I>Но тебе толи хочется повыступать, то ли увильнуть, и ты вводишь спам про процессоры.
Да какой к черту спам! Я тебе ясно объяснил свою мысль — о том, что скорость процессора резко возросла, а поэтому старый интерпретатор должен работать в N раз быстрее, чем в 90-е годы. Вот и все.
PD>>Да бога ради, 50-100 Кб — на здоровье. Что тут особенного ?
I>Особенного здесь тот факт, что JS-кода сейчас на порядки больше чем 10 лет назад, и работает он много быстрее относительно одного и того же процессора.
Что значит его больше ? На HTML-странице ? На порядки — это что, в 100 или 1000 раз ? Если 10 лет назад на странице было 5 Кб, то сейчас 500 или 5000 ? Ты вообще много файлов .html видел размером в 500 Кбайт ?
Поосторожнее с порядками!
I>>>И работали они тогда крайне медленно.
PD>>Ничего подобного. ТурбоПаскаль очень быстро работал. Найди его и запусти, убедишься сам. Он на Ямахе (2MHz, 64 Kb) компилировал 2000 строк за десять секунд.
I>Это и есть крайне медленно. Во первых, язык был убог. Во вторых, оптимизаций считай никаких не делалось.
Язык Turbo Pascal с классами (object) был более убог, чем JS ? Не смеши!
PD>>А вот тут опять же поподробнее. А вот если в 1000 раз больше — давай сюда свой расчет памяти.
I>Ага, щаз, перечислить тебе все виды оптимизации которыее вводились за несколько лет ?
Имеешь полное право не перечислять. Но и я имею полное право при этом твоим утверждениям не поверить.
I>Ты в своем уме ? Каждая из этих оптимизаций прибавляет по n-байт в рассчете на объект или коллекцию.
I>По одной — ничего, все вместе — может и в 1000 раз.
И сколько нужно оптимизаций, чтобы увеличивая на n, получить увеличение в 1000 раз ? Пусть изначально было 100 байт. На первой оптимизации добавили, допустим, еще 100. Итого в 2 раза. На второй еще 100. Теперь в 3 раза. Сдается мне, что надо 1000 оптимизаций, а поскольку не всякая оптимизация прибавляет байты (скажем, замена пузырька на quicksort их вообще не добавляет), то и все 2000. После этих 2000 оптимизаций вся программистская конница и вся программисткая рать в этом коде разобраться не сможет
I>>>Например понадобится доступ к элементам O(1) при том что коллекции у каждого элемента всегда должны быть отсортированые. Или окажется что порядок следования в коллекции не должен меняться.
PD>>Доступ за O(1) при том, что при каждом добавлении тебе придется либо пересортировывать либо сдвигать ?
I>Имеется ввиду доступ на чтение. Хештаблица — медленное решение. Предложи лучше.
Совокупность массивов указателей на общие данные.
I>Балансировалось только под оптимизацию по быстройдействию.
Я понимаю. То есть тебе поставили условие — выжать максимум скорости без ограничений по памяти. Знакомо.
PD>>Это и было и есть не так, потому что писали это и пишут черт те как.
I>Это тянет на д'Артаньяна в стране Каналий
У меня что-то сегодня ассоциации плохо работают
PD>>Ну знаешь, если ты пошел по пути приведения примеров и при этом запрещаешь мне их обсуждать, то лучше было бы тебе их и не приводить. А то как-то неэтично получается.
I>Нормально получается. Я знаю, сколько какая из оптимизаций прибавляет к расходу памяти и эти самый оптимизации могу перечислять десятками точно.
I>Ты кажду будешь мусолить ?
Нет, не буду. Но имея десятки оптмизаций и прибавляя на каждой n байт, очень сложно увеличить расход памяти в 1000 раз
PD>>Я понятия не имею о твоей модели (и о задаче), так что мне это совсем ни к чему.
I>Вот я тебе и говорю — не надо обсуждать примеры.
I>>>После всех оптимизаций модель больше похожа на БД в памяти. Ты представляешь, что такое БД ?
PD>>Нет. Никогда их не видел и о них не слышал. . Тебе обсудить что-то хочется или поерничать ?
I>О том и речь, что ты говришь о том, чего не знаешь.
Слушай, ты вообще серьезный человек или нет ? Ну что ты ерунду-то говоришь! Что я не знаю ? Или ты впрямь решил, что я никогла БД не видел ?
I>>>Модель загоняю в БД на SQL Сервере, получается около 100 мб, а в текстовом виде и сто килобайт не наберется.
PD>>Вот именно, типичный пример. 0.01% данных и 99.99 % накладных расходов. Лей память, лей, чего ее жалеть!
I>Да, именно так. Потому что имеет смысл тольк одна оптимизация — под быстродействие.
Оптимизацию под быстродействие совсем не всегда необходимо сочетать с дополнительным расходом памяти. Можно изменить алгоритм, лучшим способом разместить данные и т.д. Кстати, увеличивая расход памяти, уменьшаешь и быстродействие иногда — на обработку этой дополнительной памяти нужно время.
I>>>В памяти конечно нет 100 мб, мне индексы не нужны, но около 20мб имеется.
PD>>0.05% и 99.95%
I>Да, примерно так. И меня абсолютно не удивляет, почему Хром жрет память.
Дв и меня не удивляет. Только вот причины этого неудивления у нас с тобой различны
I>Это десктоп приложение, посмотри на тренд — доля Хрома растет со страшной скоростью.
I>Это самый быстрый браузер из аналогичных по функционалу и скорость окупается.
I>Оптимизация под память затребует дополнительных усилий и времени. За счет чего — выбирать не из чего, или функционал или перформанс.
S>Бытует мнение однако, что все вот эти извращенья — не треба, если поднатужить и выдать код без дырок в шкуре. Скажу тебе еще, отаку. Ты, друг, ударившись в усмешки — забыл что кроме веб-смотрелок вокруг еще немало софта. Забыл ты браузера цели: рендерить всякое — во первых, а во вторых следить за кодом. Зачем следить — отлично знаешь. S>А ты взгляни на ту
проблему, на мессенжер нерукотворный. Скриптов там нет, нет гипертекста, нет стилей, флеша, сильверхрени, но всеже, бооже, сотню метров ему скорми и улыбайся. S>Ты говоришь про байтофобов, но говоришь не в том контексте. Контекст смени и станет ясно.
Сменю контекст и станет ясно
(Скажу я это без прикрас),
Что в жоре памяти повинен
Лишь богомерзкий сипласплас,
Что тут воспет неоднократно,
Тобой лишь только раз мильон,
Он память жрет в поганых кедах,
И в Хроме, падла, тоже — он.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Куда падлюка хром (би-бип!) 100 метров кровных отожрал? Я ж ничего не открывал?!
Разве забыл ты, когда-то считалось,
Что шестиста сорока килобайт
Хватит с лихвою на всё. Нынче та ось
Вслух только лишь при атаке на сайт
Упоминается. Как же так вышло?
Думаешь, что безопасности для
Был комманд-лайн принесён в жертву мыши
И для удобства пользóвателя?
Как бы не так! Многотонные монстры
Ленью на свет порождаются, и
Чем разобраться и сделать всё просто —
Легче к ним вновь прилепить костыли!
И в результате они гадят в память,
Виснут и падают, и тормозят.
Тут получается не безопасность,
А скотоложество и гей-парад!
Плавает, с перьями, крякает — утка,
Сто мегабайт — это не воробей.
Если программа стартует минуту,
Пофиг что там, её просто прибей.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
I>>>Ты в курсе, что программа на ассемблере, текстовый вьювер, занимает памяти на порядки меньше с++ варианта. PD>>Нет. Это совершенно неверно. Он не только на порядки, он даже и в 2 раза больше не занимает.
I>Напиши на с++ вьювер ровно в 300 байт
Я же ясно сказал — серьезные программы. Для поделок (а тем более TSR, помнишь их ?) — могут в разы, да. Но если программа на С++ занимает хоть 1 Мб, то на асме ты ее в 500 Кб не уложишь. В 800- возможно. Ну а под Windows определенное место займут системные DLL, это вообще от языка не зависит.
А для программ размером в 300 байт — ладно, 1 Кб дам. Но 2 не дам
>>Объем кода серьезной программы на С++ по сравнению с объемом кода на асме незначительно (на проценты, от силы десятки процентов) больше, а объем данных и ресурсов от языка не зависит : массив в 100 Кб займет 100 Кб, опиши его хоть на С, хоть на Паскале, хоть на асме.
I>Об чем речь — чем _серьезнее_ программа, тем больше объем кода и вобщем то расход памяти. Чем больше памяти — тем больше можно кешировать вычисления вместо вычислений.
Объем кода вообще ничтожен по сравнению с объемом данных. Написать 100 Кб кода — это ты быстро не сделаешь, это десяток тысяч строк. А массив в 100 Кб — пустяк, превратить его в 1 Мб массив, если понадобится — раз плюнуть.
Что касается кеширования вместо вычислений — да, но далеко не везде есть это кеширование и вычисления тоже. Мне как-то трудно понять, что же там можно кешировать или вычислять, скажем, в flashget
PD>>Каждому юзеру вполне хватило бы, я так думаю, 16-32 Мб за глаза. Хватало же, когда памяти на машине было именно столько. Что с тех пор радикально нового в JS появилось ?
I>Быстродействие JS увеличилось примерно на порядок. Еще раз — быстродействие JS, а не процессора.
А процессора по сравнению с 90-ми — на 2 порядка. Плюс многоядерность. Так что прежний интерпретатор (если бы он был хорошо написан) должен был бы и без всякой компиляции на нынешних Athlon/Dual/i7 летать.
I>Считаешь, что старый браузер супротив нового на том же компе будет зависеть от процессора ?
Не понял вопрос. Как можно зависеть или не зависеть от процессора на том же компе ?
PD>>А если не секрет, на что он там ее увеличивает ? Вычисления обычно не в JS, а на сервере делают.
I>Вот так откровение. Открой чуть не любой сайт — JS этого бывает по 50 и даже 100 кб самое обычно дело и это не на сервере а вбраузере выполняется.
Да бога ради, 50-100 Кб — на здоровье. Что тут особенного ? Что я, файлы на С/С++ размером в 100 Кб не видел, что ли ? И компилировал их ТурбоС на 1 Мб ОП в DOS со вполне приличной скоростью. А TурбоПаскаль так просто летал.
I>>>Может и уже джитят, не уверен. Если джитят — то памяти просто должно расходоваться очень много.
PD>>А компилятор с Фортрана в 70-е годы работал на 256 Килобайтах. А ТурбоПаскаль с ООП в 80-е годы на 1 Мбайте. Во сколько раз JS сложнее ТурбоПаскаля ?
I>И работали они тогда крайне медленно.
Ничего подобного. ТурбоПаскаль очень быстро работал. Найди его и запусти, убедишься сам. Он на Ямахе (2MHz, 64 Kb) компилировал 2000 строк за десять секунд.
I>>>DOM-модель это уже не XML, это объктна модель где объекты соответсвуют элементам xml.
PD>>Это я все знаю, поверь.
I>Не похоже.
Что не похоже-то ? Я же тебе ниже все написал.
PD>>Об XML я говорил, имея в виду его как источник данных. Вот есть у тебя, к примеру. 1 Мб XML файл. Там строки, числа и т.д. Построили из него дерево. Сколько памяти это дерево должно занимать ?
I>Зависит от функционала модели и оптимизации. Может и в 1000 раз больше быть.
А вот тут опять же поподробнее. Дерево я тебе приводил, оверхед там рассчитал чуть ли не с калькулятором. А вот если в 1000 раз больше — давай сюда свой расчет памяти.
I>Например понадобится доступ к элементам O(1) при том что коллекции у каждого элемента всегда должны быть отсортированые. Или окажется что порядок следования в коллекции не должен меняться.
Доступ за O(1) при том, что при каждом добавлении тебе придется либо пересортировывать либо сдвигать ?
Я не спорю, такое возможно. Но ИМХО тут надо как следует задачу перепродумать и структуры данных. Слишком уж разбалансированное решение получилось.
>>Я так полагаю, что примерно тот же 1 Мб, ну пусть раза в 2-4 больше (на всякие там ссылки, может, в текстовой форме меньше памяти уходило, допустим). А вот больше — под что ????
I>Это еще 10 лет назад было не так. Качни любой парсер, который DOM-умеет, да открой 100 мб xml, памяти у тебя ведь больше 1 гига ? Стало быть за глаза хватит
Это и было и есть не так, потому что писали это и пишут черт те как.
PD>>Да бога ради. Вот тебе классическое двоичное дерево. Ссылки на родителя в нем обычно не хранят — и так хорошо. Расход памяти на узел
I>У тебя возникли какие то проблемы со фразой "(просьба примеры не обсуждать, они взяты немного из другой области, не DOM)" ?
Ну знаешь, если ты пошел по пути приведения примеров и при этом запрещаешь мне их обсуждать, то лучше было бы тебе их и не приводить. А то как-то неэтично получается.
I>Тебе что, перечислить все возможные оптимизации которые я делал для ускорения модели ?
Я понятия не имею о твоей модели (и о задаче), так что мне это совсем ни к чему. Я тоже делал всякие оптимизации для ускорения, потому что от меня эту скорость именно и требовали, но все же памятью не бросался , хотя мне никто ограничений на этот счет не делал.
I>После всех оптимизаций модель больше похожа на БД в памяти. Ты представляешь, что такое БД ?
Нет. Никогда их не видел и о них не слышал. . Тебе обсудить что-то хочется или поерничать ?
I>Модель загоняю в БД на SQL Сервере, получается около 100 мб, а в текстовом виде и сто килобайт не наберется.
Вот именно, типичный пример. 0.01% данных и 99.99 % накладных расходов. Лей память, лей, чего ее жалеть!
I>В памяти конечно нет 100 мб, мне индексы не нужны, но около 20мб имеется.
Здравствуйте, Erop, Вы писали:
E>Ну ты же очень резко против ворда 10+-летней давности? То есть примерно так 7-го. Наверное есть причина?
Ты дурак ?
I>>И поэтому люди просиживают в социальных сетях чуть не все рабочее время ? E>Очень сильно не все люди. В соц. сетях могут просиживать те, кто не работают, и делают это за компом, к тому же.
Те, кто сидят в интернете, в основном на социальных сервисах — форумы, сети, игры, блоги и тд.
E>Вот прикинь, сантехник, водитель, артист балета, операционистка в банке, комбайнёр, и вообще почти всё сельское хозяйство, строитель, военный, и очень много кто ещё не просиживают рабочее время в соц. сетях.
Почему обязательно в рабочее ? Есть коненчо люди которые мало пользуются инетом, но на них никто и не ориентируется.
E>В советское время была аналогичная тема -- курилка. И что, ты утверждал бы, что курение необходимо для общения?
Курилка нужна для того, что бы люди не курили где попало. Курилки полезны для здоровья тех, кто не курит.
I>>Попробуй подумать, что побуждает тебя писать столько сообщений. Может у тебя какая то другая потребность но она тем не менее есть. E>Я знаю что, но обсуждать это не буду.
Главное что она есть, а уже потом ты удовлетворяешь её на форуме.
I>>В социальных сетях люди развлекаются, общаются и тд. Ничего удивительно — усилий ноль, эффекта море. E>Всё ровно наоборот. Усилий море тратится, а эффекта -- 0.
Ты вероятно кирпичи таскаешь когда на форуме сидишь ? Не знал.
I>>Я не считаю что это дрянь. И я хорошо понимаю, что если люди просиживают целые дни в социалках, то они точно обрадуются мессенгеру, который интегрирует эти социалки в одной программе. E>Ну вот ты тоже сознательно готов подсаживать людей на то, что сам ты называешь дрянью...
"Я не считаю что это дрянь." а ты пишешь "что сам ты называешь дрянью.."
У тебя какие то проблеы с русским языком ?
E>Ты правда думаешь, что в "одноклассниках" люди общаются с одноклассниками? Разве что, в смысле с "представителями своей соц. группы"
Я правда думаю что это социальный сервис для общения. А одноклассник это только один из примеров.
E>Кстати, с одноклассниками через много лет общаться нифига не круто.
И потому такие сайты популярны ?
I>>Ну так я тебе давно сказал, что ты в конуре живешь. Хочешь рсдн интегрировать — открой для себя рассылку, ннтп или рсс хотя бы. E>Нет, так интегрировать я не хочу. Я хочу "из коробки"
Контингента слишком мало, что бы интегрировать это дело в какую толковую прогу.
I>>Я вроде уже говорил, что есть нефункциональные фичи, до тебя это никак не дойдет. E>Я так понимаю, что ты так называешь "бантики" они же "свистелки и перделки" и фичи вроде "общая эргономичность".
Точность в файне это свистелка и перделка однвременно, правильно понимаю ?
E>Дык вот, "общая эргономичность" она либо навязана рекламой, либо сильно индивидуальна.
Я не удивлюсь, если все морды для сайтов что ты делал окажутся говном.
Эргономика это простые наблюдения — одному пользователю надо кликнуть дважны на каждую фичу, другому — по разу или восе не нужно. Первый делает вдвое меньше, чем второй или устает сильнее при одинаковом результате или делает ошибки чаще.
Вот это — эргономика. А то про что ты говоришь — говно.
E>А "бантики" нужны, в основном, только потому, что они модные, то есть разрекламированные... E>Если ты имеешь в виду какие-то ещё "нефункциональные фичи", то расскажи о них
Точность в твоем файне. Риббон в офисе. Засечки на шрифте для удобного чтения.
E>А ты как считаешь, какой процент пользователей выбрал iPhone потому, что сравнил несколько моделей, попробовал то и сё, заценил фичи, цены, и прочие свойства продукта и ОСОЗНАННО выбрал, а какой потому, что стало модно?
Большинство этого не делает, полагается на интуицию. Интуицию рекламой и тд не обманешь.
А вот сознательные выбиратели сначала прочитают про многозадачность или ММС или разъемы, а потом бегут искать такую строчку в спецификации и обламываются.
E>Да ну. Вот тот же самый аймобилко с его проблемами с антеной, которую не видно из кулачка. Ради "бантика" пожертвовали основной функциональностью -- устойчивостью связи. И прикинь, да, прокатило. Не отзывали трубу, не было массовых возвратов и т. д.
Не пори чушь. Держал я этот телефон в руках и как только ни зажимал.
Проблема состоит из 2х частей.
Софтовая — уровень сигнала неправильно показывается
Аппаратная — на слабом сигнале если взять потной ладонью антена перестает работать.
Так вот цырк на счет антены просто форумны хайп и ничего больше.
E>А почему собственно? Да потому, что у айМобилко основная функциональность -- это демонстрировать продвинутость владельца. А надёжная и качественная связь -- пофигу.
А еще ифон четвертый держит связсь стабильнее чем 3гс.
I>>Я уже давно определился и внятно объяснил. E>Ну ты то говорил, что лишние фичи -- это основная нерешённая проблема современного софтостроения, а теперь говоришь, что не мешают. Какое-то противоречие усматриваю я в словах твоих
Противоречие исключительно у тебя в голове, тут я бессилен.
I>>Про офис. Ты ведь рассказывашеь, что никаких фич не добавилось Они добавились, только ты про них не знаешь. E>Не-не-не. Я рассказываю что никаких НУЖНЫХ МНЕ не добавилось
А ты то здесь при чем ? Или всем надо на тебя равняться ?
I>>Перечитай предыдущее сообщение, а то твои слова на генератор бреда похожи. E>Попробуй найти курсы, где учат вести себя корректно...
Ты это, знаешь ведь мою манеру общения, хрена лезешь ?
I>>Риббона не хватает, банально, да ? E>Риббон -- прямое следствие перегруженности фичами. Было бы фич в 10 раз меньше, было бы хорошо и без него.
Сейчас практически все редакторы умеют такие фичи. Редактор делает редактором именно набор фич.
Если ты в машине ездишь один и сиденья с багажником тебе не нужны, то это вовсе не значит, что автомобиль перегружен фичами.
E>Не. Ты утверждаешь, что 1997 (это, видимо, 7-й?) было невозможно пользоваться. Я хочу понять почему. Я так понял, что из-за того, что уже и 7-й был перегружен фичами? Да?
В основном неудобно было. Постоянный негатив. Представь себе, я анализом именно вордового вопроса не занимался.
I>>Это ты так думаешь. Между тем файн это набор фич, функциональных и нефункциональных. E>А откуда ты это знаешь? Я вот, например, ежегодно общаюсь с людьми. которые фичерлист на след. версию согласовывают
А что тут знать то ? А в каждом софте так.
E>Точность -- это основа маркетинговой политики файна. Это самое главное, что там есть. Самая суть. И разрабы это хорошо понимают и за каждую долю процентика удавятся. А ты, такой умный, рассказываешь мне, что это нефункциональная фича, якобы, и что она сильно не одна.
Это именно нефункциональная фича. Ведь работал же файн раньше с меньшей точностью и аналоги его рабтают с меньшей точностью и ничего.
E>Ну и кому мне верить? Тем, кто непосредственно фичерлист составляют, или твоему анализу? E>Я, кстати, ещё одну фичу забыл -- файн хорошо сканирует для целей OCR. ФСЁ.
И каждая из фич единственная_что_ажно_других_нет, правильно я тебя понял ?
>Остальные фичи, вроде поддержки албанского языка или возможность выбора шрифта для показа текста без форматирования -- это всё неважные мелочи. Покупателям на них глубоко пофиг. Не пофиг на них журналистам, которые пишут обзоры. Хороше, если по чесноку пишут, а не прикормленные какие...
Мелочи вобщем то тоже важны. Что там с албанским — не знаю.
I>>Только что сказал, что в файне только одна и единственная фича и тут же про вторую рассказываешь. E>Как я написал выше, есть ещё и третья. Но конкретно вторая, сильно уступает по важности первой. И в хомяке, кстати, её нету.
Да, и каждая по отдельности — единственная. Можешь не продолжать.
То фичлист — то единственная фича Ты бы определился.
I>А юзабилити -- это вообще полностью неверифицируемое понятие.
Верифицируемое абсолютно и полностью.
>Если у чела создать уверенность, что если ему неудобно держать аймобилко так, чтобы оно ещё и связь не теряло, то это он урод, а не аймобилко гавно. То он немедленно САМ СЕБЕ "признается", что на самом-то деле ему удобно, конечно.
Это возможно ты про себя говоришь.
E>Конечно разные. Но это не мешает смотреть на конкретные истории конкретных людей. А не на "людей в среднем". У людей в среднем, как известно, одно яйцо и одна грудь...
Если сравнивать табурет с бегемотом то так и будет.
E>Конечно, только ты пропускаешь ещё один момент. На самом деле деньги делятся не так. Пишется одна, которая как-то удовлетворяет 75%, а потом ещё рекламой с PR дожимают до того, что 95% думает, что их удовлетворяет. А 5% просто идут лесом...
Это каменный век.
E>Потому, что конкуренты тоже метят в эти 95%, а не в 5% оставшиеся
Метят, только деньги снимает узкий круг лиц который и рекламы может не раздавать.
I>>Иди купи автос и скажи что бы выкинули три сиденья да багажник, потому что ты де в одиночку хочешь кататься и тебе все это не надо E>У меня был автомобиль без переднего пассажирского. ВАЗ 2108... E>А ещё пикапы бывают. Типа есть два сиденья, а всё пространство сзади -- под груз.
Пикап это неинтересно, вот как у Калины на котрой Путин катался, только чтоб без сидений и багажника.
I>>Набор обязательных фич. И пользователю это выгоднее, потому что мелкие редакции гораздо сложнее продавать, сопровождать, разрабатывать и тд. E>Я вот не понимаю, какой смысл ты вкладываешь в это "выгоднее"? Типа простой редактор будет стоить дороже ворда? Что-то как-то не верю...
Простой редактор уже есть. Их целые вагоны. И здесь заработать невозможно.
Потому если МС начнет дробить ворд на редкаторы, они ничего не заработают, апользователю получат геморрой с совместимостью
E>Возможно я как-то не так понимаю, кто такие "друзья", но вот лично мне для переписки с друзьями десятки программ не были нужны никогда. Мыла и обычной гражданской почты всегда хватало...
Ну так я уже говорил — ты ретроград.
I>>Все это доступно из почтовика. 10 лет назад здесь нужно было минимум 6 програм. Сейчас это один сайт — gmail. E>И как и когда это всё "экономит время"? IMHO гмыл заточен под УНИЧТОЖЕНИЕ времени!
Ты головой то думай. Пользователь решает, на что тратит время.
Ему хочется початиться — значит полезное время это чат, а не инсталяции клиентов и настройка.
I>>А это не твоё дело. Главное что он потратил время как ему надо, а не на ожидание обновление страницы, что было нормой 10 лет назад. E>При чём тут выделенное? E>Попробуй по каналу, который был 10 лет назад, и на компе, который был 10 лет назад с гмылом поработать, узнаешь как много времени ты сэкономишь...
А ты попробуй откопать почтовик который умеет ровно столько, сколько умело говно вроде майл.ру 10 лет назад.
Такого и даром не нужно.
E>У меня, кстати, в домашнем хозяйстве вполне используются и более старые компы. И я НЕ ИСПЫТЫВАЮ НУЖДЫ в их апгрейде...
А поставь ты на них ДОС так хватит еще и твоим правнукам пользоваться.
I>>Маркетологам известно, что фича это только то, чем можно легко и просто пользоваться. E>Не, это то, что можно легко впарить.
Это возможно в России такой маркетинг.
I>>Ты дурак или у тебя с русским языком проблемы ? E>Напиши, пожалуйста, письмо модераторам, и попроси тебя забанить. E>Либо извинись.
Тут одно из двух — или ты дурак или у тебя с русским проблемы.
Раз ты оскорбился, стало быть ты выбрал вариант не про русский, правильно ? Модераторам пиши сам.
I>>Нет здесь никаких тонкостей. Риббон 10 лет назад при всем желании нельзя было родить. E>1) Почему? E>2) Зачем нужен Риббон, если нет перегруженности фичами?
Потому что риббон это вобщем то инновация. Инновации не рождаются тогда когда ты этого хочешь.
I>>Только на короткое. А дальше надо удерживать качественным исполнением. E>А дальше нужно впаривать следующую версию, а не удерживать
Это в России наверное так — впаривать, впаривать и еще раз впаривать.
I>>Размеры, цвет, углы наклона руля. А ты купи машину с тремя колесами или без сидений и багажника. E>Без сидений -- легко. Пикап видел?
Это неинтересно. Я хочу или мерседес какой или Калину как та на котрой Путин ездил.
E>Без багажника -- тоже легко. Машинки ультракомпактные видел E>С тремя колёсами -- тоже легко. Просто такие ТС принято называть мотоциклами. E>Ещё пожелания будут?
см выше
E>Ещё ты можешь захотеть, без тормозов, например, но такую тачку нельзя будет эксплуатировать. Так что тоже не будет ОСНОВНОЙ ФУНКЦИОНАЛЬНОСТИ. Ферштейн?
Ты правильно понял, что такое автомобиль. Осталось понять, что такое текстовый редактор.
Редактор это набор основных фич + фич которые решают сопутствующие задачи + нефункциональные.
Если например окажется что люди пишут тексты что бы паблишить в блогах — то появляется соответсвующая фича.
Это было в ворде.
А если окажется, что эти люди пользуются тольк ограниченым набором функций — для них будет сделан отдельный продукт.
Это Writer.
А если окажется, что если просто ведут заметки и надо копипастить откуда угодно — это onenote.
E>Ты в целом, хотя бы, понимаешь, что рынок браузеров и рынок тачек как-то по разному устроены? Что производители браузеров все хотят сделать топ модель феррари, а производители тачек пытаются угадать, что будут брать.
Производители софта все до единого хотят сделать топ-софтину в своем классе.
Отдельные индивидуумы рожают кастрированые недоподелки, авторы которых рассказывают о том, как неправильно двигается прогресс.
I>>А цена пользователям до фени или нет ? E>Нет, не до фени. Но покупают они автомобиль, а не запчасти.
Это до первого ремонта так.
I>>Война точно такая же и фичи точно так же постепенно мельчают, как с офисными пакетами. E>Да ну? Ну покажи мне маркетолога, который впаривает тачку потому, что органы управления расположены революционно-новым мега-удобным методом?
Уже пройдено гдето в 30-40х.
E>А вот на риббоне своём MS целую версию залудила
И правильно сделали.
E>Что-то я не понял о чём ты. Я утверждаю, что на рынке легковушек конкуренция в первую очередь идёт по РЕАЛЬНО нужным фичам. И только во вторую фичам, которые определяют степень модности. При этом перегрузка фичами -- это скорее плохо, чем хорошо. E>А вот в ПО всё ровно наоборот.
Это потому что ты плохо понимаешь пользователя. Точнее недостаток информации о пользователе ты заменяешь примерами из личного опыта.
E>Что-то я не понял. Ты хочешь сказать, что у ворда есть его, обязательный для него фичерлист? Или ты что-то другое хотел сказать?
Да. Посмотри что умеют редакторы вроде тех что есть ОО или Лотусе, подумай.
Но я сомневаюсь, что это даст эффект.
Во первых, лотус ты качать не станешь, а во вторых у тебя мега идея "навязали" которая объясняет абсолютно все, в т.ч. и прямо противоположное.
I>>Стоимость владения разная. Бензином ты за год можешь половину стоимости авто потратить. А железо компьютерное стоит буквально копейки. E>Кому как. Я вот знаю много людей, которые на комп детям КОПЯТ...
Много. Но тех, кто может купить комп с одной-двух ЗП прмиерно в 100 раз больше.
I>>ничего удивительного нет, нельзя человека описать одной формулой, как тебе хочется. E>Где это ты увидел, что мне это хочется? Мне наоборот не нравится то, что рынок ПО повернулся к тому, что все пишут один и тот же клон ворда, совершенно не понятно для чего, кстати.
А ты попробуй задаться изучением вопроса вместо выдумывания мега-теорий вроде "навязывают".
I>>"навязать" == конспироложество. E>Ты не веришь в то, что существует PR и реклама?
Это работает совсем не так, как ты думаешь.
I>>Сходство и тогда и сейчас — еда вызывает положительные ощущения, организм вырабатывает стимул в виде эндорфинов при поступлении еды. А разница в том, что зрелищами насытиться не получится. E>Зато едой не получится развлечься. И от депрессии она не помогает, а наоборот, вредит, в отличии от общения. И что?
вообще то вкусная еда способна безо всяких добавок вызвать эйфорию. Ты думаешь гурманами просто так становятся ?
E>Почему сейчас в еде система ценностей консервативная, а в развлечениях инновационная?
В еде нет никакой консервативности. Я сейчас жру то, что 10 лет назад и в помине не было.
E>Про энергию не понял. Какой энергии? Психической? Лично меня комп более 8 часов в день выматывает, например...
Да, заметно, а я то думал, откуда столько ахинеи.
I>>Удобно, что не надо на себе нести 100 кг аппаратуры. В дом идти никто не запрещает. А к выхлопам городские привыкли. E>А! Так это всё та же модель PR-навязывания! Типа "принюхайтесь и сразу полюбите"
Счиаешь, что если пиарщики не скажут, что 100кг носить на себе тяжело, то люди и не догадаются ?
E>Кстати, неужели у тебя автомузЫка 100 кило весит? Обычно там весьма посредственные динамики + компактный уселок.
Не у меня. В тех случаях про которые я говорю — примерно столько и весит. Сабвуфер, куча колонок и всякая дрянь — занимает чуть не весь багажник, остается место для запаски разве что.
E>Нормальный бумбокс с отстёгивающимися колонками рвёт почти любую автомузыку. Места занимает мало, весит тоже. Да и стоит немного. Его можно просто на даче хранить, кстати...
Он рвет обычную автомагнитолу. А я говорю по специальную технику, которая мало чем отличается от тех что на концертах играют.
E>Но если мы всё ещё про дискотеку на даче, то не совсем понятно, какая разница скока в салоне? Важно скока СНАРУЖИ...
Снаружи хватает на целую площадку, при том так что разговаривать достаточно сложно.
I>>Ты не видел хорошей акустики вероятно, когда весь багажник под сабвувер, колонки и прочую дрянь. E>Пардон, а зачем это вообще надо? В смысле когда машину как ТС юзают? Кроме того я не верю, что вот этакую хреновину часто юзают для выездов на дачи. А шашлыки они как везут? На коленках, да? Или они просто с колёсами приезжают, закидываются и втыкают под сабвуфер?
А шашлыки едут в другой машине.
I>>Я втыкаю антену в комп и не надо ничего администрировать, только тюнер запустить E>Не-не-не! Это не телевизор. Это комп. Ты про телефизор расскажи! Или ты как с вордом, "лет 10 не пользовался уже"?
Я не знаю, сколько щас чего в телевизорах, нет у меня такого устройства.
I>>Старьё. E>В смысле? 2009 года выпуска.
Русский язык придумали в России, но, похоже, не для всех.
Здравствуйте, Ikemefula, Вы писали:
PD>>Ну а что касается процесса под вкладку — извини, но ты тут просто демонстрируешь незнание базовых механизмов. Если запустить несколько процессов на базе одного и того же EXE (и DLL) , то все read-only данные (код, ресурсы, константы и т.д.) будут в ОП в одном экземпляре. А те даннные, что не будут в одном экземпляре — их что в одном процессе создавай в нескольких экземплярах, что в разных по одному — черт один. Вот тебе банальный пример. Программа , обрабатывающая картинки. Что 10 процессов запусти и каждому по картинке дай размером в 4 Мб, что один процесс с 10 картинками по 4 Мб — все равно 40 Мб получится.
I>То есть, проблема в том, что если ты не знаешь, на что программисты потратили память, ты счиатешь, что они дураки и потратили память зря потому что на твой взляд столько памяти не надо ?
А без демагогии можно ? Я спросил — на что они потратили ? Можешь сказать что-то по существу ? В применении к безопасности, о которой идет речь.
I>Как думаешь, можно ли движок джаваскрипта ускорить за счет расхода бОльшего кол.ва памяти ?
Можно. Равно как, думаю, можно и без — если написать как следует. Вообще-то интерпретатооры умели писать и раньше, и работали они достаточно быстро. А с тех пор быстродействие процессоров очень — таки возросло, а язык JS вроде как не очень усложнился...
I>Как думаешь, можно ли например DOM-модель ускорит за счет бОльшего расхода памяти ?
А вот тут, пожалуйста, поподробнее. Что за такие дополнительные данные в таком объеме потребовались ? Объем собственно данных (ну из того же XML, к примеру) определяется ими самими. Если собственно данных имеется под 100 Мб — тогда и говорить не о чем. Но не об этом случае речь. Поэтому, пожалуйста, сообщи, сколько памяти занимают собственно данные (строки, числа и т.д.) и что за накладные расходы понадобились в таком объеме ?
Павел, ты не поверишь. Я написал за пол-дня большую часть развернутого ответа тебе, а потом случайно закрыл янус Поэтому ниже его сокращенная часть, ибо задолбался и времени нет. По ходу разберемся
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>И на это нужны десятки Мб ? По Кбайту оверхеда на текстовую строку ?
А что ты хотел от динамического прототипного языка, который разогнали аки ту частицу в коллайдере?
Приветствую, Mamut, вы писали:
M> Сменю контекст и станет ясно M> (Скажу я это без прикрас), M> Что в жоре памяти повинен M> Лишь богомерзкий сипласплас, M> Что тут воспет неоднократно, M> Тобой лишь только раз мильон, M> Он память жрет в поганых кедах, M> И в Хроме, падла, тоже — он.
Мамут, ты дико предсказуем, и я тебе твердить устал, что Багдасысом именуем ты здесь. О, как же ты достал )))
Здравствуйте, Pavel Dvorkin, Вы писали:
KV>>Ну почему же не может? Есть такое понятие как "пик рабочего набора", есть "частный набор", по ним вполне можно оценить аппетиты хрома по отношению именно к ФАП. Нас ведь именно это интересует?
PD>Опять ты запутался. Про рабочий набор смотри вот здесь
PD>http://rsdn.ru/forum/dotnet/1869304.1.aspx
PD>Там, конечно, не результат моих исследований, а компиляция из Соломона-Руссиновича. Если хочешь, прочти в оригинале.
Если ты про "внутреннее устройство Windows", то я ее как бы читал, если что.
PD>Коротко — рабочий набор не является вообще характеристикой процесса, а является характеристикой поведения менеджера памяти Windows. При одном и том же размере выделенной памяти (commited) рабочий набор может отличаться в разы.
А нам интересно, что происходило в ВАП процесса или как его прожорливость по памяти отразилась на других процессах?
PD>Частный набор не имеет отношения к РН. Частный набор (черт бы побрал русскую терминологию здесь, она и на английском хорошо запутана) , если ты имеешь в виду Private Bytes — это объем коммитированной не-shared ВП.
Частный набор — это не private bytes. Это Private Working Set — часть рабочего набора, включающая в себя страницы, присутствующие в ФАП и используемые только этим процессом. Другая его часть — это Shareable Working Set — часть рабочего набора, включающая в себя страницы, присутствующие в ФАП, которые могут использоваться не только этим процессом.
PD>Если коротко.
PD>Private Bytes — управляю я. Без моего ведома ни один байт не освободить.
Это столбец "Private" раздела "Virtual Memory" на скриншотах.
PD>Shared Mem — управляю я, но отчасти и система (просто потому, что шарит хотя бы код системных DLL) PD>Working Set — я совсем не управляю, могу только рекомендовать, а Windows на мои рекомендации может наплевать. PD>Поэтому первые 2 — характеристика моего процесса, а третье — совсем нет.
Эти характеристики не дают ровным счетом ничего, если рассматривать их в разрезе влияния на доступность ФАП для других процессов.
KV>>Павел, не поленись, прочти этот документ: http://www.chromium.org/developers/design-documents/sandbox , думаю это снимет большую часть вопросов. А если заинтересует глянь этот проект: http://code.google.com/p/sandboxed/ — это песочница, отцепленная от хрома для использования в собственных приложениях. А если будет совсем интересно, то тут (http://code.google.com/p/chromium/wiki/LinuxSandboxing) реализации песочниц используемые в хроме под линукс.
PD>Все смотреть не стал, глянул начало первого документа и все стало ясно. Ничего тут нового нет. На уровне 3 кольца люди пытаются создать свою архитектуру.
Да именно так.
PD>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. PD>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
PD>Все. Дальше можно не читать. При этих базовых посылках я заранее знаю, что они могут сделать. Они могут как угодно разделить те или иные действия или ответственность между своими процессами, создать механизмы взаимодействия, определить, кто чем занимается и т.д. На здоровье.
Как это "на здоровье"?! А где же "вау! да здравствует самый безопасный браузер в мире"?!
PD>Правда, так и остается непонятным, почему тут нужны десятки и сотни Мб. Модель безопасности Windows осталсь практически неизменной от 3.1 до XP включительно. То есть она работала так же в 1994, как сейчас, при 16 Мб памяти. Едва ли она намного проще чем то, что они сделали в Хроме. Почему же там хватало 16 Мб под всю ОС, а тут нужно 100 под один броузер ?
Ты почему-то считаешь, что речь идет только о накладных расходах, связанных непосредственно с созданием нескольких процессов вместо одного, но это не так. Вот представь, что в одном процессе (ОС) рендерер подгрузил jquery. Выполняя код, он построил развесистые и весьма тяжелые структуры, необходимые V8 для быстрого исполнения скрипта. В этот момент, ты открыл в другой вкладке еще один сайт, другой, но тоже использующий jquery. Файрфокс или опера имеют возможность использовать уже построенные для этой библиотеке бэкендовые структуры, чтобы сэкономить на памяти и времени, необходимом для их построения. Хром — не может. Поэтому он снова загрузит исходник jquery (возьмет из файлового кэша, скорее всего) и заново построит все структуры в АП процесса нового сайта.
Я говорю о подобных расходах, которые являются прямым следствием мультипроцессности и платой за безопасность.
PD>Что касается механизма целостности — это лишь небольшая пришлепка к собственно механизму безопасности Windows, едва ли его реализация увеличила размер кода, отвечающегго за безопасность, очень уж заметно.
Механизм целостности — это и есть механизм безопасности Windows (одна из его частей), а не пришлепка. И я бы не назвал реализацию практически мандатного доступа "небольшой пришлепкой"
KV>>Механизмы всегда реализуются руками или все же логика взаимодействия?
PD>Еще раз цитирую из твоей ссылки PD>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. PD>Если они свои механизмы синхронизации сочинили вместо ивентов и семафоров, то я им сочувствую.
Они сочинили свой кроссплатформенный и безопасный RPC, если тебе будет угодна аналогия.
KV>>Ты говоришь о процессах ОС и совершенно прав. Давай теперь введем такое понятие как "хромпроцесс", не имеющее отношения к процессам ОС? PD>Маленькое замечание : хромпроцесс неизвестен ОС Windows.
И не должен быть известен. Хромпроцесс — это абстракция, позволяющая отцепить значительную часть кода от используемой в конкретном случае хромовской модели управления процессами.
PD>Поскольку ОС Windows ничего не знает о хромпроцессах, ей нет дела до этих песочниц. Можете заворачивать что угодно во что угодно — Windows на это плевать.
И?
PD>Слушай, зачем ты мне банальные вещи рассказываешь ?
Потому что ты мне тоже их рассказываешь
PD>Я это все 15 лет назад знал.
Я тоже, только лет 10 назад, к твоему сведению.
PD>Хочешь — открой несколько окон, запустив несколько процессов. Хочешь — открой несколько окон, запустив по потоку в процессе и по окну в потоке. В первом случае падение одного процесса не влияет на остальные. Во втором падает весь процесс со всеми потоками. Я это упражнение студентам лет так 10 даю (только вот окно не броузера), что тут за открытие Америки ?
KV>>А если учесть еще и то, что между некоторыми рендерами необходимо обеспечивать возможность доступа из javascript одного к DOM другого...
PD>И что ? Для этого нужно 100 Мб ? LPC/RPC/OLE/COM уже отменили ?
Под линуксом?
PD>А запросы из Word в Excel тебя не удивляют ? А вставка таблицы из Excel в окно моего приложения не удивляет ?
Если реализуешь это под линуксом, но с вордом и экселем — удивит.
KV>>Я говорил о "хромпроцессах" PD>Если речь идет о Windows, то это все равно верно.
Речь не может идти только о винде, т.к. хром кроссплатформенен.
>>И, в результате, получился движок, порвавший в клочья все существующие по скорости выполнения скриптов.
PD>Что немудрено, если принять во внимание качество исполнения их.
Что не так с качеством их исполнения? Очень качественно исполняются, на мой, дилетантский, взгляд
PD>>>И на это нужны десятки Мб ? По Кбайту оверхеда на текстовую строку ? KV>>А что ты хотел от динамического прототипного языка, который разогнали аки ту частицу в коллайдере? PD>Скорее от телеги, на которую поставили паровой двигатель, потом сделали несколько топок, посадили по кочегару у каждой и теперь вполне довольны, видя, как эта колымага несется, распугивая лошадей
Я рад, что ты понял основной принцип оптимизации исполнения динамически-типизированного кода Что, впрочем нисколько не умаляет достоинств динамической типизации (интересно, закастится сейчас сюда Wolfhound или нет?).
Здравствуйте, Pavel Dvorkin, Вы писали:
KV>>Не понимаешь. Либо лукавишь, не соглашаясь со мной, т.к. это взаимоисключающие друг-друга поведенческие модели PD>А можешь допустить, что понимаю по своему ?
Я не только допускаю это — я это знаю Они взаимоисключающие лишь с моей точки зрения, т.к. ни один человек не в состоянии оценивать окружающую его реальность адекватно, не опираясь при этом на опыт, полученный им в течении его жизни. Опыты, полученной мной и тобой, существенно отличаются, что и вылилось в предмет нашего спора, но это не говорит о неправильности или некорректности одного из них. То, что я считаю взаимоисключающими поведенческими моделями для другого человека может являться нормой жизни, состоянием, в котором он ежедневно живет и в ус не дует. Именно поэтому, для человека важна способность уметь оценивать чью-либо точку зрения, опираясь не на свой опыт, а на опыт этого человека, но для этого необходимо принять на веру, что этот опыт является правильным, даже если со стороны твоего опыта это не так.
Но вообще, я бы предложил не развивать эту тему. Дело в том, что я сегодня проходил ежедгодный профосмотр, а параллельно делал себе справку, чтобы продлить водительские права. И вот там, психиатр доумился спросить у меня, считаю ли я себя нормальным. Поскольку через минут 10 меня грубо прервали, вписали мне практически насильно "здоров" и попросили выйти — я не наговорился и чувствую в себе неудовлетворенное желание до конца развить мысли, которые мне так и не дали высказать
PD>>>Понимаю, что не могли авторы языка в 1996 году создать его в расчете на необходимость 100 Мб, потому что и памяти такой даже в фантазии тогда не было.
KV>>Когда они создавали этот язык, он был не более чем средством сделать выпадающую менюшку или падающий на странице новогодний снег (с не более чем полусотней синхронно двигающихся снежинок, ибо иначе начинались жуткие тормоза).
PD>Вот именно. И нечего его было применять для других целей. PD>И нечего было его для этого использовать. Нетрудно понять, что для таких целей надо не интерпретатор использовать. PD>Объясни мне бога ради, для чего ты это говоришь. Вот взяли бы GW-Basic и начали на нем для расчеты для Саяно-Шушенской ГЭС проводить. И разросся бы он до 500 Мб, и все равно работал бы медленно. И кто тут виновать — автор языка Бейсик или те, кто его использовали для совсем неподходящих задач ?
Погоди. Я нигде не утверждал, что применение яваскрипта в тех задачах, в которых его используют сейчас на клиентской стороне, сколь-нибудь оправдано с технической т.з. Здесь, я склонен согласиться с Wolfhound'ом, использование статического языка может дать серьезный выигрыш как в плане скорости разработки и быстродействия, так и в плане затрат памяти. Не думай, что никто не чешется по этому поводу, буквально в этом году где-то здесь проскакивала ссылка об инициативе по выработке стандарта для облегчения процесса встраивания скриптов на других языках в HTML-документы. Но этот рынок — как маховик, его очень трудно раскрутить, чтобы заставить вращаться. Гуглу вон, пришлось целый браузер разработать, чтобы HTML5 попер в массы (несмотря на то, что пионерами тут пытались выступить эпплы). Но рано или поздно это наступит. А пока, разработчики сайтов вынуждены принимать во внимание тот факт, что js — это единственный язык, скрипты на котором гарантировано запустятся в любом современном браузере. А разработчики браузеров не спешат с революцией, т.к. подводных камней при переходе на статику там будет более чем достаточно, а терять свою долю рынка никто не хочет.
Зато сейчас, мы имеем возможность наблюдать за тем, как из динамического языка выжимается все возможное. Даже то, что еще несколько лет назад считалось невозможным. Это — тоже ценный опыт, между прочим
KV>>При чем тут однопроходный компилятор? Он прямо во время прохода создает описываемые кодом объекты в куче? Изменяет их свойства? Вызывает их методы?
PD>Эх, не программист ты. Ну создает. Ну вызывает. И что ? Что ? На то, чтобы создать — хоть во время прохода, хоть потом — надо sizeof(структуры).
У тебя не будет этого sizeof на данном этапе, в общем случае. Оно появится только в рантайме.
PD>Чтобы изменить — надо функцию вызвать. Скажи на милость, почему это вдруг требует в десятки раз больше памяти, чем если бы сначала создать код, а потом выполнить?
Ты (в смысле не ты, а компилятор) практически ничего не знаешь о типах объектов на этапе компиляции.
PD>А я тут при чем ? Не я это придумал. Я просто вижу, что эти самые дотнетчики, чуть что, начинают укреплять таблицы, добавлялл десятки Мб памяти, и руководствуются при этом именно этим принципом. А что там Игорь изначально имел в виду — это его дело. Благими намерениями... PD>Если бы они и впрямь разумно подходили — так у них расходы памяти и были бы такими же, как в С++. С чего ей расти-то ? Правда, при одном условии — без LinQ. Тут расти будет обязательно — если каждый раз новую структуру создавать вместо того, чтобы старую модифицировать, то без расходов памяти не обойдется. PD>А они обрадовались и вперед. Смотрю я порой на решения, и мне просто страшно становится.
Ты сейчас о чем-то ком-то конкретном? Явно ведь не о хроме (нету там дотнета, ну ни грамма).
"Назовите мне имя это подлеца, сэр!" (с)
KV>>Попробуй открыть эксперимент, описанный по ссылке (http://www.chromeexperiments.com/detail/magnetic/) сначала в IE9 или FF3, а потом в хроме. Сразу поймешь, зачем в нем создаются все эти объекты. PD>Да пойму, наверное. Не в этом же вопрос, а в совсем другом — а написать так, чтобы без такого объема памяти обойтись, можно ? Или в принципе нельзя ?
Не знаю. При условии, что мы вынуждены иметь javascript в качестве скриптового языка — наверное можно еще что-то оптимизировать, заставить хром более ответственно подходить к вопросам освобождения памяти, не используемой в настоящий момент (в нем это уже реализовано, но не включено, нужно запускать с правильным ключем командной строке) и т.п., но не думаю, что это даст существенный выигрыш, т.к. эти затраты памяти обусловлены дизайнерским решением и вполне осознанны. Чтобы серьезно сократить затраты памяти придется пересматривать архитектуру, а она вышла весьма удачная.
PD>Вот ответь мне прямо, недвусмысленно и честно на такой вопрос. Пофантазируем. PD>2000 год. Увеличение объема памяти и быстродействия процессора прекратилось. Ядра не были созданы. Лучшая машина — Pentium III — 667 MHz (у меня была тогда). Все. PD>Ты готов заявить, что невозможно было бы создать ничего , равного по возможностям нынешним сайтам ? Ты готов утверждать, что при 256 Мб Google map или GMail никогда не мог бы быть создан ? Вот скажи прямо — да или нет. Без пояснений. 1 бит.
Я без пояснений не могу, это против моей природы 1 бит — могу, это ответ "нет", мог бы. Но теперь поясню: если бы среда была настолько враждебна (а потребности пользователей бы росли в соответствии с нашим сценарием), то яваскрипт бы просто умер и на его место пришел бы другой более совершенный и приспособленный к этой среде язык. И именно на нем и была бы возможна реализация всех этих вебдванольных примочек. Но в реальности, все произошло несколько иначе и среда не только не вредила яваскрипту, но и всячески способствовала его дальнейшему развитию (стало возможно, разгонять его за счет мегабайтного оверхеда) и именно поэтому мы имеем то, что имеем.
Это эволюция, практически в чистом виде.
KV>>Память — самый дешевый из ресурсов, доступных десктоп-программисту в настоящий момент. Хром появился именно в результате выделенного. Видишь ли, его разработчики не хотели потерять значительную часть своих потенциальных пользователей, которые бы умерли есстественной смертью дожидаясь, пока разработчики наиграются в оптимизации по памяти перед выпуском своего продукта.
PD>Вот именно. Это и есть основной пункт. Вместо качественного написания кода превалирует халтура, потому что халтуру делать быстрее, и можно перехватить часть рынка. Я не спорю, это серьезный аргумент. Но, кроме вопросов рынка и маркетинга, есть еще и технология как таковая. Вытекающая из теории алгоритмов и структур данных. И вот то, что все делалется в ущерб ей, означает, что технология профанируется и дискредитируется. А это даром не пройдет.
Про халтуру вспомню чуть ниже...
>>Я помню тред в гугл-группе о том, как хром с несколькими вкладками отожрал у какого-то чела полтора гига. Можешь себе представить, насколько оптимизирован код в нынешней, 7-ой версии это браузера?
PD>Могу. Делаем автомобиль размером в Боинг-747. Он ездит, распугивая всех на дорогах и не вписывается в повороты. После чего уменьшаем его размеры до Боинга-737 и с гордостью говорим — какие мы молодцы. Он, правда, по прежнему в повороты не вписывается, но хоть не настолько всех пугает.
Про автомобили тоже вспомню...
PD>Устраивает. А вот аргумент твой — нет. Предположим, что не устраивает — что же мне делать ? Все равно придется пользоваться — где я броузер возьму с потребностью по памяти в 10 раз меньше, если бы мне это надо было ? Например, VS меня радикально не устраивает ни по скорости ее работы (IDE, не компилятора), ни по памяти. Но чем я ее заменю ?
У IE8 аж 4 конкурента...
>>А скорее всего, ты и не задумывался над этим вопросом: работает, ну и работает.
PD>Задумывался. Тормозит он хорошо в самых разных ситуациях. Создает черт знает зачем несколько процессов iexplore.exe, так что когда какое-то окно виснет, я сижу и думаю — какой iexplore убить ? И т.д.
Для этого в хроме и сделал свой диспетчер задач. Чтобы не задумываться, какой процесс убивать.
>>Главное ведь чтобы хорошо работал и давал тебе комфорт при посещении сайтов, так? PD>Да. И не отнимал лишней памяти и не устраивал ненужный свопинг.
У меня ни один бразуер ни разу жуткий свопинг не устраивал. Ты серьезно наблюдал подобное?
>>Вообще говоря, в настоящий момент, IE является вторым по защищенности браузером, несмотря на сложившиеся стереотипы. PD>Спорить о защищенности с тобой я не буду, мы явно в разных весовых тут категориях. Отмечу лишь, что защищенность защищенности рознь, и мне не нужна защищенность любой ценой. Я очень хочу личной защищенности, но если мне для этого предложат не выходить из дома, закрыть окна кирпичной стенкой, поставить на входную дверь минное поле, отключить газ и электричество, то я на такую защищенность не согласен.
До тех пор, пока на улицах не услышишь постоянные автоматные очереди. А в интернетах они уже лет 7-8, как не умолкают
>>Тебя еще не смущает, что в нем применяется тот же подход к защите, что и в хроме? До этого момента, думаю, что не смущал, поэтому предлагаю провести простой эксперимент: давай возьмем 4 совершенно голых бразуера (без установленных плагинов и расширений, там где есть предустановленные — выключим нафиг), откроем в них две вкладки — одну с gmail, вторую с google reader и посмотрим как они поведут себя по отношению к затраченной памяти? Готов это увидеть? Voila: http://files.rsdn.ru/24665/browsers_memory.png
PD>А с чего ты решил, что я этот IE защищаю в противовес Хрому ? Мне они оба равно приятны или неприятны. Памяти оба жрут достаточно, ну а насчет качества исполнения — не знаю, IE при всем том. что я писал, меня относительно устраивает, за неимением лучшего.
Не знаю с чего я это решил. Наверное с твоих вопросов о нововведениях в IE8 в "инсталляции и администрировании". А тебя не смущает, что все 4 браузера выдают в общем-то сравнимые результаты затрат по памяти? А opera (внимание: браузер, всегда считавшийся одним из самых быстрых) жрет больше всех. С чего бы?
KV>>Не кажется ли тебе, что проблема все же не в криворукости разработчиков браузеров, а во всех этих ваших консерваториях? PD>Не понял . Каких консерваториях ?
Это у Жванецкого было:
Консерватория, аспирантура, мошенничество, афера, суд, Сибирь.
Консерватория, частные уроки, еще одни частные уроки, зубные протезы, золото, мебель, суд, Сибирь.
Поскольку ты попросил не продолжать развивать эту тему, а я уже успел открыть окно януса для написания ответа тебе, то скажу еще одну вещь, не совсем по теме — чтобы поправить самого себя, и потом умолкну
Не хочу лукавить, я не могу однозначно отнести себя к одному из лагерей систем типизации, хотя и недвусмысленно высказался в прошлом сообщении. Мне кажутся весьма разумными доводы Wolfhound'а, твои и многих других о том, что в динамических языках нет никаких преимуществ. Разбираясь с основами компиляторостроения, пытаясь понять нутря немерла, я стал понимать какие именно оптимизации позволяет провернуть статическая типизация, какие преимущества неизменяемые структуры имеют перед изменяемыми, еще раз убедился насколько глубокую поддержку IDE можно обеспечить в таких языках (первым ярким впечатлением был решарпер) и т.д и т.п. В общем, все то, что в динамических языках если не отсутствует вообще, то хотя бы тяжело реализуемо и совсем не той же степени. С одной стороны...
С другой же, я ежедневно наблюдаю десятки нод телекоммуникационного оборудования, которыми управляет код на динамическом языке. Знаешь что из себя представляет одна такая нода в комании где я работаю? Железку, простой которой в течении 10 минут выливается в тысячи долларов ущерба. Железку, в которой поток трафика идет круглосуточно, обеспечивая голосовую связь тысяч, одновременно активных абонентов. Железку, прекрасно работающие скрипты для которой пишут инженеры, прошедшие базовый курс обучения. Железку, в которой некорректно написанный код не обрушит всю ноду целиком, даже если сильно этого захотеть. Железку, которая никогда не падала за все время моей работы там.
Есть и другие ноды, от другого производителя. Ими управляет код на каком-то подмножестве С++. Не могу сказать ничего плохого о стабильности таких нод. Но любое изменение программного обеспечения там выливается в копеечку, потому что разбираться во всей этой лапше вызовов, ньюансов управления памятью и граблей, связанных с тем, что может натворить глючный код, умеет только вендор этих железок.
Т.е., с другой стороны я наблюдаю применение динамического языка в настолько критичной и нагруженной, а главное реальной системе, что мой разум отказывается принимать доводы, которые приводят сторонники статической типизации. Да, возможно, железки первого типа были блестяще спроектированы и реализованы педантичными шведами, а второго — делали индусы по заказу корейцев, нанятых японцами, выполняющими госзаказ китайцев. Может быть. Но факт остается фактом и его тяжело игнорировать.
Вот поэтому в дальнейшем, я пожалуй воздержусь от критики той или иной системы типизации, но с интересом буду следить за подобными обсуждениями Что же до яваскрипта, то это едва ли не единственный такой язык, прошедший путь от средства реализации микроскриптиков до серьезных серверных систем (я о node.js). Еще и самый распространенный на клиентских системах, между прочим. Раз уж эволюция пошла таким путем, то по-моему он стоит того, чтоб обратить на него свое внимание. Хотя бы, ради получения того самого опыта, которого "никогда не бывает много" (с)
Здравствуйте, Sheridan, Вы писали:
S>Бытует мнение однако, что все вот эти извращенья — не треба, если поднатужить и выдать код без дырок в шкуре.
Те, что тужатся, и через десять лет альфы не увидят.
>Скажу тебе еще, отаку. Ты, друг, ударившись в усмешки — забыл что кроме веб-смотрелок вокруг еще немало софта. Забыл ты браузера цели: рендерить всякое — во первых, а во вторых следить за кодом. Зачем следить — отлично знаешь.
Ну вот, Шеридан головного мозга Это тебе одному браузер ндо тчо бы рендерить да за кодом следить. Задача браузера — доставлять контент и показыват его, а рендеринг это дело десятое.
S>А ты взгляни на ту
проблему, на мессенжер нерукотворный. Скриптов там нет, нет гипертекста, нет стилей, флеша, сильверхрени, но всеже, бооже, сотню метров ему скорми и улыбайся.
Очнись, ICQ это уже давно не мессенгер. И там есть и гипертекст, и стили и много чего еще. На счет скриптов не уверен. Тот же квип занимает памяти всего вдвое меньше а толком то ничего и не умеет
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>И невдомек ему что хром, о безопасности радея, приватность холя и лелея, процессы пачкой создает для каждой вкладочки, плагина и рендера, чтоб тот терпила не схлопотал руткит в ядро.
П>М-м-м... А не запускать хром с правами, дающими возможность записи руткита в ядро слабо?
Давай зайдем с другой стороны: тебе слабо подобрать туда другую рифму, чтобы не про руткиты и ядро? Мне вот лень, например
Здравствуйте, kochetkov.vladimir, Вы писали:
PD>>Ну а что касается процесса под вкладку — извини, но ты тут просто демонстрируешь незнание базовых механизмов.
KV>Павел извини, но то что я не программист еще не значит, что я не в курсе, чем физическое адресное пространство отличается от виртуального, спасибо
Речь шла не об этом отличии.
KV>Твоя ошибка в том, что ты считаешь, что:
PD>>Понимаешь, 100 Мб — это массив данных, и очень большой массив.
KV>а это не совсем массив данных (да и не очень большой, если честно)
Все есть массив данных
KV>Давай разберемся что это:
KV>Павел, обрати внимание на понятия memory и virtual memory.
Вот отсюда я и остановлюсь. Дело в том, что никакого понятия memory в противовес virtual memory в Windows не существует. Что это такое — знает только хром, это его понятие, мне оно неизвестно, поэтому оценить твои последующие рассуждения не могу.
(Если же речь идет о рабочем множестве (working set) — это вообще не показатель, так как может изменяться в очень широких пределах без какого либо участия процесса — просто потому, что Windows решила расширить РМ или , наоборот, отнять страницы).
KV>Смотри, на сколько увеличилось потребление невиртуальной памяти.
Не могу я спокойно на это смотреть — не на картинку, а на твои слова. Нет никакой невиртуальной памяти вообще у процесса, хоть он хром, хоть марганец
>Т.е. как бы той readonly о которой ты говоришь и которую можно было бы замапить в другие процессы, там не так уж и много.
Readonly память тоже виртуальная. Опять ты запутался. Ее не надо мапить в другие процессы — она сама мапится. Более того, это просто нельзя отменить. Хоть он хром, хоть черт лысый, а те страницы, которые readonly, все равно будут в ФП в одном экземпляре. И эти страницы там будут обязательно.
KV>Т.о., как видишь, мультипроцессная модель управления памятью дает весьма приличный оверхед. Каждый процесс хрома (кроме одного — супервизора) оборачивается в песочницу, изолирующую его от остальных процессов куда более гибче, чем это делает та же винда
Для того, чтобы любой процесс изолировать от остальных процессов, не надо никакой песочницы. Он и так изолирован. Наоборот, надо предпринять меры, чтобы иметь общую память. Тот факт, что readonly страницы присутствуют в ФП один раз, в этом плане ничего, абсолютно ничего не меняет. Никакой возможности изменить страницу в чужом процессе нет, пока не предприняты специальные действия. Если их не предпринимать, то нет , и все!
>Все механизмы межпроцессного взаимодействия для этих песочниц реализованы руками
Все механизмы межпроцессного взаимодействия всегда реализуются руками.
>и их необходимо дублировать от процесса к процессу, чтобы повреждение памяти в одном (к примеру) не сказалось на всех остальных.
Повреждение памяти в каком бы то ни было процессе никогда не может сказаться на всех других процессах, если не используется не-readonly общая память.
>Та же фигня и со всеми структурами данных, используемых песочницами и собственно самих данных. Шарить это нельзя, т.к. это сведет на нет все усилия по изоляции процессов друг от друга.
Ты, увы, опять не понимаешь сути. Шарить не то что нельзя или можно — шарить общие данные R/O будет Windows независимо от твоего желания. Просто иначе не бывает. Что же касается R/W данных — их и не надо шарить, и без всякой песочницы их никто не шарит.
Вот смотри
char* p = "Sample";
В процессе A текст "Sample" хранится в R/O памяти,в некоей странице. Это страница ВП, ей соответствует страница ФП. Эта же страница ФП выделена процессу B, и это нельзя отменить!
Если же процесс B попробует изменить общие данные, то возможны 2 варианта. В случае выше просто будет access violation. В других случаях это разрешается, но срабатывает механизм write copy. При этом делается копия страницы и процессу подсовывается эта копия вместо оригинала. Остальные процессы продолжают пользоваться оригиналом. Так что и в этом случае никакого изменения страниц чужого процесса быть не может.
KV>Но ведь это еще не все Javascript в хроме исполняется движком V8 одной из отличительных черт которого является способ представления объектов в памяти процесса. Вместо того, чтобы держать хэш таблицы для доступа ко всем динамическим членам объектов, V8 при каждом изменении какого-либо объекта (например, при добавлении в него нового поля) создает на базе этого объекта т.н. скрытый класс, унаследованный от текущей структуры объекта, который в дальнейшем используется в качестве прототипа при создании новых объектов и для доступа к его членам. Это позволяет избежать поиска динамических членов по всей цепочке иерархии и существенно ускорить доступ к членам (т.к. эти скрытые классы еще и джитятся в нативный код), за счет опять-таки, затрат памяти, т.к. всю эту иерархию нужно хранить на протяженнии всего жизненного цикла скрипта (ибо таков суровый мир динамических языков). Мне лень делать скриншоты (кому надо — проверят сами), но разница между открытым gmail в режиме html-only и его представлением по умолчанию измеряется не одним десятков мегабайт, именно за счет того, что броузеру не приходится плодить все эти скрытые классы:
Вот именно. Вместо того, чтобы оптимизировать код и найти оптимальные алгоритмы, пошли по пути захвата лишней памяти. Сколько там этих объектов (переменных), в обычном файле на js ? Сотни ? Тысячи ? Ну пусть даже десятки тысяч! И на это нужны десятки Мб ? По Кбайту оверхеда на текстовую строку ?
Здравствуйте, 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'е браузеров.
Ну так нечего было давать писать броузеры тем, кто это делать не умеет.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Ты все еще продолжаешь жить в мире 640кб.
PD>Как ты думаешь — используя такие аргументы, можно хоть чуть-чуть добавить правоты свому мнению ?
Здравствуйте, WolfHound, Вы писали:
PD>>Несомненно. Для этого и аргументировать не надо. Кстати. я и не говорил в этом топике ничего про быстродействие. Я тут обсуждал объем памяти. Мне тут упорно доказывали, что без десятков, а то и сотни Мб никак с этим js и программой на нем справиться невозможно. А вот это никакие хеш-таблицы не объяснят. Да, память под объект несколько увеличится, но лишь несколько, а не в сотню раз. WH>Эти мегабайты нужны для того чтобы избавится от хеш-таблиц. WH>По той ссылке что я тебе дал очень подробно рассказывается как конкретно это делается.
Ссылку я смотреть не могу, но вот маленький, совсем маленький вопрос задам.
За год до этого была выпущена Windows 95, которая вполне успешно работала на 8 Мб ОП, а на 16 Мб чувствовала себя просто-таки великолепно. IE и NN там тоже чувствовали себя не плохо.
1 Гб ОП для 1995 года — величина фантастическая, таких винчестеров тогда не было. Про 4 Гб и говорить не приходится.
Тактовую не помню, но вроде как это время появления Пентиума. Значит, гд-то под 100 MHz.
О многоядерности и речи не было.
А интерпретатор с JS как-то работал. И программа тоже.
Прошло 15 лет, и оказалось, что без десятков, а то и сотни Мб никак не обойтись. И без 3 GHz. И без 4 ядер.
Так вот.
Не могли авторы языка в 1995 году закладывать в него или что-то с ним связанное с потребностью в 100 Мб. Просто не могли и все! Если бы они предложили язык, для работы с котороым надо иметь 100 Мб — они бы просто в посмешище превратились. Не было такой памяти! И рассчитывать. что тактовая увеличится в 30 раз, они тоже не могли — не было еще закона Мура, в течение 80-х и начала 90-х тактовая росла медленно (помню 386-40, потом 486-66, потом P-70, потом P-100 )
Что же это значит ? Что, в 1995 году придумали язык, с которым работать нельзя ? Вроде как нет, работали.
У меня 2 варианта ответа
1. Этот инструмент использовали не по назначению. Ну все равно как взять какой-нибудь ДОС-овский бейсик и начать на нем решать задачи адронного коллайдера. Тут сразу завопишь — сделайте мне, чтобы памяти было в 100 раз больше, чтобы скорость была в десятки раз больше, а то у меня расчет месяц занимает.
2. Все нормально, просто в 1995 этот язык придумали люди, которые умели писать как следует.
Здравствуйте, Pavel Dvorkin, Вы писали:
>>Что, впрочем нисколько не умаляет достоинств динамической типизации (интересно, закастится сейчас сюда Wolfhound или нет?). PD>Welcome!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Я же не о том говорю, что интерпретатор мог быть сравним со скоростью с компилятором. Я о том. что интерпретатор или полукомпилятор — это совсем не такая уж страшная вещь, требующая сотни Мб памяти из-за того, видите ли, что там только в рантайме определяется тип переменной, как меня тут уверяют. Все это давно было, и вполне без сотни Мб.
I>>И в этом же контексте по полмиллиона и более объектов в хипе ?
I>>Врешь, ведь.
PD>Ну и ну. Полмиллиона объектов на памяти в 640 Кб. М-да. Переутомление у тебя ?
Это был намёк на твои сравнения. JS работает с кол.вом объектов в памяти большим чем количество байт в памяти с которым работал Турбо Паскаль.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Pavel Dvorkin, Вы писали:
KV>Поскольку ты попросил не продолжать развивать эту тему, а я уже успел открыть окно януса для написания ответа тебе, то скажу еще одну вещь, не совсем по теме — чтобы поправить самого себя, и потом умолкну
Я просто устал от этой дискуссии. Да и основные идеи я уже не раз озвучил, какой смысл повторять-то ?
Про типизацию.
Я отнюдь не стороннник этой самой динамической типизации и не противник ее. Лично мне самому идея, что переменная может изменять свой тип, кажется надуманной. Вот если бы было введено ограничение по количеству переменных в программе (вот тебе 100 на программу и крутись как хочешь , тогда еще можно бы понять. Но такого ограничения нет, поэтому зачем нужны эти мутанты, мне не совсем очевидно.
Но если уж они есть, то не надо из них монстра делать. Переменные могут менять свой тип, но типы-то не могут! Тот факт, что переменная может менять свой тип, грубо говоря, просто означает, что указатель от нее на нечто, характеризующее тип, может изменяться.
В С++ это нечто называется vtable. Тип изменить нельзя, поэтому указатель на vtable для данной переменной никогда не изменяется. А дай возможность его изменить — и будет тебе динамическая типизация.
При изменении типа , возможно, изменится размер, понадобится реаллокация.
Да, при этом всякик проверки переносятся из compile-time в run-tme. За что боролись — на то и напоролись. Но и из этого не надо монстра делать. Реально компилятору с такого несложного языка, как js, я думаю, 1-2 Мб должно было бы хватить. Даже если обозвать этот компилятор исполняющей системой, запихнуть его целиком в рантайм и отправить заниматься этими проверками, то все равно 100 Мб тут брать неоткуда.
А вот если еще и упорно добиваться быстродействия "на уровне С++", то израсходовать легко и 100 Мб, и гигабайт тоже. Правда, быстродействия такого все равно не будет (за все эти проверки платить-то надо ?), но вот "освоить" эти Мбайты можно, благо они есть. Есть — бери!
Вот если бы их не было — вот тогда бы и пришлось писать как следует. Был бы при этом js в качестве основного языка или что-то иное — не суть важно. А вот написано было бы в соответствии с концепциями науки информатики, теориии алгоритмов, теории структур данных и т.д, а не потому, что стоимость ОП упала в 2 раза, поэтому вместо 2 GB можно поставить 4 и тратить 100 Мб там, где и 10 много.
WH>>А что касается 640кб да не вопрос. Только получится интерпретатор который будет все также тормозить.
PD>Ладно, давай заканчивать (это ко всем веткам относится).
Действительно, стоит заканчивать. Если ты даже ссылки
Здравствуйте, Pavel Dvorkin, Вы писали:
>Я не знаю , что они там в v8 сделали, и, честно говоря, мне это не слишком интересно. >Я бы понял, если бы речь шла о языке, на порядки более сложном. Но этого нет. Вот и все.
Задачи стали на порядки более сложными, а не языки.
О чем ведь и речь — нынче объектов в хипе JS больше, чем байтов в том же хипе Turbo Pascal.
На Турбо Паскале никогда не решались задачи такой же сложности.
И ты никак не хочешь, именно не хочешь, сунуть нос в картинки про JS V8 что бы понять, насколько сложная задача.
PD>>Понимаешь, все эти аргументы бледнеют перед одним простым фактом — компиляторы, которые работают в 1-2 Мб, сделать можно. A>и в лучшем случае они будут иметь такой же процент функционала от сегодняшних компиляторов, какой имеет линукс среди десктопов
Да ну ? Ну-ка, расскажи, что имеет компилятор VC++ 2008 С++ сверх того, что было в BC 5.5. Кроме оптимизации. Впрочем, она и там была, вот только сравнивать не берусь.
PD>>Я просто констатирую факт — пока памяти было мало, они занимали эту малую память и работали с приличной скоростью. Значит, это можно сделать. A>ставить скорость сборки выше скорости выполнения результата это суметь надо
Где это я ее ставил ? Выделил специально для тебя.
PD>>Я бы понял, если бы речь шла о языке, на порядки более сложном. Но этого нет. Вот и все. A>это типа здесь сказано, что сложность компилятора зависит исключительно(или в большей мере) от сложности языка?
Именно так. Компилятор (я не оговорился) с Бейсика на Ямахе работал в 64 Кб. С VB6 его там не разместить.
Здравствуйте, Antikrot, Вы писали:
PD>>Конечно! Авторы его предсказали будущее и можно было программировать для любой параллельной архитектуры , которая появится вплоть до 2050 года A>то есть, говоря: A>
A>Ну-ка, расскажи, что имеет компилятор VC++ 2008 С++ сверх того, что было в BC 5.5
A>ты имел в виду что можно рассказывать лишь о том, что было во времена bc5.5? или просто не устраивает, что 2008 всё-таки что-то имеет сверх?
Я имел в виду, что спрашивать, была ли в компиляторе 1996 года поддержка openmp не выглядит особенно умной. Естественно, сравнивая эти два компилятора, можно говорить только об их общем подмножестве, то есть о компиляции на базовый набор команд x86.
Здравствуйте, Erop, Вы писали:
E>С одной стороны, глупо не использовать возросшие мощности на улучшение работы программ. E>Но с другой стороны, я согласен с Павлом в том, что авторы современного ПО слишком агрессивны в этом своём стремлении.
А у вас у обоих одна и та же болезнь — "не знаю", "не пробовал", "не разбирался", "не специалист" и при этом какие то претензии к авторам.
E>Оно и понятно: они на перспективу работают, а не на вчерашний день. Но можно и пользователей понять. Так комфортно, как в TORе и в пятом ворде, я уже нигде тексты не редактировал. Чем современнее становилось ПО, тем тормознее оно работало на актуальных для себя компах...
Чем мощнее компы, тем сложнее задачи и больше количество. JS — никакая не тривиальная задача.
Здравствуйте, Ikemefula, Вы писали:
I>Текст можешь набирать точно так же как и 15 лет назад — открыл нотпад и пошел херачить.
Не-не-не! И TOR и пятый Word -- это намного круче блокнота!
Я же не про ncEditor и не про vi, а про вполне так себе мощные редакторы/процессоры текста.
I>А вот с мылом уже давно не так, потому что мощный комп позволяет удовлетворить больше потребностей, что проявляется в количестве возможностей которые предоставляет аутлук тот же.
Не знаю. Все эти "больше потребностей" -- возможность вставлять картинки и форматирование в текст. Вложения, как раньше были, так и сейчас есть.
Что-то как-то не много добавилось функциональности-то?
I>JS это тоже задача, только цель другая.
Да нет такой пользовательской задачи, как JS. Ты ещё скажи, что С++ -- это тоже задача.
IMHO, то, что г. майл написал такую оболочку мыльницы, что им надо поллимона ОБЪЕКТОВ, это не от большого ума автором г.мыла всё-таки...
I>Можно. Покажи мыльницу с мордой, которая экономичнее, удобнее, отзывчивее, функциональнее и тд.
Не знаю. Про "удобнее" и "функциональнее" -- это абстракиця всё. Так как неизмеримо.
Про "отзывчивее" -- смешно написал. Любая мыльница с, так сказать, "позапрошлого витка прогресса железа" "отзывчивее" всего нынешнего УГ.
А про "функциональнее", так в том-то и поинт. Что часть этой "функциональности" занафиг никому не упёрлась, и добавили её только потому. что ресурсы у компов бесплатные, а конкуренция идёт по фичам и только. Тем не менее война фич несомненно ухудшает ВСЕ участвующие продукты.
Да и то, что GMail какой-то там мегаотзывчивый -- это всё песни. Отзывчивый он на моём ноуте, на котором я продакшин код нашей системы на несколько лимонов LOC компилю. А на нетбуке, например, он тормозит и чахлый очень. А всё потому, что нетбук часто "тока что с мороза" бывает, и при этом ещё и памяти там не много...
так что бесплатность ресурсов -- это таки иллюзия, а то, что память, например, это приемлемая плата за ненужные фичи -- это просто маркетинговое враньё. Надо же как-то версию номер N+1 впаривать?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>С чего это ты взял, что я не знаю и не пробовал? Вопрос в том, где не будет тормозить твой текстовый редактор -- на топовом компе послезавтрашнего дня, или будет быстро работать на уже сейчас устаревшем компе средней секретарши -- это всего лишь вопрос ценностного выбора и маркетинговой стратегии. При чём тут вообще претензии к авторам? Они просто делают то, что считают выгодным. При этом понятно, что крупные игроки на рынке коммерческого ПО навязали рынку войну фич. Типа прогресс ПО состоит не в том, что оно становится быстрее, компактнее и безглючнее, а в том, что оно становится фичастее. А "скорее и компактнее" предлагается удовлетворять за счёт прогресса аппаратуры. Но, при этом, IMHO, разрабы ПО опережают прогресс аппаратуры. Вот всё и тормозит на типичном компе...
Я, наверное, в каком-то другом мире живу. То, чем я пользуюсь ежедневно, с увеличением номера версии получает новые фичи, и быстрее работает. Например, Office 2010 просто летает. Несмотря на то, что в нём офигенная интерактивность UI. И несмотря на то, что фич в нём раз в двадцать больше, чем в том же Word 6.0. А ведь когда я писал диплом, Word тормозил просто нечеловечески. Несмотря на существенно меньшую сложность документа по сравнению с сегодняшними моими документами.
Аутлук 2010 у меня прекрасно работает, несмотря на то, что писем только в инбоксе четыре с половиной тысячи писем. Аутлук 98, я полагаю, просто бы лёг и умер с таким размером инбокса. Даже на этой же машине. А новый аутлук еще и мгновенный поиск ухитряется делать по всем этим гигабайтам. Лично я не готов отказаться от таких функций ради экономии памяти. Которой, кстати, тот самый аутлук сейчас отожрал всего 113М.
Дворкин неспроста включает дурочку всякий раз, как ему предлагают сравнить быстродействие тех "правильно написанных" программ 15-летней давности с современными программами. Иначе ему придётся признать, что софт сейчас пишут лучше, чем в старые времена. И что "разбрасывание байтами" не имеет столь массового характера, как тут постулируется.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Павел, давай сразу оговорюсь: я не считаю, что на затраты памяти можно плевать вообще, в принципе. Я лишь пытаюсь объяснить, почему именно в хроме эти затраты более-менее оправданы и аргументированы. Ок?
PD>А вот когда мне говорят, что для обеспечения безопасности нужно 100 Мб — это я не понимаю. Что там за данные, которых аж 100 Мб набралось ?
Не только для обеспечения безопасности. Но не в стихах же мне всю архитектуру хрома излагать?
PD>Ну а что касается процесса под вкладку — извини, но ты тут просто демонстрируешь незнание базовых механизмов.
Павел извини, но то что я не программист еще не значит, что я не в курсе, чем физическое адресное пространство отличается от виртуального, спасибо
Твоя ошибка в том, что ты считаешь, что:
PD>Понимаешь, 100 Мб — это массив данных, и очень большой массив.
а это не совсем массив данных (да и не очень большой, если честно)
Давай разберемся что это:
во-первых, 100 мегабайт (на самом деле, чуть больше, по крайней мере у меня, из-за установленных расширений) — это не на каждый процесс, это в сумме на все, если что:
это скрин одного экземпляра приложения google chrome с тремя открытыми вкладками: gmail, google reader и вкладкой диагностики памяти. Кроме того, в моем хроме установлены 5 расширений и один плагин на каждый из которых тоже создается свой процесс. Вот как это выглядит в упомянутой вкладке диагностики:
Павел, обрати внимание на понятия memory и virtual memory. Проведем простой эксперимент, откроем еще по одной вкладке почты и новостей:
Смотри, на сколько увеличилось потребление невиртуальной памяти. Т.е. как бы той readonly о которой ты говоришь и которую можно было бы замапить в другие процессы, там не так уж и много.
А хочешь я тебе еще и фокус один покажу? Следи за руками:
Почти сотни метров — как ни бывало. И только за счет запихивания всех открытых страниц в один процесс. Фишка в том, что у хрома есть три стратегии распределения контента по процессам: процесс на каждый экземпляр сайта, процесс на каждый сайт и процесс на каждый таб. По умолчанию используется первый (а в свежих версиях они кажется начали экспериментировать с динамическим переключением между стратегиями), но это легко исправляется ключами командной строки.
Т.о., как видишь, мультипроцессная модель управления памятью дает весьма приличный оверхед. Каждый процесс хрома (кроме одного — супервизора) оборачивается в песочницу, изолирующую его от остальных процессов куда более гибче, чем это делает та же винда (с линуксом, там все несколько иначе). Все механизмы межпроцессного взаимодействия для этих песочниц реализованы руками и их необходимо дублировать от процесса к процессу, чтобы повреждение памяти в одном (к примеру) не сказалось на всех остальных. Та же фигня и со всеми структурами данных, используемых песочницами и собственно самих данных. Шарить это нельзя, т.к. это сведет на нет все усилия по изоляции процессов друг от друга.
Но ведь это еще не все Javascript в хроме исполняется движком V8 одной из отличительных черт которого является способ представления объектов в памяти процесса. Вместо того, чтобы держать хэш таблицы для доступа ко всем динамическим членам объектов, V8 при каждом изменении какого-либо объекта (например, при добавлении в него нового поля) создает на базе этого объекта т.н. скрытый класс, унаследованный от текущей структуры объекта, который в дальнейшем используется в качестве прототипа при создании новых объектов и для доступа к его членам. Это позволяет избежать поиска динамических членов по всей цепочке иерархии и существенно ускорить доступ к членам (т.к. эти скрытые классы еще и джитятся в нативный код), за счет опять-таки, затрат памяти, т.к. всю эту иерархию нужно хранить на протяженнии всего жизненного цикла скрипта (ибо таков суровый мир динамических языков). Мне лень делать скриншоты (кому надо — проверят сами), но разница между открытым gmail в режиме html-only и его представлением по умолчанию измеряется не одним десятков мегабайт, именно за счет того, что броузеру не приходится плодить все эти скрытые классы:
невиртуальная память (приватная, шарящаяся, всего):
html gmail: 12376k 11812k 24188k
ajax gmail: 68676k 12796k 81472k
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, WolfHound, Вы писали:
PD>За год до этого была выпущена Windows 95, которая вполне успешно работала на 8 Мб ОП, PD>а на 16 Мб чувствовала себя просто-таки великолепно. IE и NN там тоже чувствовали себя не плохо.
требовала 4 мб. я ставил (путем танцев с бубном) на 3 с хвостиком. 8 метров можно было работать с несколькими приложениями.
PD>А интерпретатор с JS как-то работал. И программа тоже.
js итерпретатор работал тормозно. первые скрипты использовались для проверок данных с форм до их отправки серверу. динамически страницы никто не генерил тогда. во всяком случае не скриптами.
Google v8 движок js -- очень компактный, быстрый и может использоваться как отдельный язык программирования с терминальным вв никак не связанный с браузером. СпайдерМонки (который в горящем лисе) по сравнению с ним тормоз ужасный, но тоже как бы ничего. и тоже может использоваться как автономный движок. и памяти он потребляет мизер в общем зачете.
PD>Не могли авторы языка в 1995 году закладывать в него или что-то с ним связанное с потребностью в 100 Мб.
тем не менее заложили. не в сам язык, но в способ его сношения с браузером. попробуте написать свою реализацию и посмотрите во что она выливается.
PD>1. Этот инструмент использовали не по назначению. Ну все равно как взять какой-нибудь ДОС-овский бейсик и начать на нем решать задачи адронного коллайдера.
это да. сравните накладные расходы на js и as, например. js выигрывает только на легковесных задачах, а используют его сейчас для всях монстров.
PD>2. Все нормально, просто в 1995 этот язык придумали люди, которые умели писать как следует.
вы все-таки возмите Google v8. и посмотрите хотя бы что там за тесты идут с ним. там и числодробилки и работа с массивами... причем, числодробилка, написанная на js, на v8 исполняется практически с той же скоростью как если бы она была написана на си. разница есть, конечно, но всего в несколько раз. даже не на порядок. а с учетом, что js это все-таки на си -- это хороший показатель.
чистый js двиг написан умно и жрет мало памяти.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
M>>По сути так и есть. Потому что у каждой переменной в каждый данный момент времени может просто так появиться новое поле. Или новый метод:
P>[Код скипнут].
P>Такое я бы не взялся реализовывать на Фортране. Впрочем, это может говорить только о недостаточном знании мною Фортрана.
P>Я вот сейчас посмотрел ресурсы по JavaScipt для полных чайников. Пришел к выводу, что вещи, показанные в твоем коде, применяются чаще, чем некоторые об этом думают. Прав ли я? Если да, не мог бы ты подкинуть какой-нибудь реальный случай, когда срочно требуется изменить тип уже существующей переменной? Я бы покопался, но, поскольку я ни одной строки кода на JS не написал, то не могу отличить реальные случаи от, скажем так, учебных.
Обычно такое делается, чтобы добавить отсутствующую в том или ином виде функциональность (по сути, mixin'ы):
// расширение встроенных типов
Array.prototype.each = function(){ логика, реализующая перебор элементов массива };
// расширение функционала существующих библиотек
jQuery.fn.new_plugin = function(){ что-то там }; // новый плагин в jQuery
// реализация иерархии объектов
Ext.Panel = function(){...} // реализация «панели»
Ext.FormPanel = Ext.extend(Ext.Panel, новый/доп. функционал) // extend тут: http://dev.sencha.com/deploy/dev/docs/source/Ext.html#cls-Ext
// расширение функционала существующих объектов без потери обратной совместимости
/*--- начало долгого примера ---*/
Ext.MessageBox = function(){ return {
createWindow: function(){
// что-то типаvar wnd = создаем окно ...;
return wnd;
},
show: function(message){
var w = this.createWindow();
w.getCmp('messagebox').setValue(message);
w.show();
}
};}();
// соответственно вызывается как Ext.MessageBox.show('сообщение')
// нам для внутренних разборок надо было перечислять все созданные окна
// и уничтожать их. Что приводило к тому, что Ext.MessageBox.show
// вылетало с ошибкой. Ну не проверят оно, что окна больше нет
// Решение:
Ext.MessageBox.createWindow_old = Ext.MessageBox.createWindow;
Ext.MessageBox.createWindow = function(){
var wnd = this.createWindow();
wnd.special_flag = true;
return wnd;
}
// в итоге при разборках можно сделать так:
WindowMgr.each(function(w){
if(!w.special_flag) w.destroy();
});
/*--- конец долгого примера ---*/
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, kochetkov.vladimir, Вы писали:
PD><skipped>
Самое интересное находится в конце. Дочитай плс
KV>>Все сказанное выше — весьма неполная подборка проблем, которые должны решить те, кто занимается созданием современного браузера. Странно только, что это понимаю я, ни разу не программист, но не понимаешь ты. Я ведь даже не "разработчик языков программирования" я так, "пристально за ними наблюдающий" в лучшем случае.
PD>Именно потому, что я программист, я это и понимаю.
Не понимаешь. Либо лукавишь, не соглашаясь со мной, т.к. это взаимоисключающие друг-друга поведенческие модели
PD>Понимаю, что не могли авторы языка в 1996 году создать его в расчете на необходимость 100 Мб, потому что и памяти такой даже в фантазии тогда не было.
Когда они создавали этот язык, он был не более чем средством сделать выпадающую менюшку или падающий на странице новогодний снег (с не более чем полусотней синхронно двигающихся снежинок, ибо иначе начинались жуткие тормоза). Разумеется, у них не хватило фантазии, чтобы понять, что через 15 лет этот язык будет использоваться в качестве полноценной codebehind на стороне клиента. Что на нем будет рисовать клиентские MVC-приложения и использовать его для доступа к DOM в стиле, более характерным для реляционных БД. Что появится HTML5 и CSS3 и на чистом javascript создадут практически полноценную реализацию проигрывателя флеш-роликов, например.
Язык за это время практические не изменился, лишь "чуть-чуть" расширилась его предметная область, чем и обуславливаются столь высокие требования к его производительности.
PD>Понимаю, что язык отнюдь не самый сложный, даже если придется иметь дело со столь ужасной ситуацией, как недозагруженный текст (Для твоего сведения — любой однопроходной компилятор всегда имеет дело с этой ситуацией, так как просматривает код один раз и, стало быть, при его просмотре в некоем месте можно считать, что последующий код он еще не видел).
При чем тут однопроходный компилятор? Он прямо во время прохода создает описываемые кодом объекты в куче? Изменяет их свойства? Вызывает их методы?
PD>Понимаю, что для компиляции чего бы то ни было размером в мегабайты исходного текста вполне хватало в старопрежние времена 1-2 Мб, и решительно не понимаю, что тут такого нового образовалось, что увеличивает потребности в сотню раз.
См. выше.
PD>А вот если писать, руководствуясь принципом "память больше не ресурс",
), эта фраза означала, что память в .NET не является тем ресурсом, который необходимо явно выделять и следить за его освобождением. А уже местные доброжелатели, выдернув ее из контекста, стали размахивать ей как флагом, крича, что дотнетчики не собираются экономить драгоценную память и уповают лишь на всемогущий GC.
Тем не менее, и .NET не избавляет от необходимости разумно подходить к вопросам использования памяти и держать в уме особенности реализации как GC, так и структур данных, но делает этот процесс легким и непринужденным, в отличии от.
PD>если в каждый объект добавлять по паре десятков байт на то, что , скорее всего, никому и не понадобится, если создавать эти объекты по принципу "зачем нам думать, как тут сэкономить, надо что-то еще — добавим новый объект, и дело с концом", если на базе небольшого js размером в 50-100 Кб соорудить некую структуру объектов с количеством под миллион — тогда, конечно, израсходовать 100 Мб не долго, и больше можно.
Попробуй открыть эксперимент, описанный по ссылке (http://www.chromeexperiments.com/detail/magnetic/) сначала в IE9 или FF3, а потом в хроме. Сразу поймешь, зачем в нем создаются все эти объекты.
PD>Но вот это и есть нынешний дурной стиль программирования, когда любую проблему решают за счет памяти, вместо того, чтобы продумать алгоритмы и выбрать хорошую структуру данных.
Память — самый дешевый из ресурсов, доступных десктоп-программисту в настоящий момент. Хром появился именно в результате выделенного. Видишь ли, его разработчики не хотели потерять значительную часть своих потенциальных пользователей, которые бы умерли есстественной смертью дожидаясь, пока разработчики наиграются в оптимизации по памяти перед выпуском своего продукта. Затраты памяти существенно уменьшились с момента выхода первого релиза хрома. Я помню тред в гугл-группе о том, как хром с несколькими вкладками отожрал у какого-то чела полтора гига. Можешь себе представить, насколько оптимизирован код в нынешней, 7-ой версии это браузера?
PD>Вот и все.
Нет, не все. Давай напоследок, я подкину тебе очень богатую пищу для размышлений? Каким браузером пользуешься ты? Насколько я помню — IE8. Он устраивает тебя по затратам памяти? Думаю, что устраивает, иначе — зачем тебе им пользоваться? А скорее всего, ты и не задумывался над этим вопросом: работает, ну и работает. Главное ведь чтобы хорошо работал и давал тебе комфорт при посещении сайтов, так? А ты знаешь, что IE8 реализует мультипроцессную модель, во многом схожую с хромовской? Вообще говоря, в настоящий момент, IE является вторым по защищенности браузером, несмотря на сложившиеся стереотипы. Тебя еще не смущает, что в нем применяется тот же подход к защите, что и в хроме? До этого момента, думаю, что не смущал, поэтому предлагаю провести простой эксперимент: давай возьмем 4 совершенно голых бразуера (без установленных плагинов и расширений, там где есть предустановленные — выключим нафиг), откроем в них две вкладки — одну с gmail, вторую с google reader и посмотрим как они поведут себя по отношению к затраченной памяти? Готов это увидеть? Voila: http://files.rsdn.ru/24665/browsers_memory.png
Не кажется ли тебе, что проблема все же не в криворукости разработчиков браузеров, а во всех этих ваших консерваториях?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Кто вы и что вы сделали с Павлом Дворкиным?
Последнюю пару-тройку дней мне приходится заниматься в своем проекте некоторой крайне полезной и в то же время нудной и долгоиграющей работой. Что-то запустил, сижу, жду, пока закончится процесс. Во время ожидания читаю КСВ. Обсуждения, подобные этому, доставляют в такие часы неимоверно.
Кто я.
Есть все основания считать меня ретроградом и консерватором. Да что там – сразу старпером. Мне в свое время приходилось и байты считать в резидентных программах, и работать в условиях, о которых пишет Павел Дворкин здесь
Вот если бы было введено ограничение по количеству переменных в программе (вот тебе 100 на программу и крутись как хочешь
Там было, правда, не 100, а чуть больше 200 переменных. Все глобальные. Если что, такие ограничения наличествуют у Бейсика в компьютере «Искра-226». Работали люди в таких условиях. Отличный софт выпускали. Но сколько всяких подробностей в голове держать приходилось — это кошмар. Так что IBM PC/AT-12 — роскошь, по сравнению с этим. Вдруг выяснилось, что вовсе не нужно помнить, в какой подпрограмме какие переменные задействованы, потому что есть локальные переменные. Не нужно писать на бумажке, какая переменная какую смысловую нагрузку несет, потому что их можно называть по-человечески. Если что, на «Искре» имя переменной состояло из 2 символов, причем второй – обязательно цифра. Это все может помнить машина. Но для этого ей надо памяти добавить.
И те, кому приходилось работать в жестких рамках, ресурсами не разбрасываются. Вот так писать недопустимо.
String a = new Integer(“12”).toString();
Но я считаю: все, что может делать машина, должна делать машина.
Что я сделал с Павлом Дворкиным?
Он, сдается мне, продолжает свой крестовый поход. Так что все в порядке.
KV>Скажи мне чудное виденье (раз предо мной явилось ты), готово ль ты нести кресты за появление согласных в рассаднике твоих идей, считающих "пхыпы с апачем" уделом истинных мужей? Ты ль спиногрыз потом за ними, полезешь баги подчищать? А уязвимости латать? Зачем вот так, на ровном месте, умы на байты разлагать? .... Ведь я, как можешь ты заметить, про аську слова не сказал, а в адрес хрома свой оскал — засунь себе подальше в кучу, пока GC не оторвал...
ты в явную ломоносовщину ударился, это шикарно Жалко только тема аськи осталась не раскрытой, даже в конце посылки.
А вот это надо повесить над кроватью у каждого уважающего себя программиста.
Нет, я не спорю, что культура работы с памятью должна, не побоюсь этого слова, привита всем в районе лба.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Такой запустит хром внезапно и в тот же миг сорвется в крик: "Здесь только что был целый гиг!!! Куда падлюка хром (би-бип!) 100 метров кровных отожрал? Я ж ничего не открывал?! Ну почта, новости — не в счет... Вот с хера хром так много жрет?!". И невдомек ему что хром, о безопасности радея, приватность холя и лелея, процессы пачкой создает для каждой вкладочки, плагина и рендера, чтоб тот терпила не схлопотал руткит в ядро.
Все это замечательно, но объясни бога ради, зачем тут все же 100 Мб понадобилось! Понимаешь, 100 Мб — это массив данных, и очень большой массив. Когда мне говорят, что под картинку 1000*1000 нужно 4 Мб — это я понимаю : пиксели хранить надо (сжатие не обсуждаем). Когда мне говорят. что под БД нужно 10 или 100 Гб — это я тоже понимаю — данные хранить надо. А вот когда мне говорят, что для обеспечения безопасности нужно 100 Мб — это я не понимаю. Что там за данные, которых аж 100 Мб набралось ?
Ну а что касается процесса под вкладку — извини, но ты тут просто демонстрируешь незнание базовых механизмов. Если запустить несколько процессов на базе одного и того же EXE (и DLL) , то все read-only данные (код, ресурсы, константы и т.д.) будут в ОП в одном экземпляре. А те даннные, что не будут в одном экземпляре — их что в одном процессе создавай в нескольких экземплярах, что в разных по одному — черт один. Вот тебе банальный пример. Программа , обрабатывающая картинки. Что 10 процессов запусти и каждому по картинке дай размером в 4 Мб, что один процесс с 10 картинками по 4 Мб — все равно 40 Мб получится.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>То есть, проблема в том, что если ты не знаешь, на что программисты потратили память, ты счиатешь, что они дураки и потратили память зря потому что на твой взляд столько памяти не надо ?
PD>А без демагогии можно ? Я спросил — на что они потратили ? Можешь сказать что-то по существу ? В применении к безопасности, о которой идет речь.
А в магазине часом ты не задаешь тот же самый вопрос ? Задай его разрабам хрома или сам посмотри в код хрома.
Ты в курсе, что программа на ассемблере, текстовый вьювер, занимает памяти на порядки меньше с++ варианта.
Тебя это не смущает ? Прикинь, а если все программы переписать на ассемблере, каждому юзеру хватит 1 гиг за глаза
I>>Как думаешь, можно ли движок джаваскрипта ускорить за счет расхода бОльшего кол.ва памяти ?
PD>Можно. Равно как, думаю, можно и без — если написать как следует. Вообще-то интерпретатооры умели писать и раньше, и работали они достаточно быстро. А с тех пор быстродействие процессоров очень — таки возросло, а язык JS вроде как не очень усложнился...
Вообще то щас там уже не интерпретатор, как раньше.
JS постоянно увеличивает быстродействие. Его скоро чуть не джитить будут.
Может и уже джитят, не уверен. Если джитят — то памяти просто должно расходоваться очень много.
I>>Как думаешь, можно ли например DOM-модель ускорит за счет бОльшего расхода памяти ?
PD>А вот тут, пожалуйста, поподробнее. Что за такие дополнительные данные в таком объеме потребовались ? Объем собственно данных (ну из того же XML, к примеру) определяется ими самими. Если собственно данных имеется под 100 Мб — тогда и говорить не о чем. Но не об этом случае речь. Поэтому, пожалуйста, сообщи, сколько памяти занимают собственно данные (строки, числа и т.д.) и что за накладные расходы понадобились в таком объеме ?
DOM-модель это уже не XML, это объктна модель где объекты соответсвуют элементам xml.
Простой пример(просьба примеры не обсуждать, они взяты немного из другой области, не DOM) — иногда для оптимизации модели в каждый объект вводится ссылка например на рутовый объект для быстрого доступа.
Это дает оверхед по памяти и выигрыш за счет того, что нен адо бегать вверх-вниз по модель что бы найти рута.
Или например захочешь иметь быстрый доступ к элементам коллекции. Обычно используется List который в STL vector.
Для быстрого доступа нужно иногда всунуть HashSet который в Stl map и получается огромный расход памяти — минимум вдвое больше на каждую коллекцию
А еще бываею челы зающают что нить вроде immutable-структур что бы очистить логику и сосредотачиваются именно на функционале, а не на памяти.
I>>>То есть, проблема в том, что если ты не знаешь, на что программисты потратили память, ты счиатешь, что они дураки и потратили память зря потому что на твой взляд столько памяти не надо ?
PD>>А без демагогии можно ? Я спросил — на что они потратили ? Можешь сказать что-то по существу ? В применении к безопасности, о которой идет речь.
I>А в магазине часом ты не задаешь тот же самый вопрос ? Задай его разрабам хрома или сам посмотри в код хрома.
Опять демагогия.
I>Ты в курсе, что программа на ассемблере, текстовый вьювер, занимает памяти на порядки меньше с++ варианта.
Нет. Это совершенно неверно. Он не только на порядки, он даже и в 2 раза больше не занимает. Объем кода серьезной программы на С++ по сравнению с объемом кода на асме незначительно (на проценты, от силы десятки процентов) больше, а объем данных и ресурсов от языка не зависит : массив в 100 Кб займет 100 Кб, опиши его хоть на С, хоть на Паскале, хоть на асме. Bmp в ресурсах тоже.
I>Тебя это не смущает ? Прикинь, а если все программы переписать на ассемблере, каждому юзеру хватит 1 гиг за глаза
Каждому юзеру вполне хватило бы, я так думаю, 16-32 Мб за глаза. Хватало же, когда памяти на машине было именно столько. Что с тех пор радикально нового в JS появилось ?
I>Вообще то щас там уже не интерпретатор, как раньше.
М-да. Скорость процессора возросла точно на порядки. Но на старых процессорах интерпретатор работал и ему хватало 16-32 Мб (больше просто не было), а теперь ему и быстродействия почему-то не хватает, надо за счет памяти увеличивать, хотя он теперь вроде как уже и не интерпретатор. Чудны дела твои, господи.
I> JS постоянно увеличивает быстродействие. Его скоро чуть не джитить будут.
А если не секрет, на что он там ее увеличивает ? Вычисления обычно не в JS, а на сервере делают.
I>Может и уже джитят, не уверен. Если джитят — то памяти просто должно расходоваться очень много.
А компилятор с Фортрана в 70-е годы работал на 256 Килобайтах. А ТурбоПаскаль с ООП в 80-е годы на 1 Мбайте. Во сколько раз JS сложнее ТурбоПаскаля ?
I>>>Как думаешь, можно ли например DOM-модель ускорит за счет бОльшего расхода памяти ?
PD>>А вот тут, пожалуйста, поподробнее. Что за такие дополнительные данные в таком объеме потребовались ? Объем собственно данных (ну из того же XML, к примеру) определяется ими самими. Если собственно данных имеется под 100 Мб — тогда и говорить не о чем. Но не об этом случае речь. Поэтому, пожалуйста, сообщи, сколько памяти занимают собственно данные (строки, числа и т.д.) и что за накладные расходы понадобились в таком объеме ?
I>DOM-модель это уже не XML, это объктна модель где объекты соответсвуют элементам xml.
Это я все знаю, поверь. Об XML я говорил, имея в виду его как источник данных. Вот есть у тебя, к примеру. 1 Мб XML файл. Там строки, числа и т.д. Построили из него дерево. Сколько памяти это дерево должно занимать ? Я так полагаю, что примерно тот же 1 Мб, ну пусть раза в 2-4 больше (на всякие там ссылки, может, в текстовой форме меньше памяти уходило, допустим). А вот больше — под что ????
I>Простой пример(просьба примеры не обсуждать, они взяты немного из другой области, не DOM) — иногда для оптимизации модели в каждый объект вводится ссылка например на рутовый объект для быстрого доступа.
Да бога ради. Вот тебе классическое двоичное дерево. Ссылки на родителя в нем обычно не хранят — и так хорошо. Расход памяти на узел
2*sizeof(pointer) + sizeof(data)
Теперь мы решили (не знаю зачем) хранить в каждом узле ссылку на родителя. Имеем
3*sizeof(pointer) + sizeof(data)
При sizeof(data) порядка десятков байт и sizeof(pointer) == 4 — вообще копейки. Даже если до абсурда довести (sizeof(data) = 0), то всего в 1.5 раза.
I>Это дает оверхед по памяти и выигрыш за счет того, что нен адо бегать вверх-вниз по модель что бы найти рута.
Не вполне понял, о чем идет речь, но охотно дам тебе еще sizeof(pointer). Будет не в 1.5, а в 2 раза больше
Вот тут-то вся суть. Если в дереве тысяча элементов — объем может быть либо 8 Кб (без рута или парента), или 16 Кб (с ними). А вот как сделать хоть 1 Мб — не понимаю!!!
I>Или например захочешь иметь быстрый доступ к элементам коллекции. Обычно используется List который в STL vector.
I>Для быстрого доступа нужно иногда всунуть HashSet который в Stl map и получается огромный расход памяти — минимум вдвое больше на каждую коллекцию
Да бога ради, двойной расход даю тебе без проблем!!! Двойной мне не жалко. То есть если у тебя данных на 100 Кб, то попросишь 200 Кб — бери! Я тебе даже 400 дам — бери! Но вот 4 Мб не дам!!! А ведь берут 40!
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Ты в курсе, что программа на ассемблере, текстовый вьювер, занимает памяти на порядки меньше с++ варианта. PD>Нет. Это совершенно неверно. Он не только на порядки, он даже и в 2 раза больше не занимает.
Напиши на с++ вьювер ровно в 300 байт
>Объем кода серьезной программы на С++ по сравнению с объемом кода на асме незначительно (на проценты, от силы десятки процентов) больше, а объем данных и ресурсов от языка не зависит : массив в 100 Кб займет 100 Кб, опиши его хоть на С, хоть на Паскале, хоть на асме.
Об чем речь — чем _серьезнее_ программа, тем больше объем кода и вобщем то расход памяти. Чем больше памяти — тем больше можно кешировать вычисления вместо вычислений.
PD>Каждому юзеру вполне хватило бы, я так думаю, 16-32 Мб за глаза. Хватало же, когда памяти на машине было именно столько. Что с тех пор радикально нового в JS появилось ?
Быстродействие JS увеличилось примерно на порядок. Еще раз — быстродействие JS, а не процессора.
I>>Вообще то щас там уже не интерпретатор, как раньше.
PD>М-да. Скорость процессора возросла точно на порядки. Но на старых процессорах интерпретатор работал и ему хватало 16-32 Мб (больше просто не было), а теперь ему и быстродействия почему-то не хватает, надо за счет памяти увеличивать, хотя он теперь вроде как уже и не интерпретатор. Чудны дела твои, господи.
Считаешь, что старый браузер супротив нового на том же компе будет зависеть от процессора ?
Воистину, "Чудны дела твои, господи"
I>> JS постоянно увеличивает быстродействие. Его скоро чуть не джитить будут.
PD>А если не секрет, на что он там ее увеличивает ? Вычисления обычно не в JS, а на сервере делают.
Вот так откровение. Открой чуть не любой сайт — JS этого бывает по 50 и даже 100 кб самое обычно дело и это не на сервере а вбраузере выполняется.
I>>Может и уже джитят, не уверен. Если джитят — то памяти просто должно расходоваться очень много.
PD>А компилятор с Фортрана в 70-е годы работал на 256 Килобайтах. А ТурбоПаскаль с ООП в 80-е годы на 1 Мбайте. Во сколько раз JS сложнее ТурбоПаскаля ?
И работали они тогда крайне медленно.
I>>DOM-модель это уже не XML, это объктна модель где объекты соответсвуют элементам xml.
PD>Это я все знаю, поверь.
Не похоже.
PD>Об XML я говорил, имея в виду его как источник данных. Вот есть у тебя, к примеру. 1 Мб XML файл. Там строки, числа и т.д. Построили из него дерево. Сколько памяти это дерево должно занимать ?
Зависит от функционала модели и оптимизации. Может и в 1000 раз больше быть.
Например понадобится доступ к элементам O(1) при том что коллекции у каждого элемента всегда должны быть отсортированые. Или окажется что порядок следования в коллекции не должен меняться.
>Я так полагаю, что примерно тот же 1 Мб, ну пусть раза в 2-4 больше (на всякие там ссылки, может, в текстовой форме меньше памяти уходило, допустим). А вот больше — под что ????
Это еще 10 лет назад было не так. Качни любой парсер, который DOM-умеет, да открой 100 мб xml, памяти у тебя ведь больше 1 гига ? Стало быть за глаза хватит
Потом приходи, расскажешь результаты.
PD>Да бога ради. Вот тебе классическое двоичное дерево. Ссылки на родителя в нем обычно не хранят — и так хорошо. Расход памяти на узел
У тебя возникли какие то проблемы со фразой "(просьба примеры не обсуждать, они взяты немного из другой области, не DOM)" ?
Я знаю точные значения, потому показал два варианта оптимизации, хотя их вагоны.
I>>Для быстрого доступа нужно иногда всунуть HashSet который в Stl map и получается огромный расход памяти — минимум вдвое больше на каждую коллекцию
PD>Да бога ради, двойной расход даю тебе без проблем!!! Двойной мне не жалко. То есть если у тебя данных на 100 Кб, то попросишь 200 Кб — бери! Я тебе даже 400 дам — бери! Но вот 4 Мб не дам!!! А ведь берут 40!
Тебе что, перечислить все возможные оптимизации которые я делал для ускорения модели ?
После всех оптимизаций модель больше похожа на БД в памяти. Ты представляешь, что такое БД ?
Модель загоняю в БД на SQL Сервере, получается около 100 мб, а в текстовом виде и сто килобайт не наберется.
В памяти конечно нет 100 мб, мне индексы не нужны, но около 20мб имеется.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Напиши на с++ вьювер ровно в 300 байт
PD>Я же ясно сказал — серьезные программы. Для поделок (а тем более TSR, помнишь их ?) — могут в
С одной стороны, ты понимаешь, что программы различаются по серьезности.
С другой сторны, как только доходит до расхода памяти, ты вдруг отказываешься это понимать.
Как быть и не знаю.
PD>Объем кода вообще ничтожен по сравнению с объемом данных. Написать 100 Кб кода — это ты быстро не сделаешь, это десяток тысяч строк. А массив в 100 Кб — пустяк, превратить его в 1 Мб массив, если понадобится — раз плюнуть.
А если генерировать код, что тогда ?
PD>Что касается кеширования вместо вычислений — да, но далеко не везде есть это кеширование и вычисления тоже. Мне как-то трудно понять, что же там можно кешировать или вычислять, скажем, в flashget
Неправильно думаешь. Тебя должен интересовать один вопрос — какое направление оптимизации выбрали для написания флешгета.
Вот когда ты это установишь наверняка и ознакомишься с кодом, тогда можно говорить, что де флешкгет расходует память зазря.
I>>Быстродействие JS увеличилось примерно на порядок. Еще раз — быстродействие JS, а не процессора.
PD>А процессора по сравнению с 90-ми — на 2 порядка. Плюс многоядерность. Так что прежний интерпретатор (если бы он был хорошо написан) должен был бы и без всякой компиляции на нынешних Athlon/Dual/i7 летать.
Будет летать, а программы на нем будут ползать по сравнению с современными JS-машинами на "нынешних Athlon/Dual/i7"
I>>Считаешь, что старый браузер супротив нового на том же компе будет зависеть от процессора ?
PD>Не понял вопрос. Как можно зависеть или не зависеть от процессора на том же компе ?
Все ты понял. Нечего валять Ваньку.
Если сравнение JS vs JS, то очевидно, остальные параметры эквивалентны или их влиянием можно пренебречь.
Но тебе толи хочется повыступать, то ли увильнуть, и ты вводишь спам про процессоры.
PD>Да бога ради, 50-100 Кб — на здоровье. Что тут особенного ?
Особенного здесь тот факт, что JS-кода сейчас на порядки больше чем 10 лет назад, и работает он много быстрее относительно одного и того же процессора.
I>>И работали они тогда крайне медленно.
PD>Ничего подобного. ТурбоПаскаль очень быстро работал. Найди его и запусти, убедишься сам. Он на Ямахе (2MHz, 64 Kb) компилировал 2000 строк за десять секунд.
Это и есть крайне медленно. Во первых, язык был убог. Во вторых, оптимизаций считай никаких не делалось.
I>>Зависит от функционала модели и оптимизации. Может и в 1000 раз больше быть.
PD>А вот тут опять же поподробнее. А вот если в 1000 раз больше — давай сюда свой расчет памяти.
Ага, щаз, перечислить тебе все виды оптимизации которыее вводились за несколько лет ?
Ты в своем уме ? Каждая из этих оптимизаций прибавляет по n-байт в рассчете на объект или коллекцию.
По одной — ничего, все вместе — может и в 1000 раз.
I>>Например понадобится доступ к элементам O(1) при том что коллекции у каждого элемента всегда должны быть отсортированые. Или окажется что порядок следования в коллекции не должен меняться.
PD>Доступ за O(1) при том, что при каждом добавлении тебе придется либо пересортировывать либо сдвигать ?
Имеется ввиду доступ на чтение. Хештаблица — медленное решение. Предложи лучше.
PD>Я не спорю, такое возможно. Но ИМХО тут надо как следует задачу перепродумать и структуры данных. Слишком уж разбалансированное решение получилось.
Балансировалось только под оптимизацию по быстройдействию.
Все остальное тупо шло в помойку.
PD>Это и было и есть не так, потому что писали это и пишут черт те как.
Это тянет на д'Артаньяна в стране Каналий
I>>У тебя возникли какие то проблемы со фразой "(просьба примеры не обсуждать, они взяты немного из другой области, не DOM)" ?
PD>Ну знаешь, если ты пошел по пути приведения примеров и при этом запрещаешь мне их обсуждать, то лучше было бы тебе их и не приводить. А то как-то неэтично получается.
Нормально получается. Я знаю, сколько какая из оптимизаций прибавляет к расходу памяти и эти самый оптимизации могу перечислять десятками точно.
Ты кажду будешь мусолить ?
PD>Я понятия не имею о твоей модели (и о задаче), так что мне это совсем ни к чему.
Вот я тебе и говорю — не надо обсуждать примеры.
I>>После всех оптимизаций модель больше похожа на БД в памяти. Ты представляешь, что такое БД ?
PD>Нет. Никогда их не видел и о них не слышал. . Тебе обсудить что-то хочется или поерничать ?
О том и речь, что ты говришь о том, чего не знаешь.
I>>Модель загоняю в БД на SQL Сервере, получается около 100 мб, а в текстовом виде и сто килобайт не наберется.
PD>Вот именно, типичный пример. 0.01% данных и 99.99 % накладных расходов. Лей память, лей, чего ее жалеть!
Да, именно так. Потому что имеет смысл тольк одна оптимизация — под быстродействие.
I>>В памяти конечно нет 100 мб, мне индексы не нужны, но около 20мб имеется.
PD>0.05% и 99.95%
Да, примерно так. И меня абсолютно не удивляет, почему Хром жрет память.
Это десктоп приложение, посмотри на тренд — доля Хрома растет со страшной скоростью.
Это самый быстрый браузер из аналогичных по функционалу и скорость окупается.
Оптимизация под память затребует дополнительных усилий и времени. За счет чего — выбирать не из чего, или функционал или перформанс.
А память стоит дешево, кстати говоря. Боязнь расхода памяти это психологический барьер после 20 лет 32х приложений.
M>при чем тут HTML страница? Открою страшную тайну: js- код может подгружаться из внешних файлов
А я и не знал .
M>inbox GMail'а загружает аяксом — внимание — 2.8 MB данных: M>
Да уж. Gmail это умеет
M>И загружается там не банальный JSON, а
M>
M>На скриншоте — аякс запрос на 177.27 KB. Интерпретатор 10-летней давности умер бы, утащив за собой всю систему. Сейчас же у меня Safari даже не чешется, загружает и все.
Я все же одно не пойму. ТурбоПаскаль 1987 года тихо и спокойно переварил бы файл на 177.27 Кб при 640 Кб ОП и не почесался бы. Подумаешь, 177 Кб. Ну ладно, на тебе в 10 раз больше. А в 100 зачем ? Что за чудная такая задача — интерпретатор с несложного, в общем-то, языка, к тому же большая часть кода в котором есть вызовы браузера (всякие document.open и window.on_не_знаю_что)
M>Банальный RSDN подгружает 50 килобайтов скриптов. M>google.com подгружает 188 килобайтов скриптов и 22 килобайта скрипттов аякс-запросом. первый же поиск по слову test увеличивает XHR до 361 килобайта.
И что ? 50, 188, 22, а не 500 и 5000
M>Так что с порядками все в порядке.
M>>>>при чем тут HTML страница? Открою страшную тайну: js- код может подгружаться из внешних файлов PD>>>А я и не знал .
M>>Тогда почему ты заострил внимание на «одной HTML-странице в 500 килобайт»?
PD>Потому что, как правило, страницы HTML вместе с внедренным в него или иначе вставленным JS имеют размер, намного меньше. О том, что размер вырос на порядки, говорить все же не приходится. Вырос, не спорю, в несколько раз, но не на порядки.
Минимум на порядок
M>>>>inbox GMail'а загружает аяксом — внимание — 2.8 MB данных: M>>>>http://files.rsdn.ru/9088/gmail%20ajax.png
PD>>>Да уж. Gmail это умеет
M>>Да и не только GMail.
PD>Между прочим. Компиляция обычных статических языков, как я уже не раз тут замечал, вполне может идти на нескольких Мб. Доказательство простое — она шла, и с весьма приличной скоростью при памяти в Мбайты и частоте в десятки-сотню MHz и без многоядерности. Это сейчас просто начали памятью бросаться. А Язык С++ от времен BC 5.0 до нашего времени не менялся практически. А тут, видите ли, чтобы откомпилировать 2.8 Мб сорсов, нужна сотня Мб. При том, что язык довольно простой. Что же это такое, кроме как халтурное программирование ?
Фигня, что этот скрипт не только компилируется, но и выполняется? Или мне надо взять Фотошоп, запустить его, увидеть, что он жрет немерянно памяти и сделать вывод о фиговом компиляторе?
M>>>>И загружается там не банальный JSON, а
M>>>>http://files.rsdn.ru/9088/gmail%20ajax%202.png PD>>>
M>>Улыбки улыбками, но там грузится не 50 килобайтов скриптов, а почти 3 мегабайта.
PD>Да пусть и 3! Вот возьми BC 3.1 в MS-DOS , процессор Пентиум-100, ОП чтобы было 4 Мб, а лучше 8 и откомпилируй эти 3 Мб. Со свистом. При том, что там еще и .h файлы включаются и компилируются, если отключены predcompiled headers. Ты будешь утверждать, что JS сложнее C++ ?
Повторю во второй раз: «Фигня, что этот скрипт не только компилируется, но и выполняется?»
M>>>>На скриншоте — аякс запрос на 177.27 KB. Интерпретатор 10-летней давности умер бы, утащив за собой всю систему. Сейчас же у меня Safari даже не чешется, загружает и все.
PD>>>Я все же одно не пойму. ТурбоПаскаль 1987 года тихо и спокойно переварил бы файл на 177.27 Кб при 640 Кб ОП и не почесался бы. Подумаешь, 177 Кб. Ну ладно, на тебе в 10 раз больше. А в 100 зачем ? Что за чудная такая задача — интерпретатор с несложного, в общем-то, языка, к тому же большая часть кода в котором есть вызовы браузера (всякие document.open и window.on_не_знаю_что)
M>>Javascript кажется несложным. Тут тебе и динамика и функции высшего порядка и замыкания и eval.
PD>Ай-яй-яй. На замыкания с eval нужно 100 Мб. А динамика — так она вроде как в любом интерпретаторе потенциально возможна, на то он и интерпретатор. К примеру, в той же FoxPro на 1 Мб в DOS-времена были переменные, тип которых изменялся во время выполнения. Что тут такого-то ?
Повторю в третий раз: «Фигня, что этот скрипт не только компилируется, но и выполняется?» Что тебя зациклило на компиляции? Компиляция на современных реализациях Яваскрипта занимает доли секунды, а то и быстрее.
А те самые «вызовы» браузера — не настолько простая и нересурсоемкая операция, как тебе кажется. В том же GMail'е идет постоянная манипуляция DOM'ом (который сам по себе не является особо эффективной структурой для хранения). Банальный insert/show отожрет у тебя или память или процессор (а вернее, и то и другое), и Javascript тут вообще не причем. Курить reflow и redraw/repaint.
>>Но его обработка ускоряется. Повторю, что интерпретатор 10-летней давности умер бы на 2 мегабайтах скриптов. PD>Значит, так хорошо умели (умеют) писать эти интерпретаторы
Повторю в четвертый раз: «Фигня, что этот скрипт не только компилируется, но и выполняется?».
M>>>>Так что с порядками все в порядке.
PD>>>Не совсем
M>>Угу. Порядок — это степень 10.
PD>Именно. На порядок — в 10 раз. На 3 порядка — в 1000. Если было 50 Кб — давай сюда HTML с JS на 50 Мб, вот это и будет 3 порядка. Только имей в виду, что у меня канал номинально 10 Мбит, так что загрузится твой JS хорошо если через минуту
M>>Возьмем сначала: M>>
M>> На порядки — это что, в 100 или 1000 раз ? Если 10 лет назад на странице было 5 Кб, то сейчас 500 или 5000 ?
M>>10 лет тому назад 5 килобайт.
PD>А сейчас так-таки сплошь и рядом 5 Мб ? Между прочим, на его загрузку нужно 5 сек у меня, а если скорость 1-2 Мбит ?
Не пять, но 3. На том же GMail'е. На том же facebook'е. на том же Твиттере. Ты думаешь, что, раз загрузив 100 килобайт на том все? Любой твой поиск в Google Instant бросает в тебя сотню-другую килобайтов яваскрипта. Любой чих на Фейсбуке — аналогично. Рассказать тебе, какие сайты сейчас самые популярные в мире или сам догадаешься?
M>>RSDN: 50 килобайт. Разница на порядок. M>>google.com: 188-361 килобайт. Разница на два порядка.
PD>На 2 порядка будет все же 500, а не 188.
M>>gmail.com: 2800 килобайт. Разница на три порядка.
PD>И здесь все же надо 5000. Ты с порядками поаккуратнее
M>>
M>>Все в порядке с порядками. Более того, если 10 лет тому назад две-три страницы с большими/активными яваксриптами могли намертво и надолго завесить браузер, то сейчас не проблема иметь в одном окне gmail, в другом — твиттер, в третьем — facebook и т.д. и т.п., а в нцатом спокойно что-нибудь искать в google instant (да еще и с предосмотром страниц).
PD>Счастье-то какое! Помню, в 2000-м был у меня Пентиум-3, памяти 256 Мб, тактовая 667 MHz. И работал в ней Netscape Navigator 4.7. В одном окне была почта, в другом web, а еще был composer и не помню что еще. И ничего они не вешали. Вот поиска в гугле не было, потому что не было гугла. Но поиск на altavista (я тогда ей пользовался) или rambler — без проблем.
Угу. И почта, видимо была уровня GMail'а и поиск тоже был уровня Google Instant, ага. Еще навреное уже тогда Facebook существовал в нынешней инкарнации — с динамикой, мгновенными нотификациями и т.п. Ага-ага, верю.
PD>А всего-то 256 Мб... Получается, что для того, чтобы от 5 Кб JS перейти к 500 Кб, надо объем ОП увеличить в 16 раз, тактовую в 5, ядер в 4 ! Да это просто чудовище какое-то, ваш JS .
Угу, только проблема сейчас уже не столько в JS, сколько DOM'е браузеров.
M>> H>Причем тут IE вообще? Речь о интерпретаторах и их качествах Ты говоришь, что с течением времени они стали круче, и оправдываешь этим возросший расход памяти (а что еще ты хотел сказать говоря об умирающем на 2Mb скрипте интерпретаторе). Я тебе говорю, что и семь лет назад можно было не умирать на больших скриптах, если писать интерпретатор нормально.
M>> Охохонюшки. В контексте данной подветки: M>> — я не оправдываю возрост памяти M>> — интерпретаторы в браузерах улучшились M>> — обхемы загружаемых в браузеры данных возрасли на порядки
H>Как раз в контексте треда идет спор об оправданности высокого потребления Твои слова о размерах скриптов прозвучали, как аргумент в защиту позиции оправдывающей высокое потребление. Первый раз ты вообще сказал: H>
На скриншоте — аякс запрос на 177.27 KB. Интерпретатор 10-летней давности умер бы, утащив за собой всю систему. Сейчас же у меня Safari даже не чешется, загружает и все.
Это к тому, что Павел не верил, что сейчас передаются огромное количество данных на веб-страницы.
H>Из этого, как бы, должно следовать, что коли сегодняшние интерпретаторы не умирают от 178Kb скриптов утащив при этом за собою всю систему (твоя гипербола вышла на орбиту ) то это должно их оправдывать. Вот у меня тут не срастается...
Павел почему-то зациклился на компиляции. помимо компиляции есть еще и выполнение этих скриптов. Которые не работают в вакууме, а манипулируют тем же DOM'ом, например. И работают сейчас с тем же DOM'ом намного интенсивней и одновременно эфективней, чем 10 лет тому назад. Не говоря уже о том, что и сама структура страниц значительно усложнилась
Здравствуйте, Pavel Dvorkin, Вы писали:
KV>>А если учесть еще и то, что между некоторыми рендерами необходимо обеспечивать возможность доступа из javascript одного к DOM другого...
PD>И что ? Для этого нужно 100 Мб ? LPC/RPC/OLE/COM уже отменили ? И при чем тут js ? Запрос в любом случае делают не из js.
LPC/RPC/OLE/COM безбожно тормозит. Это было актуально во времена эксплорера 4.0, а сейчас уже устарело для данных задач.
JS или рендерер абсолютно не важно — доступ к DOM должен быть мгновенный и сама DOM должна работать мгновенно.
Вот ради этого люди пошли оптимизировать структуры данных под перформанс, ради этого и потребляется память — JS+DOM+рендереры.
>А запросы из Word в Excel тебя не удивляют ? А вставка таблицы из Excel в окно моего приложения не удивляет ?
Это _очень_ медленно по сравнению с тем что может JS V8.
Здравствуйте, Mamut, Вы писали:
M>>>Пустой фотошоп спокойно отжирает 130 метров памяти. Компилятор С++ — гуано, однозначно.
PD>>Слушай, не смеши. При чем тут компилятор ? У меня сейчас фотошоп не установлен, посмотреть не могу. Запусти на него dumpbin, а лучше Process Explorer, и посмотри, что там в этих 130 Мб. Там скорее всего несколько Мб кода (не считая, конечно, кода системных DLL), а остальное — либо массивы данных, либо ресурсы. Вот они там зачем в таком объеме для пустого фотошопа — это действительно вопрос, но уж никак не к С++, а к авторам фотошопа. Я тоже могу сделать приложение мастером VC++, добавить массив на 100 Мб и будет тебе 100 Мб памяти.
M>Ну ты же привязался непременно к компиляции яваскрипта
Не к компиляции, а к работе. Если в JS объявлен массив на 100 Мб — я первый потребую под него место. Но пока его нет, нечего память транжирить.
PD>>А все же можно без аналогий объяснить, что же такое особо ценноеза последние 10 лет появилось в почте ?
M>Можно, например, вспомнить, интерфейс хотмэйла в 2000-м, потом открыть GMail и посмотреть на тот интерфейс, что он предлагает. Действительно совсем-совсем ничего не изменилось? ни встроенного чата, ни отсутствия перезагрузок между переходами страниц, ни схлопывания частей писем, ни драг'н'дропа, ни прозрачного выставления флагов и меток, ни прозрачного, без перезагрузки страницы, обновления инбокса по мере посупления новых сообщений — вообще ничего. То есть то, что в браузере у тебя почти полноценный аналог того же thunderbird'f — это вообще никаких изменений по сравнению с хотмейлом образца 2000-го года, ага.
Я вообще-то имел в виду именно десктопную почту, а в этом плане нынешний thunderbird мало чем отличается от Netscape Mail 1998 года. Ну а то, что в web-интерфейсе, потратив на это десятки и более Мб, сумели добиться почти полноценного аналога продукта десятилетней давности — говорит лишь о том, насколько подходящий инструмент (браузер) используется для этих целей. Впрочем, об этом я уже писал, повторяться не буду.
M>Да хотя бы GMail открой. Facebook.com — ссылка для facebook'а.
Попробовал GMail под NN 4.7. Не работает, но со странной дмагностикой — у меня, мол, медленный Интернет. Запускал под XP Mode, но дело не в ней, так как под IE вполне работает.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Слушай, ты же ясно сказал, что тебе жаль времени, потраченного на дискуссию со мной. Зачем же ты хочешь еще раз его потратить ? Я — не хочу.
Здравствуйте, Mamut, Вы писали:
PD>>>>Не к компиляции, а к работе. Если в JS объявлен массив на 100 Мб — я первый потребую под него место. Но пока его нет, нечего память транжирить.
M>>>Ну пока его нет, его и не транжирят. Вернее, транжирят столько, соклько нужно для JIT'а и runtime-оптимизаций.
PD>>А сколько нужно под код на js размером в 50-100 Кб при том, что там нет больших массивов ? Я так полагаю, что 1 Мб должно хватить. Для ТурбоПаскаля хватало же.
M>Честно, не знаю, сколько
Но ведь для ТР хватало 1 Мб. А JS не сложнее.
M>Ну, как я и сказал, Thunderbird вообще неудачный пример
А что в OE лучше, кроме уязвимостей ?
M>Вот смотрю я на Mail.app под макосью... Почти пять игов писем, синхронизированных по IMAP, но хранящихся локально. С поиском, threading'ом, фильтрами, смарт-боксами, rss-читалкой и т.п. 84 мегабайта в памяти
Ну и я смотрю. Thunderbird. 2 GB писем. Хранятся локально. Поиск и прочее на месте. Размер примерно тот же.
Здравствуйте, мыщъх, Вы писали:
М>кстати, а вы не пробовали не перезапускать лиса и gtalk пару недель. попробуйте. больше двух месяцев не продержитесь. даже если есть память -- закончится адресное пространство. ну с лисом как бы все понятно. там у меня стоит несколько плагинов и на них всегда можно свалить все грехи. а вот откуда берутся утечки памяти в gtalk в таком кол-ве? как было в первой версии, так и в последней...
Это все по тому что авторы пишут на С/С++. Так типа эффуктивнее. А про фрагментацию адресного пространства все почемуто забывают.
При этом если язык имеет уплотняющий сборщик мусора то у него таких проблем не бывает в принципе.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Слушай, у тебя , как я понимаю, была основная цель этого постинга — объянить, что я ничего не понимаю.
Именно так.
Ты пишешь такой бред что даже не смешно.
Это я тебе говорю как человек занимающейся проектированием языков программирования.
PD>Ну и на здоровье. Считай, что ты в очередной раз отметился, а дискутировать мне с тобой на эту тему незачем.
А ты посмотри видео по ссылке.
Может быть и сам поймешь сколько бреда ты тут понаписал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ikemefula, Вы писали:
PD>>Как ты думаешь — используя такие аргументы, можно хоть чуть-чуть добавить правоты свому мнению ?
I>Да я как то за правотой не гоняюсь.
А тогда я вообще не понимаю. Если ты не уверен в своей правоте — зачем с такой энергией защищать свою точку зрения ?
Я — в своей правоте уверен. По очень простой причине — я все это видел своими глазами и работал с этим. Я готов допустить, что нынешние языки и средства сложнее тех, что были 10-20 лет назад, в 5-10 раз. Но я никак не могу согласиться с тем, что они сложнее в 100 раз. Если бы я видел, что нынешнее ПО требует в 10 раз больше памяти и быстродействия , чем ПО 10-20 летней давности. я бы и слова не сказал. Но когда я вижу, что потребности в памяти увеличились в 100 раз, скорость процессора — в 50-100, в все вопят — памяти мало, программы тормозят (и это правда), то объяснение только одно — разучились писать как следует.
Pavel Dvorkin, Вы писали:
PD>Здравствуйте, мыщъх, Вы писали:
>>а потому чтобы хакеры не юзали дыры им теперь приходится пускать си++ код на эмуляторе PD>C++ на эмуляторе ??? Ну и ну!
детали реализации не разглашают, но вот сама адобе об этом пишет тут: http://blogs.adobe.com/asset/2010/10/inside-adobe-reader-protected-mode-part-1-design.html
причем ее чудо работает примерно с той скоростью с которой работает BOCHS. во всяком случае адобе ридер без сандбокса под vm ware выполняется в несколько раз быстрее, чем новый с сандбоксом на живой оси.
PD>Именно! Взяли HTML, имевший назначением HyperText Markup, и не более, и сделали из него какую-то PD>странную среду для выполнения всяких программ всякого рода. Ну и получили что заслужили.
а ведь если бы проектировали по уму -- этого бы не было. и даже проектировать было не надо. уже были протоклы для удаленного выполнения гуйни к тому времени в никсах. вот бы и реализовали их в браузере. а так получилось все равно кривая интерактивность, кривая кросс-платформенность и дикий оверхид в придачу. и все это совершенно небезопасно, потому как дыр просто туча и ссылки лучше не открывать.
М>>если взять бейскик образца начала 90х, то у него по сравнению с компилируемыми языками разница будет в несколько порядков. но у меня был шок, когда я обнаружил, что на js можно написать то, что я раньше писал на си для реал-тайма и оно будет работать не сильно хуже, но вот писать уж точно проще. PD>Да я и не спорю, может, и есть такое. Я вообще не js обсуждаю. Меня 100 Мб интересуют
я тут просто сказал, что основной потребитель это не скрипты. а кто потребитель -- не знаю. тут в моей программе файл под гиг размером читается целиком в память. и это ушло в продакшен. я говорил, что могу и переписать, но решили, что "оно того не стоит" (с). гиг -- это терпимо. то, что у меня на экспериментальном двиге делается за 15 ms, на продакшен двиге (моем же) делается за 40 сек. и все довольны. у конкурентов-то оно делается 10 ~ 15 минут. и все! руководство _очень_ довольно. а там у меня все _ужасно_ тупо и буквально за пару дней работы можно было бы оптимизировать с 40 сек по крайней мере до 6 сек. а может и до 3 сек. но... меня никто не пинает. скорость вполне устраивает. руководство больше печалиться, что интерфейс (а это уже не моя часть работы) галимый и бажный.
так и с хромом. гугловцы просто не видят проблемы в этих 100 метрах. и ведь конкуренты отъедают не сильно меньше... отсюда у разработчиков отмазка, что по другому делать не надо и все равно не получится.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я — в своей правоте уверен. По очень простой причине — я все это видел своими глазами и работал с этим. Я готов допустить, что нынешние языки и средства сложнее тех, что были 10-20 лет назад, в 5-10 раз. Но я никак не могу согласиться с тем, что они сложнее в 100 раз. Если бы я видел, что нынешнее ПО требует в 10 раз больше памяти и быстродействия , чем ПО 10-20 летней давности. я бы и слова не сказал. Но когда я вижу, что потребности в памяти увеличились в 100 раз, скорость процессора — в 50-100, в все вопят — памяти мало, программы тормозят (и это правда), то объяснение только одно — разучились писать как следует.
Это всего лишь потому, что ты сравниваешь вот в таком виде — BC на старом проце супротив VС на новом.
Сравнить BC vs VC в одинаковых условиях тебе не помогает 640кб-религия
Ты даже TP супротив Дельфи боишься сравнить в одинаковых условиях, хотя чуть не в каждом сообщении вспоминаешь этот TP.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я просто там ничего относящегося к делу там не нашел. Ну реализация калькулятора, ну в байт-код, ну и что ? Может, он и хороший, но какое отношение к делу имеет ?
Прямое. Я тебе показываю как работают интерпретаторы.
А то ты судя по твоим словам не знаешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>JS V8 делает тоже самое, но уже в памяти.
PD>А c ТурбоПаскалем ты знаком, нет ? У него режим был — все в памяти. На входе — .pas, результирующая программа создается прямо в ОП, никаких файлов вообще не создается. А компилировал прямо-таки с жуткой скоростью. И знаешь, сколько памяти нужно было первой версии TP ? 64 килобайта. На Ямахе именно столько памяти и было. Последняя версия TP (7.0) работала под DOS и ей хватало 640 Кб. Я в те времена вел кружок в школе, на машинах без винчестера, только 1.44 флоппи, тактовая 12 MHz, и он у меня прекрасно работал. Так-то!
Правльно понимаю, в браузере используется аналог Turbo Pascal ?
Или же более мощный и динамический язык с GC + кодогонерация в рантайме + DOM + CSS + Rendering + многопоточность ?
M>>В 1996-м году никому и в голову не приходило, что на странице будет полмиллиона объектов (а ведь Владимир тебе скриншот привел)
I>Полмиллиона это не на странице, а в рантайме, т.е. в памяти браузера.
Хм. Судя по скриншоту — это таки для вкладки, где открыт gmail, ане для всео браузера. Что так же видно по колонке count для этой страницы.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>JS V8 делает тоже самое, но уже в памяти. PD>А c ТурбоПаскалем ты знаком, нет ?
ТурбоПаскалем статически типизированный язык.
Ты конечно можешь не верить но разница в компиляции статически типизированного языка и динамически типизированного огромна.
Я бы даже сказал там нет почти ничего общего.
В случае со статикой мы можем сгенерировать машинный код не запуская программу.
В случае с динамикой это сделать нельзя ибо набор полей и методов у объекта будет известен только во время исполнения программы.
Апеллировать к паскалю глядя на то как компилятр жабаскрипта кушает память просто глупо.
Ибо там работают принципиально разные алгоритмы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
I>>>JS V8 делает тоже самое, но уже в памяти. PD>>А c ТурбоПаскалем ты знаком, нет ? WH>ТурбоПаскалем статически типизированный язык.
Это все ерунда.
Турбо Паскаль умел оперировать количеством памяти которое (в байтах) меньше количества объектов в хипе JS.
Мало того — он еще и делал это очень медленно, потому что генерировал тупой, идиотский код.
WH>>>>А что касается 640кб да не вопрос. Только получится интерпретатор который будет все также тормозить.
PD>>>Ладно, давай заканчивать (это ко всем веткам относится).
M>>Действительно, стоит заканчивать. Если ты даже ссылки
не удосуживаешься смотреть, а размахиваешь турбопаскалем направо-налево с криками «нипанимаю»
PD>Дима, я просто устал от этой дискуссии. Владимиру я ответил сегодня, он как-никак ТС, а больше никому не буду. Извини.
Ну как бы ты не особо и не отвечаешь
Ты спашиваешь: объясните, а то в TP все просто
Тебе дают ссылку на дизайн V8, где все показано даже картинками.
Ты спрашиваешь (не глядя на картинку): объясните, а то в TP все просто
Тебе отвечают, расписывая архитектуру браузера, пробелмы, возникающие при реализации всего этого дела и т.п.
Ты спрашиваешь (не читая): объясните, а то в TP все просто
Ну и т.п.
Пол-моему, в этом топике все расписано и разжевано достаточно четко. Но диалог какой-то односторонний получается
Здравствуйте, Mamut, Вы писали:
M>Ты спашиваешь: объясните, а то в TP все просто M>Тебе дают ссылку на дизайн V8, где все показано даже картинками. M>Ты спрашиваешь (не глядя на картинку): объясните, а то в TP все просто M>Тебе отвечают, расписывая архитектуру браузера, пробелмы, возникающие при реализации всего этого дела и т.п. M>Ты спрашиваешь (не читая): объясните, а то в TP все просто M>Ну и т.п.
И т.п.
Понимаешь, все эти аргументы бледнеют перед одним простым фактом — компиляторы, которые работают в 1-2 Мб, сделать можно. Я не знаю , что они там в v8 сделали, и, честно говоря, мне это не слишком интересно. И разбираться в их исходниках, чтобы сказать, где там можно затраты памяти подскоратить, я не буду. Тем более, что, возможно, для этого нужен полный пересмотр всей архитектуры, а я не в силах такое сделать. Я вообще не специалист в построении компиляторов, а поэтому отнюдь не собираюсь ни анализировать существующие реализации, ни давать советы. Я просто констатирую факт — пока памяти было мало, они занимали эту малую память и работали с приличной скоростью. Значит, это можно сделать. Я бы понял, если бы речь шла о языке, на порядки более сложном. Но этого нет. Вот и все.
Что касается броузера и применимости js — см. мой сегодняшний ответ Владимиру.
Извини, но я действительно устал от этой дискуссии.
это ж шедевр просто
PD>Понимаешь, все эти аргументы бледнеют перед одним простым фактом — компиляторы, которые работают в 1-2 Мб, сделать можно.
и в лучшем случае они будут иметь такой же процент функционала от сегодняшних компиляторов, какой имеет линукс среди десктопов
PD>Я не знаю , что они там в v8 сделали, и, честно говоря, мне это не слишком интересно. И разбираться в их исходниках, чтобы сказать, где там можно затраты памяти подскоратить, я не буду. Тем более, что, возможно, для этого нужен полный пересмотр всей архитектуры, а я не в силах такое сделать. Я вообще не специалист в построении компиляторов, а поэтому отнюдь не собираюсь ни анализировать существующие реализации, ни давать советы.
да, "не специалист", "не буду", "не интересно", но у них всех кривые руки.
PD>Я просто констатирую факт — пока памяти было мало, они занимали эту малую память и работали с приличной скоростью. Значит, это можно сделать.
ставить скорость сборки выше скорости выполнения результата это суметь надо
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>>>Но если уж они есть, то не надо из них монстра делать. Переменные могут менять свой тип, но типы-то не могут! 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'ом.
Здравствуйте, WolfHound, Вы писали:
PD>>Если бы мы портирование обсуждали — существенно. Но мы язык обсуждаем. А он на 99% тот же. WH>БРЕД! Язык не поменялся но вот уровень поддержки языка в разных компиляторах отличается очень существенно.
А можно подробнее ? Я, например, перенес свой проект с BC++ на VC++. Не знаю, что ты имеешь в виду под уровнем поддержки, но перенос прошел без особых проблем.
А то ведь договоришься и до того, что уровень поддержки различен ну хотя бы для VC++ и ICC++. Что же мне, грешному, потом делать-то — я привык свом программы после окончания разработки транслировать в ICC++, в надежде получить какой-нибудь выигрыш в быстродействии. А теперь буду мучиться — работать-то работает, даже быстрее, а как же с уровнем поддержки ?
А уж на GNU C++ переводить — все, никак невозможно. Не может же там быть тот же уровень поддержки! Он вообще из юникса, в Windows — не родной. Пойди в форум по С++ и скажи там всем, что из-за уровня поддержки они должны перенос VC++ <-> GNU C++ немедленно прекратить!
M>>Почему ты так упорно не хочешь читать дальше первых двух строчек? M>>// при этом сам тип A никуда не делся:
M>>var c = new a(); PD>Ну и на здоровье. Я разве говорил, что он исчез ?
M>>b.f() // есть такая функция, потому что она есть в типе A PD>Отлично. В описании типа A есть такая функция.
M>>b.aa() // есть такая функция, потому что она есть в типе B PD>То же.
То же что?
M>>c.f() // есть такая функция, потому что она есть в типе A PD>То же M>>c.aa() // ошибка, нет такой функции, потому что она есть тольков типе B, уникально для переменной b PD>То же.
M>>Выделенное убивает все твои рассуждения о типах. PD>Не понял, почему. PD>Тип A содержит описание f PD>Тип B содержит описание aa
Угу. Только переменная b случайно оказывается двух типов одновременно. Потому что любое изменение типа A повлечет изменения и в переменной b.
PD>Переменная c типа A, вызвать f можно, а aa нельзя, потому как нет ее в типе A
Потом ты делаешь это:
c.new_field = неважно_что
Какого типа будет переменная c?
После чего ты делаешь это:
a.prototype.other_field = неважно что
что должно отразиться и на a и на b и на c. При этом у b и c будут личные, ни на что не похожие типы. О чем, в принципе, говорится по ссылке, коорую ты упорно игнорируешь.
M>>В реальной жизни такие изменения типов сплошь и рядом.
PD>Я не сопрю, но все же, думаю, использований без изменения типа больше ? На порядки, наверное. Все же в основном переменные заводят для того, чтобы с ними что-то сделать, а не тут же, не использовав, немедленно сменить ей тип и опять, не использовав, смнить тип
PD>Важно, что рантайм должен уметь эти финты ушами делать в любой момент для любого объекта любого типа — менять тип, расширять тип, создавать новый тип. Для каждого из сотен тысяч объектов, каждый из которых потенциально обладает уникальным типом.
PD>Эээ, вот тут-то самое интересное. PD>Рантайм должен это делать — бесспорно. PD>Но он должен также сообразоваться с тем, как часто происходят изменения типов и использование. Вот в этом вся хитрость и есть.
Ссылку, как это делает рантайм я уже приводил.
M>>Именно поэтому v8, например создает скрытые классы на каждый чих (ссылку, блин, даю в пятый раз).
PD>Дима. я смотреть не буду, нет никакого желания и времени разбираться в том, что мне, в общем, не нужно. Я не спорю, может они и неплохое решение сделали, но похоже, все же очень дорогое.
Действительно. смотреть не буду, разбираться не буду, но уверен, что был бы я, всю бы архитектуру с нуля переписал, ага.. Хороший подход, ничего не скажешь Но я повторяюсь
.
PD>Ты все же мне так и не ответил на мой вопрос. Если бы в 2000 году остановилось развитие железа, то что, современные сайты со всем этим js и т.д в принципе не могли быть созданы ?
В принципе не могли бы быть созданы. Причины я привел тут
. Появились бы другие способы достичь того же, или чего-то похожего. Ты, кстати, сам себе ответь — почему интерфейс уровня GMail'а не появился в 2000-м году? И с какой сокростью он бы работал, если бы появился. Хотя... Достаточно поставить в виртуалку win 98/me, и запустить тот же gmail.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>>А ты в курсе, что 16 бит — это не только другая оптимизация, но и другая модель памяти (неплоская), да не одна, а целых 5 (tiny, small, ...)? Ты в курсе, как там адреса формируются ? память адресуется ? Ты хоть что-то о huge-указателях слыхал и как под них память выделяется, хоть что-то знаешь ? I>>>>Конечно знаю PD>>>А если знаешь, то мог бы и сообразить, что компиляция на 16 бит по сравнению с компиляцией на 32 бита намного больше отличается, чем на 32 и 64. A>>неужто компиляция под 16бит сложнее чем на 32/64, при том что с 32 там напихали всяких симдов, а huge указатель ты описываешь сам, и компилятору не надо париться с автоназначением типов указателей? PD>Ты просто не в курсе того, о чем судишь.
это типа попытка меня спровоцировать на что-то?
в контексте "Я вообще не специалист в построении компиляторов"
очень авторитетно прозвучало...
PD>huge указатель я назначаю сам, да, а вот для выделения памяти под него придется добавлять несколько элементов в LDT, потому что в 16-битной модели сегмент не может превышать 64 К. Поэтому вот такое PD>huge char* p = new char[128K] PD>потребует 2 вызова AllocSelector (вроде так называлась, не помню) PD>И когда его значение станет равно PD>xxxx:0FFFFh PD>и будет p++, он должен превратиться в PD>xxxx+8 : 0 PD>что, как сам понимаешь, одной командой inc не сделаешь. PD>И все это компилятор должен в код заложить. Или библиотека компилятора.
а мужики-то и не знают!
я вообще-то спрашивал "сложнее ли".
так вот, повторяю с расшифровкой, на случай если кто не в курсе того, о чём судит:
что сложнее:
1. 2 вызова allocselector + сгенерить if на изменение указателя (причём тут точно известно, что это надо сделать)
2. векторизация чего-либо, что тянет за собой проверку на алиасинг (что в общем случае сделать в compile-time невозможно, а пихать if-ы в runtime часто нецелесообразно)
кстати, ты очень аккуратно так убрал мои слова про mcmodel — с чего бы?
Здравствуйте, WolfHound, Вы писали:
WH>Апеллировать к паскалю глядя на то как компилятр жабаскрипта кушает память просто глупо. WH>Ибо там работают принципиально разные алгоритмы.
Ой, да ерунда всё это. Павел прав в главном.
Если уж жабаСкрипт такой урод, что для его реализации надо жрать память сотнями метров и проц мегафлопсами (хотя я в это не верю, на самом деле), то он бы просто издох, под своей моструозностью, если бы компы так нереально не окрутели бы. И вместо жабаСкрипта был бы какой-нибудь лягушкаСкрипт, не имеющий этих проблем...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Ой, да ерунда всё это. Павел прав в главном. E>Если уж жабаСкрипт такой урод, что для его реализации надо жрать память сотнями метров и проц мегафлопсами
Если бы современным программам на все про все хватало бы одной перфокарты...
Здравствуйте, Erop, Вы писали:
E>Прикольно при этом то, что даже разрабы свободного или условно свободного ПО тоже ввязались в войну фич, а вовсе и не скорости, компактности и безглючности...
нормальный пользователь хочет фич, плюшек и возможность попить чай/кофе пока тормозит ворд, а отдельные личности почему-то решили, что надо пользователя ткнуть мордой в текстовый экран и заставить набивать текст/код на скорость — естественно, они в пролёте. к тому же, война фич даёт работу много кому, и это правильно.
Здравствуйте, Erop, Вы писали:
I>>Пользуйся нотпадом — он не тормозит даже на древних компах. E>При чём тут нотепад?
Т ж говорил что фунункционал не главное, а главное — скорость, компактность и тд.
I>>Вот уже конспироложество полезло. Еще чуть чуть и скажешь что потребность в чтении, общении была навязана сверху E>Это ты так думаешь, а не я. E>И потом при чём тут конспироложество, вообще? То, что рынку крупными игроками навязана та, или иная модель -- это экспериментальное наблюдение, а не конспироложество.
Это конспироложество. Ты вообще можешь хоть как то объяснить, каким образом было навязано это дело ?
E>Это просто неправда. Например, я ещё помню времена, когда ОС конкурировали именно по скорости, надёжности и компактности. Тот же лялих себе долго-долго это в мегаплюс записывал. Не знаю, записывает ли сейчас E>Я думаю и ты их вспомнишь, если напряжёшься. Они закончились всего лет восемь назад
И сейчас и раньше в первую очередь конкурировали по фичам для пользователя, а потом — по перформансу и тд.
I>>Именно так.Фичи они всегда востребованы на рынке. Это не значит софт ценен списком фич. Это значит, что новые фичи экономят(или дают заработать) бОльше времени/денег, чем старые.
E>Это тоже маркетинговое враньё. Во-первых, лично тебе приносят пользу только те фичи, КОТОРЫЕ ТЫ ИСПОЛЬЗУЕШЬ, а те, которые не используешь -- приносят вред
Так враньё или приносят таки пользу ? Естественно, лишние фичи(для конкретного пользователя) усложняют софт и это одна из центральных проблем в софтостроении, которая до сих пор решения не имеет.
E>Вот как сильно возрос список лично тебе нужных фич текстового редактора, со времён 7-го ворда, например?
С вордом я почти не сталкиваюсь. В таких программах уже давно развитие в основном идет за счет юзабилити.
I>>А тормоза — это издержки. Время/деньги важнее. E>Ну так я же написал, что куда оптимизировать -- это вопрос ценностного выбора и маркетинговой стратегии
У конкУрентов микрософта продукты очень часто и быстрее и компактнее, однако толку пока не видно, их даже впарить забесплатно не всегда можно.
E>Нет. Если бы это было так, то не было бы облегчённых версий, например. E>Скажем я дома использую хомяк файна, а не его профессиональную версию. Как ты думаешь, почему?
Потому что тебе нужны вполне конкретные фичи, а не их отсутствие. То есть даже хомяк файна ты берешь сначала из за фич, а потом уже из за скорости и тд.
E>При этом я использую хомяк одного из последних, тем не менее, хотя на нетбуке, использую всё же пятёрку. Тоже, как ты думаешь, почему?
см выше.
E>Мало того, я ещё больше утверждаю. E>1) Большинство пользователей не понимают, что у каждой фичи есть стоимость владения. Так что каждая неиспользуемая фича -- это убыток.
Да, но отсутствие неиспользуемой фичи может оказаться еще большим убытком.
E>Например, я пользовался очень навороченными телефонами, а потом осознал, что это мне не надо, и теперь юзаю очень простую звонилку. Зато маленькую и с длинной батарейкой. И дешёвую довольно
Ты сто пудов пользовался говном вроде нокии и только потом "осознал"
E>2) Большинство пользователей вообще не дают себе труда как-то систематизировать свои действия и сценарии работы. Так что они вообще не могут понять какие фичи им нужны, какие нет, а какие конкретно мешают и снижают производительность.
Конечно, потому за них продумывают и анализируют другие люди, а потребители действуют интуитивно — вызывает положительные ощущение, пользуются. Вызывает дискомфорт — не пользуются.
I>>Это тебе его достаточно, а я его и видеть не хочу. E>Почему? Как думаешь, какой фичи современного форда тебе не хватит в пятом?
Я про форд ничего не могу сказать, т.к. водить машину не умею. Но мне нравятся машины в которых тепло, сухо, комфортно, тихо, при условии что они ездят хотя бы со скоростью 40-60 кмч что хватит для большинства случаев, в такие машины я и сажусь как пассажир такси например.
В жигулях-такси например больше 10 лет не ездил, глядя по сторонам не я один такой
I>>Но если тебе нужны фичи — ты можешь взять второй. E>Я возьму первый, так как редко всё сразу бывает хорошо.
То есть откажешься от нужной фичи что бы все остальные работали хорошо ?э
Так поступают ПРОФЕССИОНАЛЬНЫЕ пользователи.
Для обычных пользователей отсутствие мелкой фичи может вылиться и выливается в недельный геморрой.
I>>Ему нужны общение, познанние, развлечение и тд. I>>Компьютер это только средство. E>Причём неудачно. Удачное -- это, например, римские термы
Ага, которые были доступны примерно одному из тысячи, при том что компьютер доступен примерно каждому пятому-десятому.
I>>Им нужен софт который умеет решать все дела. E>Я считаю, что эта модель навязана крупными производителями ПО.
Такие тенденции вообще везде. В любой отрасли. Миниатюризация + увеличение возможностей.
E>Вот автомашина у тебя электричество для дачи вырабатывает, например? Нет? А почему, ведь она может в принципе?
Я все чаще вижу, как люди машину используют как медиа-центр для дискотек на даче.
I>>Что это за софт, ты уже знаешь — браузер, т.е. единственно настоящий софт который умеет решительно все. E>Полный бред. Браузер почти ничего полезного не умеет. То, что всё надо делать через б., который при этом должен быть х. -- это маркетинговое враньё, распространяемое гуглом. Просто потому, что ему так выгодно.
Это еще до гугла произошло. Просто мало кто заметил и по этой причне гугл и заработал деньги.
E>Вот смотри, на домашнем компе, я E>смотрю кино/слушаю музыку (это на одном, отдельном) E>пишу и редактирую тексты E>пользуюсь всяким специфическим софтом, вроде бюджетирования и планирования рационов спортивных походов, например. E>Храню приватную инфу E>Хожу по нету.
E>Ну и что из этого умеет браузер?
Абсолютно всё, кино, музыку, тексты, бюджетирование, планирование, приватная инфа. Ну а по нету, ясное дело, ты браузером ходишь.
I>>Все остальные софтины, кроме средств разработки, по функционалу стремятся именно к браузеру. E>Тоже бред. Скажем касперский, файнридер, винамп туда нифига не стремятся вроде как...
Винамп это отстой. Другие плейеры именно к браузеру и стремятся. Касперский — это системный софт, он вобщем то никаких потребностей не удовлетворяет. Файнридер — специализированый, он тоже никаких потребностей не удовлетворяет.
Здравствуйте, Erop, Вы писали:
I>>Т ж говорил что фунункционал не главное, а главное — скорость, компактность и тд. E>Ты споришь про абстрактные какие-то продукты. А я тебе пытаюсь пояснить, что текстовый редактор и мыльница уже 15 лет назад умели всё, что на самом деле нужно. И умели это неплохо.
Умели только редактировать текст, чуть лучше чем нотпад, и умель только отсылать почту.
При этом пользователю надо не текст и почта, а общение. А для этого надо побольше тех самых фич.
Не нужна пользователю почта. Ему надо общаться.
Общение включает в себя не только отсылку и прием почты, но и чаты и социальные сети и прочую дрянь.
По этой причине нынешние почтовики такую потребность как общение удовлетворяют гораздо лучше, чем раньше.
I>>Это конспироложество. Ты вообще можешь хоть как то объяснить, каким образом было навязано это дело ? E>Так же как и любая мода. Вот как iPhone навязан, например? Хорошие PR + маркетинг,..
Никто не навязывал. Пользователи приняли. Реклама всего лишь ускорила этот процесс.
Приняли потому что удобно, просто, функционально.
I>>И сейчас и раньше в первую очередь конкурировали по фичам для пользователя, а потом — по перформансу и тд. E>Ну перфоманс был одной из ВАЖНЫХ фич...
Он и сейчас важен, только никогда самой главной фичей не будет.
I>>Так враньё или приносят таки пользу ? E>Ну те, которые ТЕБЕ НА САМОМ ДЕЛЕ нужны, приносят пользу, а те, которые нет -- пользу уносят. Если вторых много больше, чем первых, польза в среднем может стать отрицатльной
Это и ежу понятно. И сейчас лишние фичи в таких продуктах как Офис вообще не мешают.
Ты про них и не знаешь, пока не понадобятся и только по этому ты утверждаешь что их там нет.
E>Да имеет она решение. Просто то решение, которое выгодно пользователям не выгодно производителям ПО. Конфликт интересов групп...
Ну и дела — люди готовы платить деньгами, а производители ПО отмахиваются от этого
I>>С вордом я почти не сталкиваюсь. В таких программах уже давно развитие в основном идет за счет юзабилити. E>То есть тебя бы устроил ворд 10-15 летней давности. Так?
Нет и ответ на это был даден. Старым вордом очень тяжело пользоваться.
E>Дык главная фишка ворда -- это то, что он везде есть. Она побеждает всё. E>Но вот я, например, для редактирования своих текстов вордом сильно не всегда пользуюсь, ты. я так понял, тоже...
У меня есть VS2010, это основной редактор. Еще есть Onenote 2011. Ворд — раз в месяц и я не хочу того говна которое было 10-15 лет назад.
I>>Потому что тебе нужны вполне конкретные фичи, а не их отсутствие. То есть даже хомяк файна ты берешь сначала из за фич, а потом уже из за скорости и тд. E>Не, именно файна я беру из-за точности.
Во первых, из за фич. Именно набор фич делает софтину файном. А точность это еще одна фича, только нефункциональная.
Судя по твоим выступлениям, ты понятия не имеешь, что такое нефункциональные фичи а между тем на это огромный спрос.
I>>см выше. E>А вот ресурсы оказываются дороже фич. А современный рынок ПО такого выбора почти не даёт...
Какие ресурсы ? Самый главный ресурс это время. Нынешние фичи его экономят гораздо лучше, чем те что были 10 лет назад.
I>>Да, но отсутствие неиспользуемой фичи может оказаться еще большим убытком. E>Может, но не обязано. Вопрос сложный. Часто всё ровно наоборот происходит. Стоимость освоения новой фичи вообще превышает всю выгоду от её использования за всё время
Это значит что фича по факту отсутствует.
I>>Ты сто пудов пользовался говном вроде нокии и только потом "осознал" E>Нокией не пользовался вообще, но я не понимаю, почему ты считаешь её "говоном"? E>И, тем не менее, когда была первая война фич в телефонах и я ушёл в конце концов на простые звонилки, тоглда нокия была лидером рынка, и соответствовала выбору миллионов и могла навязать много чего юзерам.
В телефонах идет тот же самый процесс.
I>>Конечно, потому за них продумывают и анализируют другие люди, а потребители действуют интуитивно — вызывает положительные ощущение, пользуются. Вызывает дискомфорт — не пользуются. E>Ну да, но эти люди ставят цель заработать денег себе, а не съэкономить усилий пользователю. Такой вот потреблятский рынок в ПО сформировался.
Ты пойми одну вещь — если пользователю не нравится софтина или устройство, он рано или поздно перестаёт им пользоваться.
Другого расклада не бывает.
E>Вот в автомобилях, например, загогулина вырулила к тому, что ты сам решаешь, какие фичи тебе на борту нужны, а какие нет. А вот в ПО так пока не делают
Коврик, пепельница, кондиционер, объем двигателя ?
Автомобиль это длинный перечь обязательных фич которые ты менять не можешь.
Более того, если ты залезешь в базу аналогов по автомобильным запчастям то сильно удивишься.
Аналоги могут отличаться по цене на порядок при абсолютно одинаковом качестве.
И из всего этого ты практически ничего не можешь менять. Наприер никто тебе не продаст автос без выхлопной трубы или без задних колёс.
В софте все идет к тому же — обязательный перечень фич для определенных пакетов.
I>>Так поступают ПРОФЕССИОНАЛЬНЫЕ пользователи. I>>Для обычных пользователей отсутствие мелкой фичи может вылиться и выливается в недельный геморрой. E>Это просто от того, что у них сформирована такая модель поведения. Реально нужных фич очень мало, и они все везде давно реализованы
Наоборот. Они просто не умеют пользоваться компьютером, софтом. Для этого нужны годы опыта. А вот у тебя именно сформированая модель поведения.
I>>Ага, которые были доступны примерно одному из тысячи, при том что компьютер доступен примерно каждому пятому-десятому. E>Это где он так доступен?
Везде. В среднем конечно же. Компьютеров примерно между 1 млрд до 2 млрд, а населения — 6 млрд. Я не говорю, что личный компьютер есть у каждого пятого — я говорю, что компьютер доступен каждому пятому-десятому.
E>Кроме того, не понятно, что мешает сейчас сделать заведение вроде терм доступным каждому желающему?
Где есть вода и другие ресурсы это уже есть. И обычно складывается так, что в этих же странах и компьютеров больше всего.
I>>Такие тенденции вообще везде. В любой отрасли. Миниатюризация + увеличение возможностей. E>Дык это особенность последних несколько десятков лет. Одноразовые всемогутеры на полгода, которые потом надо заменить ещё более одноразовым ещё более всемогутером...
Всемогутеры у тебя в голове. Компьютер удовлетворяет вполне конкретные потребности. Компьютер не будет делать за тебя детей например.
E>Это такая бизнес-модель эпохи НТТР. Если удаётся навязать в каком-то сегменте рынка такое поведение потребителям, то дальше хорошие вещи делать не надо, надо делать вещи, которые можно хорошо впарить.
Опять полезло конспироложество
I>>Я все чаще вижу, как люди машину используют как медиа-центр для дискотек на даче. E>И это что, удобно? Или качество звука хорошее получается?
Да, удобно. Что для тебя хорошее ?
Вариант А — дачный домик где полно аппаратуры вдали от города.
Вариант Б — тыщить аппаратуру на себе каждый месяц
Вариант В — обходиться бумбоксом.
Очевидно — хорошая автомобильная аккустика дешевле на несколько порядков варианта А, несравнимо легче варианта Б и намного качественнее варианта В.
I>>Это еще до гугла произошло. Просто мало кто заметил и по этой причне гугл и заработал деньги. E>Да гугол это продвигает, а перед этим M$ продвигала, которая хотела ентерпрайз на свой IE6 подсадить. Вот так маркетинговую политику и заточили...
Ой, не гони. Микрософт вообще забила на браузер и не рассматривала его всерьез. Одно время даже официально заявили что развивать не будут.
E>Да и неудобно же это нифига. Удобно иметь несколько простых интерфейсов для конкретных вещей.
Пользователю нет времени развиваться с твоими интерфейсами и потому удобно иметь один и тот же интерфейс ровно для трех потребностей — развлечение, общение, познание.
E>Вот телевизор -- это удобно. И магнитофон с радио -- удобно.
И то и другое редкое говно. Телевизоры все больше становятся похожими на компьютеры, а магнитофоны и вовсе вымерли. Плейеры нынешние уже больше на компьютеры похожи.
E>А если про тенденции говорить, то все идут в телефоны сейчас, и прочие мобилы. И там лишняя прокладка в виде браузера нафиг не упёрлась
Это ты так думаешь. На мобильных гаджетах _уже_ начались войны браузеров.
I>>Абсолютно всё, кино, музыку, тексты, E>Хреново он это умеет. Особенно тексты редактировать и НОРМАЛЬНО кино показывать. Нормально -- это с 5.1 или 7.1 звуком + выбор камеры, языка, титров, 3D, и т. д...
А это отдельные фичи — нефункциональные.
I>>бюджетирование, планирование, приватная инфа. E>Соответственно браузер встаёт и идёт лесом
Вылезь из конуры хоть на пять минут ?
I>>Винамп это отстой. Другие плейеры именно к браузеру и стремятся. Касперский — это системный софт, он вобщем то никаких потребностей не удовлетворяет. Файнридер — специализированый, он тоже никаких потребностей не удовлетворяет. E>Не понимаю, что значит "никаких потребностей не удовлетворяет"? Зачем тогда его ставить?
Ну в твоем случае может у тебя секс с Касперским или общение, я ведь не в курсе
E>И почему винамп отстой? Зачем прослушивалке музыки браузер?
Для покупки, скачивания и тд. Вот нарыл ты музыки чуток и хочешь найти остальные треки или альбомы ?
Можно по идиотски — загрузить браузер, лазить в поисковике, регистрироваться на сайтах.
А можно по простому — один раз кликнул и перешел к полной подборке. Второй раз кликнул — заполучил музло себе.
Здравствуйте, Ikemefula, Вы писали:
E>>Ты споришь про абстрактные какие-то продукты. А я тебе пытаюсь пояснить, что текстовый редактор и мыльница уже 15 лет назад умели всё, что на самом деле нужно. И умели это неплохо.
I>Умели только редактировать текст, чуть лучше чем нотпад, и умель только отсылать почту.
Ты можешь просто и понятно объяснить, какой именно фичи тебе не хватало в пятом ворде, например?
Если не помнишь/не видел пятого, что весьма вероятно, то какой не хватало в 7-м?..
Единственное, что мне приходит на ум, так это проверка орфографии по мере набора текста. Ну и поставка русского спеллера "из коробки". Но я уверен, что тот же самый "лингвокорректор" или "орфу" можно было поставлять и с коробкой 7-го ворда...
I>При этом пользователю надо не текст и почта, а общение. А для этого надо побольше тех самых фич. I>Не нужна пользователю почта. Ему надо общаться.
Не. Чтобы общаться надо вообще другое. Надо не в компе сидеть, а идти к людям, тусовать где-то и т. п.
Для развлечений тоже самое.
А сколько ты фич на браузер не навернёшь, общение лучше от этого не станет. Так что давай не будем повторять маркетинговое враньё?
Утверждать, что пользователям нужно общаться, поэтому им нужны чаты и соц. сети, это примерно тоже самое, что утверждать, что людям нужно счастье, поэтому им нужны наркотики...
Кроме того, если кому-то нужна социальная сеть, то ему нужна социальная сеть. Так бывает. Соц. сети легко вызывают зависимость. Так же как и героин. Но есть много людей, кому нужно мыло, а не "общаться". Ну чисто в качестве инструмента вступить с тобой в контакт, если ты кому-то зачем-то понадобился. Не в смысле бота для чата, а в смысле инструмента асинхронной приватной коммуникации.
I>Общение включает в себя не только отсылку и прием почты, но и чаты и социальные сети и прочую дрянь.
Ты сам понимаешь, что все эти "фичи для общения" -- это дрянь. Почему же ты утверждаешь, что пользователи нуждаются в дряни?
IMHO, вполне понятно, что их на эту дрянь осознанно подсаживают, с целью паразитировать потом на возникшей у человека зависимости.
Так же как в игровом бизнесе, илши табачном, или нарко и т. д...
I>По этой причине нынешние почтовики такую потребность как общение удовлетворяют гораздо лучше, чем раньше.
Да ну? Что это за "нынешние почтовики" такие? Вот, например, я общаюсь с коллегами в одном закрытом театральном чате, и тут. И иногда обмениваюсь инфой с руководителями тургрупп, на всяких спец. ресурсах. И в какой же почтовик это всё интегрировано, можно узнать?
E>>Так же как и любая мода. Вот как iPhone навязан, например? Хорошие PR + маркетинг,.. I>Никто не навязывал. Пользователи приняли. Реклама всего лишь ускорила этот процесс.
Что они приняли? Что вообще нового/хорошего/нужного в аймобилко? Прибор для измерения ускорений? И то не ново было...
I>Приняли потому что удобно, просто, функционально.
Я так не считаю. Я считаю, что 99% пользователей купили себе аймобилко потому, что это круто и модно, а не потому, что это как-то там удобно или функционально. Первый iPhone вообще был недоделанным уродом, например
I>Он и сейчас важен, только никогда самой главной фичей не будет.
Это не правда. Кому как и когда. Когда припекает, то главная функциональность выходит на первый план. А когда пофиг всё, то шашечки становятся важнее...
I>Это и ежу понятно. И сейчас лишние фичи в таких продуктах как Офис вообще не мешают.
Так ты определись, вредят ли лишние фичи, или нет?
Вот я уверен, что вредят. Но обсуждать именно это нужно в отдельном топике, IMHO.
I>Ты про них и не знаешь, пока не понадобятся и только по этому ты утверждаешь что их там нет.
Кого и где нет? И про кого я это утверждаю?
Ты не понимаешь, как тебе вредят фичи ворда про которые ты не знаешь? Я могу привести тебе пример. Макросы ворда, могут быть совершенно скрыты от твоего сознания, но при этом от вирусов вордовых ты всё равно огребёшь
E>>Да имеет она решение. Просто то решение, которое выгодно пользователям не выгодно производителям ПО. Конфликт интересов групп...
E>>То есть тебя бы устроил ворд 10-15 летней давности. Так? I>Нет и ответ на это был даден. Старым вордом очень тяжело пользоваться.
Почему? Чего в нём не хватает? Кстати, кто такой "старый ворд"? 2-й? 5-й? 6-й? 7-й? 2000-й?
I>У меня есть VS2010, это основной редактор. Еще есть Onenote 2011. Ворд — раз в месяц и я не хочу того говна которое было 10-15 лет назад.
Так что именно тебе не нравилось в старом ворде, или что хорошего появилось в новом?
I>Во первых, из за фич. Именно набор фич делает софтину файном. А точность это еще одна фича, только нефункциональная.
Не понимаю о чём речь. Файном файн делает то, что им можно распознать страничку И НЕ ПРАВИТЬ ЕЁ ПОТОМ. Это основаня главная и единственная фича.
Вторая важная фича -- это если уж пришлось править, то удобно смотреть что было нарисовано в распознаваемом документе, на том месте, которое сейчас находится под курсором в редактируемом тексте-результате распознавания. Эта вторая фича уже менее важная. И её в хомяке нет. А всё остальное -- полная фигня. Мелочи и бантики. Распозанвалку, в которой есть просто море фич, но которая не имеет той самой главной я вообще рассматривать не буду. Она мне не нужна, хоть бы она кино бесплатно казала и браузером была самым лучшим
I>Судя по твоим выступлениям, ты понятия не имеешь, что такое нефункциональные фичи а между тем на это огромный спрос.
Ну ты объясни, что это такое.
Ты, IMHO, вообще не понимаешь моего тезиса.
Тезиса два, они разные, и один ты вообще не обсуждаешь, а второй извращаешь.
Второй тезис состоит в том, что спрос на большинство фич, хотя бы и огромный, создан искусственно. И на самом деле они не нужны.
Первый тезис состоит в том, что обилие фич, особенно не сильно нужных, не стоит тотального утяжеления ПО...
E>>А вот ресурсы оказываются дороже фич. А современный рынок ПО такого выбора почти не даёт... I>Какие ресурсы ? Самый главный ресурс это время. Нынешние фичи его экономят гораздо лучше, чем те что были 10 лет назад.
Примеры будут?
Давай рассмотрим редактор текста и мыльницу. Раз уж мы про это говорим. Какие такие фичи, скока времени экономят, при каких раскладах...
А то пока что ты показал, как переделав мыльницу в чат-переросток можно сжечь сколько угодно времени, а не сэкономить
I>Это значит что фича по факту отсутствует.
Нет не значит. Она по факту присутствует, и навязывается даже. Так как фичу заказали маркетологи, чтобы потом её толкать и впаривать. И тебе либо самому надо знать очень точно, что именно тебе надо, либо разгребать весь этот маркетинговый поток заманух, либо делегировать кому-то эту обязанность...
Ещё раз, что за фичи в современном ворде делают его ДЛЯ ТЕБЯ лучше, по сравнению с 7-м или 5-м? И откуда ТЫ ЛИЧНО узнал, что именно эти фичи, а не какие-то другие?
I>Ты пойми одну вещь — если пользователю не нравится софтина или устройство, он рано или поздно перестаёт им пользоваться.
Конечно. Но тут есть две тонкости
1) Сейчас выгодно делать так, чтобы пользователю захотелось проапгрейдлится. Решения "на века" нынче мало кто предлагает
2) На короткое время "нравится/не нравится" можно сильно сместить при помощи PR и рекламы. Вот смотри, в миниюбках легко простудить яйцы и засветить кобуру, но заметно это становится не сразу. Поэтому мода на них всё время возвращается
E>>Вот в автомобилях, например, загогулина вырулила к тому, что ты сам решаешь, какие фичи тебе на борту нужны, а какие нет. А вот в ПО так пока не делают I>Коврик, пепельница, кондиционер, объем двигателя ?
I>Автомобиль это длинный перечь обязательных фич которые ты менять не можешь.
В смысле? Есть много ОЧЕНЬ разных автомобилей, и в каждой модели ещё есть широкие варианты кастомизации, обчно...
I>Более того, если ты залезешь в базу аналогов по автомобильным запчастям то сильно удивишься.
Платформы -- это дело разрабов. Пользователям они до фени.
I>Аналоги могут отличаться по цене на порядок при абсолютно одинаковом качестве.
Да, и дело тут опять же только и исключительно в маркетинге. Тем, не менее, у автомобилей нет войны фич. Всё-таки люди покупают дорогие машины, потому, что комфорт и приятное вождение, а не потому, что там чат в магнитолу интегрирован.
I>И из всего этого ты практически ничего не можешь менять. Наприер никто тебе не продаст автос без выхлопной трубы или без задних колёс.
Дык оно не поедет. ОСНОВНАЯ ФУНКЦИОНАЛЬНОСТЬ не заведётся без задних колёс.
I>В софте все идет к тому же — обязательный перечень фич для определенных пакетов.
Примеры, можно? Вот у автомобилей, которые, кстати, сильно сложнее софта, всё просто. Есть основные эксплуатационные характеристики. Ну там, шумность в салоне, как оно рулится, динамика, материалы салона, место в салоне, место в багажнике, безопасность, экономичность, надёжность и ремнотопригодность и т. д. А есть "бантики". Ну, там, встроенный mp3 проигрыватель, например. Вот по бантикам автомобили почти не конкурируют, а по экономичности или тяговитости -- очень даже.
А в современном ПО, грубо говоря, всем пофиг скока оно будет бензина кушать, главное, чтобы можно было машину на ходу перекрашивать, и в бардачке было отделение для презервативов, а пассажирское сиденье позволяло заюзать максимум поз из "Кама Сутры"...
I>Наоборот. Они просто не умеют пользоваться компьютером, софтом. Для этого нужны годы опыта. А вот у тебя именно сформированая модель поведения.
Ну и, тем не менее, телефизором или авто они тоже не умеют пользоваться профессионально. Тем не мене, модель поведения другая.
И в одежде, напирмер, и в еде, тоже другая.
I>Везде. В среднем конечно же. Компьютеров примерно между 1 млрд до 2 млрд, а населения — 6 млрд. Я не говорю, что личный компьютер есть у каждого пятого — я говорю, что компьютер доступен каждому пятому-десятому.
IMHO, это зависит очень от того, кого ты уже считаешь достойным звания "каждый"
Но это тут офтоп...
E>>Кроме того, не понятно, что мешает сейчас сделать заведение вроде терм доступным каждому желающему? I>Где есть вода и другие ресурсы это уже есть. И обычно складывается так, что в этих же странах и компьютеров больше всего.
Чего? Где в Москве, например, я могу в аналог римских терм сходить?
I>Всемогутеры у тебя в голове. Компьютер удовлетворяет вполне конкретные потребности. Компьютер не будет делать за тебя детей например.
А вот занятия сексом многие ему уже перепоручают
E>>Это такая бизнес-модель эпохи НТТР. Если удаётся навязать в каком-то сегменте рынка такое поведение потребителям, то дальше хорошие вещи делать не надо, надо делать вещи, которые можно хорошо впарить. I>Опять полезло конспироложество
Я наверное как-то не так, как ты понимаю это понятие. По мне так нет никакого *ложества. Есть просто групповые интересы производителей. Если производителям удаётся навязать пользователям выгодную себе модель, то там случается мега-рост. Ну просто потому, что в нормальной ситуации сверхрприбыль извлечь трудно, так как учитываются и интересы пользователей и интересы производителей. А если производители, как группа, смогли навязать пользователям модель потребления выгодную производителям, то сверхприбыль получить намного легче
Я вот тебе простой пример приведу. А ты расскажешь мне в чём там секрет. Хорошо?
Вот есть всякие такие простые, первичные потребности. Скажем еда и общение, или более общая -- развлечение. Они вечны. И люди уже очень давно придумали очень много подходов к их удовлетворению. Про "хлеба и зрелищ" ты, наверняка слышал
Вот последние 10 лет в области общения/развлечения доминирует модель НТТР. То есть чем новее метод, тем лучше. А вот в области питания нифига. А вот 200 лет назад эти области не отличались, например. Так в чём же принципиальная разница между хлебом и зрелищами?
I>>>Я все чаще вижу, как люди машину используют как медиа-центр для дискотек на даче. E>>И это что, удобно? Или качество звука хорошее получается? I>Да, удобно. Что для тебя хорошее ?
А что именно удобно? То, что машину нельзя глушить? То, что она пердит наприроде? То, что нельзя, в случае дождика в дом пойти?
По идее бумбокс средней паршивости, в качестве "музыки для дачи" превосходит таки машину по всем статьям.
Качество звука я обсуждать тут не буду, просто потому, что это тут тоже очень далёкий офтоп.
I>Вариант А — дачный домик где полно аппаратуры вдали от города. I>Вариант Б — тыщить аппаратуру на себе каждый месяц I>Вариант В — обходиться бумбоксом.
I>Очевидно — хорошая автомобильная аккустика дешевле на несколько порядков варианта А, несравнимо легче варианта Б и намного качественнее варианта В.
Да ладно уж там. Хорошая автомобильная акустика хороша, когда ты её в салоне слушаешь, а не рядом с тачкой
Кроме того, для дискотеки, уровня "автомагнитола из открытой дверцы", не надо "полно аппаратуры", однако. Очень посредственный аппарат, но, зато, с колонками, которые можно разнести хотя бы метров на пять порвёт автомагнитолу
I>Ой, не гони. Микрософт вообще забила на браузер и не рассматривала его всерьез. Одно время даже официально заявили что развивать не будут.
Так это они когда уже всех сделали. А до этого очень даже продвигала. Или ты думаешь вся индустрия написания ентерпрайза под IE сама собой возникла?
I>Пользователю нет времени развиваться с твоими интерфейсами и потому удобно иметь один и тот же интерфейс ровно для трех потребностей — развлечение, общение, познание.
Да глупость всё это. Уши, рот и руки -- вот интерфейс
E>>Вот телевизор -- это удобно. И магнитофон с радио -- удобно.
I>И то и другое редкое говно. Телевизоры все больше становятся похожими на компьютеры,
Ой, правда, что ли? И как много настроек есть в твоём телеке? Хотя бы сотня наберётся? А на администрирование компа можно потратить бесконечные ресурсы...
I>Плейеры нынешние уже больше на компьютеры похожи.
Это зависит. Но у меня, например, есть DVD-игралка. Она ни разу не ноут. А у соседей есть несколько игровых приставок для детей. (Мы против комп. игр для детей). Так приставки тоже на компы ничем не похожи. Там диск вставляешь и играешь. И всё.
I>Это ты так думаешь. На мобильных гаджетах _уже_ начались войны браузеров.
Дык маркетинг-то не дремлет. Но, реально, из-за войн все проиграют.
I>А это отдельные фичи — нефункциональные.
У тебя есть какая-то идея, про функциональные и нефункциональные фичи.
Я не понимаю наверное о чём ты. Но я сильно подозреваю, что это очередная маркетинговая пропаганда.
В маркетинге есть два пути. Один -- понять, что надо твоему клиенту, и сделать это хорошо. Это старый путь. В некоторых направлениях он всё ещё основной. Например такого пути придерживаются производители хороших сигар. Или издатели хороших книг.
А есть новый, современный путь. Он более эффективный, с точки зрения быстрого извлечения прибыли. Это путь создания или актуализации потребностей.
Ну типа мы ищем не то, что надо нашему клиенту, а то, в нужде в чём мы можем убедить максимально много народу, а потом придумываем продукт, который под эту искусственно раздутую нужду, можно эффективно впарить. То есть мы, на самом деле, кидаем своего клиента дважды. Сначала мы делаем так, что он хочет не то, что ему надо, или не совсем то, что ему надо. А потом ещё и впариваем ему не то, что он хочет, или не совсем то
Но это работает. И не только на рынке ПО
I>>>бюджетирование, планирование, приватная инфа. E>>Соответственно браузер встаёт и идёт лесом I>Вылезь из конуры хоть на пять минут ?
В смысле? Ты зранишь приватную инфу в гугле? Или что?
I>Ну в твоем случае может у тебя секс с Касперским или общение, я ведь не в курсе
В моём случае, я комп использую утилитарно. Либо как источник аудио и видио сигнала, либо как устройство для обработки информации, либо для доступа в нет. Я, кстати, обычно для каждой из этих целей использую разные компы. Так что если бы их всемогутность была бы ограничена, я бы только радовался.
E>>И почему винамп отстой? Зачем прослушивалке музыки браузер? I>Для покупки, скачивания и тд. Вот нарыл ты музыки чуток и хочешь найти остальные треки или альбомы ?
Мне лично для покупки музыки винамп не нужен. Это наоборот, держателю прав нужно, чтобы мне было удобно из винампа найти и купить.
А всё как-то по старинке предпочитаю. Я вот и книжки предпочитаю выбирать в уютном книжном, с диванчиками и кофе, а не по банерам в браузере
I>Можно по идиотски — загрузить браузер, лазить в поисковике, регистрироваться на сайтах. I>А можно по простому — один раз кликнул и перешел к полной подборке. Второй раз кликнул — заполучил музло себе.
Ты знаешь, лучше чем у пиратов, которых всё время зарывают всякие суки, я нигде это не видел.
Но это всё, что ты расписываешь тут, это не имеет к музыке никакого отношения, на самом деле. Это имеет отношение к шопингу. Чего покупать не важно.
IMHO, шопинг, вообще занятие саморазрушительное, а интеренет шопинг -- саморазрушительное в квадрате. Это просто победа маркетологов над мозгом и смыслом. Без всяких заговоров...
Я про то и говорю, что вместо того, чтобы для развлечения прочитать хорошую книжку, ты идёшь в какой-то айшоп и там тратишь своё время и деньги на ненужную тебе хрень. Это всё та же самая игра в "купи, если успеешь", навязанная тебе профессиональными впаривателями фигни. На самом деле тебе это не надо, и вообще вредно.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
P>Ну, для написания "Hello, World!" 55 Мб не требуется. Можно обойтись notepad, edlin, экстремалам вообще хватит copy con: hello.c. А вот для выполнения — другое дело. C-версия "Hello, World!" весит на несколько порядков больше ассемблерной, а функциональность одна и та же у обеих версий. Какой вывод? C не нужен?
Откуда сведения про несколько порядков ? По крайней мере, в MS-DOS вполне можно было написать С-шную, сравнимую по размерам с асмовской. В Win API тоже. Может, раза в 1.5-2 будет длиннее, но уж никак не на порядок. Есть такие способы, есть
P>Мой комментарий, разумеется, к делу не относится. Как и твой, впрочем. Потому что рассуждений о "Hello, World!" на C явно недостаточно для обоснования потребления памяти интерпретатором js. Ты веришь, что много, я считаю, нужны тесты, замеры.
Нужен анализ, серьезный анализ исходного кода и запросов.
PD>>А при чем тут GIF ? Их, что js анимирует разве ? А разве 10 лет назад не было картинок под пол-Мб ? Ну не GIF, так JPG уж точно были.
P>Вместо GIF я вполне мог сказать JPG. Кстати, где я говорил, что js их анимирует?
Нигде не сказал, но сказал именно про анимированный. А от замены GIF на JPG ничего не изменится — js в обоих случаях ни при чем.
>10 лет назад картинки в полмегабайта в Интернете разве были?
Были. За 0.5 Мб точно не поручусь, но вот 200-300 Кб точно были. Грузились медленно, да.
>С теми ресурсами загрузки сайта с такими картинками часами можно было ждать.
Ну не надо так. 40-50 Кбайт/сек тогда у меня было. А это всего 4 секунды.
P>Я VS5 (точнее, еще DS5) пропустил. А от 6-ки избавиться не удалось. А ты, видимо, запускал их на P-133 с 32 Мб. Там разница, быть может, не так заметна. А на 16 — очень даже.
На 16 я VS6 не запускал, только VS5
PD>>Да живет, кто же спорит...
P>Дак ты, как я понимаю...
Да я же не говорю, что он помирает... Просто очень уж много кушает.
Здравствуйте, Erop, Вы писали:
E>Ой, да ерунда всё это. Павел прав в главном. E>Если уж жабаСкрипт такой урод, что для его реализации надо жрать память сотнями метров и проц мегафлопсами (хотя я в это не верю, на самом деле), то он бы просто издох, под своей моструозностью, если бы компы так нереально не окрутели бы. И вместо жабаСкрипта был бы какой-нибудь лягушкаСкрипт, не имеющий этих проблем...
Осталось найти где я с этим спорю.
Более того я тут пожалуй громче всех кричу что динамическая типизация вообще и жабаскрипт как ее пердставитель унылое говно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Павел, вот ты сейчас меня конкретно расстроил, кроме шуток. Знаешь почему? Потому что я достаточно много всего написал здесь, привел все необходимые ссылки, после которых бы вопроса о "Как бы иначе сам броузер что-то в реестре сохранял?" просто не возникло. У меня нет времени, даже безотносительно моего желания, еще раз расписывать все это и приводить все те же ссылки.
Сожалею, что я тебя расстроил. Я просто отметил особенность Windows, ничего больше.
Здравствуйте, Sinclair, Вы писали:
S>Дворкин неспроста включает дурочку всякий раз, как ему предлагают сравнить быстродействие тех "правильно написанных" программ 15-летней давности с современными программами. Иначе ему придётся признать, что софт сейчас пишут лучше, чем в старые времена. И что "разбрасывание байтами" не имеет столь массового характера, как тут постулируется.
Дурочку он не включает, он говорит абсолютно искренне. Его неумение сравнивать проявляется тотально, практически во всех топиках независимо от тематики. Кроме этого, во всех топиках он демонстрирует плохую память, невнимательное чтение. Можно конечно предположить, откуда это все взялось, но проблемы это не решит.
Бытует мнение однако, что все вот эти извращенья — не треба, если поднатужить и выдать код без дырок в шкуре. Скажу тебе еще, отаку. Ты, друг, ударившись в усмешки — забыл что кроме веб-смотрелок вокруг еще немало софта. Забыл ты браузера цели: рендерить всякое — во первых, а во вторых следить за кодом. Зачем следить — отлично знаешь.
А ты взгляни на ту
проблему, на мессенжер нерукотворный. Скриптов там нет, нет гипертекста, нет стилей, флеша, сильверхрени, но всеже, бооже, сотню метров ему скорми и улыбайся.
Ты говоришь про байтофобов, но говоришь не в том контексте. Контекст смени и станет ясно.
Приветствую, Privalov, вы писали:
P> Говорил ты о типе стопы, а имел в виду размер... Мой телепатический модуль, как я не раз говорил, очень далек от совершенства.
Я нигде не писал "размер". Впрочем ты несколько прав, надо было написать "хореем" или там "амфибрахием" ))
P> P.S. А в Gentoo какой размер?
35см.
Приветствую, Privalov, вы писали:
P> Да ничего. Зато повод потрындеть. Понедельник — день тяжелый.
А завтра еще один, да
P> P>> P.S. А в Gentoo какой размер? P> S>35см. P> А в пикселях это сколько?
Вам для "посмотреть" или для "распечатать"?
проблему, на мессенжер нерукотворный. S>нет гипертекста, нет стилей, флеша S>но всеже, бооже, сотню метров ему скорми и улыбайся.
я не уверен тут, но, братцы,
неплохо было б разобраться:
пусть это странно, но, быть может,
туда htmllayout вложен?
а для просмотра флеш-рекламы —
адоба мерзкая программа?
ps. прошу не считать наездом на htmllayout и flashplayer
Приветствую, Antikrot, вы писали:
A> я не уверен тут, но, братцы, A> неплохо было б разобраться: A> пусть это странно, но, быть может, A> туда htmllayout вложен? A> а для просмотра флеш-рекламы - A> адоба мерзкая программа?
Позор! От двух сторонних компонентов имея рамы дикий жор — прикрыться фразой "нуу, так памяти щас много" — и продолжать их пользовать... Угу, позор.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>И невдомек ему что хром, о безопасности радея, приватность холя и лелея, процессы пачкой создает для каждой вкладочки, плагина и рендера, чтоб тот терпила не схлопотал руткит в ядро.
М-м-м... А не запускать хром с правами, дающими возможность записи руткита в ядро слабо?
Здравствуйте, Sheridan, Вы писали:
S>Рифмоплёт S>Ямбом слабо?
Знаешь, вот если бы ты меня попросил транспонировать какую-нибудь мелодию в другую тональность, адаптировать ее под левую ритм-секцию, из веселой мелодии сделать грустную, ну или перерисовать картину в теплых тонах так, чтобы она осталась ей же, но в холодных — я бы это смог. Смог бы переписать код с PHP,Python,C#,Nemerle на любой из этих языков, наверное. А вот что такое ябм, хорей и прочие размеры — я понять без подглядывания в википедию не смогу, к своему стыду.
периодически входя в циклы по рифме и наоборот прерывая цепочку, начиная паттерн заново еще не закончив. Я хз, как это называется. Наверное, рифмоплетство и есть
Приветствую, Privalov, вы писали:
P> P>> Да ничего. Зато повод потрындеть. Понедельник — день тяжелый. P> S>А завтра еще один, да P> "Завтра" уже наступило.
Мне эта сволочь на поджелудочную похоже наступило. Завтра к доктору на анализы
P> P>> А в пикселях это сколько? P> S>Вам для "посмотреть" или для "распечатать"? P> Дак ты скажи сколько, а мы уж сами подумаем, куда это использовать.
Так оно-ж на порядки отличается
F>>Тут получается не безопасность, F>>А скотоложество и гей-парад!
M>А нет ли в ваших словах гомофобии?
M>
1) IMHO, скотоложество, а так же публичная массовая демонстрация сексуальности -- аморальны.
А вот в слове безопасность есть о чём подумать. Не знаю, как гомофобии, а вот козлизма там хватает
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>поскипано
Рифмой писать не умею, но вот я с хрома возвращаюсь обратно на фаерфокс именно из-за памяти Я в курсе почему разработчики приняли решение — "на каждую вкладку отдельный процесс", только я почти уверен, что когда хром наберет процентов 20 пользователей — будет фиолетового сколько у него там процессов. ИМХО большинство современной малвари играют больше на поле социальной инженерии (активно использую комп. безграмотность населения), чем на чисто техническом. Поэтому у меня скорее всего нет малвари (каспер не детектит, ничего не глючит), а у тети Клавы скорее всего есть. Я себя не отношу к ярым байтофилам, но тем не менее предпочитаю, чтобы end-user софт работал быстро и запускался быстро. Тот же хром мне использовать накладнее, чем фаерфокс и на машине с 3Гб оперативки к сожалению это иногда становится заметно. И перейти на 64 битную винду с 4+гигами или вообще на линукс я смогу как только сменю работу и специализацию (а ее я обязательно сменю, но позже). Насчет icq — миранда у меня кушает около 10 мегабайт — я считаю вполне приемлимо, квип мне тупо не нравится, родной клиент аськи вообще тупо страшный.
З.Ы. Посоветуйте скин для миранды, чтобы максимально вписывался в систему (win7), тобишь границы окна чтобы рисовались самой виндой(и тем цветом который я задал в аэро, а не каким придумал автор скина), но чтобы при этом сам список контактов не потерял функционал.
Здравствуйте, frogkiller, Вы писали:
F>Здравствуйте, Ikemefula, Вы писали:
I>>Очнись, ICQ это уже давно не мессенгер. И там есть и гипертекст, и стили и много чего еще.
F>Ну и нахрена это всё там, спрашивается
Для удобства, разве нет? Форматирование текста придумали давно, значит оно нужно, а значит полезно и удобно в Instant Messenger. А там делать форматированый текст наиболее естественно используя гипертекст. Стили просто добавляют комфорта — кому-то удобнее читать белым по черному, кому-то черным по белому, а дебилам голубым по розовому — все довольны.
Здравствуйте, frogkiller, Вы писали:
I>>Очнись, ICQ это уже давно не мессенгер. И там есть и гипертекст, и стили и много чего еще.
F>Ну и нахрена это всё там, спрашивается
Открой MSN, Skype и другие мессенгеры, посмотри, нет ли там общего. Возьми отгул, подумай, почему такой тренд.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну а что касается процесса под вкладку — извини, но ты тут просто демонстрируешь незнание базовых механизмов. Если запустить несколько процессов на базе одного и того же EXE (и DLL) , то все read-only данные (код, ресурсы, константы и т.д.) будут в ОП в одном экземпляре. А те даннные, что не будут в одном экземпляре — их что в одном процессе создавай в нескольких экземплярах, что в разных по одному — черт один. Вот тебе банальный пример. Программа , обрабатывающая картинки. Что 10 процессов запусти и каждому по картинке дай размером в 4 Мб, что один процесс с 10 картинками по 4 Мб — все равно 40 Мб получится.
То есть, проблема в том, что если ты не знаешь, на что программисты потратили память, ты счиатешь, что они дураки и потратили память зря потому что на твой взляд столько памяти не надо ?
Как думаешь, можно ли движок джаваскрипта ускорить за счет расхода бОльшего кол.ва памяти ?
Как думаешь, можно ли например DOM-модель ускорит за счет бОльшего расхода памяти ?
А, ну да, вот Ikemefula про DOM сказал, а я забыл. Там тоже имеют место оптимизации для ускорения времени доступа к его узлам из скриптов и тоже за счет затрат памяти, как это ни странно.
I>>Особенного здесь тот факт, что JS-кода сейчас на порядки больше чем 10 лет назад, и работает он много быстрее относительно одного и того же процессора.
PD>Что значит его больше ? На HTML-странице ? На порядки — это что, в 100 или 1000 раз ? Если 10 лет назад на странице было 5 Кб, то сейчас 500 или 5000 ? Ты вообще много файлов .html видел размером в 500 Кбайт ? PD>Поосторожнее с порядками!
при чем тут HTML страница? Открою страшную тайну: js- код может подгружаться из внешних файлов
inbox GMail'а загружает аяксом — внимание — 2.8 MB данных:
И загружается там не банальный JSON, а
На скриншоте — аякс запрос на 177.27 KB. Интерпретатор 10-летней давности умер бы, утащив за собой всю систему. Сейчас же у меня Safari даже не чешется, загружает и все.
Банальный RSDN подгружает 50 килобайтов скриптов.
google.com подгружает 188 килобайтов скриптов и 22 килобайта скрипттов аякс-запросом. первый же поиск по слову test увеличивает XHR до 361 килобайта.
M>>при чем тут HTML страница? Открою страшную тайну: js- код может подгружаться из внешних файлов PD>А я и не знал .
Тогда почему ты заострил внимание на «одной HTML-странице в 500 килобайт»?
M>>inbox GMail'а загружает аяксом — внимание — 2.8 MB данных: M>>http://files.rsdn.ru/9088/gmail%20ajax.png
PD>Да уж. Gmail это умеет
Улыбки улыбками, но там грузится не 50 килобайтов скриптов, а почти 3 мегабайта.
M>>На скриншоте — аякс запрос на 177.27 KB. Интерпретатор 10-летней давности умер бы, утащив за собой всю систему. Сейчас же у меня Safari даже не чешется, загружает и все.
PD>Я все же одно не пойму. ТурбоПаскаль 1987 года тихо и спокойно переварил бы файл на 177.27 Кб при 640 Кб ОП и не почесался бы. Подумаешь, 177 Кб. Ну ладно, на тебе в 10 раз больше. А в 100 зачем ? Что за чудная такая задача — интерпретатор с несложного, в общем-то, языка, к тому же большая часть кода в котором есть вызовы браузера (всякие document.open и window.on_не_знаю_что)
Javascript кажется несложным. Тут тебе и динамика и функции высшего порядка и замыкания и eval. Но его обработка ускоряется. Повторю, что интерпретатор 10-летней давности умер бы на 2 мегабайтах скриптов.
На порядки — это что, в 100 или 1000 раз ? Если 10 лет назад на странице было 5 Кб, то сейчас 500 или 5000 ?
10 лет тому назад 5 килобайт.
RSDN: 50 килобайт. Разница на порядок.
google.com: 188-361 килобайт. Разница на два порядка.
gmail.com: 2800 килобайт. Разница на три порядка.
Все в порядке с порядками. Более того, если 10 лет тому назад две-три страницы с большими/активными яваксриптами могли намертво и надолго завесить браузер, то сейчас не проблема иметь в одном окне gmail, в другом — твиттер, в третьем — facebook и т.д. и т.п., а в нцатом спокойно что-нибудь искать в google instant (да еще и с предосмотром страниц).
Здравствуйте, v2kochetov, Вы писали:
V>Здравствуйте, frogkiller, Вы писали:
F>>Здравствуйте, Ikemefula, Вы писали:
I>>>Очнись, ICQ это уже давно не мессенгер. И там есть и гипертекст, и стили и много чего еще.
F>>Ну и нахрена это всё там, спрашивается V>Для удобства, разве нет? Форматирование текста придумали давно, значит оно нужно, а значит полезно и удобно в Instant Messenger. А там делать форматированый текст наиболее естественно используя гипертекст. Стили просто добавляют комфорта — кому-то удобнее читать белым по черному, кому-то черным по белому, а дебилам голубым по розовому — все довольны.
ни разу не отправлял и не принимал форматированных мессаг.
ты точно уверен, что это — не маркетинговая плюшка?
Здравствуйте, Mamut, Вы писали:
M> Javascript кажется несложным. Тут тебе и динамика и функции высшего порядка и замыкания и eval. Но его обработка ускоряется. Повторю, что интерпретатор 10-летней давности умер бы на 2 мегабайтах скриптов.
Что ты имеешь ввиду, когда говоришь "умер"? В момент трансляции или в момент исполнения? Я тебе могу показать семилетней давности интерпретатор, правда не JavaScript, который 4Мб скрипт (синтетический правда) транслирует за 2 сек, а интерпретирует (исполняет т.е.) за 60 мсек (без джитов и прочего).
M>> Javascript кажется несложным. Тут тебе и динамика и функции высшего порядка и замыкания и eval. Но его обработка ускоряется. Повторю, что интерпретатор 10-летней давности умер бы на 2 мегабайтах скриптов.
H>Что ты имеешь ввиду, когда говоришь "умер"? В момент трансляции или в момент исполнения? Я тебе могу показать семилетней давности интерпретатор, правда не JavaScript, который 4Мб скрипт (синтетический правда) транслирует за 2 сек, а интерпретирует (исполняет т.е.) за 60 мсек (без джитов и прочего).
Еще скажи, что этот интерпретатор использовался в IE5.5/IE6, например (как раз семь лет тому назад).
Здравствуйте, Mamut, Вы писали:
M> H>Что ты имеешь ввиду, когда говоришь "умер"? В момент трансляции или в момент исполнения? Я тебе могу показать семилетней давности интерпретатор, правда не JavaScript, который 4Мб скрипт (синтетический правда) транслирует за 2 сек, а интерпретирует (исполняет т.е.) за 60 мсек (без джитов и прочего).
M> Еще скажи, что этот интерпретатор использовался в IE5.5/IE6, например (как раз семь лет тому назад).
Причем тут IE вообще? Речь о интерпретаторах и их качествах Ты говоришь, что с течением времени они стали круче, и оправдываешь этим возросший расход памяти (а что еще ты хотел сказать говоря об умирающем на 2Mb скрипте интерпретаторе). Я тебе говорю, что и семь лет назад можно было не умирать на больших скриптах, если писать интерпретатор нормально.
Здравствуйте, Mamut, Вы писали:
M>>>при чем тут HTML страница? Открою страшную тайну: js- код может подгружаться из внешних файлов PD>>А я и не знал .
M>Тогда почему ты заострил внимание на «одной HTML-странице в 500 килобайт»?
Потому что, как правило, страницы HTML вместе с внедренным в него или иначе вставленным JS имеют размер, намного меньше. О том, что размер вырос на порядки, говорить все же не приходится. Вырос, не спорю, в несколько раз, но не на порядки.
M>>>inbox GMail'а загружает аяксом — внимание — 2.8 MB данных: M>>>http://files.rsdn.ru/9088/gmail%20ajax.png
PD>>Да уж. Gmail это умеет
M>Да и не только GMail.
Между прочим. Компиляция обычных статических языков, как я уже не раз тут замечал, вполне может идти на нескольких Мб. Доказательство простое — она шла, и с весьма приличной скоростью при памяти в Мбайты и частоте в десятки-сотню MHz и без многоядерности. Это сейчас просто начали памятью бросаться. А Язык С++ от времен BC 5.0 до нашего времени не менялся практически. А тут, видите ли, чтобы откомпилировать 2.8 Мб сорсов, нужна сотня Мб. При том, что язык довольно простой. Что же это такое, кроме как халтурное программирование ?
M>>>И загружается там не банальный JSON, а
M>>>http://files.rsdn.ru/9088/gmail%20ajax%202.png PD>>
M>Улыбки улыбками, но там грузится не 50 килобайтов скриптов, а почти 3 мегабайта.
Да пусть и 3! Вот возьми BC 3.1 в MS-DOS , процессор Пентиум-100, ОП чтобы было 4 Мб, а лучше 8 и откомпилируй эти 3 Мб. Со свистом. При том, что там еще и .h файлы включаются и компилируются, если отключены predcompiled headers. Ты будешь утверждать, что JS сложнее C++ ?
M>>>На скриншоте — аякс запрос на 177.27 KB. Интерпретатор 10-летней давности умер бы, утащив за собой всю систему. Сейчас же у меня Safari даже не чешется, загружает и все.
PD>>Я все же одно не пойму. ТурбоПаскаль 1987 года тихо и спокойно переварил бы файл на 177.27 Кб при 640 Кб ОП и не почесался бы. Подумаешь, 177 Кб. Ну ладно, на тебе в 10 раз больше. А в 100 зачем ? Что за чудная такая задача — интерпретатор с несложного, в общем-то, языка, к тому же большая часть кода в котором есть вызовы браузера (всякие document.open и window.on_не_знаю_что)
M>Javascript кажется несложным. Тут тебе и динамика и функции высшего порядка и замыкания и eval.
Ай-яй-яй. На замыкания с eval нужно 100 Мб. А динамика — так она вроде как в любом интерпретаторе потенциально возможна, на то он и интерпретатор. К примеру, в той же FoxPro на 1 Мб в DOS-времена были переменные, тип которых изменялся во время выполнения. Что тут такого-то ?
>Но его обработка ускоряется. Повторю, что интерпретатор 10-летней давности умер бы на 2 мегабайтах скриптов.
Значит, так хорошо умели (умеют) писать эти интерпретаторы
M>>>Так что с порядками все в порядке.
PD>>Не совсем
M>Угу. Порядок — это степень 10.
Именно. На порядок — в 10 раз. На 3 порядка — в 1000. Если было 50 Кб — давай сюда HTML с JS на 50 Мб, вот это и будет 3 порядка. Только имей в виду, что у меня канал номинально 10 Мбит, так что загрузится твой JS хорошо если через минуту
M>Возьмем сначала: M>
M> На порядки — это что, в 100 или 1000 раз ? Если 10 лет назад на странице было 5 Кб, то сейчас 500 или 5000 ?
M>10 лет тому назад 5 килобайт.
А сейчас так-таки сплошь и рядом 5 Мб ? Между прочим, на его загрузку нужно 5 сек у меня, а если скорость 1-2 Мбит ?
M>RSDN: 50 килобайт. Разница на порядок. M>google.com: 188-361 килобайт. Разница на два порядка.
На 2 порядка будет все же 500, а не 188.
M>gmail.com: 2800 килобайт. Разница на три порядка.
И здесь все же надо 5000. Ты с порядками поаккуратнее
M>
M>Все в порядке с порядками. Более того, если 10 лет тому назад две-три страницы с большими/активными яваксриптами могли намертво и надолго завесить браузер, то сейчас не проблема иметь в одном окне gmail, в другом — твиттер, в третьем — facebook и т.д. и т.п., а в нцатом спокойно что-нибудь искать в google instant (да еще и с предосмотром страниц).
Счастье-то какое! Помню, в 2000-м был у меня Пентиум-3, памяти 256 Мб, тактовая 667 MHz. И работал в ней Netscape Navigator 4.7. В одном окне была почта, в другом web, а еще был composer и не помню что еще. И ничего они не вешали. Вот поиска в гугле не было, потому что не было гугла. Но поиск на altavista (я тогда ей пользовался) или rambler — без проблем.
А всего-то 256 Мб... Получается, что для того, чтобы от 5 Кб JS перейти к 500 Кб, надо объем ОП увеличить в 16 раз, тактовую в 5, ядер в 4 ! Да это просто чудовище какое-то, ваш JS .
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>А если генерировать код, что тогда ?
PD>Тогда, извини, это не код. Это данные, которые обрабатываются специальным образом. Текст на JS — это не код, а данные для интерпретатора (или как он там) JS.
То есть памяти это не жрёт ?
I>>Неправильно думаешь. Тебя должен интересовать один вопрос — какое направление оптимизации выбрали для написания флешгета.
PD>Правильно думаю . Нечего там во flashget кешировать — 2 раза я один и тот же файл не качаю, а если и качаю, то все равно нельзя кешировать и незачем.
Ты не ответил на главный вопрос — "какое направление оптимизации выбрали для написания флешгета".
Ты даже список фич не глянул, но решил что речь будто идет про кеширование
I>>Вот когда ты это установишь наверняка и ознакомишься с кодом, тогда можно говорить, что де флешкгет расходует память зазря.
PD>А он ее не расходует.
Ага, прям 0 байт занимает в памяти.
I>>Будет летать, а программы на нем будут ползать по сравнению с современными JS-машинами на "нынешних Athlon/Dual/i7"
PD>Каких еще программ ? Если имеем дело с чистым интерпретатором, то его работа и есть исполнение программы
Вот те программы, про которые ты говори " то его работа и есть исполнение программы " и будут тормозить по сравнению современными JS-машинами.
PD>Да какой к черту спам! Я тебе ясно объяснил свою мысль — о том, что скорость процессора резко возросла, а поэтому старый интерпретатор должен работать в N раз быстрее, чем в 90-е годы. Вот и все.
Ты хорошо понимаешь, как сравниваются вещи ?
Но компе ставится два браузера — старый и новый. Всё. А твой текст про процессор это спам.
Новый браузер рвёт старый в пух и прах по перформансу того же JS.
Еще раз — процессор в обоих случаях один и тот же.
I>>Особенного здесь тот факт, что JS-кода сейчас на порядки больше чем 10 лет назад, и работает он много быстрее относительно одного и того же процессора.
PD>Что значит его больше ? На HTML-странице ?
Имеется ввиду тот который необходим для показа страницы на клиентской стороне
>На порядки — это что, в 100 или 1000 раз ? Если 10 лет назад на странице было 5 Кб, то сейчас 500 или 5000 ? Ты вообще много файлов .html видел размером в 500 Кбайт ?
Очнись и пой. 10 лет назад JS считай и не было вовсе, 5 кб — это слишком большая цифра. Сумасшедший рост начался где то с 2005го.
Качни пару страниц на серьезных сайтах, где динамика всякая, ajax, jquery, и посмотри что тебе скачается на локаль.
Щас только JS может быть на десятки и даже сотни килобайт. Добавь сюда css и окажется, что html уже давно не самая большая часть страницы.
I>>Это и есть крайне медленно. Во первых, язык был убог. Во вторых, оптимизаций считай никаких не делалось.
PD>Язык Turbo Pascal с классами (object) был более убог, чем JS ? Не смеши!
Конечно убог. Сравить с турбопаскалем сложно, но можешь посмотреть сравнение с дельфи
I>>Ага, щаз, перечислить тебе все виды оптимизации которыее вводились за несколько лет ?
PD>Имеешь полное право не перечислять. Но и я имею полное право при этом твоим утверждениям не поверить.
Проще и быстрее написать книгу и издать.
I>>Ты в своем уме ? Каждая из этих оптимизаций прибавляет по n-байт в рассчете на объект или коллекцию.
I>>По одной — ничего, все вместе — может и в 1000 раз.
PD>И сколько нужно оптимизаций, чтобы увеличивая на n, получить увеличение в 1000 раз ?
Очевидно — в среднем 1000/n, и 1000 это частный случай
>Пусть изначально было 100 байт.
Откуда ты взял 100 байт ?
>На первой оптимизации добавили, допустим, еще 100. Итого в 2 раза. На второй еще 100. Теперь в 3 раза.
Бред какой то. Вот, на вскидку
Допустим у тега есть n атрибутов и вложеные теги.
1 на lpvtbl
n филдов
массив вложеных тегов
это минимально необходимое количество.
теперь
добавить филд на парента
добавить филд на рут
для быстрого доступа по имени атрибута тебе надо ввести таблицу атрибутов
для быстрого добавления тега надо вместо массива сделать коллекцию
для быстрого поиска тега по ID надо усилить коллекцию
для быстрого поиска тега по типу надо усилить коллекцию
для быстрого поиска тега по классу надо усилить коллекцию
для быстрого вызова метода по имени нужна таблица методов
для быстрого добавления метода в рантайме надо таблицу усилить
строки должны быть максимально быстрые — strlen не катит, опять расход памяти
наиболее часто вызываемые функции кешируем — снова расход памяти — таблица на каждую функцию !
А теперь фокус — для ускорения доступа к любому филду, элементу и тд вводим выравнивание, например по кешу или еще как нибудь
Теперь оказывается, что фрагментация памяти слишком большая — выделяем память большими кусками что бы хватило на основные сценарии
Теперь посчитай, как увеличится расход памяти.
При этом до html мы еще и не добрались.
Такая фича как CSS тоже ест память.
Рендеринг как ты в курсе тоже жрет память и это еще мягко сказано.
I>>>>Например понадобится доступ к элементам O(1) при том что коллекции у каждого элемента всегда должны быть отсортированые. Или окажется что порядок следования в коллекции не должен меняться.
PD>>>Доступ за O(1) при том, что при каждом добавлении тебе придется либо пересортировывать либо сдвигать ?
I>>Имеется ввиду доступ на чтение. Хештаблица — медленное решение. Предложи лучше.
PD>Совокупность массивов указателей на общие данные.
А это память не потребляет, правильно ?
I>>Ты кажду будешь мусолить ?
PD>Нет, не буду. Но имея десятки оптмизаций и прибавляя на каждой n байт, очень сложно увеличить расход памяти в 1000 раз
Это сложно понять но это так. Техника вроде memoize например потребляет просто страшное количество памяти.
PD>Слушай, ты вообще серьезный человек или нет ? Ну что ты ерунду-то говоришь! Что я не знаю ? Или ты впрямь решил, что я никогла БД не видел ?
Когда речь о БД, ты вроде понимаешь из за чего расходуется пространство.
А когда о БД в памяти, ты начинаешь рассказывать что все программисты дураки ибо плохо пишут.
PD>Оптимизацию под быстродействие совсем не всегда необходимо сочетать с дополнительным расходом памяти. Можно изменить алгоритм, лучшим способом разместить данные и т.д.
Алгоритмы это долгосрочная стратегия и иногда даже проф. математики не могут предложить хорошего решения.
А заказчик просит хоть 10% но прямо сейчас.
I>>Да, примерно так. И меня абсолютно не удивляет, почему Хром жрет память. PD>Дв и меня не удивляет. Только вот причины этого неудивления у нас с тобой различны
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Mamut, Вы писали:
M>> H>Что ты имеешь ввиду, когда говоришь "умер"? В момент трансляции или в момент исполнения? Я тебе могу показать семилетней давности интерпретатор, правда не JavaScript, который 4Мб скрипт (синтетический правда) транслирует за 2 сек, а интерпретирует (исполняет т.е.) за 60 мсек (без джитов и прочего).
M>> Еще скажи, что этот интерпретатор использовался в IE5.5/IE6, например (как раз семь лет тому назад).
H>Причем тут IE вообще? Речь о интерпретаторах и их качествах Ты говоришь, что с течением времени они стали круче, и оправдываешь этим возросший расход памяти (а что еще ты хотел сказать говоря об умирающем на 2Mb скрипте интерпретаторе). Я тебе говорю, что и семь лет назад можно было не умирать на больших скриптах, если писать интерпретатор нормально.
Охохонюшки. В контексте данной подветки:
— я не оправдываю возрост памяти
— интерпретаторы в браузерах улучшились
— обхемы загружаемых в браузеры данных возрасли на порядки
Здравствуйте, Mamut, Вы писали:
M> H>Причем тут IE вообще? Речь о интерпретаторах и их качествах Ты говоришь, что с течением времени они стали круче, и оправдываешь этим возросший расход памяти (а что еще ты хотел сказать говоря об умирающем на 2Mb скрипте интерпретаторе). Я тебе говорю, что и семь лет назад можно было не умирать на больших скриптах, если писать интерпретатор нормально.
M> Охохонюшки. В контексте данной подветки: M> — я не оправдываю возрост памяти M> — интерпретаторы в браузерах улучшились M> — обхемы загружаемых в браузеры данных возрасли на порядки
Как раз в контексте треда идет спор об оправданности высокого потребления Твои слова о размерах скриптов прозвучали, как аргумент в защиту позиции оправдывающей высокое потребление. Первый раз ты вообще сказал:
На скриншоте — аякс запрос на 177.27 KB. Интерпретатор 10-летней давности умер бы, утащив за собой всю систему. Сейчас же у меня Safari даже не чешется, загружает и все.
Из этого, как бы, должно следовать, что коли сегодняшние интерпретаторы не умирают от 178Kb скриптов утащив при этом за собою всю систему (твоя гипербола вышла на орбиту ) то это должно их оправдывать. Вот у меня тут не срастается...
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>Да, я в курсе, все кроме тебя пишут неправильно.
Ты тут много риторических вопросов привел, можно мне теперь только один задать ? Ты и впрямь уверен, что такими аргументами можно добавить хоть какую-то убедительность твоим высказываниям ?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Pavel Dvorkin, Вы писали:
KV>Павел, ты не поверишь. Я написал за пол-дня большую часть развернутого ответа тебе, а потом случайно закрыл янус Поэтому ниже его сокращенная часть, ибо задолбался и времени нет. По ходу разберемся
Кстати, а сколько янус жрет?
Здравствуйте, denisko, Вы писали:
D>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Здравствуйте, Pavel Dvorkin, Вы писали:
KV>>Павел, ты не поверишь. Я написал за пол-дня большую часть развернутого ответа тебе, а потом случайно закрыл янус Поэтому ниже его сокращенная часть, ибо задолбался и времени нет. По ходу разберемся D>Кстати, а сколько янус жрет?
Здравствуйте, 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. Давай больше дискутировать не будем. Ты не будешь терять время, я — тоже.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Конечно непродуктивная — у меня примерно 10 лет работы с вещами вроде DOM, а у тебя всего лишь "БД R/O в памяти".
PD>Я думаю, не зная того, что я делал и не говоря толком ничего о том, что ты делаешь сам, едва ли стоит меряться.
M>>Пустой фотошоп спокойно отжирает 130 метров памяти. Компилятор С++ — гуано, однозначно.
PD>Слушай, не смеши. При чем тут компилятор ? У меня сейчас фотошоп не установлен, посмотреть не могу. Запусти на него dumpbin, а лучше Process Explorer, и посмотри, что там в этих 130 Мб. Там скорее всего несколько Мб кода (не считая, конечно, кода системных DLL), а остальное — либо массивы данных, либо ресурсы. Вот они там зачем в таком объеме для пустого фотошопа — это действительно вопрос, но уж никак не к С++, а к авторам фотошопа. Я тоже могу сделать приложение мастером VC++, добавить массив на 100 Мб и будет тебе 100 Мб памяти.
Ну ты же привязался непременно к компиляции яваскрипта
M>>Да-да. Прибегая к любимым здесь автомобильным ассоциациям: Разницы между фордом T и subaru outback'ом ты тоже не видишь. Ту же четыре колеса и руль, ага.
PD>А все же можно без аналогий объяснить, что же такое особо ценноеза последние 10 лет появилось в почте ?
Можно, например, вспомнить, интерфейс хотмэйла в 2000-м, потом открыть GMail и посмотреть на тот интерфейс, что он предлагает. Действительно совсем-совсем ничего не изменилось? ни встроенного чата, ни отсутствия перезагрузок между переходами страниц, ни схлопывания частей писем, ни драг'н'дропа, ни прозрачного выставления флагов и меток, ни прозрачного, без перезагрузки страницы, обновления инбокса по мере посупления новых сообщений — вообще ничего. То есть то, что в браузере у тебя почти полноценный аналог того же thunderbird'f — это вообще никаких изменений по сравнению с хотмейлом образца 2000-го года, ага.
>>>>Еще навреное уже тогда Facebook существовал в нынешней инкарнации — с динамикой, мгновенными нотификациями и т.п. Ага-ага, верю.
PD>>>Вот тут не знаю, ибо им не пользуюсь.
M>>не существовал, ибо существовать не мог. Любой браузер загнулся бы. PD>Хм. Я вообще с ним не знаком. Дай ссылку. Гд-то у меня валялся NN 4.7. Попробую под виртуалкой.
Да хотя бы GMail открой. Facebook.com — ссылка для facebook'а.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Хочу я в этом сообщении, о байтофобах рассказать.
Pzz>Это психотворение?
Здравствуйте, kochetkov.vladimir, Вы писали:
PD>>Коротко — рабочий набор не является вообще характеристикой процесса, а является характеристикой поведения менеджера памяти Windows. При одном и том же размере выделенной памяти (commited) рабочий набор может отличаться в разы.
KV>А нам интересно, что происходило в ВАП процесса или как его прожорливость по памяти отразилась на других процессах?
Отчасти да, так как если он прожорлив — другим мало останется. В этом-то и суть проблемы.
PD>>Если коротко.
PD>>Private Bytes — управляю я. Без моего ведома ни один байт не освободить.
KV>Это столбец "Private" раздела "Virtual Memory" на скриншотах.
Да.
PD>>Shared Mem — управляю я, но отчасти и система (просто потому, что шарит хотя бы код системных DLL) PD>>Working Set — я совсем не управляю, могу только рекомендовать, а Windows на мои рекомендации может наплевать. PD>>Поэтому первые 2 — характеристика моего процесса, а третье — совсем нет.
KV>Эти характеристики не дают ровным счетом ничего, если рассматривать их в разрезе влияния на доступность ФАП для других процессов.
Ну как же так! Вот сделаю я программу , в которой Private Bytes == 2 Gb, и где они храниться будут ? Либо в ОП, либо в свопе. Если в ОП , значит, другим меньше останется. Если в свопе — тормоза с обменом. Чудес не бывает.
PD>>Все. Дальше можно не читать. При этих базовых посылках я заранее знаю, что они могут сделать. Они могут как угодно разделить те или иные действия или ответственность между своими процессами, создать механизмы взаимодействия, определить, кто чем занимается и т.д. На здоровье.
KV>Как это "на здоровье"?! А где же "вау! да здравствует самый безопасный браузер в мире"?!
А откуда это следует ? Модель, в которой ответственность разнесена по процессам отнюдь не безопаснее, чем модель , в которой все в одном процессе. Существует много способов сделать куски кода или данных в пределах одного процесса отнюдь не равнодоступными. Иными словами, и в пределах одного процесса можно сделать так, чтобы некий код мог выполняться только этим модулем или этим потоком, то же верно для данных. А можно и наоборот — чтобы 2 процесса свободно могли иметь общие равнодоступные данные.
Так что само по себе использование одной из этих моделей ровно ни о чем не говорит, вопрос — как это написано. Можно написать хорошо один процесс и плохо — много.
PD>>Правда, так и остается непонятным, почему тут нужны десятки и сотни Мб. Модель безопасности Windows осталсь практически неизменной от 3.1 до XP включительно. То есть она работала так же в 1994, как сейчас, при 16 Мб памяти. Едва ли она намного проще чем то, что они сделали в Хроме. Почему же там хватало 16 Мб под всю ОС, а тут нужно 100 под один броузер ?
KV>Ты почему-то считаешь, что речь идет только о накладных расходах, связанных непосредственно с созданием нескольких процессов вместо одного, но это не так. Вот представь, что в одном процессе (ОС) рендерер подгрузил jquery. Выполняя код, он построил развесистые и весьма тяжелые структуры, необходимые V8 для быстрого исполнения скрипта. В этот момент, ты открыл в другой вкладке еще один сайт, другой, но тоже использующий jquery. Файрфокс или опера имеют возможность использовать уже построенные для этой библиотеке бэкендовые структуры, чтобы сэкономить на памяти и времени, необходимом для их построения. Хром — не может. Поэтому он снова загрузит исходник jquery (возьмет из файлового кэша, скорее всего) и заново построит все структуры в АП процесса нового сайта.
Ну я бы не слишком гордился таким решением. Вы вот сделайте так, чтобы при использовании общих данных быть уверенным, что при этом в обоих процесах будет надежно — вот тогда я вам свой респект и уважение выскажу. А в таком виде — не очень.
И все равно остается неясным, зачем же тут 100 Мб. Что это за такие развесистые структуры, которые имеют размер в 100 Мб.
Задам вопрос жестче. Представь себе, что увеличение объема ОП прекратилось бы, когда оно было равно , скажем, 256 Мб. Дальше не удалось. И многоядерности нет, одно ядро. В общем, в 2002 году вышли на плато.
А теперь вопрос
Утверждаешь ли ты, что в этом случае броузер по модели Хрома не мог бы быть вообще создан ?
KV>Механизм целостности — это и есть механизм безопасности Windows (одна из его частей), а не пришлепка. И я бы не назвал реализацию практически мандатного доступа "небольшой пришлепкой"
Я имел в виду, что он был добавлен после XP — пришлепка к предыдущему.
PD>>И что ? Для этого нужно 100 Мб ? LPC/RPC/OLE/COM уже отменили ?
KV>Под линуксом?
А что, под Линуксом нет ничего похожего ? Я так думаю, что есть.
PD>>А запросы из Word в Excel тебя не удивляют ? А вставка таблицы из Excel в окно моего приложения не удивляет ?
KV>Если реализуешь это под линуксом, но с вордом и экселем — удивит.
Владимир, не надо. Ты играешь на моем незнании Линукса. Там свои механизмы для этого есть, не могут не быть, потому что иначе это не ОС будет, а примитив какой-то.
KV>Речь не может идти только о винде, т.к. хром кроссплатформенен.
И что ?
PD>>Что немудрено, если принять во внимание качество исполнения их.
KV>Что не так с качеством их исполнения? Очень качественно исполняются, на мой, дилетантский, взгляд
Когда платят таким расходом памяти, это качественным называться не может.
PD>>Скорее от телеги, на которую поставили паровой двигатель, потом сделали несколько топок, посадили по кочегару у каждой и теперь вполне довольны, видя, как эта колымага несется, распугивая лошадей
KV>Я рад, что ты понял основной принцип оптимизации исполнения динамически-типизированного кода
>Что, впрочем нисколько не умаляет достоинств динамической типизации (интересно, закастится сейчас сюда Wolfhound или нет?).
PD>>>Слушай, не смеши. При чем тут компилятор ? У меня сейчас фотошоп не установлен, посмотреть не могу. Запусти на него dumpbin, а лучше Process Explorer, и посмотри, что там в этих 130 Мб. Там скорее всего несколько Мб кода (не считая, конечно, кода системных DLL), а остальное — либо массивы данных, либо ресурсы. Вот они там зачем в таком объеме для пустого фотошопа — это действительно вопрос, но уж никак не к С++, а к авторам фотошопа. Я тоже могу сделать приложение мастером VC++, добавить массив на 100 Мб и будет тебе 100 Мб памяти.
M>>Ну ты же привязался непременно к компиляции яваскрипта
PD>Не к компиляции, а к работе. Если в JS объявлен массив на 100 Мб — я первый потребую под него место. Но пока его нет, нечего память транжирить.
Ну пока его нет, его и не транжирят. Вернее, транжирят столько, соклько нужно для JIT'а и runtime-оптимизаций.
PD>>>А все же можно без аналогий объяснить, что же такое особо ценноеза последние 10 лет появилось в почте ?
M>>Можно, например, вспомнить, интерфейс хотмэйла в 2000-м, потом открыть GMail и посмотреть на тот интерфейс, что он предлагает. Действительно совсем-совсем ничего не изменилось? ни встроенного чата, ни отсутствия перезагрузок между переходами страниц, ни схлопывания частей писем, ни драг'н'дропа, ни прозрачного выставления флагов и меток, ни прозрачного, без перезагрузки страницы, обновления инбокса по мере посупления новых сообщений — вообще ничего. То есть то, что в браузере у тебя почти полноценный аналог того же thunderbird'f — это вообще никаких изменений по сравнению с хотмейлом образца 2000-го года, ага.
PD>Я вообще-то имел в виду именно десктопную почту, а в этом плане нынешний thunderbird мало чем отличается от Netscape Mail 1998 года.
Там был threading, поиск и т.п.? Правда, Thunderbird плохой показатель в этом плане.
M>>Да хотя бы GMail открой. Facebook.com — ссылка для facebook'а.
PD>Попробовал GMail под NN 4.7. Не работает, но со странной дмагностикой — у меня, мол, медленный Интернет. Запускал под XP Mode, но дело не в ней, так как под IE вполне работает.
Видимо, он диагностирует не только inet, но и работу скрипта тоже.
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>Ну ты же привязался непременно к компиляции яваскрипта
PD>Не к компиляции, а к работе. Если в JS объявлен массив на 100 Мб — я первый потребую под него место. Но пока его нет, нечего память транжирить.
То есть не имея на то оснований, оптимизировать расход памяти в ущерб перформансу ?
Здравствуйте, Pavel Dvorkin, Вы писали:
KV>>Что не так с качеством их исполнения? Очень качественно исполняются, на мой, дилетантский, взгляд
PD>Когда платят таким расходом памяти, это качественным называться не может.
Здравствуйте, Mamut, Вы писали:
PD>>Не к компиляции, а к работе. Если в JS объявлен массив на 100 Мб — я первый потребую под него место. Но пока его нет, нечего память транжирить.
M>Ну пока его нет, его и не транжирят. Вернее, транжирят столько, соклько нужно для JIT'а и runtime-оптимизаций.
А сколько нужно под код на js размером в 50-100 Кб при том, что там нет больших массивов ? Я так полагаю, что 1 Мб должно хватить. Для ТурбоПаскаля хватало же.
PD>>Я вообще-то имел в виду именно десктопную почту, а в этом плане нынешний thunderbird мало чем отличается от Netscape Mail 1998 года.
M>Там был threading, поиск и т.п.? Правда, Thunderbird плохой показатель в этом плане.
Threading был, поиск был, news были, все было. Да и вообще Thunderbird лишь приятнее в интерфейсе, не более. Ничего там существенно нового нет.
PD>>Попробовал GMail под NN 4.7. Не работает, но со странной дмагностикой — у меня, мол, медленный Интернет. Запускал под XP Mode, но дело не в ней, так как под IE вполне работает.
M>Видимо, он диагностирует не только inet, но и работу скрипта тоже.
PD>>>Не к компиляции, а к работе. Если в JS объявлен массив на 100 Мб — я первый потребую под него место. Но пока его нет, нечего память транжирить.
M>>Ну пока его нет, его и не транжирят. Вернее, транжирят столько, соклько нужно для JIT'а и runtime-оптимизаций.
PD>А сколько нужно под код на js размером в 50-100 Кб при том, что там нет больших массивов ? Я так полагаю, что 1 Мб должно хватить. Для ТурбоПаскаля хватало же.
Честно, не знаю, сколько
PD>>>Я вообще-то имел в виду именно десктопную почту, а в этом плане нынешний thunderbird мало чем отличается от Netscape Mail 1998 года.
M>>Там был threading, поиск и т.п.? Правда, Thunderbird плохой показатель в этом плане.
PD>Threading был, поиск был, news были, все было. Да и вообще Thunderbird лишь приятнее в интерфейсе, не более. Ничего там существенно нового нет.
Ну, как я и сказал, Thunderbird вообще неудачный пример
Вот смотрю я на Mail.app под макосью... Почти пять игов писем, синхронизированных по IMAP, но хранящихся локально. С поиском, threading'ом, фильтрами, смарт-боксами, rss-читалкой и т.п. 84 мегабайта в памяти
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А сколько нужно под код на js размером в 50-100 Кб при том, что там нет больших массивов ? Я так полагаю, что 1 Мб должно хватить. Для ТурбоПаскаля хватало же.
Надо начинать не с килобайт и строчек, а с размера одного объекта для JS или DOM.
Этот ответ был уже и ты сказал "разобраться невозможно".
PD>>Слушай, ты же ясно сказал, что тебе жаль времени, потраченного на дискуссию со мной. Зачем же ты хочешь еще раз его потратить ? Я — не хочу.
I>Ты распространяешь вредную идеологию.
Ты мне КПСС начинаешь напоминать. Она тоже с вредной идеологией боролась, защищала нас от от нее
Если коротко — нет вредной идеологии. Есть мнения, близкие к истине, а есть — далекие от нее. Я высказываю свое мнение, а насколько оно близко или далеко от истины — пусть другие оценят.
Здравствуйте, Ikemefula, Вы писали:
PD>>А сколько нужно под код на js размером в 50-100 Кб при том, что там нет больших массивов ? Я так полагаю, что 1 Мб должно хватить. Для ТурбоПаскаля хватало же.
I>Надо начинать не с килобайт и строчек, а с размера одного объекта для JS или DOM.
Ну вот и давай сюда этот размер. Ты же с DOM 10 лет работаешь. Давай сюда какой-нибудь пример.
Вот тебе мой пример.
Дано : набор целых чисел в количестве 10000 штук.
Объем этих данных — 40 Кб.
Решено построить из них BST
В каждом узле 4 байта под число + 8 байт под два указателя. Итого 12 байт. Возможно, при выравнивании будет 16.
16*10000 == 160000 = 160 Кб.
Так что извини, но больше 200 Кб не дам — при этой структуре.
PD>>>>>Не к компиляции, а к работе. Если в JS объявлен массив на 100 Мб — я первый потребую под него место. Но пока его нет, нечего память транжирить.
M>>>>Ну пока его нет, его и не транжирят. Вернее, транжирят столько, соклько нужно для JIT'а и runtime-оптимизаций.
PD>>>А сколько нужно под код на js размером в 50-100 Кб при том, что там нет больших массивов ? Я так полагаю, что 1 Мб должно хватить. Для ТурбоПаскаля хватало же.
M>>Честно, не знаю, сколько
PD>Но ведь для ТР хватало 1 Мб. А JS не сложнее.
А кто сказал, что JS'e не хватит?
M>>Ну, как я и сказал, Thunderbird вообще неудачный пример
PD>А что в OE лучше, кроме уязвимостей ?
Ээээ, а что такое ОЕ?
M>>Вот смотрю я на Mail.app под макосью... Почти пять игов писем, синхронизированных по IMAP, но хранящихся локально. С поиском, threading'ом, фильтрами, смарт-боксами, rss-читалкой и т.п. 84 мегабайта в памяти
PD>Ну и я смотрю. Thunderbird. 2 GB писем. Хранятся локально. Поиск и прочее на месте. Размер примерно тот же.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
M>>>Ну ты же привязался непременно к компиляции яваскрипта
PD>>Не к компиляции, а к работе. Если в JS объявлен массив на 100 Мб — я первый потребую под него место. Но пока его нет, нечего память транжирить.
I>То есть не имея на то оснований, оптимизировать расход памяти в ущерб перформансу ?
кстати, а вы не пробовали не перезапускать лиса и gtalk пару недель. попробуйте. больше двух месяцев не продержитесь. даже если есть память -- закончится адресное пространство. ну с лисом как бы все понятно. там у меня стоит несколько плагинов и на них всегда можно свалить все грехи. а вот откуда берутся утечки памяти в gtalk в таком кол-ве? как было в первой версии, так и в последней...
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Ikemefula, Вы писали:
PD>>>А сколько нужно под код на js размером в 50-100 Кб при том, что там нет больших массивов ? Я так полагаю, что 1 Мб должно хватить. Для ТурбоПаскаля хватало же.
I>>Надо начинать не с килобайт и строчек, а с размера одного объекта для JS или DOM.
PD>Ну вот и давай сюда этот размер. Ты же с DOM 10 лет работаешь. Давай сюда какой-нибудь пример.
PD>Вот тебе мой пример.
PD>Дано : набор целых чисел в количестве 10000 штук. PD>Объем этих данных — 40 Кб. PD>Решено построить из них BST PD>В каждом узле 4 байта под число + 8 байт под два указателя. Итого 12 байт. Возможно, при выравнивании будет 16.
PD>16*10000 == 160000 = 160 Кб.
PD>Так что извини, но больше 200 Кб не дам — при этой структуре.
PD>Приведи свой пример.
Ты забываешь, что в JS int'ы, пусть и в теории, тоже объекты, тип которых, кстати, не известен. Более того, нет в Javascript'е указателей. И самое более того, ООП там немного совсем не паскалевское.
Из-за чего для ускорения быстродействия приходится делать интересные ухищрения такого типа: http://code.google.com/apis/v8/design.html, которые ускоряют работу, но отжирают память.
JIT способен распознать int's, но не всегда сразу. Не знаю, как работает v8, но, в теории, ему надо набрать статистику вызовов и только потом превратить их в int'ы. Что тоже бесплатно не дается. Везде компромиссы.
Здравствуйте, Mamut, Вы писали:
PD>>Но ведь для ТР хватало 1 Мб. А JS не сложнее.
M>А кто сказал, что JS'e не хватит?
Так пусть и хватит. Если хватит — о чем разговор ? Но мне же тут доказывали, что на 500 Кб js-текстов надо что-то умопомрачительное.
M>>>Ну, как я и сказал, Thunderbird вообще неудачный пример
PD>>А что в OE лучше, кроме уязвимостей ?
M>Ээээ, а что такое ОЕ?
Outlook Express
M>>>Вот смотрю я на Mail.app под макосью... Почти пять игов писем, синхронизированных по IMAP, но хранящихся локально. С поиском, threading'ом, фильтрами, смарт-боксами, rss-читалкой и т.п. 84 мегабайта в памяти
PD>>Ну и я смотрю. Thunderbird. 2 GB писем. Хранятся локально. Поиск и прочее на месте. Размер примерно тот же.
M>Хм. Странно Должно быть больше, по идее
Здравствуйте, Mamut, Вы писали:
M>Ты забываешь, что в JS int'ы, пусть и в теории, тоже объекты, тип которых, кстати, не известен.
Нет, не забыл. Под это готов дать еще 4 байта на объект. Даже 8 дам, так и быть — для ссылки на объект типа (тип же должен быть известен)
Псевдоязык
class ClassType
{
int type; // не нравится int - возьми иное, возражать не буду, ибо это синглетон
string typename;
};
class Variable
{
ClassType* type;
void* pData;
};
>Более того, нет в Javascript'е указателей.
Указатели всегда есть. Их может не быть в языке, ими может быть , нельзя прямо оперировать, но по сути они всегда есть. Потому что это адреса чего-то
такого в памяти, с чем имеем дело. В одном языке (С++) они есть явно, в другом (С#) они выступают в виде ссылок и т.д. Вот в Фортране-4 их действительно не было >И самое более того, ООП там немного совсем не паскалевское.
Ну и что ? Ладно, еще 4 байта дам. Даже 8.
M>JIT способен распознать int's, но не всегда сразу. Не знаю, как работает v8, но, в теории, ему надо набрать статистику вызовов и только потом превратить их в int'ы. Что тоже бесплатно не дается. Везде компромиссы.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mamut, Вы писали:
M>>Ты забываешь, что в JS int'ы, пусть и в теории, тоже объекты, тип которых, кстати, не известен.
PD>Нет, не забыл. Под это готов дать еще 4 байта на объект. Даже 8 дам, так и быть — для ссылки на объект типа (тип же должен быть известен)
PD>Ну и что ? Ладно, еще 4 байта дам. Даже 8.
Ты меня в нашей ветке обвинил в том, что я играю на твоем незнании линукс (между тем, я хотел лишь прозрачно намекнуть, что механизмы высокуровневого IPC там немножко отличаются от виндовых), сам же здесь рассуждаешь об излишестве байтв том, о чем владеешь информацией едва ли не в меньшей степени, чем о линуксе
Давай попробуем по другому? Вот тебе объект, описывающий в хроме один элемент DOM. Ткни пожалуйста пальцем в те места, которые там лишние или которые ты считаешь расточительными с т.з. затрат памяти. Ок?
/*
* Copyright (C) 1999 Lars Knoll (knoll@kde.org)
* (C) 1999 Antti Koivisto (koivisto@kde.org)
* (C) 2001 Peter Kelly (pmk@post.com)
* (C) 2001 Dirk Mueller (mueller@kde.org)
* Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Apple Inc. All rights reserved.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Library General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Library General Public License for more details.
*
* You should have received a copy of the GNU Library General Public License
* along with this library; see the file COPYING.LIB. If not, write to
* the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
* Boston, MA 02110-1301, USA.
*
*/#ifndef Element_h
#define Element_h
#include"Document.h"#include"FragmentScriptingPermission.h"#include"NamedNodeMap.h"#include"ScrollTypes.h"namespace WebCore {
class Attribute;
class ClientRect;
class ClientRectList;
class DOMStringMap;
class DOMTokenList;
class ElementRareData;
class IntSize;
enum SpellcheckAttributeState {
SpellcheckAttributeTrue,
SpellcheckAttributeFalse,
SpellcheckAttributeDefault
};
class Element : public ContainerNode {
public:
static PassRefPtr<Element> create(const QualifiedName&, Document*);
virtual ~Element();
DEFINE_ATTRIBUTE_EVENT_LISTENER(abort);
DEFINE_ATTRIBUTE_EVENT_LISTENER(change);
DEFINE_ATTRIBUTE_EVENT_LISTENER(click);
DEFINE_ATTRIBUTE_EVENT_LISTENER(contextmenu);
DEFINE_ATTRIBUTE_EVENT_LISTENER(dblclick);
DEFINE_ATTRIBUTE_EVENT_LISTENER(dragenter);
DEFINE_ATTRIBUTE_EVENT_LISTENER(dragover);
DEFINE_ATTRIBUTE_EVENT_LISTENER(dragleave);
DEFINE_ATTRIBUTE_EVENT_LISTENER(drop);
DEFINE_ATTRIBUTE_EVENT_LISTENER(dragstart);
DEFINE_ATTRIBUTE_EVENT_LISTENER(drag);
DEFINE_ATTRIBUTE_EVENT_LISTENER(dragend);
DEFINE_ATTRIBUTE_EVENT_LISTENER(input);
DEFINE_ATTRIBUTE_EVENT_LISTENER(invalid);
DEFINE_ATTRIBUTE_EVENT_LISTENER(keydown);
DEFINE_ATTRIBUTE_EVENT_LISTENER(keypress);
DEFINE_ATTRIBUTE_EVENT_LISTENER(keyup);
DEFINE_ATTRIBUTE_EVENT_LISTENER(mousedown);
DEFINE_ATTRIBUTE_EVENT_LISTENER(mousemove);
DEFINE_ATTRIBUTE_EVENT_LISTENER(mouseout);
DEFINE_ATTRIBUTE_EVENT_LISTENER(mouseover);
DEFINE_ATTRIBUTE_EVENT_LISTENER(mouseup);
DEFINE_ATTRIBUTE_EVENT_LISTENER(mousewheel);
DEFINE_ATTRIBUTE_EVENT_LISTENER(scroll);
DEFINE_ATTRIBUTE_EVENT_LISTENER(select);
DEFINE_ATTRIBUTE_EVENT_LISTENER(submit);
// These four attribute event handler attributes are overridden by HTMLBodyElement
// and HTMLFrameSetElement to forward to the DOMWindow.
DECLARE_VIRTUAL_ATTRIBUTE_EVENT_LISTENER(blur);
DECLARE_VIRTUAL_ATTRIBUTE_EVENT_LISTENER(error);
DECLARE_VIRTUAL_ATTRIBUTE_EVENT_LISTENER(focus);
DECLARE_VIRTUAL_ATTRIBUTE_EVENT_LISTENER(load);
// WebKit extensions
DEFINE_ATTRIBUTE_EVENT_LISTENER(beforecut);
DEFINE_ATTRIBUTE_EVENT_LISTENER(cut);
DEFINE_ATTRIBUTE_EVENT_LISTENER(beforecopy);
DEFINE_ATTRIBUTE_EVENT_LISTENER(copy);
DEFINE_ATTRIBUTE_EVENT_LISTENER(beforepaste);
DEFINE_ATTRIBUTE_EVENT_LISTENER(paste);
DEFINE_ATTRIBUTE_EVENT_LISTENER(reset);
DEFINE_ATTRIBUTE_EVENT_LISTENER(search);
DEFINE_ATTRIBUTE_EVENT_LISTENER(selectstart);
#if ENABLE(TOUCH_EVENTS)
DEFINE_ATTRIBUTE_EVENT_LISTENER(touchstart);
DEFINE_ATTRIBUTE_EVENT_LISTENER(touchmove);
DEFINE_ATTRIBUTE_EVENT_LISTENER(touchend);
DEFINE_ATTRIBUTE_EVENT_LISTENER(touchcancel);
#endif
#if ENABLE(FULLSCREEN_API)
DEFINE_ATTRIBUTE_EVENT_LISTENER(webkitfullscreenchange);
#endif
virtual PassRefPtr<DocumentFragment> deprecatedCreateContextualFragment(const String&, FragmentScriptingPermission = FragmentScriptingAllowed);
bool hasAttribute(const QualifiedName&) const;
const AtomicString& getAttribute(const QualifiedName&) const;
void setAttribute(const QualifiedName&, const AtomicString& value, ExceptionCode&);
void removeAttribute(const QualifiedName&, ExceptionCode&);
// Typed getters and setters for language bindings.int getIntegralAttribute(const QualifiedName& attributeName) const;
void setIntegralAttribute(const QualifiedName& attributeName, int value);
unsigned getUnsignedIntegralAttribute(const QualifiedName& attributeName) const;
void setUnsignedIntegralAttribute(const QualifiedName& attributeName, unsigned value);
// Call this to get the value of an attribute that is known not to be the style
// attribute or one of the SVG animatable attributes.bool fastHasAttribute(const QualifiedName&) const;
const AtomicString& fastGetAttribute(const QualifiedName&) const;
bool hasAttributes() const;
bool hasAttribute(const String& name) const;
bool hasAttributeNS(const String& namespaceURI, const String& localName) const;
const AtomicString& getAttribute(const String& name) const;
const AtomicString& getAttributeNS(const String& namespaceURI, const String& localName) const;
void setAttribute(const AtomicString& name, const AtomicString& value, ExceptionCode&);
void setAttributeNS(const AtomicString& namespaceURI, const AtomicString& qualifiedName, const AtomicString& value, ExceptionCode&, FragmentScriptingPermission = FragmentScriptingAllowed);
bool isIdAttributeName(const QualifiedName&) const;
const AtomicString& getIdAttribute() const;
void setIdAttribute(const AtomicString&);
// Call this to get the value of the id attribute for style resolution purposes.
// The value will already be lowercased if the document is in compatibility mode,
// so this function is not suitable for non-style uses.const AtomicString& idForStyleResolution() const;
void scrollIntoView(bool alignToTop = true);
void scrollIntoViewIfNeeded(bool centerIfNeeded = true);
void scrollByLines(int lines);
void scrollByPages(int pages);
int offsetLeft();
int offsetTop();
int offsetWidth();
int offsetHeight();
Element* offsetParent();
int clientLeft();
int clientTop();
int clientWidth();
int clientHeight();
virtual int scrollLeft() const;
virtual int scrollTop() const;
virtual void setScrollLeft(int);
virtual void setScrollTop(int);
virtual int scrollWidth() const;
virtual int scrollHeight() const;
IntRect boundsInWindowSpace() const;
PassRefPtr<ClientRectList> getClientRects() const;
PassRefPtr<ClientRect> getBoundingClientRect() const;
void removeAttribute(const String& name, ExceptionCode&);
void removeAttributeNS(const String& namespaceURI, const String& localName, ExceptionCode&);
PassRefPtr<Attr> getAttributeNode(const String& name);
PassRefPtr<Attr> getAttributeNodeNS(const String& namespaceURI, const String& localName);
PassRefPtr<Attr> setAttributeNode(Attr*, ExceptionCode&);
PassRefPtr<Attr> setAttributeNodeNS(Attr*, ExceptionCode&);
PassRefPtr<Attr> removeAttributeNode(Attr*, ExceptionCode&);
virtual CSSStyleDeclaration* style();
const QualifiedName& tagQName() const { return m_tagName; }
String tagName() const { return nodeName(); }
bool hasTagName(const QualifiedName& tagName) const { return m_tagName.matches(tagName); }
// A fast function for checking the local name against another atomic string.bool hasLocalName(const AtomicString& other) const { return m_tagName.localName() == other; }
bool hasLocalName(const QualifiedName& other) const { return m_tagName.localName() == other.localName(); }
const AtomicString& localName() const { return m_tagName.localName(); }
const AtomicString& prefix() const { return m_tagName.prefix(); }
const AtomicString& namespaceURI() const { return m_tagName.namespaceURI(); }
virtual KURL baseURI() const;
virtual String nodeName() const;
PassRefPtr<Element> cloneElementWithChildren();
PassRefPtr<Element> cloneElementWithoutChildren();
void normalizeAttributes();
String nodeNamePreservingCase() const;
// convenience methods which ignore exceptionsvoid setAttribute(const QualifiedName&, const AtomicString& value);
void setBooleanAttribute(const QualifiedName& name, bool);
// Please don't use setCStringAttribute in performance-sensitive code;
// use a static AtomicString value instead to avoid the conversion overhead.void setCStringAttribute(const QualifiedName&, const char* cStringValue);
NamedNodeMap* attributes(bool readonly = false) const;
// This method is called whenever an attribute is added, changed or removed.virtual void attributeChanged(Attribute*, bool preserveDecls = false);
void setAttributeMap(PassRefPtr<NamedNodeMap>, FragmentScriptingPermission = FragmentScriptingAllowed);
NamedNodeMap* attributeMap() const { return m_attributeMap.get(); }
virtual void copyNonAttributeProperties(const Element* /*source*/) { }
virtual void attach();
virtual void detach();
virtual RenderObject* createRenderer(RenderArena*, RenderStyle*);
virtual void recalcStyle(StyleChange = NoChange);
RenderStyle* computedStyle(PseudoId = NOPSEUDO);
AtomicString computeInheritedLanguage() const;
void dispatchAttrRemovalEvent(Attribute*);
void dispatchAttrAdditionEvent(Attribute*);
virtual void accessKeyAction(bool/*sendToAnyEvent*/) { }
virtual bool isURLAttribute(Attribute*) const;
KURL getURLAttribute(const QualifiedName&) const;
KURL getNonEmptyURLAttribute(const QualifiedName&) const;
virtual const QualifiedName& imageSourceAttributeName() const;
virtual String target() const { return String(); }
virtual void focus(bool restorePreviousSelection = true);
virtual void updateFocusAppearance(bool restorePreviousSelection);
void blur();
String innerText() const;
String outerText() const;
virtual String title() const;
String openTagStartToString() const;
void updateId(const AtomicString& oldId, const AtomicString& newId);
IntSize minimumSizeForResizing() const;
void setMinimumSizeForResizing(const IntSize&);
// Use Document::registerForDocumentActivationCallbacks() to subscribe to thesevirtual void documentWillBecomeInactive() { }
virtual void documentDidBecomeActive() { }
// Use Document::registerForMediaVolumeCallbacks() to subscribe to thisvirtual void mediaVolumeDidChange() { }
bool isFinishedParsingChildren() const { return isParsingChildrenFinished(); }
virtual void finishParsingChildren();
virtual void beginParsingChildren() { clearIsParsingChildrenFinished(); }
// ElementTraversal API
Element* firstElementChild() const;
Element* lastElementChild() const;
Element* previousElementSibling() const;
Element* nextElementSibling() const;
unsigned childElementCount() const;
bool webkitMatchesSelector(const String& selectors, ExceptionCode&);
DOMTokenList* classList();
DOMTokenList* optionalClassList() const;
DOMStringMap* dataset();
DOMStringMap* optionalDataset() const;
#if ENABLE(MATHML)
virtual bool isMathMLElement() const { return false; }
#else
static bool isMathMLElement() { return false; }
#endif
virtual bool isFormControlElement() const { return false; }
virtual bool isEnabledFormControl() const { return true; }
virtual bool isReadOnlyFormControl() const { return false; }
virtual bool isSpinButtonElement() const { return false; }
virtual bool isTextFormControl() const { return false; }
virtual bool isOptionalFormControl() const { return false; }
virtual bool isRequiredFormControl() const { return false; }
virtual bool isDefaultButtonForForm() const { return false; }
virtual bool willValidate() const { return false; }
virtual bool isValidFormControlElement() { return false; }
virtual bool hasUnacceptableValue() const { return false; }
virtual bool formControlValueMatchesRenderer() const { return false; }
virtual void setFormControlValueMatchesRenderer(bool) { }
virtual const AtomicString& formControlName() const { return nullAtom; }
virtual const AtomicString& formControlType() const { return nullAtom; }
virtual bool shouldSaveAndRestoreFormControlState() const { return true; }
virtual bool saveFormControlState(String&) const { return false; }
virtual void restoreFormControlState(const String&) { }
virtual void dispatchFormControlChangeEvent() { }
#if ENABLE(SVG)
virtual bool childShouldCreateRenderer(Node*) const;
#endif
#if ENABLE(FULLSCREEN_API)
enum {
ALLOW_KEYBOARD_INPUT = 1
};
void webkitRequestFullScreen(unsigned short flags);
#endif
virtual bool isSpellCheckingEnabled() const;
protected:
Element(const QualifiedName& tagName, Document* document, ConstructionType type)
: ContainerNode(document, type)
, m_tagName(tagName)
{
}
virtual void insertedIntoDocument();
virtual void removedFromDocument();
virtual void childrenChanged(bool changedByParser = false, Node* beforeChange = 0, Node* afterChange = 0, int childCountDelta = 0);
// The implementation of Element::attributeChanged() calls the following two functions.
// They are separated to allow a different flow of control in StyledElement::attributeChanged().void recalcStyleIfNeededAfterAttributeChanged(Attribute*);
void updateAfterAttributeChanged(Attribute*);
private:
void scrollByUnits(int units, ScrollGranularity);
virtual void setPrefix(const AtomicString&, ExceptionCode&);
virtual NodeType nodeType() const;
virtual bool childTypeAllowed(NodeType);
virtual PassRefPtr<Attribute> createAttribute(const QualifiedName&, const AtomicString& value);
#ifndef NDEBUG
virtual void formatForDebugger(char* buffer, unsigned length) const;
#endif
bool pseudoStyleCacheIsInvalid(const RenderStyle* currentStyle, RenderStyle* newStyle);
void createAttributeMap() const;
virtual void updateStyleAttribute() const { }
#if ENABLE(SVG)
virtual void updateAnimatedSVGAttribute(const QualifiedName&) const { }
#endif
void cancelFocusAppearanceUpdate();
virtual const AtomicString& virtualPrefix() const { return prefix(); }
virtual const AtomicString& virtualLocalName() const { return localName(); }
virtual const AtomicString& virtualNamespaceURI() const { return namespaceURI(); }
virtual RenderStyle* virtualComputedStyle(PseudoId pseudoElementSpecifier = NOPSEUDO) { return computedStyle(pseudoElementSpecifier); }
// cloneNode is private so that non-virtual cloneElementWithChildren and cloneElementWithoutChildren
// are used instead.virtual PassRefPtr<Node> cloneNode(bool deep);
virtual PassRefPtr<Element> cloneElementWithoutAttributesAndChildren() const;
QualifiedName m_tagName;
virtual NodeRareData* createRareData();
ElementRareData* rareData() const;
ElementRareData* ensureRareData();
SpellcheckAttributeState spellcheckAttributeState() const;
private:
mutable RefPtr<NamedNodeMap> m_attributeMap;
};
inline Element* toElement(Node* node)
{
ASSERT(!node || node->isElementNode());
return static_cast<Element*>(node);
}
inline const Element* toElement(const Node* node)
{
ASSERT(!node || node->isElementNode());
return static_cast<const Element*>(node);
}
// This will catch anyone doing an unnecessary cast.void toElement(const Element*);
inline bool Node::hasTagName(const QualifiedName& name) const
{
return isElementNode() && toElement(this)->hasTagName(name);
}
inline bool Node::hasAttributes() const
{
return isElementNode() && toElement(this)->hasAttributes();
}
inline NamedNodeMap* Node::attributes() const
{
return isElementNode() ? toElement(this)->attributes() : 0;
}
inline Element* Node::parentElement() const
{
ContainerNode* parent = parentNode();
return parent && parent->isElementNode() ? toElement(parent) : 0;
}
inline NamedNodeMap* Element::attributes(bool readonly) const
{
if (!isStyleAttributeValid())
updateStyleAttribute();
#if ENABLE(SVG)
if (!areSVGAttributesValid())
updateAnimatedSVGAttribute(anyQName());
#endif
if (!readonly && !m_attributeMap)
createAttributeMap();
return m_attributeMap.get();
}
inline void Element::updateId(const AtomicString& oldId, const AtomicString& newId)
{
if (!inDocument())
return;
if (oldId == newId)
return;
Document* doc = document();
if (!oldId.isEmpty())
doc->removeElementById(oldId, this);
if (!newId.isEmpty())
doc->addElementById(newId, this);
}
inline bool Element::fastHasAttribute(const QualifiedName& name) const
{
return m_attributeMap && m_attributeMap->getAttributeItem(name);
}
inline const AtomicString& Element::fastGetAttribute(const QualifiedName& name) const
{
if (m_attributeMap) {
if (Attribute* attribute = m_attributeMap->getAttributeItem(name))
return attribute->value();
}
return nullAtom;
}
inline const AtomicString& Element::idForStyleResolution() const
{
ASSERT(hasID());
return m_attributeMap->idForStyleResolution();
}
inline bool Element::isIdAttributeName(const QualifiedName& attributeName) const
{
// FIXME: This check is probably not correct for the case where the document has an id attribute
// with a non-null namespace, because it will return false, a false negative, if the prefixes
// don't match but the local name and namespace both do. However, since this has been like this
// for a while and the code paths may be hot, we'll have to measure performance if we fix it.return attributeName == document()->idAttributeName();
}
inline const AtomicString& Element::getIdAttribute() const
{
return fastGetAttribute(document()->idAttributeName());
}
inline void Element::setIdAttribute(const AtomicString& value)
{
setAttribute(document()->idAttributeName(), value);
}
} // namespace#endif
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ты мне КПСС начинаешь напоминать. Она тоже с вредной идеологией боролась, защищала нас от от нее
PD>Если коротко — нет вредной идеологии. Есть мнения, близкие к истине, а есть — далекие от нее. Я высказываю свое мнение, а насколько оно близко или далеко от истины — пусть другие оценят.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну вот и давай сюда этот размер. Ты же с DOM 10 лет работаешь. Давай сюда какой-нибудь пример.
Щас ты говоришь, "Давай", а в ответ на пример пишешь "разобраться невозможно"
PD>Вот тебе мой пример.
PD>Дано : набор целых чисел в количестве 10000 штук. PD>Объем этих данных — 40 Кб. PD>Решено построить из них BST PD>В каждом узле 4 байта под число + 8 байт под два указателя. Итого 12 байт. Возможно, при выравнивании будет 16.
БСТ это не то. DOM ближе всего не к BST, а к графу. Во всяком случае у одного узла есть n-дочерних, а не 2.
Добавь указатель на таблицу виртуальных методов, указатель на верхний элемент, указатель на рут, получится всего 24 байта.
С выравниванием есть нюансы, например, вырвнивание под кеш или на границу параграфа
В браузере же к одному html DOM не сводится.
PD>Приведи свой пример.
Вот пример, который я приводил раньше, я его дополнил и упростил, что бы тебе полегче было
Есть вещь вроде <tag attr1="value1" ... ><tag1 attr1="value1" ... ></tag1></tag>
То есть у тега имя, есть n атрибутов и вложеные теги с такой же структурой.
Далее по тексту предполагается, что доп. данные надо будет где то хранить, хотя и не обязательно в экземпляре объекта. "усилить таблицу == подобрать нужную структуру данных"
Итого 1 тег это
n аттрибутов
вложеные теги
Это минимально необходимое количество, меньше просто невозможно и это только данные
Для DOM надо добавить список подписчиков на различные эвенты — ибо это АПИ не просто данные
lpvtbl
парент
рут
для быстрого доступа по имени атрибута тебе надо ввести таблицу атрибутов
для быстрого добавления дочернего элемента надо вместо массива сделать коллекцию
для быстрого поиска тега по ID надо усилить коллекцию
для быстрого поиска тега по имени надо усилить коллекцию
для быстрого поиска тега по классу надо усилить коллекцию
для быстрого вызова метода по имени нужна таблица методов (метод можно добавить конкретному объекту !)
для быстрого добавления метода в рантайме надо таблицу усилить
строки должны быть максимально быстрые, обычных сишных недостаточно
Теперь посчитай, как увеличится расход памяти ну и издержки из за CSS и рендеринга учти сам и это не предел для оптимизаций.
После этого останется учесть расход памяти для CSS и рендеринга.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Ты меня в нашей ветке обвинил в том, что я играю на твоем незнании линукс (между тем, я хотел лишь прозрачно намекнуть, что механизмы высокуровневого IPC там немножко отличаются от виндовых), сам же здесь рассуждаешь об излишестве байтв том, о чем владеешь информацией едва ли не в меньшей степени, чем о линуксе
Ну-ну.
KV>Давай попробуем по другому? Вот тебе объект, описывающий в хроме один элемент DOM. Ткни пожалуйста пальцем в те места, которые там лишние или которые ты считаешь расточительными с т.з. затрат памяти. Ок?
Нет. По очень простой причине — тут вообще затрат памяти на данные нет, потому что нет данных. Я тебе простой вопрос задам — чему равен sizeof(class Element) ? Функции тут все ни при чем, они в структуру не входят, как ты понимаешь (если нужно, могу объяснить, как реализованы virtual и не-virtual функции). static тоже. А данных я тут что-то не вижу, кроме DEFINE_ATTRIBUTE_EVENT_LISTENER, о котором не знаю, что это такое и каков его размер (думаю, что это указатель (как в MFC), а не описание функции). Может быть, данные у класса — родителя, не знаю, но для этого класса sizeof будет очень маленький.
Владимир, пойми одну простую вещь. Добавляя скалярные поля в класс, размер сильно не увеличишь. Ну еще 4 байта, ну еще 16, все это мелочи и пустяки. Заведи в классе хоть 1000 методов — тоже. Единственный способ серьезно увеличить расход памяти — добавить большой блок памяти (массив то есть). Зачем тут массив — не вижу, да его и нет. А то, что здесь под сотню методов — роли не играет, код методов в одном экземпляре хранится на все объекты. Я не вижу кода всех этих методов, но смело могу сказать, что их суммарный объем едва ли выходит за 50 Кбайт.
Здравствуйте, Ikemefula, Вы писали:
I>Щас ты говоришь, "Давай", а в ответ на пример пишешь "разобраться невозможно"
Еще бы. Как я могу разбираться в твоем укреплении таблицы, если я не знаю, что такое у тебя таблица и как ее укрепляют.
PD>>Вот тебе мой пример.
PD>>Дано : набор целых чисел в количестве 10000 штук. PD>>Объем этих данных — 40 Кб. PD>>Решено построить из них BST PD>>В каждом узле 4 байта под число + 8 байт под два указателя. Итого 12 байт. Возможно, при выравнивании будет 16.
I>БСТ это не то. DOM ближе всего не к BST, а к графу. Во всяком случае у одного узла есть n-дочерних, а не 2.
Я БСТ не потому привел, что оно близко к DOM, а просто как пример того, что я от тебя хочу получить. Но вот получить никак не могу
I>Добавь указатель на таблицу виртуальных методов, указатель на верхний элемент, указатель на рут, получится всего 24 байта.
Да пусть хоть 100. Неужели ты не понимаешь, что добавляя скалярные поля, хоть 5, хоть десять, потребность в памяти можно увеличить тоже в 5 или 10 раз, а не в сотни и тысячи. Вот если ты 1000 полей добавишь — тогда да, но где ты их возьмешь ? А можно и не 1000 полей, а всего лишь один массив на 1000 элементов — тогда тоже да. Но вот это и будет расточительством памяти.
I>С выравниванием есть нюансы, например, вырвнивание под кеш или на границу параграфа
И это все +4 лишних байта, то есть тоже мелочи.
I>В браузере же к одному html DOM не сводится.
PD>>Приведи свой пример.
I>Вот пример, который я приводил раньше, я его дополнил и упростил, что бы тебе полегче было
У меня нет времени и желания разбираться с неизвестными мне понятиями. К тому же ты делаешь попытки определить
I>Есть вещь вроде <tag attr1="value1" ... ><tag1 attr1="value1" ... ></tag1></tag>
I>То есть у тега имя, есть n атрибутов и вложеные теги с такой же структурой.
I>Далее по тексту предполагается, что доп. данные надо будет где то хранить, хотя и не обязательно в экземпляре объекта. "усилить таблицу == подобрать нужную структуру данных"
Ты думаешь, это определение делает что-то понятнее ? Какую структуру, что за таблица ?
I>Итого 1 тег это
I>n аттрибутов I>вложеные теги
Само собой.
I>Это минимально необходимое количество, меньше просто невозможно и это только данные
I>Для DOM надо добавить список подписчиков на различные эвенты — ибо это АПИ не просто данные
I>lpvtbl I>парент I>рут I>для быстрого доступа по имени атрибута тебе надо ввести таблицу атрибутов I>для быстрого добавления дочернего элемента надо вместо массива сделать коллекцию I>для быстрого поиска тега по ID надо усилить коллекцию I>для быстрого поиска тега по имени надо усилить коллекцию I>для быстрого поиска тега по классу надо усилить коллекцию I>для быстрого вызова метода по имени нужна таблица методов (метод можно добавить конкретному объекту !) I>для быстрого добавления метода в рантайме надо таблицу усилить I>строки должны быть максимально быстрые, обычных сишных недостаточно
I>Теперь посчитай, как увеличится расход памяти ну и издержки из за CSS и рендеринга учти сам и это не предел для оптимизаций.
Нет, пожалуйста, посчитай сам (тебе лучше знать) и приведи. Есть элемент (подчеркиваю, элемент, а не все дерево), в твоих терминах — тег (я правильно понял ?). Ну вот и приведи (примерно, конечно), из чего складывается sizeof этого тега. Указатель занимает 4 байта, int — тоже 4, double — 8 и т.д. Вот и приведи. Без лишних слов. Просто значения.
I>После этого останется учесть расход памяти для CSS и рендеринга.
V>>Для удобства, разве нет? Форматирование текста придумали давно, значит оно нужно, а значит полезно и удобно в Instant Messenger. А там делать форматированый текст наиболее естественно используя гипертекст. Стили просто добавляют комфорта — кому-то удобнее читать белым по черному, кому-то черным по белому, а дебилам голубым по розовому — все довольны. M_>ни разу не отправлял и не принимал форматированных мессаг. M_>ты точно уверен, что это — не маркетинговая плюшка?
Точно, я отправлял и принимал, иногда очень полезно. А вообще можно юзать миранду без плагинов — вообще нифига там нет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А что тут такого ? Интерпретаторы этим всю свою историю занимались, на то они и интерпретаторы. Даже какой-нибудь GW-Basic на 64 Кб это умел. Чистый интерпретатор берет строчку исходного текста, строит машинные команды, исполняет.
Мда... "Построчные" интерпритаторы машинный код не создают.
Учи матчасть.
PD> Полукомпилятор хранит еще и кэш этих кусков машинных команд, чтобы повторно не интерпретировать.
Я хренею дорогая редакция.
PD>Из 5 Мбайт исходников на каком угодно языке (хоть на асме) этих машинных команд можно создать не более 1-2 Мбайт. В чем проблема-то ?
Проблема в том что ты даже не представляешь о чем говоришь.
Ты полностью безграмотен в данном вопросе.
Послушай эту лекцию: http://www.youtube.com/watch?v=FrufJFBSoQY
Там один из авторов V8 расказывает о том почему жабаскрип это медленно и как они с этим борятся.
Послушай внимательно и с самого начала.
PD>Ты знаешь, я с тех пор ничего нового в почте так и не увидел. Я лично пользуюсь Thunderbird, он, конечно, получше, чем Netscape mail 1990-х, но не намного. Что там, в самом деле, радикально нового ? Почта она и есть почта.
Ну хотябы то что gmail живет в браузере и доступен откуда угодно.
PD>Ну так нечего было давать писать броузеры тем, кто это делать не умеет.
Они это делать умеют.
Проблема не в них.
Проблема тут: http://www.w3.org/
Комитет как всегда создал жуткого монстра которого просто не возможно эффективно реализовать.
За примером смотри хотябы лекцию выше. Это же просто ужос как мужики извращаются для того чтобы заставить жабаскрипт не тормозить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Учи матчасть. WH>Я хренею дорогая редакция. WH>Ты полностью безграмотен в данном вопросе. WH>Послушай внимательно и с самого начала.
Слушай, у тебя , как я понимаю, была основная цель этого постинга — объянить, что я ничего не понимаю. Ну и на здоровье. Считай, что ты в очередной раз отметился, а дискутировать мне с тобой на эту тему незачем.
Здравствуйте, мыщъх, Вы писали:
I>>То есть не имея на то оснований, оптимизировать расход памяти в ущерб перформансу ? М>кстати, а вы не пробовали не перезапускать лиса и gtalk пару недель. попробуйте. больше двух месяцев не продержитесь. даже если есть память -- закончится адресное пространство. ну с лисом как бы все понятно. там у меня стоит несколько плагинов и на них всегда можно свалить все грехи. а вот откуда берутся утечки памяти в gtalk в таком кол-ве? как было в первой версии, так и в последней...
Странно.
Выделяя память в куче, такого эффекта добиться нельзя. Дело в том, что с точки зрения АП куча целиком — это занятый участок (или участки), а что там внутри нее (свободные и занятые участки в смысле кучи) — значения вообще не имеет. Поэтому если куча оккупировала бы все АП, у тебя было бы выделенной памяти за гигабайт.
С помощью VirtualAlloc такого добиться — раз плюнуть, но такие действия нормальные программисты всегда контролируют.
Попробуй запусти vmmap и посмотри.
Здравствуйте, WolfHound, Вы писали:
WH>Ты пишешь такой бред что даже не смешно. WH>Это я тебе говорю как человек занимающейся проектированием языков программирования.
О господи! Я всего лишь озвучил то, что в любом учебнике написано. Почитай хоть здесь
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>О господи! Я всего лишь озвучил то, что в любом учебнике написано.
Учебники ты тоже читать не умеешь.
Чистый интерпретатор берет строчку исходного текста, строит машинные команды, исполняет.
(С)Pavel Dvorkin
Вот этот алгоритм бред полный. Интерпретатор ничего не строит.
Он распознав инструкцию сразу исполняет ее.
Более умные интерпретаторы распознают текст один раз (ибо это очень медленно) и строят либо байткод либо AST и запускают интерпретацию уже по нему.
Но это всеравно очень медленно ибо для того чтобы вызвать функцию нужно произвести поиск в нескольких хештаблицах.
Чтобы обратиться к полю нужно опять таки искать это поле в нескольких хештаблицах.
Авторы V8 с помощью очень страшной магии с этим борятся. Но магия жрет память.
Твоя апелляция к паскалю опять таки бред. Ибо паскаль статически типизируемый язык.
Как следвие все вызовы функций и обращения к полям можно найти на этапе компиляции.
И даже если генерировать код в методом что вижу то пою (без оптимизации) всеравно получится быстрее чем любой интерпретатор.
PD>и при этом не выполнить команду add — будет очень интересно.
Чистый интерпретатор берет строчку исходного текста, строит машинные команды, исполняет.
PD>Увы, не могу. Грустно признаться, но английский я на слух не воспринимаю
Там еще субтитры есть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>О господи! Я всего лишь озвучил то, что в любом учебнике написано. WH>Учебники ты тоже читать не умеешь. WH>
WH>Чистый интерпретатор берет строчку исходного текста, строит машинные команды, исполняет.
WH>(С)Pavel Dvorkin WH>Вот этот алгоритм бред полный. Интерпретатор ничего не строит. WH>Он распознав инструкцию сразу исполняет ее.
О господи! Он создает машинную команду, которая исполняет эту строчку. Я же не утверждал, что он это делает в какой-то отдельной области памяти и т.п. Не хватало мне еще пытаться определить, как он там внутри работает. Я лишь одно утверждал — он анализирует исходный текст, создает машинную команду и выполняет ее. Создает он ее путем заноса байтов в отдельную область или же она у него уже готовая есть — какое это значение имеет ?
WH>Более умные интерпретаторы распознают текст один раз (ибо это очень медленно) и строят либо байткод либо AST и запускают интерпретацию уже по нему.
Смотря какие. Во времена Бейсика не было никакого байткода, а делалось именно это. Читал об этом еще лет 15 назад.
Здравствуйте, WolfHound, Вы писали:
PD>> Полукомпилятор хранит еще и кэш этих кусков машинных команд, чтобы повторно не интерпретировать. WH>Я хренею дорогая редакция.
На, читай, специалист по разработке языков! Выделено мной
По мере увеличения ресурсов компьютеров и расширения гетерогенных сетей (в том числе Интернета), связывающих компьютеры разных типов и архитектур, выделился новый вид интерпретации, при котором исходный (или промежуточный) код компилируется в машинный код непосредственно во время исполнения, «на лету». Уже скомпилированные участки кода кэшируются, чтобы при повторном обращении к ним они сразу получали управление, без перекомпиляции. Этот подход получил название динамической компиляции
Но ИМХО что-то такое я припоминаю из времен гораздо более давних.
WH>Более умные интерпретаторы распознают текст один раз (ибо это очень медленно) и строят либо байткод либо AST и запускают интерпретацию уже по нему. WH>Но это всеравно очень медленно ибо для того чтобы вызвать функцию нужно произвести поиск в нескольких хештаблицах. WH>Чтобы обратиться к полю нужно опять таки искать это поле в нескольких хештаблицах. WH>Авторы V8 с помощью очень страшной магии с этим борятся. Но магия жрет память.
WH>Твоя апелляция к паскалю опять таки бред. Ибо паскаль статически типизируемый язык. WH>Как следвие все вызовы функций и обращения к полям можно найти на этапе компиляции. WH>И даже если генерировать код в методом что вижу то пою (без оптимизации) всеравно получится быстрее чем любой интерпретатор.
Несомненно. Для этого и аргументировать не надо. Кстати. я и не говорил в этом топике ничего про быстродействие. Я тут обсуждал объем памяти. Мне тут упорно доказывали, что без десятков, а то и сотни Мб никак с этим js и программой на нем справиться невозможно. А вот это никакие хеш-таблицы не объяснят. Да, память под объект несколько увеличится, но лишь несколько, а не в сотню раз.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, мыщъх, Вы писали:
I>>>То есть не имея на то оснований, оптимизировать расход памяти в ущерб перформансу ? М>>кстати, а вы не пробовали не перезапускать лиса и gtalk пару недель. попробуйте. больше двух месяцев не продержитесь. даже если есть память -- закончится адресное пространство. ну с лисом как бы все понятно. там у меня стоит несколько плагинов и на них всегда можно свалить все грехи. а вот откуда берутся утечки памяти в gtalk в таком кол-ве? как было в первой версии, так и в последней...
PD>Странно. PD>Выделяя память в куче, такого эффекта добиться нельзя. Дело в том, что с точки зрения АП куча целиком — это занятый участок (или участки), а что там внутри нее (свободные и занятые участки в смысле кучи) — значения вообще не имеет. Поэтому если куча оккупировала бы все АП, у тебя было бы выделенной памяти за гигабайт.
так его за гигабайт и есть. на подступах к двум гигабайтам gtalk дохнет. на это (если не пользоваться войсом) у меня уходит два месяца. на фрагментацию очень слабо похоже. при фрагментации потребление памяти резко растет только в начале, а потом все чаще и чаще попадаются куски памяти подходящей величины и они используются повторно без выделения новых блоков.
и ведь это не только gtalk. это так многие. включая фар. после месяца работы с ним он превращается в очень толстого потребителя памяти. правда, опять-таки, возможно, не сам фар. возможно, плагины. но с точки зрения пользователя -- без разницы. хотя я понимаюю, что 90% пользователей перезапускают комп или приложения каждый день (или чаще) и потому приложения на круголосуточную работу никем не тестируются. а память -- течет.
кстати, работая до миграции в штаты на P-III с 512 метрами я легко мерял память и без всяких диспетчеров задач. вот тут все затормозилось и стало уходить в своп. закрыл Gtalk -- сразу появилось куча свободной памяти
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
PD>>Выделяя память в куче, такого эффекта добиться нельзя. Дело в том, что с точки зрения АП куча целиком — это занятый участок (или участки), а что там внутри нее (свободные и занятые участки в смысле кучи) — значения вообще не имеет. Поэтому если куча оккупировала бы все АП, у тебя было бы выделенной памяти за гигабайт. М>так его за гигабайт и есть.
Что, VM Size под Гбайт ? Объем коммитированной памяти ? Извини, не верю.
>на подступах к двум гигабайтам gtalk дохнет.
2 Гбайта — это предел по x86 (без флага /3GB). Тут всем дохнуть надо или что-то предпринимать. Но коммитировать (не резервировать!) 2 Гб — это уж чистая фантастика дл обычных десктопных приложений.
>на это (если не пользоваться войсом) у меня уходит два месяца. на фрагментацию очень слабо похоже. при фрагментации потребление памяти резко растет только в начале, а потом все чаще и чаще попадаются куски памяти подходящей величины и они используются повторно без выделения новых блоков.
Ты не путаешь 2 механизма ? Есть выделение памяти на уровне ОС (выделение страниц) и на уровне кучи (блоков произвольного размера). Фрагментация кучи ОС не интересует — пока в куче есть нужного размера участок, куча не растет, а когда нет — добавляется новый экстент кучи, вот только тогда уменьшается объем свободного АП. Исчерпать так АП можно, но для этого надо кучу довести до сумасшедших размеров. Я один раз довел, а потом она меня до белого каления довела, когда выяснилось, что на XP все в порядке (ну рассчитал же я!), а под 2000 — нет. Оказалось, что там куча ведет себя как-то странно.
М>и ведь это не только gtalk. это так многие. включая фар. после месяца работы с ним он превращается в очень толстого потребителя памяти. правда, опять-таки, возможно, не сам фар. возможно, плагины. но с точки зрения пользователя -- без разницы. хотя я понимаюю, что 90% пользователей перезапускают комп или приложения каждый день (или чаще) и потому приложения на круголосуточную работу никем не тестируются. а память -- течет.
Я свой рабочий комп перезапускаю крайне редко сейчас. Я с ним не работаю напрямую, а только хожу за всякими файлами со своего домашнего компьютера через RDP. Поэтому рабочий комп у меня постоянно включен, а перезагружается он либо при сбое питания, либо при установке апдейтов.
Вот сейчас заглянул. Фар — 4 Мб, Мозилла — 56. Лиса не запущена. Мозилла работает по крайней мере 2 недели.
М>кстати, работая до миграции в штаты на P-III с 512 метрами я легко мерял память и без всяких диспетчеров задач. вот тут все затормозилось и стало уходить в своп. закрыл Gtalk -- сразу появилось куча свободной памяти
Все же запусти vmmap от Руссиновича. Поймешь, что там в АП творится.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>О господи! Он создает машинную команду, которая исполняет эту строчку. Я же не утверждал, что он это делает в какой-то отдельной области памяти и т.п. Не хватало мне еще пытаться определить, как он там внутри работает. Я лишь одно утверждал — он анализирует исходный текст, создает машинную команду и выполняет ее.
Вот простейший интерпретатор арифметических выражений:
Макрос PegGrammar генерирует код парсера.
Каждый раз когда парсер разберает очередное правило он вызывает метод с тем же именем.
NToken это тупо два int'а. Позиция начала и позиция конца.
[PegGrammar(start,
grammar
{
any = ['\u0000'..'\uFFFF'];
digits = ['0'..'9']+;
s : void = ' '*;
num : int = digits s;
unaryMinus : int = '-'s simpleExpr;
parenthesesExpr : int = '('s sumOrSub ')'s;
simpleExpr : int = num / unaryMinus / parenthesesExpr;
mulOrDiv : int = simpleExpr (('*' / '/')s simpleExpr)*;
sumOrSub : int = mulOrDiv (('+' / '-')s mulOrDiv )*;
start : int = s sumOrSub !any;
})]
public class SimpleCalc
{
//Requred for parser -------------------------------------------------------------------------------------------- private num(digit : NToken) : int
{
int.Parse(GetText(digit))
}
private unaryMinus(_ : NToken, se : int) : int
{
-se
}
private parenthesesExpr(_ : NToken, se : int, _ : NToken) : int
{
se
}
private simpleExpr(se : int) : int
{
se
}
private start(se : int) : int
{
se
}
private mulOrDiv(se : int, lst : List[NToken * int]) : int
{
DoOpHelper(se, lst)
}
private sumOrSub(se : int, lst : List[NToken * int]) : int
{
DoOpHelper(se, lst)
}
//End requred for parser -------------------------------------------------------------------------------------------- private DoOpHelper(se : int, lst : List[NToken * int]) : int
{
def doOp(x : int, y : int, op : string) : int
{
match (op)
{
| "*" => x * y
| "/" => x / y
| "+" => x + y
| "-" => x - y
| _ => assert(false);
}
}
mutable result = se;
foreach ((opTok, value) in lst)
result = doOp(result, value, GetText(opTok));
result
}
}
В каком месте он "создает машинную команду"?
PD>Создает он ее путем заноса байтов в отдельную область или же она у него уже готовая есть — какое это значение имеет ?
Это показывает уровень твоего понимания.
WH>>Более умные интерпретаторы распознают текст один раз (ибо это очень медленно) и строят либо байткод либо AST и запускают интерпретацию уже по нему. PD>Смотря какие. Во времена Бейсика не было никакого байткода, а делалось именно это. Читал об этом еще лет 15 назад.
Прочитай выделенное.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Несомненно. Для этого и аргументировать не надо. Кстати. я и не говорил в этом топике ничего про быстродействие. Я тут обсуждал объем памяти. Мне тут упорно доказывали, что без десятков, а то и сотни Мб никак с этим js и программой на нем справиться невозможно. А вот это никакие хеш-таблицы не объяснят. Да, память под объект несколько увеличится, но лишь несколько, а не в сотню раз.
Эти мегабайты нужны для того чтобы избавится от хеш-таблиц.
По той ссылке что я тебе дал очень подробно рассказывается как конкретно это делается.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
WH>Вот простейший интерпретатор арифметических выражений:
И на кой ты привел этот текст на незнакомом мне языке ?
PD>>Создает он ее путем заноса байтов в отдельную область или же она у него уже готовая есть — какое это значение имеет ? WH>Это показывает уровень твоего понимания.
Ох...
Ну неужели надо объяснять, что на разных платформах реализации различны. В одном случае окажется более приемлемым иметь уже в памяти команду типа add и выполнить ее. В другом случае окажется разумнее сформировать некий кусок кода и передать на него управление с помощью чего-то вроде call. Ты готов категорически заявить, что ни в одном интерпретаторе бейсика ни на одной машине никогда такое не делалось ?
WH>>>Более умные интерпретаторы распознают текст один раз (ибо это очень медленно) и строят либо байткод либо AST и запускают интерпретацию уже по нему. PD>>Смотря какие. Во времена Бейсика не было никакого байткода, а делалось именно это. Читал об этом еще лет 15 назад. WH>Прочитай выделенное.
А, ну-ну. То есть то, что я назвал полукомпилятором, в твоей терминологии есть лишь более умный интерпретатор. Это, действительно, существенно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет. По очень простой причине — тут вообще затрат памяти на данные нет, потому что нет данных.
mutable RefPtr<NamedNodeMap> m_attributeMap;
PD>А данных я тут что-то не вижу, кроме DEFINE_ATTRIBUTE_EVENT_LISTENER, о котором не знаю, что это такое и каков его размер (думаю, что это указатель (как в MFC), а не описание функции).
это макрос, в результате будет как раз описание функции
PD>Может быть, данные у класса — родителя, не знаю, но для этого класса sizeof будет очень маленький.
данные есть у ContainerNode и Node, но там указатели, не стал смотреть что там с ними делается — в принципе, может быть сколько угодно памяти
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Нет. По очень простой причине — тут вообще затрат памяти на данные нет, потому что нет данных. A>
A>mutable RefPtr<NamedNodeMap> m_attributeMap;
A>
Виноват, не заметил. Но судя по RefPtr, скорее всего 4 байта.
PD>>А данных я тут что-то не вижу, кроме DEFINE_ATTRIBUTE_EVENT_LISTENER, о котором не знаю, что это такое и каков его размер (думаю, что это указатель (как в MFC), а не описание функции). A>это макрос, в результате будет как раз описание функции
Тогда он тут тоже ни при чем. Функции в sizeof не входят.
A>данные есть у ContainerNode и Node, но там указатели, не стал смотреть что там с ними делается — в принципе, может быть сколько угодно памяти
Я тоже смотреть не буду , но чтобы под указатель было выделено много памяти, надо чтобы он на массив показывал. А если он показывает на экземпляр другого класса — то мы к исходной ситуации возвращаемся. На структурах (а классы в конечном счете структуры) без массивов увеличить память серьезно можно только одним способом — резко увеличивая число этих структур, и не в разы, а на порядки.
Здравствуйте, мыщъх, Вы писали:
PD>>За год до этого была выпущена Windows 95, которая вполне успешно работала на 8 Мб ОП, PD>>а на 16 Мб чувствовала себя просто-таки великолепно. IE и NN там тоже чувствовали себя не плохо. М>требовала 4 мб. я ставил (путем танцев с бубном) на 3 с хвостиком. 8 метров можно было работать с несколькими приложениями.
Я ее тоже на 4 поставил, и она работала, как и обещала MS. Но смотреть на работу приложений под ней без слез было нельзя.
М>Google v8 движок js -- очень компактный, быстрый и может использоваться как отдельный язык программирования с терминальным вв никак не связанный с браузером. СпайдерМонки (который в горящем лисе) по сравнению с ним тормоз ужасный, но тоже как бы ничего. и тоже может использоваться как автономный движок. и памяти он потребляет мизер в общем зачете.
Прекрасно, а зачем тогда 100 Мб ? Я ведь не об этом движке говорил, а началось все с сообщения Владимира, где он отстаивал необходимость 100 Мб на вкладку в этом самом Хроме. Вот я и спросил зачем ? Если js тут ни при чем — отставим в сторону js, но вопрос останется. Если DOM тут ни при чем — отставим DOM, но вопрос все равно останется.
PD>>Не могли авторы языка в 1995 году закладывать в него или что-то с ним связанное с потребностью в 100 Мб. М>тем не менее заложили. не в сам язык, но в способ его сношения с браузером. попробуте написать свою реализацию и посмотрите во что она выливается.
Слушай, ну некорректный прием же. Ты прекрасно понимаешь, что я не напишу. Равно как я не сделаю самолет даже класса АН-24. Это что, не дает мне права рассуждать о его характеристиках ?
PD>>1. Этот инструмент использовали не по назначению. Ну все равно как взять какой-нибудь ДОС-овский бейсик и начать на нем решать задачи адронного коллайдера. М>это да. сравните накладные расходы на js и as, например. js выигрывает только на легковесных задачах, а используют его сейчас для всях монстров.
А если да, то это и означает, что пошли не тем путем. Значит, надо было js оставить его нишу образца 1996 года (простое управление броузером, всякие там window.open и history.goback , а для серьезных задач на стороне клиента в web-приложениях что-то иное использовать.
PD>>2. Все нормально, просто в 1995 этот язык придумали люди, которые умели писать как следует. М>вы все-таки возмите Google v8. и посмотрите хотя бы что там за тесты идут с ним. там и числодробилки и работа с массивами... причем, числодробилка, написанная на js, на v8 исполняется практически с той же скоростью как если бы она была написана на си. разница есть, конечно, но всего в несколько раз. даже не на порядок.
А с памятью как ? И потом в несколько раз — это уже серьезно. А на порядок — это неприемлемо. Это значит, что мы реально работает с машиной с тактовой не 3 GHz, а 300 MHz. 2000 год вместо 2010.
М>чистый js двиг написан умно и жрет мало памяти.
Готов поверить. Тогда кто там в хроме 100 Мб на вкладку жрет ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>1. Этот инструмент использовали не по назначению. Ну все равно как взять какой-нибудь ДОС-овский бейсик и начать на нем решать задачи адронного коллайдера. Тут сразу завопишь — сделайте мне, чтобы памяти было в 100 раз больше, чтобы скорость была в десятки раз больше, а то у меня расчет месяц занимает.
Конечно не по назначению.
У динамически типизированных языков предназначения нет.
Проблема в том что браузеры понимают только жабаскрипт.
Как следствие если хочешь на клиенте исполнить код то от жабаскрипта никуда не деться.
PD>2. Все нормально, просто в 1995 этот язык придумали люди, которые умели писать как следует.
Просто в 95ом оптимизировали по памяти забив на производительность, а сейчас оптимизируют по производительности забив на память ибо ее много.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Проблема в том что браузеры понимают только жабаскрипт. WH>Как следствие если хочешь на клиенте исполнить код то от жабаскрипта никуда не деться.
Это почему же? Скажем, GWT очень круто компилирует статически типизированную Java в JavaScript. Люди сейчас со Скалой экспериментируют.
PS: недавно всё-таки нашёл классный пример, когда динамика помогает — миграция структуры в БД. Загружается объект, аккуратно обрабатывается напильником, а потом сохраняется уже как объект другого класса.
Здравствуйте, WolfHound, Вы писали:
WH>Конечно не по назначению. WH>У динамически типизированных языков предназначения нет.
Если у них нет предназначения, то это может означать одно из двух. Либо они ни для чего не годятся (с этим ты не согласишься, да я это и не утверждаю), либо они годятся для любой задачи. Значит, надо js рекомендовать для адронного коллайдера
WH>Проблема в том что браузеры понимают только жабаскрипт. WH>Как следствие если хочешь на клиенте исполнить код то от жабаскрипта никуда не деться.
А браузер дан нам святым духом ? Кто мешал за эти 15 лет сделать так, чтобы он еще что-то понимать смог ?
PD>>2. Все нормально, просто в 1995 этот язык придумали люди, которые умели писать как следует. WH>Просто в 95ом оптимизировали по памяти забив на производительность, а сейчас оптимизируют по производительности забив на память ибо ее много.
Нет, не пойдет. Производительность просто по тактовой частоте увеличилась в 50 раз. Так что и без всякой оптимизации должно бы работать раз так в 20-30 быстрее. Ну а что касается памяти — я бы не возразил, если бы ее потребление увеличилось раз в 5-10, но вот в 100 — это просто перебор.
Кстати, маленькое замечание. Если серьезно увеличивать расходы памяти — растет время. Просто потому, что на обработку этой памяти оно потребно.
Вот тебе простой пример
int _tmain(int argc, _TCHAR* argv[])
{
DWORD dw1 = GetTickCount();
char* p = new char[100000000];
memset(p,0, 100000000);
DWORD dw2 = GetTickCount();
delete [] p;
printf("%d\n", dw2-dw1);
return 0;
}
На моей машине (Phenom 955 3.20 4 GB) — 47 мсек (Release). А в этом тесте я эти 100 Мб одним махом выделил и одним махом обнулил. А если я начну кусочками по 50-100 байт выделять и заносить туда по 4 байта ?
Здравствуйте, Pavel Dvorkin, Вы писали:
WH>>Вот простейший интерпретатор арифметических выражений: PD>И на кой ты привел этот текст на незнакомом мне языке ?
Выключи дурку.
Там все настолько просто что дальше некуда.
PD>Ну неужели надо объяснять, что на разных платформах реализации различны. В одном случае окажется более приемлемым иметь уже в памяти команду типа add и выполнить ее. В другом случае окажется разумнее сформировать некий кусок кода и передать на него управление с помощью чего-то вроде call. Ты готов категорически заявить, что ни в одном интерпретаторе бейсика ни на одной машине никогда такое не делалось ?
Читый интерпритатор накогда ничего не генерирует.
На то он и чистый.
PD>А, ну-ну. То есть то, что я назвал полукомпилятором, в твоей терминологии есть лишь более умный интерпретатор. Это, действительно, существенно.
1)Ты даже байткод от машинного кода отличить не можешь.
Вот тебе интерпритатор который сначала компилирует формулу в байткод, а потом исполняет ее. http://rsdn.ru/forum/alg/618399.1.aspx
2)Наивная генерация машинного кода интерпритатору динамически типизированного языка не поможет.
Ибо чтобы она ему помогла нужно избавляться от хештаблиц. А это задачка _очень_ не простая и жрет много памяти.
V8 именно этим и занимается.
И именно по этому жрет больше памяти.
И именно по этому рвет по производительности другие исполнялки жабоскрипта.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
WH>>Проблема в том что браузеры понимают только жабаскрипт. WH>>Как следствие если хочешь на клиенте исполнить код то от жабаскрипта никуда не деться. C>Это почему же? Скажем, GWT очень круто компилирует статически типизированную Java в JavaScript. Люди сейчас со Скалой экспериментируют.
И что после этого у тебя будет исполняться в браузере?
Короче читай внимательно то что пишут.
C>PS: недавно всё-таки нашёл классный пример, когда динамика помогает — миграция структуры в БД. Загружается объект, аккуратно обрабатывается напильником, а потом сохраняется уже как объект другого класса.
Мигрировать РДБ через ОРМ.
Жжжжжжжжжжжжжжжжжееееееееееесть.
Ща тебя IB увидят и
А с какой скоростью это все работает я даже представить боюсь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, мыщъх, Вы писали:
М>>Google v8 движок js -- очень компактный, быстрый и может использоваться как отдельный язык программирования с терминальным вв никак не связанный с браузером. СпайдерМонки (который в горящем лисе) по сравнению с ним тормоз ужасный, но тоже как бы ничего. и тоже может использоваться как автономный движок. и памяти он потребляет мизер в общем зачете.
PD>Прекрасно, а зачем тогда 100 Мб ?
а вот -- хз. в гугле вообще какой-то сандбокс встроили. он же теперь появился в акробате. криворукие потому что. писать не умеют, а потому чтобы хакеры не юзали дыры им теперь приходится пускать си++ код на эмуляторе. тут сейчас разбираем ошибку этих умников, которая тянется аж с 95 года. там типа вместо указателя p функции передавали указатель на указатель &p. и оно как-то работало. пока хакеры это не заюзали для порчи памяти строго дозированным образом на предмет передачи управления на хакерский код. а функция туда не только писала, она же его и освобождала. в смысле &p освобождала. а p так и болтался.
PD> Я ведь не об этом движке говорил, а началось все с сообщения Владимира, где он отстаивал необходимость 100 Мб на вкладку в этом самом Хроме. Вот я и спросил зачем ?
"для открытия страницы в 100 кб нужно памяти 100 мб" (с),
я тоже против такого отношения к памяти. если у меня стоит 4 гю, то это не значит, что ими можно разбрасываться. они у меня может для виртуалок стоят, а тут какому-то хрому отдай больше чем я выделяю целому серверу (виртуальному).
PD> Если js тут ни при чем — отставим в сторону js, но вопрос останется. Если DOM тут ни при чем — отставим DOM, но вопрос все равно останется.
куда конкретно уходит память -- тут нужно смотреть сорцы. могу сказать, что в js много не уходит. во всяком случае сам двиг не сильно прожорливый. разве что запускают кучу его копий...
PD>>>Не могли авторы языка в 1995 году закладывать в него или что-то с ним связанное с потребностью в 100 Мб. М>>тем не менее заложили. не в сам язык, но в способ его сношения с браузером. попробуте написать свою реализацию и посмотрите во что она выливается.
PD>Слушай, ну некорректный прием же. Ты прекрасно понимаешь, что я не напишу. Равно как я не сделаю самолет даже класса АН-24. Это что, не дает мне права рассуждать о его характеристиках ?
ну а я вот с апреля пишу свою реализацию там даже если заменить заглушками все, что можно ими заменить, все равно требуется уйма памяти...
PD>А если да, то это и означает, что пошли не тем путем. Значит, надо было js оставить его нишу образца 1996 года (простое управление броузером, всякие там window.open и history.goback , а для серьезных задач на стороне клиента в web-приложениях что-то иное использовать.
HTML вообще-то изначально был статичным. и попытки прикрутить к нему интерактивность как раз и породили скрипты. и теперь эти скрипты даже на главной странице гугла, где по хорошему только одна строка ввода
PD>>>2. Все нормально, просто в 1995 этот язык придумали люди, которые умели писать как следует. М>>вы все-таки возмите Google v8. и посмотрите хотя бы что там за тесты идут с ним. там и числодробилки и работа с массивами... причем, числодробилка, написанная на js, на v8 исполняется практически с той же скоростью как если бы она была написана на си. разница есть, конечно, но всего в несколько раз. даже не на порядок.
PD>А с памятью как ? И потом в несколько раз — это уже серьезно. А на порядок — это неприемлемо. Это значит, что мы реально работает с машиной с тактовой не 3 GHz, а 300 MHz. 2000 год вместо 2010.
если взять бейскик образца начала 90х, то у него по сравнению с компилируемыми языками разница будет в несколько порядков. но у меня был шок, когда я обнаружил, что на js можно написать то, что я раньше писал на си для реал-тайма и оно будет работать не сильно хуже, но вот писать уж точно проще.
М>>чистый js двиг написан умно и жрет мало памяти. PD>Готов поверить. Тогда кто там в хроме 100 Мб на вкладку жрет ?
хромом не пользуюсь. мне хватает что лис отъедает кучу памяти, а ведь у меня открыто совсем немного вкладок...
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, WolfHound, Вы писали:
WH>Выключи дурку. WH>Там все настолько просто что дальше некуда.
Слушай, тебя на конюшне или в дворницкой воспитывали ? Ты не мог бы более парламентские выражения выбирать ?
По сущесиву — я не читаю код на незнакомом мне языке и не комментирую его.
PD>>Ну неужели надо объяснять, что на разных платформах реализации различны. В одном случае окажется более приемлемым иметь уже в памяти команду типа add и выполнить ее. В другом случае окажется разумнее сформировать некий кусок кода и передать на него управление с помощью чего-то вроде call. Ты готов категорически заявить, что ни в одном интерпретаторе бейсика ни на одной машине никогда такое не делалось ? WH>Читый интерпритатор накогда ничего не генерирует. WH>На то он и чистый.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>чтобы под указатель было выделено много памяти, надо чтобы он на массив показывал
так вышеупомянутый RefPtr<NamedNodeMap> m_attributeMap как раз на массив и указывает
Здравствуйте, мыщъх, Вы писали:
PD>>Прекрасно, а зачем тогда 100 Мб ? М>а вот -- хз. в гугле вообще какой-то сандбокс встроили. он же теперь появился в акробате. криворукие потому что. писать не умеют,
Так а я о чем говорю!!!
>а потому чтобы хакеры не юзали дыры им теперь приходится пускать си++ код на эмуляторе
C++ на эмуляторе ??? Ну и ну!
PD>> Я ведь не об этом движке говорил, а началось все с сообщения Владимира, где он отстаивал необходимость 100 Мб на вкладку в этом самом Хроме. Вот я и спросил зачем ? М>"для открытия страницы в 100 кб нужно памяти 100 мб" (с), М>я тоже против такого отношения к памяти. если у меня стоит 4 гю, то это не значит, что ими можно разбрасываться. они у меня может для виртуалок стоят, а тут какому-то хрому отдай больше чем я выделяю целому серверу (виртуальному).
+1
М>куда конкретно уходит память -- тут нужно смотреть сорцы. могу сказать, что в js много не уходит. во всяком случае сам двиг не сильно прожорливый. разве что запускают кучу его копий...
Смотреть сорцы я не буду. Подождем, пока кто-нибудь ответит на этот вопрос. Может быть
PD>>А если да, то это и означает, что пошли не тем путем. Значит, надо было js оставить его нишу образца 1996 года (простое управление броузером, всякие там window.open и history.goback , а для серьезных задач на стороне клиента в web-приложениях что-то иное использовать. М>HTML вообще-то изначально был статичным. и попытки прикрутить к нему интерактивность как раз и породили скрипты. и теперь эти скрипты даже на главной странице гугла, где по хорошему только одна строка ввода
Именно! Взяли HTML, имевший назначением HyperText Markup, и не более, и сделали из него какую-то странную среду для выполнения всяких программ всякого рода. Ну и получили что заслужили.
PD>>А с памятью как ? И потом в несколько раз — это уже серьезно. А на порядок — это неприемлемо. Это значит, что мы реально работает с машиной с тактовой не 3 GHz, а 300 MHz. 2000 год вместо 2010.
М>если взять бейскик образца начала 90х, то у него по сравнению с компилируемыми языками разница будет в несколько порядков. но у меня был шок, когда я обнаружил, что на js можно написать то, что я раньше писал на си для реал-тайма и оно будет работать не сильно хуже, но вот писать уж точно проще.
Да я и не спорю, может, и есть такое. Я вообще не js обсуждаю. Меня 100 Мб интересуют
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Если у них нет предназначения, то это может означать одно из двух. Либо они ни для чего не годятся (с этим ты не согласишься, да я это и не утверждаю),
Я именно это и утверждаю.
Динамически типизированные языки вообще и жабаскрипт в частности унылое говно и ни для чего не годятся.
Но из-за каких то дебилов жабаскрипт стал стандартом в браузерах и приходится мучаться.
PD>А браузер дан нам святым духом ? Кто мешал за эти 15 лет сделать так, чтобы он еще что-то понимать смог ?
И ты иди попробуй уговорить всех (или хотябы пяток крупнейших) производителей браузеров поддержать что-то еще.
И это задачка простая.
Потом тебе придется еще уговорить переписать кучу сайтов которые используют жабаскрипт на это "еще что-то".
Дело осложняется тем что довольно долго придется поддерживать и "еще что-то" и жабаскрипт ибо пользователи не каждый день браузеры обновляют.
PD>Нет, не пойдет. Производительность просто по тактовой частоте увеличилась в 50 раз. Так что и без всякой оптимизации должно бы работать раз так в 20-30 быстрее.
А надо еще быстрее.
PD>Ну а что касается памяти — я бы не возразил, если бы ее потребление увеличилось раз в 5-10, но вот в 100 — это просто перебор.
Ты можешь протестовать сколько угодно но от этого ничего не изменится.
Если алгоритм требует в 100 раз больше памяти то вынь да полож.
PD>Кстати, маленькое замечание. Если серьезно увеличивать расходы памяти — растет время. Просто потому, что на обработку этой памяти оно потребно.
Спасибо тебе капитан очевидность.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>чтобы под указатель было выделено много памяти, надо чтобы он на массив показывал A>так вышеупомянутый RefPtr<NamedNodeMap> m_attributeMap как раз на массив и указывает
Вообще-то Map вряд ли массив, ну да ладно.
Но если массив — чему его размер равен? Как определяется ? Если, как я предполагаю, это map атрибутов, то сколько там этих атрибутов у ноды ? 10 ? Допускаю. 100 ? Тоже допускаю, но вряд и у всех нод столько атрибутов. 10000 ? Что-то плохо верится. А ведь 10000 атрибутов, да по 16 байт на атрибут — это лишь жалкие 160 (ну пусть 320) Кбайт.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Слушай, тебя на конюшне или в дворницкой воспитывали ? Ты не мог бы более парламентские выражения выбирать ?
Я предпочитаю объяснять просто и доходчиво.
PD>По сущесиву — я не читаю код на незнакомом мне языке и не комментирую его.
Я тебе дал ссылку на код на С++. Но ты и ее проигнорировал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Если у них нет предназначения, то это может означать одно из двух. Либо они ни для чего не годятся (с этим ты не согласишься, да я это и не утверждаю), WH>Я именно это и утверждаю. WH>Динамически типизированные языки вообще и жабаскрипт в частности унылое говно и ни для чего не годятся. WH>Но из-за каких то дебилов жабаскрипт стал стандартом в браузерах и приходится мучаться.
Нет, не полезу я в эту дискуссию. Во-первых, я не согласен с этим (он вполне годится как язык управления броузером), а во-вторых, мне просто эта дискуссия надоела. Пусть кто-нибудь другой тебе возразит из адептов этих языков, а мне-то что — я их не сторонник.
PD>>А браузер дан нам святым духом ? Кто мешал за эти 15 лет сделать так, чтобы он еще что-то понимать смог ? WH>И ты иди попробуй уговорить всех (или хотябы пяток крупнейших) производителей браузеров поддержать что-то еще.
А зачем мне их уговаривать ? Я просто констатирую факт — выбрав js в качестиве языка и броузер в качестве среды, они сели в лужу, потому что применили топор для создания ажуронй мебели. Или лобзик для постройки деревянного забора. Выбери сам сравнение, которое больше нравится.
WH>И это задачка простая. WH>Потом тебе придется еще уговорить переписать кучу сайтов которые используют жабаскрипт на это "еще что-то". WH>Дело осложняется тем что довольно долго придется поддерживать и "еще что-то" и жабаскрипт ибо пользователи не каждый день браузеры обновляют.
То есть скажем просто — 15 (или 10) лет назад было выбрано неправильное направление развития, и мы пожинаем плоды этого. Если бы полумали как следует, то js, конечно, остался бы для совместимости, но вспоминали бы о нем не больше, чем, скажем, в Delphi вспоминают об object. В курсе, о чем я написал ? Borland сначала сделала в TP ООП на базе object (более похоже на С++, то есть не ссылочная модель), а потом в Delphi ввела ссылочную модель (class). object никуда не делся, но только ветераны вроде меня о нем помнят
PD>>Нет, не пойдет. Производительность просто по тактовой частоте увеличилась в 50 раз. Так что и без всякой оптимизации должно бы работать раз так в 20-30 быстрее. WH>А надо еще быстрее.
Ну если надо автомобиль заставить летать, то , конечно, надо еще быстрее. Но лучше все же взять самолет.
PD>>Ну а что касается памяти — я бы не возразил, если бы ее потребление увеличилось раз в 5-10, но вот в 100 — это просто перебор. WH>Ты можешь протестовать сколько угодно но от этого ничего не изменится. WH>Если алгоритм требует в 100 раз больше памяти то вынь да полож.
Уф. Хоть одно место нашлось, где я могу с тобой согласиться. Если требует — вынь да положь. Если нужна bmp несжатая 10000*10000 — 400 Мб вынь да положь, и все разговоры о том, как бы ее целиком в ОП 1995 года разместить — в корзину.
Остается лишь малость — доказать, что требует. А вот в этом я не уверен.
PD>>Кстати, маленькое замечание. Если серьезно увеличивать расходы памяти — растет время. Просто потому, что на обработку этой памяти оно потребно. WH>Спасибо тебе капитан очевидность.
Не за что. Просто прими это к сведению, прежде чем уповать на гигабайты. А то можешь получить прямо противоположный эффект.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Слушай, тебя на конюшне или в дворницкой воспитывали ? Ты не мог бы более парламентские выражения выбирать ? WH>Я предпочитаю объяснять просто и доходчиво.
А хамить при этом обязательно ?
PD>>По сущесиву — я не читаю код на незнакомом мне языке и не комментирую его. WH>Я тебе дал ссылку на код на С++. Но ты и ее проигнорировал.
Я просто там ничего относящегося к делу там не нашел. Ну реализация калькулятора, ну в байт-код, ну и что ? Может, он и хороший, но какое отношение к делу имеет ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет, не полезу я в эту дискуссию. Во-первых, я не согласен с этим (он вполне годится как язык управления броузером), а во-вторых, мне просто эта дискуссия надоела. Пусть кто-нибудь другой тебе возразит из адептов этих языков, а мне-то что — я их не сторонник.
PD>А зачем мне их уговаривать ? Я просто констатирую факт — выбрав js в качестиве языка и броузер в качестве среды, они сели в лужу, потому что применили топор для создания ажуронй мебели. Или лобзик для постройки деревянного забора. Выбери сам сравнение, которое больше нравится.
Тебе не кажется что в этих двух абзацах ты противоречишь сам себе.
PD>То есть скажем просто — 15 (или 10) лет назад было выбрано неправильное направление развития, и мы пожинаем плоды этого.
Именно так.
PD>Если бы полумали как следует, то js,
Те кто умеет думать динамически типизируемый язык придумать не могут.
Динамическая типизация возникает из-за желания быстро наговнокодить не думая о долгосрочных последствиях.
PD>Ну если надо автомобиль заставить летать, то , конечно, надо еще быстрее. Но лучше все же взять самолет.
Браузеры не поддерживают самолет по тому что его не используют сайты.
Сайты не используют самолет по тому что его не поддерживают браузеры.
Фсе! Приплыли.
PD>Остается лишь малость — доказать, что требует. А вот в этом я не уверен.
Послушай лекцию узнаешь куда они память девают.
PD>Не за что. Просто прими это к сведению, прежде чем уповать на гигабайты. А то можешь получить прямо противоположный эффект.
Я уповаю исключетельно на измерения.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>Это почему же? Скажем, GWT очень круто компилирует статически типизированную Java в JavaScript. Люди сейчас со Скалой экспериментируют. WH>И что после этого у тебя будет исполняться в браузере?
А какая разница-то? Писать ведь можно вполне на статическом языке. А детали исполняющей виртуальной машины — уже не так важны.
C>>PS: недавно всё-таки нашёл классный пример, когда динамика помогает — миграция структуры в БД. Загружается объект, аккуратно обрабатывается напильником, а потом сохраняется уже как объект другого класса. WH>Мигрировать РДБ через ОРМ.
А чего бы и нет? Особенно, если во время миграции нужно проводить вычисления, которые в чистом SQL непредставимы. Понятно, что если миграция выражается в обычных update/alter table — их и надо использовать.
Вообще, мне стало интересно как это можно сделать на статических языках. Пока ничего хорошего не придумывается — нужно как-то менять тип объектов в рантайме. И что гораздо хуже, иметь несколько описаний одного типа ("старое" и "новое").
WH>Жжжжжжжжжжжжжжжжжееееееееееесть. WH>Ща тебя IB увидят и
Аааа!!!!
WH>А с какой скоростью это все работает я даже представить боюсь.
Вполне нормально для своей задачи.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Прекрасно, а зачем тогда 100 Мб ? Я ведь не об этом движке говорил, а началось все с сообщения Владимира, где он отстаивал необходимость 100 Мб на вкладку в этом самом Хроме.
100мб на все вкладки, а не на одну. Ты бы хоть иногда читал то.
Здравствуйте, Cyberax, Вы писали:
C>А какая разница-то? Писать ведь можно вполне на статическом языке. А детали исполняющей виртуальной машины — уже не так важны.
Огромная. Я писал про то что как ни крутись, а в конце концов будет исполняться жабаскрипт.
А так да. Писать можно и на статически типизированном языке. Только в этом случае лучше брать что-то более умное чем жабу.
Но в браузере всеравно будет работать жабаскрипт.
C>А чего бы и нет? Особенно, если во время миграции нужно проводить вычисления, которые в чистом SQL непредставимы.
И что это за вычисления такие?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>А чего бы и нет? Особенно, если во время миграции нужно проводить вычисления, которые в чистом SQL непредставимы. WH>И что это за вычисления такие?
Скажем, у меня были в БД только исходные данные для payroll'а, надо добавить результат их вычисления для того, чтобы по ним можно строить отчёт. Как ты понимаешь, вычисление payroll'а — это почти вся бизнес-логика. Запихнуть её в одни update не получится.
Или другой пример был, в поле "Company Name" было имя компании вместе с её адресом (слажали товарищи до меня). Нужно было во время миграции распихать его по полям. Можно было "распихиватель" сделать на SQL, но намного проще его написать было на Скале.
Здравствуйте, Cyberax, Вы писали:
C>Скажем, у меня были в БД только исходные данные для payroll'а, надо добавить результат их вычисления для того, чтобы по ним можно строить отчёт. Как ты понимаешь, вычисление payroll'а — это почти вся бизнес-логика. Запихнуть её в одни update не получится.
1)Не понимаю. Ибо не знаю что такое payroll.
2)Сваливать исходные данные и производные данные в одну кучу кривь.
C>Или другой пример был, в поле "Company Name" было имя компании вместе с её адресом (слажали товарищи до меня). Нужно было во время миграции распихать его по полям. Можно было "распихиватель" сделать на SQL, но намного проще его написать было на Скале.
Зачем тут динамическая типизация не понятно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>Скажем, у меня были в БД только исходные данные для payroll'а, надо добавить результат их вычисления для того, чтобы по ним можно строить отчёт. Как ты понимаешь, вычисление payroll'а — это почти вся бизнес-логика. Запихнуть её в одни update не получится. WH>1)Не понимаю. Ибо не знаю что такое payroll.
Грубо говоря — вычисление сколько тебе должны заплатить зарплаты. Для этого используется движек с кучей правил. В общем, в SQL непереводимо.
WH>2)Сваливать исходные данные и производные данные в одну кучу кривь.
Ну так а что делать?.. Другого выхода нет.
C>>Или другой пример был, в поле "Company Name" было имя компании вместе с её адресом (слажали товарищи до меня). Нужно было во время миграции распихать его по полям. Можно было "распихиватель" сделать на SQL, но намного проще его написать было на Скале. WH>Зачем тут динамическая типизация не понятно.
Ну вот я разрабатываю код в ветке. Сделал эту миграцию, теперь дальше работаю с новым классом, где нет поля CompanyNameAndAddress, а есть поля [Name, Address, Blackjack, Hookers]. Как мне представить это в коде? При том, что мне не хочется хранить две версии класса Company вечно.
Пока сделал тупо — код миграции откатывает все исходники на соответствующую git-версию (где есть переходный вариант класса с полями CompanyNameAndAddress и набором [Name, Address, Blackjack, Hookers]) и потом накладывает патч.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, WolfHound, Вы писали:
C>>>А чего бы и нет? Особенно, если во время миграции нужно проводить вычисления, которые в чистом SQL непредставимы. WH>>И что это за вычисления такие? C>Скажем, у меня были в БД только исходные данные для payroll'а, надо добавить результат их вычисления для того, чтобы по ним можно строить отчёт. Как ты понимаешь, вычисление payroll'а — это почти вся бизнес-логика. Запихнуть её в одни update не получится.
Это зависит от талантов пихающего. Учитывая полноту по тьюригну SQL DML во многих СУБД, то это вполне реально.
C>Или другой пример был, в поле "Company Name" было имя компании вместе с её адресом (слажали товарищи до меня). Нужно было во время миграции распихать его по полям. Можно было "распихиватель" сделать на SQL, но намного проще его написать было на Скале.
Для этого есть специальные инструменты. Я вот SSIS для MS SQL пользуюсь. Код приходилось писать ровно один раз.
Здравствуйте, gandjustas, Вы писали:
WH>>>И что это за вычисления такие? C>>Скажем, у меня были в БД только исходные данные для payroll'а, надо добавить результат их вычисления для того, чтобы по ним можно строить отчёт. Как ты понимаешь, вычисление payroll'а — это почти вся бизнес-логика. Запихнуть её в одни update не получится. G>Это зависит от талантов пихающего. Учитывая полноту по тьюригну SQL DML во многих СУБД, то это вполне реально.
Не, я понимаю, что всё приложение можно хоть на VisualBasic'е переписать. Но смысл? Код УЖЕ написан и прекрасно работает.
C>>Или другой пример был, в поле "Company Name" было имя компании вместе с её адресом (слажали товарищи до меня). Нужно было во время миграции распихать его по полям. Можно было "распихиватель" сделать на SQL, но намного проще его написать было на Скале. G>Для этого есть специальные инструменты. Я вот SSIS для MS SQL пользуюсь. Код приходилось писать ровно один раз.
Чем оно поможет?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
WH>>>>И что это за вычисления такие? C>>>Скажем, у меня были в БД только исходные данные для payroll'а, надо добавить результат их вычисления для того, чтобы по ним можно строить отчёт. Как ты понимаешь, вычисление payroll'а — это почти вся бизнес-логика. Запихнуть её в одни update не получится. G>>Это зависит от талантов пихающего. Учитывая полноту по тьюригну SQL DML во многих СУБД, то это вполне реально. C>Не, я понимаю, что всё приложение можно хоть на VisualBasic'е переписать. Но смысл? Код УЖЕ написан и прекрасно работает.
А стоило тогда начинать разговор? Всем ясно что рабочее приложение никто переписывать не будет, но это никак не доказывает что "запихнуть супер-логику в одни update не получится".
C>>>Или другой пример был, в поле "Company Name" было имя компании вместе с её адресом (слажали товарищи до меня). Нужно было во время миграции распихать его по полям. Можно было "распихиватель" сделать на SQL, но намного проще его написать было на Скале. G>>Для этого есть специальные инструменты. Я вот SSIS для MS SQL пользуюсь. Код приходилось писать ровно один раз. C>Чем оно поможет?
Такие инструменты предназначены в первую очередь для миграции данных. Поэтому описывать сценарии миграции, разделения и слияния потоков данных, обработки отдельных значений в них гораздо проще и есть куча встроенных инструментов.
Здравствуйте, gandjustas, Вы писали:
C>>Не, я понимаю, что всё приложение можно хоть на VisualBasic'е переписать. Но смысл? Код УЖЕ написан и прекрасно работает. G>А стоило тогда начинать разговор? Всем ясно что рабочее приложение никто переписывать не будет, но это никак не доказывает что "запихнуть супер-логику в одни update не получится".
Ну да, оно получится, если бизнес-логика реализована в БД. Что как бы логично.
G>>>Для этого есть специальные инструменты. Я вот SSIS для MS SQL пользуюсь. Код приходилось писать ровно один раз. C>>Чем оно поможет? G>Такие инструменты предназначены в первую очередь для миграции данных. Поэтому описывать сценарии миграции, разделения и слияния потоков данных, обработки отдельных значений в них гораздо проще и есть куча встроенных инструментов.
Не поможет. Там самая большая сложность была угадать как именно имя надо парсить.
I>Сравнить BC vs VC в одинаковых условиях тебе не помогает 640кб-религия
Чепуха какая-то. Что я должен сравнить — BC на старом процессоре и VC тоже на старом ? Так не будет он там работать. Или оба на новом ? Так я об этом и говорю, что скорость процессора возросла в десятки раз. И при чем тут 640 Кб ?
I>Ты даже TP супротив Дельфи боишься сравнить в одинаковых условиях, хотя чуть не в каждом сообщении вспоминаешь этот TP.
I>Поставь в виртуалках две системы — старую вындоус 95 и новую xp-32 c новым хромом.
I>Виртуалки нужны что бы сравнение было корректным, без виртуалки нынче 95-ку не запустить.
А зачем нужна 95-я ? Может, просто старый браузер запустить под W7, и дело с концом ? 95-я тот тут при чем ?
KV>Все сказанное выше — весьма неполная подборка проблем, которые должны решить те, кто занимается созданием современного браузера. Странно только, что это понимаю я, ни разу не программист, но не понимаешь ты. Я ведь даже не "разработчик языков программирования" я так, "пристально за ними наблюдающий" в лучшем случае.
Именно потому, что я программист, я это и понимаю. Понимаю, что не могли авторы языка в 1996 году создать его в расчете на необходимость 100 Мб, потому что и памяти такой даже в фантазии тогда не было. Понимаю, что язык отнюдь не самый сложный, даже если придется иметь дело со столь ужасной ситуацией, как недозагруженный текст (Для твоего сведения — любой однопроходной компилятор всегда имеет дело с этой ситуацией, так как просматривает код один раз и, стало быть, при его просмотре в некоем месте можно считать, что последующий код он еще не видел). Понимаю, что для компиляции чего бы то ни было размером в мегабайты исходного текста вполне хватало в старопрежние времена 1-2 Мб, и решительно не понимаю, что тут такого нового образовалось, что увеличивает потребности в сотню раз.
А вот если писать, руководствуясь принципом "память больше не ресурс", если в каждый объект добавлять по паре десятков байт на то, что , скорее всего, никому и не понадобится, если создавать эти объекты по принципу "зачем нам думать, как тут сэкономить, надо что-то еще — добавим новый объект, и дело с концом", если на базе небольшого js размером в 50-100 Кб соорудить некую структуру объектов с количеством под миллион — тогда, конечно, израсходовать 100 Мб не долго, и больше можно. Но вот это и есть нынешний дурной стиль программирования, когда любую проблему решают за счет памяти, вместо того, чтобы продумать алгоритмы и выбрать хорошую структуру данных.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Поставь в виртуалках две системы — старую вындоус 95 и новую xp-32 c новым хромом.
I>>Виртуалки нужны что бы сравнение было корректным, без виртуалки нынче 95-ку не запустить.
PD>А зачем нужна 95-я ? Может, просто старый браузер запустить под W7, и дело с концом ? 95-я тот тут при чем ?
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Сравнить BC vs VC в одинаковых условиях тебе не помогает 640кб-религия
PD>Чепуха какая-то. Что я должен сравнить — BC на старом процессоре и VC тоже на старом ?
Оба можно сравнить на новом.
>Так не будет он там работать. Или оба на новом ? Так я об этом и говорю, что скорость процессора возросла в десятки раз. И при чем тут 640 Кб ?
Оба на новом и по этой причине во сколько возросла скорость процессора не имеет значения.
Поскольку процессор одинаковый в обоих тестах, то следовательно разница в перформансе будет в основном из за JS (ну или BC vs VC, TP vs Delphi)
Такое ощущение, что ты вообще не представляешь, как сравнивать программы по перформансу.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да пусть хоть 100. Неужели ты не понимаешь, что добавляя скалярные поля, хоть 5, хоть десять, потребность в памяти можно увеличить тоже в 5 или 10 раз, а не в сотни и тысячи. Вот если ты 1000 полей добавишь — тогда да, но где ты их возьмешь ? А можно и не 1000 полей, а всего лишь один массив на 1000 элементов — тогда тоже да. Но вот это и будет расточительством памяти.
Вобщем есть хороший ответ — часовая лекция по JS V8 от разработчика Google.
I>Там нигде нет по 100 мб на вкладку.
>Павел, обрати внимание на понятия memory и virtual memory. Проведем простой эксперимент, откроем еще по одной вкладке почты и новостей:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Именно потому, что я программист, я это и понимаю. Понимаю, что не могли авторы языка в 1996 году создать его в расчете на необходимость 100 Мб, потому что и памяти такой даже в фантазии тогда не было. Понимаю, что язык отнюдь не самый сложный, даже если придется иметь дело со столь ужасной ситуацией, как недозагруженный текст (Для твоего сведения — любой однопроходной компилятор всегда имеет дело с этой ситуацией, так как просматривает код один раз и, стало быть, при его просмотре в некоем месте можно считать, что последующий код он еще не видел). Понимаю, что для компиляции чего бы то ни было размером в мегабайты исходного текста вполне хватало в старопрежние времена 1-2 Мб, и решительно не понимаю, что тут такого нового образовалось, что увеличивает потребности в сотню раз.
Ты и со студентами своими так же ведешь себя, ответ под носом а ты будешь доказывать что ответа нет ?
PD>А вот если писать, руководствуясь принципом "память больше не ресурс", если в каждый объект добавлять по паре десятков байт на то, что , скорее всего, никому и не понадобится, если создавать эти объекты по принципу "зачем нам думать, как тут сэкономить, надо что-то еще — добавим новый объект, и дело с концом", если на базе небольшого js размером в 50-100 Кб соорудить некую структуру объектов с количеством под миллион — тогда, конечно, израсходовать 100 Мб не долго, и больше можно. Но вот это и есть нынешний дурной стиль программирования, когда любую проблему решают за счет памяти, вместо того, чтобы продумать алгоритмы и выбрать хорошую структуру данных.
Ты хоть лекцию открой про JS V8 ?
Раз уж ты держишься за свой BC, то должен знать, что оный компилер создает для компиляции одного exe файла целую кучу вспомогательных файлов, объектных и тд и тд. При чем размер этого барахла в десятки раз больше результирующего файла.
JS V8 делает тоже самое, но уже в памяти.
Здравствуйте, Ikemefula, Вы писали:
I>Такое ощущение, что ты вообще не представляешь, как сравнивать программы по перформансу.
У меня такое ощущение, что ты меня упорно понять не хочешь. Я не сравниваю их по перфомансу. Я просто говорю, что старый BC на старом проце работал с вполне приличной скоростью. Так что если сохранить его технологию, то он должен на новом работать раз в 20-30 быстрее (конечно, если скорость лимитируется процессором, а не чем-то иным). Вот и все.
Здравствуйте, Ikemefula, Вы писали:
I>Ты и со студентами своими так же ведешь себя, ответ под носом а ты будешь доказывать что ответа нет ?
PD>>А вот если писать, руководствуясь принципом "память больше не ресурс", если в каждый объект добавлять по паре десятков байт на то, что , скорее всего, никому и не понадобится, если создавать эти объекты по принципу "зачем нам думать, как тут сэкономить, надо что-то еще — добавим новый объект, и дело с концом", если на базе небольшого js размером в 50-100 Кб соорудить некую структуру объектов с количеством под миллион — тогда, конечно, израсходовать 100 Мб не долго, и больше можно. Но вот это и есть нынешний дурной стиль программирования, когда любую проблему решают за счет памяти, вместо того, чтобы продумать алгоритмы и выбрать хорошую структуру данных.
I>Ты хоть лекцию открой про JS V8 ?
Я же писал, что не воспринимаю английский на слух.
I>Раз уж ты держишься за свой BC, то должен знать, что оный компилер создает для компиляции одного exe файла целую кучу вспомогательных файлов, объектных и тд и тд. При чем размер этого барахла в десятки раз больше результирующего файла.
Компилятор (хоть BC, хоть VC) не создает EXE. Не умеет он этого делать. Он компилирует .cpp и создает .obj. И не кучу, а 1 obj на 1 cpp. Это и есть его результирующий файл. А вот линкер берет эти obj да еще всякие lib и делает EXE.
I>JS V8 делает тоже самое, но уже в памяти.
А c ТурбоПаскалем ты знаком, нет ? У него режим был — все в памяти. На входе — .pas, результирующая программа создается прямо в ОП, никаких файлов вообще не создается. А компилировал прямо-таки с жуткой скоростью. И знаешь, сколько памяти нужно было первой версии TP ? 64 килобайта. На Ямахе именно столько памяти и было. Последняя версия TP (7.0) работала под DOS и ей хватало 640 Кб. Я в те времена вел кружок в школе, на машинах без винчестера, только 1.44 флоппи, тактовая 12 MHz, и он у меня прекрасно работал. Так-то!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Компилятор (хоть BC, хоть VC) не создает EXE. Не умеет он этого делать. Он компилирует .cpp и создает .obj. И не кучу, а 1 obj на 1 cpp. Это и есть его результирующий файл. А вот линкер берет эти obj да еще всякие lib и делает EXE.
а вот удержится ли BC (или TP, или ещё какой твой любимый компилятор) в рамках той же памяти и проца, если добавить в него whole program optimization?
и таки да, это было на тему кто какие obj берёт.
Здравствуйте, Antikrot, Вы писали:
A>а вот удержится ли BC (или TP, или ещё какой твой любимый компилятор) в рамках той же памяти и проца, если добавить в него whole program optimization?
Наверное нет, но я же и не предлагаю остаться в рамках 1 Мб.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>У меня такое ощущение, что ты меня упорно понять не хочешь. Я не сравниваю их по перфомансу. Я просто говорю, что старый BC на старом проце работал с вполне приличной скоростью.
Я не знаю что такое "приличная скорость". Я понимаю только простые, проверяемые вещи вроде
компиляние строчек в секунду
оптимизации которые умеет делать компилер
скорость работы скомпилированого кода
>Так что если сохранить его технологию, то он должен на новом работать раз в 20-30 быстрее (конечно, если скорость лимитируется процессором, а не чем-то иным). Вот и все.
Запусти свой BC но современном железе да проверь. Трудно что ли ?
Здравствуйте, Cyberax, Вы писали:
C>PS: недавно всё-таки нашёл классный пример, когда динамика помогает — миграция структуры в БД. Загружается объект, аккуратно обрабатывается напильником, а потом сохраняется уже как объект другого класса.
Что-то вроде такого?
(companyName, companyAddress) = splitNameAddress (company .!. companyNameAndAddress)
-- начинаем обработку напильником
company' = name .=. companyName .*. -- добавляем поле
address .=. companyAddress .*. -- и еще одно
company .-. companyNameAndAddress -- удаляем поле
Это расширяемые записи, HList. Все статическое, никакой динамики.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Ikemefula, Вы писали:
I>>Мне очень интересно, как ты запустишь IE3 на W7
PD>IE3 — никак, двум IE не жить, а вот Netscape Navigator 4.7 я под XP запускал.
IE3 ты вообще на XP не запустишь. А на современное железо win95 скорее всего вообще не поставишь.
Поэтому для сравнения в одинаковых условиях нужно взять обе системы поставить в виртуалки.
Здравствуйте, Pavel Dvorkin, Вы писали:
A>>а вот удержится ли BC (или TP, или ещё какой твой любимый компилятор) в рамках той же памяти и проца, если добавить в него whole program optimization?
PD>Наверное нет, но я же и не предлагаю остаться в рамках 1 Мб.
Здравствуйте, Ikemefula, Вы писали:
PD>>А c ТурбоПаскалем ты знаком, нет ? У него режим был — все в памяти. На входе — .pas, результирующая программа создается прямо в ОП, никаких файлов вообще не создается. А компилировал прямо-таки с жуткой скоростью. И знаешь, сколько памяти нужно было первой версии TP ? 64 килобайта. На Ямахе именно столько памяти и было. Последняя версия TP (7.0) работала под DOS и ей хватало 640 Кб. Я в те времена вел кружок в школе, на машинах без винчестера, только 1.44 флоппи, тактовая 12 MHz, и он у меня прекрасно работал. Так-то!
I>Правльно понимаю, в браузере используется аналог Turbo Pascal ?
Не понял. TP умел то, о чем я писал. То, что броузер является аналогом TP — этого я не утверждал.
I>Или же более мощный и динамический язык
Ну это еще большой вопрос, кто из этих языков более мощный. Ты уже однажды пытался сравнить по числу фич и проиграл.
>с GC
GC там точно не было, верно. Но он там и даром не нужен.
>+ кодогонерация в рантайме
Генерируйте, раз взялись интерпретировать. Компиляторы генерируют в компиле-тайм, а в рантайме потом только исполняется. И выходит ничуть не хуже.
> + DOM
Ты все же, может, приведешь оценки памяти (в численном выражении) для этого DOM ? Ты же мне не раз говорил о своем укреплении таблиц, но как речь заходит о количественных оценках — так сразу замолкаешь.
>+ CSS + Rendering
И что, на эти стили нужны десятки Мб ?
>+ многопоточность ?
Ух ты! Да. Побил ты меня. Напрочь побил. Не было в TP многопоточности. Посыпаю голову пеплом и признаю свою неправоту ровно на одну строчку этого сообщения.
А в этой строчке уже не признаю. Delphi 2(или 3, не помню, словом, первая 32-битная версия). была там многопоточность. И работала эта Delphi не то на 4, не то на 8 Мб физической памяти. И программа, ей сгенерированная, тоже десятки Мб не занимала, потому что их просто физически не было.
Ты хоть понимаешь, что потоки создает не js и не Delphi, а ядро Windows ? И для создания потока надо 1 Мб (по умолчанию) адресного пространства для стека потока (подчеркиваю, АП , а не памяти, памяти там выделяется по умолчанию 16 Кбайт для начала) + некая память в ядре под объекты ядра + копейки на tls-секции — а вот и все!
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Здравствуйте, kochetkov.vladimir, Вы писали:
PD>><skipped>
KV>Самое интересное находится в конце. Дочитай плс
Да читал я, читал.
PD>>Именно потому, что я программист, я это и понимаю.
KV>Не понимаешь. Либо лукавишь, не соглашаясь со мной, т.к. это взаимоисключающие друг-друга поведенческие модели
А можешь допустить, что понимаю по своему ?
PD>>Понимаю, что не могли авторы языка в 1996 году создать его в расчете на необходимость 100 Мб, потому что и памяти такой даже в фантазии тогда не было.
KV>Когда они создавали этот язык, он был не более чем средством сделать выпадающую менюшку или падающий на странице новогодний снег (с не более чем полусотней синхронно двигающихся снежинок, ибо иначе начинались жуткие тормоза).
Вот именно. И нечего его было применять для других целей.
>Разумеется, у них не хватило фантазии, чтобы понять, что через 15 лет этот язык будет использоваться в качестве полноценной codebehind на стороне клиента.
И нечего было его для этого использовать. Нетрудно понять, что для таких целей надо не интерпретатор использовать.
>Что на нем будет рисовать клиентские MVC-приложения и использовать его для доступа к DOM в стиле, более характерным для реляционных БД. Что появится HTML5 и CSS3 и на чистом javascript создадут практически полноценную реализацию проигрывателя флеш-роликов, например.
Объясни мне бога ради, для чего ты это говоришь. Вот взяли бы GW-Basic и начали на нем для расчеты для Саяно-Шушенской ГЭС проводить. И разросся бы он до 500 Мб, и все равно работал бы медленно. И кто тут виновать — автор языка Бейсик или те, кто его использовали для совсем неподходящих задач ?
KV>Язык за это время практические не изменился, лишь "чуть-чуть" расширилась его предметная область, чем и обуславливаются столь высокие требования к его производительности.
Ну да. Расчеты энергосистемы Саяно-Шушенской ГЭС в принципе похожи на расчеты напряжений и тока в моей квартире. Чуть-чуть расширилась область, всего лишь.
PD>>Понимаю, что язык отнюдь не самый сложный, даже если придется иметь дело со столь ужасной ситуацией, как недозагруженный текст (Для твоего сведения — любой однопроходной компилятор всегда имеет дело с этой ситуацией, так как просматривает код один раз и, стало быть, при его просмотре в некоем месте можно считать, что последующий код он еще не видел).
KV>При чем тут однопроходный компилятор? Он прямо во время прохода создает описываемые кодом объекты в куче? Изменяет их свойства? Вызывает их методы?
Эх, не программист ты. Ну создает. Ну вызывает. И что ? Что ? На то, чтобы создать — хоть во время прохода, хоть потом — надо sizeof(структуры). Чтобы изменить — надо функцию вызвать. Скажи на милость, почему это вдруг требует в десятки раз больше памяти, чем если бы сначала создать код, а потом выполнить ? Ну дам тебе еще память под исходный текст (при компиляции его нет), так это копейки. Что за проблемы-то ?
PD>>А вот если писать, руководствуясь принципом "память больше не ресурс",
KV>Павел не надо спекулировать этой цитатой, оставь это местным троллям. Изначально, озвученная на RSDN в статье Игоря (http://www.rsdn.ru/article/dotnet/GCnet.xml
), эта фраза означала, что память в .NET не является тем ресурсом, который необходимо явно выделять и следить за его освобождением. А уже местные доброжелатели, выдернув ее из контекста, стали размахивать ей как флагом, крича, что дотнетчики не собираются экономить драгоценную память и уповают лишь на всемогущий GC.
А я тут при чем ? Не я это придумал. Я просто вижу, что эти самые дотнетчики, чуть что, начинают укреплять таблицы, добавлялл десятки Мб памяти, и руководствуются при этом именно этим принципом. А что там Игорь изначально имел в виду — это его дело. Благими намерениями...
KV>Тем не менее, и .NET не избавляет от необходимости разумно подходить к вопросам использования памяти и держать в уме особенности реализации как GC, так и структур данных, но делает этот процесс легким и непринужденным, в отличии от.
Если бы они и впрямь разумно подходили — так у них расходы памяти и были бы такими же, как в С++. С чего ей расти-то ? Правда, при одном условии — без LinQ. Тут расти будет обязательно — если каждый раз новую структуру создавать вместо того, чтобы старую модифицировать, то без расходов памяти не обойдется.
А они обрадовались и вперед. Смотрю я порой на решения, и мне просто страшно становится.
KV>Попробуй открыть эксперимент, описанный по ссылке (http://www.chromeexperiments.com/detail/magnetic/) сначала в IE9 или FF3, а потом в хроме. Сразу поймешь, зачем в нем создаются все эти объекты.
Да пойму, наверное. Не в этом же вопрос, а в совсем другом — а написать так, чтобы без такого объема памяти обойтись, можно ? Или в принципе нельзя ?
Вот ответь мне прямо, недвусмысленно и честно на такой вопрос. Пофантазируем.
2000 год. Увеличение объема памяти и быстродействия процессора прекратилось. Ядра не были созданы. Лучшая машина — Pentium III — 667 MHz (у меня была тогда). Все.
Ты готов заявить, что невозможно было бы создать ничего , равного по возможностям нынешним сайтам ? Ты готов утверждать, что при 256 Мб Google map или GMail никогда не мог бы быть создан ? Вот скажи прямо — да или нет. Без пояснений. 1 бит.
KV>Память — самый дешевый из ресурсов, доступных десктоп-программисту в настоящий момент. Хром появился именно в результате выделенного. Видишь ли, его разработчики не хотели потерять значительную часть своих потенциальных пользователей, которые бы умерли есстественной смертью дожидаясь, пока разработчики наиграются в оптимизации по памяти перед выпуском своего продукта.
Вот именно. Это и есть основной пункт. Вместо качественного написания кода превалирует халтура, потому что халтуру делать быстрее, и можно перехватить часть рынка. Я не спорю, это серьезный аргумент. Но, кроме вопросов рынка и маркетинга, есть еще и технология как таковая. Вытекающая из теории алгоритмов и структур данных. И вот то, что все делалется в ущерб ей, означает, что технология профанируется и дискредитируется. А это даром не пройдет.
>Затраты памяти существенно уменьшились с момента выхода первого релиза хрома.
Ну слава богу
>Я помню тред в гугл-группе о том, как хром с несколькими вкладками отожрал у какого-то чела полтора гига. Можешь себе представить, насколько оптимизирован код в нынешней, 7-ой версии это браузера?
Могу. Делаем автомобиль размером в Боинг-747. Он ездит, распугивая всех на дорогах и не вписывается в повороты. После чего уменьшаем его размеры до Боинга-737 и с гордостью говорим — какие мы молодцы. Он, правда, по прежнему в повороты не вписывается, но хоть не настолько всех пугает.
PD>>Вот и все.
KV>Нет, не все. Давай напоследок, я подкину тебе очень богатую пищу для размышлений? Каким браузером пользуешься ты? Насколько я помню — IE8.
IE8 и Лиса.
>Он устраивает тебя по затратам памяти? Думаю, что устраивает, иначе — зачем тебе им пользоваться?
Устраивает. А вот аргумент твой — нет. Предположим, что не устраивает — что же мне делать ? Все равно придется пользоваться — где я броузер возьму с потребностью по памяти в 10 раз меньше, если бы мне это надо было ? Например, VS меня радикально не устраивает ни по скорости ее работы (IDE, не компилятора), ни по памяти. Но чем я ее заменю ?
>А скорее всего, ты и не задумывался над этим вопросом: работает, ну и работает.
Задумывался. Тормозит он хорошо в самых разных ситуациях. Создает черт знает зачем несколько процессов iexplore.exe, так что когда какое-то окно виснет, я сижу и думаю — какой iexplore убить ? И т.д.
>Главное ведь чтобы хорошо работал и давал тебе комфорт при посещении сайтов, так?
Да. И не отнимал лишней памяти и не устраивал ненужный свопинг.
>А ты знаешь, что IE8 реализует мультипроцессную модель, во многом схожую с хромовской?
Догадываюсь. См. выше.
>Вообще говоря, в настоящий момент, IE является вторым по защищенности браузером, несмотря на сложившиеся стереотипы.
Спорить о защищенности с тобой я не буду, мы явно в разных весовых тут категориях. Отмечу лишь, что защищенность защищенности рознь, и мне не нужна защищенность любой ценой. Я очень хочу личной защищенности, но если мне для этого предложат не выходить из дома, закрыть окна кирпичной стенкой, поставить на входную дверь минное поле, отключить газ и электричество, то я на такую защищенность не согласен.
>Тебя еще не смущает, что в нем применяется тот же подход к защите, что и в хроме? До этого момента, думаю, что не смущал, поэтому предлагаю провести простой эксперимент: давай возьмем 4 совершенно голых бразуера (без установленных плагинов и расширений, там где есть предустановленные — выключим нафиг), откроем в них две вкладки — одну с gmail, вторую с google reader и посмотрим как они поведут себя по отношению к затраченной памяти? Готов это увидеть? Voila: http://files.rsdn.ru/24665/browsers_memory.png
А с чего ты решил, что я этот IE защищаю в противовес Хрому ? Мне они оба равно приятны или неприятны. Памяти оба жрут достаточно, ну а насчет качества исполнения — не знаю, IE при всем том. что я писал, меня относительно устраивает, за неимением лучшего.
KV>Не кажется ли тебе, что проблема все же не в криворукости разработчиков браузеров, а во всех этих ваших консерваториях?
>>Так что если сохранить его технологию, то он должен на новом работать раз в 20-30 быстрее (конечно, если скорость лимитируется процессором, а не чем-то иным). Вот и все.
I>Запусти свой BC но современном железе да проверь. Трудно что ли ?
Что проверить-то ? Скорость его компиляции на современном железе против компиляции на 386DX-40 ? Где я ее возьму ?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
A>>>а вот удержится ли BC (или TP, или ещё какой твой любимый компилятор) в рамках той же памяти и проца, если добавить в него whole program optimization?
PD>>Наверное нет, но я же и не предлагаю остаться в рамках 1 Мб.
I>Начни с википедии, если ты английский не знаешь
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну это еще большой вопрос, кто из этих языков более мощный. Ты уже однажды пытался сравнить по числу фич и проиграл.
Дельфи мы взяли потому, что не было сравнительной инфы по TP и вместо TP взяли Дельфи — там есть все что есть в TP.
Итого — JS проиграл со счетом 27 — 33
Далее необходимо было вычеркнуть пункты, которые отсутствовали у TP и вот здесь ты полез в бутылку.
А между тем, TP не умеет шаблоны, информацию о типах в рантайме, исключения, динамические массивы, foreach, проперти, интерфейсы, анонимные функции, первоклассные функции, перегрузку, значения по умолчанию — всего 11 шт
Итого — TP проигрывает Delphi со счетом 22-33 и проигрывает JS со счетм 22-27.
PD>Генерируйте, раз взялись интерпретировать. Компиляторы генерируют в компиле-тайм, а в рантайме потом только исполняется. И выходит ничуть не хуже.
Компиляция в компайл-тайм очень медленная. За счет чего ее можно ускорить в рантайме ?
>PD>Ты все же, может, приведешь оценки памяти (в численном выражении) для этого DOM ? Ты же мне не раз говорил о своем укреплении таблиц, но как речь заходит о количественных оценках — так сразу замолкаешь.
Чисто для DOM без контента, CSS, рендеринга формула получается такая
размер контента + (32 + m*8 + a*12 + t*32 + e*4) * выравнивание * перерасход из за хеш-мап.
m — кол-во методов, a-кол.во аттрибутов, t-вложеных тегов, e-эвентов.
выравнивание — 2..4 раза, перерасход из за хешмапов — 1.5..2 раза.
Вобщем типичный объект в моем случае занимает около 1-2кб не считая контента.
То есть DOM-модель ест памяти в 10-100 раз больше чем размер текста которым она описывается.
>>+ CSS + Rendering
PD>И что, на эти стили нужны десятки Мб ?
>>+ многопоточность ?
PD>Ух ты! Да. Побил ты меня. Напрочь побил. Не было в TP многопоточности. Посыпаю голову пеплом и признаю свою неправоту ровно на одну строчку этого сообщения. PD>А в этой строчке уже не признаю. Delphi 2(или 3, не помню, словом, первая 32-битная версия). была там многопоточность. И работала эта Delphi не то на 4, не то на 8 Мб физической памяти. И программа, ей сгенерированная, тоже десятки Мб не занимала, потому что их просто физически не было.
PD>Ты хоть понимаешь, что потоки создает не js и не Delphi, а ядро Windows ? И для создания потока надо 1 Мб (по умолчанию) адресного пространства для стека потока (подчеркиваю, АП , а не памяти, памяти там выделяется по умолчанию 16 Кбайт для начала) + некая память в ядре под объекты ядра + копейки на tls-секции — а вот и все!
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Запусти свой BC но современном железе да проверь. Трудно что ли ?
PD>Что проверить-то ? Скорость его компиляции на современном железе против компиляции на 386DX-40 ? Где я ее возьму ?
Сравнить скорость работы BC и VC на ОДНОМ И ТОМ ЖЕ ЖЕЛЕЗЕ. У BC по моему был режим 32 бита — вот его и заюзать.
Сравнивается BC против VС, то есть влияние процессора свести к минимуму.
Ты можешь ответить, какой смысл сравнивать BC(VC) сейчас и BC на 386DX-40 ? Ты так и не рассказал, что за результат получится и как его использовать.
А сравнивая в одинаковых условиях можно выяснить например улучшения в скорости компиляции, качестве генерируемого кода и так далее.
Например, запустив BC и VC на современном Core2Duo (или i3,i5,i7) и получив одинаковые результаты можно говорить о том, что прогресса за 15 лет не было.
Или если получим превосходство BC стало быть имеет место деградация вместо прогресса.
А если будет превосходство VC, стало быть окажется что ты рассказывал сказки да байки всякие.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Ну это еще большой вопрос, кто из этих языков более мощный. Ты уже однажды пытался сравнить по числу фич и проиграл.
I>Дельфи мы взяли потому, что не было сравнительной инфы по TP и вместо TP взяли Дельфи — там есть все что есть в TP.
I>Итого — JS проиграл со счетом 27 — 33
I>Далее необходимо было вычеркнуть пункты, которые отсутствовали у TP и вот здесь ты полез в бутылку.
Ну если вычеркнуть то, чего нет в JS, то из JS надо вычеркнуть то, чего нет в Delphi
I>А между тем, TP не умеет шаблоны
Этого нет, верно.
>информацию о типах в рантайме
Есть, хот и примитивно. typeof.
>исключения
Не помню. В delphi-32 точно есть.
>динамические массивы
Есть.
>foreach, проперти
Я с помощью for не смогу сделать то же, что с foreach ? полумаешь, достижение из Visual Basic
>интерфейсы
Ну это как сказать. Поинтересуйся, как в Delphi c COM работают.
>анонимные функции
Слава богу, нет.
>первоклассные функции
Этих я и не знаю.
>перегрузку
С чего это нет ? Там нормальное ООП было, со всеми его причиндалами.
>значения по умолчанию
Вот этого в Паскале не было никогда. Но гордиться тут нечем — мелочь это и пустяк. В С++ есть.
I>Итого — TP проигрывает Delphi со счетом 22-33 и проигрывает JS со счетм 22-27.
I>Компиляция в компайл-тайм очень медленная.
С чего это она очень медленная ? Ты бы на TP посмотрел, как он компилировал, и на Delphi тоже. Да и с С++ компиляторы отнюдь не медленные.
>За счет чего ее можно ускорить в рантайме ?
Ни за счет чего. Нечего ее туда переносить.
>>PD>Ты все же, может, приведешь оценки памяти (в численном выражении) для этого DOM ? Ты же мне не раз говорил о своем укреплении таблиц, но как речь заходит о количественных оценках — так сразу замолкаешь.
I>Чисто для DOM без контента, CSS, рендеринга формула получается такая
I>размер контента + (32 + m*8 + a*12 + t*32 + e*4) * выравнивание * перерасход из за хеш-мап.
I>m — кол-во методов, a-кол.во аттрибутов, t-вложеных тегов, e-эвентов.
I>Вобщем типичный объект в моем случае занимает около 1-2кб не считая контента.
Вот с этим совершенно согласен. Более того, я предполагал, что будет больше. Я рассчитывал примерно на 4-5.
I>То есть DOM-модель ест памяти в 10-100 раз больше чем размер текста которым она описывается.
Несомненно. Но при размере в 2 Кб на элемент и тысяче элементов (с тегами, ивентами и атрибутами) — всего лишь 2 Мб.
У тебя там что, миллион элементов ? Если да — сниму свои возражения, но это просто будет значить, что у тебя огромный размер данных. Против такого я не возражаю. Если есть картинка 10000*10000 — давай сюда 400 Мб , и без разговоров (сжатие не рассматриваем). Но ты же мне говорил, что исходных данных совсем немного.
PD>>Ух ты! Да. Побил ты меня. Напрочь побил. Не было в TP многопоточности. Посыпаю голову пеплом и признаю свою неправоту ровно на одну строчку этого сообщения. PD>>А в этой строчке уже не признаю. Delphi 2(или 3, не помню, словом, первая 32-битная версия). была там многопоточность. И работала эта Delphi не то на 4, не то на 8 Мб физической памяти. И программа, ей сгенерированная, тоже десятки Мб не занимала, потому что их просто физически не было.
PD>>Ты хоть понимаешь, что потоки создает не js и не Delphi, а ядро Windows ? И для создания потока надо 1 Мб (по умолчанию) адресного пространства для стека потока (подчеркиваю, АП , а не памяти, памяти там выделяется по умолчанию 16 Кбайт для начала) + некая память в ядре под объекты ядра + копейки на tls-секции — а вот и все!
С этим, как я понимаю, ты согласился ? Или просто забыл ответить ?
А вообще-то пора кончать эту дискуссию ? За тобой последнее слово
I>Сравнить скорость работы BC и VC на ОДНОМ И ТОМ ЖЕ ЖЕЛЕЗЕ. У BC по моему был режим 32 бита — вот его и заюзать.
Не было у BC 3.1, был только начиная с 4.0. У меня их нет.
I>Сравнивается BC против VС, то есть влияние процессора свести к минимуму.
I>Ты можешь ответить, какой смысл сравнивать BC(VC) сейчас и BC на 386DX-40 ?
Ты так и не рассказал, что за результат получится и как его использовать.
Определить, насколько быстрее стала компиляция.
I>А сравнивая в одинаковых условиях можно выяснить например улучшения в скорости компиляции, качестве генерируемого кода и так далее.
Ну насчет качества — тут надо программы для сравнения и скать, и не имеет это отношения к скорости компиляции.
I>Например, запустив BC и VC на современном Core2Duo (или i3,i5,i7) и получив одинаковые результаты можно говорить о том, что прогресса за 15 лет не было.
Одинаковые результаты чего ? Скорости компиляции ? Выполнения ?
I>А если будет превосходство VC, стало быть окажется что ты рассказывал сказки да байки всякие.
Так чего превосходство-то ? Скорости исполняемой программы ? Я это не обсуждал и не сравнивал. Скорости компиляции ? Бессмысленно — BC все же не использует более 4 Мб. Вот сравнить, насколько BC быстрее компилирует на Duo, чем на 386 — можно было бы, если бы 386 был в наличии.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Далее необходимо было вычеркнуть пункты, которые отсутствовали у TP и вот здесь ты полез в бутылку.
PD>Ну если вычеркнуть то, чего нет в JS, то из JS надо вычеркнуть то, чего нет в Delphi
Нет, из JS ничего не надо вычеркивать. А результат по TP получается из результата по Дельфи за вычетом новых фич.
I>>А между тем, TP не умеет шаблоны
PD>Этого нет, верно.
>>информацию о типах в рантайме
PD>Есть, хот и примитивно. typeof.
Это отстой а не рантайм
>>исключения
PD>Не помню. В delphi-32 точно есть.
>>динамические массивы
PD>Есть.
Нет.
>>foreach, проперти
PD>Я с помощью for не смогу сделать то же, что с foreach ? полумаешь, достижение из Visual Basic
foreach это очень сильная вещь.
>>интерфейсы
PD>Ну это как сказать. Поинтересуйся, как в Delphi c COM работают.
В TP интерфейсов нет.
>>анонимные функции
PD>Слава богу, нет.
>>первоклассные функции
PD>Этих я и не знаю.
>>перегрузку
PD>С чего это нет ? Там нормальное ООП было, со всеми его причиндалами.
Чушь. В TP нет перегрузки.
>>значения по умолчанию
PD>Вот этого в Паскале не было никогда. Но гордиться тут нечем — мелочь это и пустяк. В С++ есть.
I>>Итого — TP проигрывает Delphi со счетом 22-33 и проигрывает JS со счетм 22-27.
PD>
Представь себе — TP это действительно каменный век и сравнение с JS это однозначно показывает.
I>>Вобщем типичный объект в моем случае занимает около 1-2кб не считая контента.
PD>Вот с этим совершенно согласен. Более того, я предполагал, что будет больше. Я рассчитывал примерно на 4-5.
Если ты предполагал 4-5кб, то должен был понимать, что для современных страниц это будет от 4-5 до 20-25 мб и это только на DOM.
I>>То есть DOM-модель ест памяти в 10-100 раз больше чем размер текста которым она описывается.
PD>Несомненно. Но при размере в 2 Кб на элемент и тысяче элементов (с тегами, ивентами и атрибутами) — всего лишь 2 Мб.
Ты всего то ошибся на порядок-другой, вот и всё. А тысяча элементов — это вобщем то не много для нынешних страниц.
PD>>>Ты хоть понимаешь, что потоки создает не js и не Delphi, а ядро Windows ?
>ЮИ для создания потока надо 1 Мб (по умолчанию) адресного пространства для стека потока (подчеркиваю, АП , а не памяти, памяти там выделяется по умолчанию 16 Кбайт для начала) + некая память в ядре под объекты ядра + копейки на tls-секции — а вот и все!
Нет, не все. Многопоточная работа это увеличение потребления памяти объектами в виде кода и доп. структур.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Сравнивается BC против VС, то есть влияние процессора свести к минимуму.
I>>Ты можешь ответить, какой смысл сравнивать BC(VC) сейчас и BC на 386DX-40 ? PD>Ты так и не рассказал, что за результат получится и как его использовать.
PD>Определить, насколько быстрее стала компиляция.
Для этого надо исключить влияние других факторов, как разница в процессорах. В противном случае получится неизвестно что.
I>>А сравнивая в одинаковых условиях можно выяснить например улучшения в скорости компиляции, качестве генерируемого кода и так далее. PD>Ну насчет качества — тут надо программы для сравнения и скать, и не имеет это отношения к скорости компиляции.
Не надо никаких программ. Скармливаешь одну и ту же либу двум компилерам и пусть компиляют в цикле сутки, потом сравнить кол.во проходов
I>>Например, запустив BC и VC на современном Core2Duo (или i3,i5,i7) и получив одинаковые результаты можно говорить о том, что прогресса за 15 лет не было.
PD>Одинаковые результаты чего ? Скорости компиляции ? Выполнения ?
Для начала с компиляцией разоброаться. А качество генерируемого кода проверить гораздо проще.
I>>А если будет превосходство VC, стало быть окажется что ты рассказывал сказки да байки всякие.
PD>Так чего превосходство-то ? Скорости исполняемой программы ? Я это не обсуждал и не сравнивал. Скорости компиляции ? Бессмысленно — BC все же не использует более 4 Мб. Вот сравнить, насколько BC быстрее компилирует на Duo, чем на 386 — можно было бы, если бы 386 был в наличии.
Ну получишь ты, скажем, N раз. Что тебе это даст ? Все равно нужно сравнение с VC в тех же условиях, что бы выяснить, есть ли прогресс.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Но вообще, я бы предложил не развивать эту тему. Дело в том, что я сегодня проходил ежедгодный профосмотр, а параллельно делал себе справку, чтобы продлить водительские права. И вот там, психиатр доумился спросить у меня, считаю ли я себя нормальным. Поскольку через минут 10 меня грубо прервали, вписали мне практически насильно "здоров" и попросили выйти — я не наговорился и чувствую в себе неудовлетворенное желание до конца развить мысли, которые мне так и не дали высказать
Принято
KV>Погоди. Я нигде не утверждал, что применение яваскрипта в тех задачах, в которых его используют сейчас на клиентской стороне, сколь-нибудь оправдано с технической т.з. Здесь, я склонен согласиться с Wolfhound'ом, использование статического языка может дать серьезный выигрыш как в плане скорости разработки и быстродействия, так и в плане затрат памяти. Не думай, что никто не чешется по этому поводу, буквально в этом году где-то здесь проскакивала ссылка об инициативе по выработке стандарта для облегчения процесса встраивания скриптов на других языках в HTML-документы. Но этот рынок — как маховик, его очень трудно раскрутить, чтобы заставить вращаться. Гуглу вон, пришлось целый браузер разработать, чтобы HTML5 попер в массы (несмотря на то, что пионерами тут пытались выступить эпплы). Но рано или поздно это наступит. А пока, разработчики сайтов вынуждены принимать во внимание тот факт, что js — это единственный язык, скрипты на котором гарантировано запустятся в любом современном браузере. А разработчики браузеров не спешат с революцией, т.к. подводных камней при переходе на статику там будет более чем достаточно, а терять свою долю рынка никто не хочет.
+1. Но см. то, что я писал — повторяться не буду.
KV>Зато сейчас, мы имеем возможность наблюдать за тем, как из динамического языка выжимается все возможное. Даже то, что еще несколько лет назад считалось невозможным. Это — тоже ценный опыт, между прочим
Вот с этим не согласен. Нечего из Антилопы-Гну выжимать, Тойоту делать надо.
KV>>>При чем тут однопроходный компилятор? Он прямо во время прохода создает описываемые кодом объекты в куче? Изменяет их свойства? Вызывает их методы?
PD>>Эх, не программист ты. Ну создает. Ну вызывает. И что ? Что ? На то, чтобы создать — хоть во время прохода, хоть потом — надо sizeof(структуры).
KV>У тебя не будет этого sizeof на данном этапе, в общем случае. Оно появится только в рантайме.
Я тебя не понимаю. Да, конечно, в рантайме. Что, от этого его величина изменится ? Что ты так на рантайм упираешь ? Ну идет в рантайме компиляция вместе с выполнением. Ну в худшем случае это значит, что нужна память для компилятора и рабочей программы. Это еще TP умел на 1 Мб, и без всякой интерпретации. Да, не было там многого, но многое и было. На 1 Мб.
PD>>Чтобы изменить — надо функцию вызвать. Скажи на милость, почему это вдруг требует в десятки раз больше памяти, чем если бы сначала создать код, а потом выполнить?
KV>Ты (в смысле не ты, а компилятор) практически ничего не знаешь о типах объектов на этапе компиляции.
О черт! Ну не знаю, и что ? Откомпилирую — узнаю. Что от этого изменится-то ? Ты так говоришь, как будто между компиляцией и исполнением какой-то потусторонний мир стоит. Ну есть там объект, какого типа — черт знает. Ну дали ему тип, то есть поставили ему указатель на объект типа "тип". Ну вот теперь и ясно, какого он типа сейчас. Потом другого станет Что за проблема-то ?
PD>>А я тут при чем ? Не я это придумал. Я просто вижу, что эти самые дотнетчики, чуть что, начинают укреплять таблицы, добавлялл десятки Мб памяти, и руководствуются при этом именно этим принципом. А что там Игорь изначально имел в виду — это его дело. Благими намерениями... PD>>Если бы они и впрямь разумно подходили — так у них расходы памяти и были бы такими же, как в С++. С чего ей расти-то ? Правда, при одном условии — без LinQ. Тут расти будет обязательно — если каждый раз новую структуру создавать вместо того, чтобы старую модифицировать, то без расходов памяти не обойдется. PD>>А они обрадовались и вперед. Смотрю я порой на решения, и мне просто страшно становится.
KV>Ты сейчас о чем-то ком-то конкретном? Явно ведь не о хроме (нету там дотнета, ну ни грамма).
Именно. Я не о дотнете. Я о бесконтрольном и беспардонном выделении объемом памяти, на порядки превышающие необходимые затраты. Независимо от языка. В js тоже нет дотнета.
KV>"Назовите мне имя это подлеца, сэр!" (с)
Безалаберное и безграмотное программирование.
KV>Не знаю. При условии, что мы вынуждены иметь javascript в качестве скриптового языка — наверное можно еще что-то оптимизировать, заставить хром более ответственно подходить к вопросам освобождения памяти, не используемой в настоящий момент (в нем это уже реализовано, но не включено, нужно запускать с правильным ключем командной строке) и т.п., но не думаю, что это даст существенный выигрыш, т.к. эти затраты памяти обусловлены дизайнерским решением и вполне осознанны. Чтобы серьезно сократить затраты памяти придется пересматривать архитектуру, а она вышла весьма удачная.
А она не могда выйти весьма удачной, если бы им сказали — 30 Мб и ини копейки больше ? Нет у нас больше, и все!
PD>>Вот ответь мне прямо, недвусмысленно и честно на такой вопрос. Пофантазируем. PD>>2000 год. Увеличение объема памяти и быстродействия процессора прекратилось. Ядра не были созданы. Лучшая машина — Pentium III — 667 MHz (у меня была тогда). Все. PD>>Ты готов заявить, что невозможно было бы создать ничего , равного по возможностям нынешним сайтам ? Ты готов утверждать, что при 256 Мб Google map или GMail никогда не мог бы быть создан ? Вот скажи прямо — да или нет. Без пояснений. 1 бит.
KV>Я без пояснений не могу, это против моей природы 1 бит — могу, это ответ "нет", мог бы. Но теперь поясню: если бы среда была настолько враждебна (а потребности пользователей бы росли в соответствии с нашим сценарием), то яваскрипт бы просто умер и на его место пришел бы другой более совершенный и приспособленный к этой среде язык. И именно на нем и была бы возможна реализация всех этих вебдванольных примочек. Но в реальности, все произошло несколько иначе и среда не только не вредила яваскрипту, но и всячески способствовала его дальнейшему развитию (стало возможно, разгонять его за счет мегабайтного оверхеда) и именно поэтому мы имеем то, что имеем.
Вот именно. То есть неправильные решения, которые не дохнут, потому что, к счастью для тех, кто их принимает и к несчастью для технологии, растут ресурсы. Вот и все. Отрасль пожертвовала своей технологической базой, своими алгоритмическим и т.д разработками, воспользовавшись тем, что ей вдруг ни с того ни с сего прислали целый кремовый торт размером с дом. Вот она его и жует, забыв про то, что надо все же развивать сельское хозяйство свое.
KV>Это эволюция, практически в чистом виде.
Это голландская болезнь в чистом виде.
PD>>Устраивает. А вот аргумент твой — нет. Предположим, что не устраивает — что же мне делать ? Все равно придется пользоваться — где я броузер возьму с потребностью по памяти в 10 раз меньше, если бы мне это надо было ? Например, VS меня радикально не устраивает ни по скорости ее работы (IDE, не компилятора), ни по памяти. Но чем я ее заменю ?
KV>У IE8 аж 4 конкурента...
А они что, в хоть в 5 раз меньше памяти едят или виснут меньше ? Да и потом — привык я к IE.
KV>Для этого в хроме и сделал свой диспетчер задач. Чтобы не задумываться, какой процесс убивать.
Спасибо . Надеюсь, он сам никогда не зависает и его не приходится убивать
KV>У меня ни один бразуер ни разу жуткий свопинг не устраивал. Ты серьезно наблюдал подобное?
Да.
KV>До тех пор, пока на улицах не услышишь постоянные автоматные очереди. А в интернетах они уже лет 7-8, как не умолкают
Я же не спорю, что проблема есть. Но любой ценой защита мне не нужна. Тебе же не нужно объяснять, что средства защиты должны быть соизмеримы защищаемой цели ?
KV>Не знаю с чего я это решил. Наверное с твоих вопросов о нововведениях в IE8 в "инсталляции и администрировании". А тебя не смущает, что все 4 браузера выдают в общем-то сравнимые результаты затрат по памяти? А opera (внимание: браузер, всегда считавшийся одним из самых быстрых) жрет больше всех. С чего бы?
Не знаю. Я ее помню в самом начале — прелесть была, да и только.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Именно. Я не о дотнете. Я о бесконтрольном и беспардонном выделении объемом памяти, на порядки превышающие необходимые затраты. Независимо от языка. В js тоже нет дотнета.
Дотнета нет, а почти что джит есть, GC — есть. Опаньки !
KV>>"Назовите мне имя это подлеца, сэр!" (с)
PD>Безалаберное и безграмотное программирование.
Как ты учил студентов, так они и программируют.
PD>Вот именно. То есть неправильные решения, которые не дохнут, потому что, к счастью для тех, кто их принимает и к несчастью для технологии, растут
Да, эволюция страшная вещь. Кто выжил — у того решение правильное.
KV>>У IE8 аж 4 конкурента...
PD>Не знаю. Я ее помню в самом начале — прелесть была, да и только. PD>А где обещанное про халтуру и автомобили ?
M>>Ты забываешь, что в JS int'ы, пусть и в теории, тоже объекты, тип которых, кстати, не известен. PD>Нет, не забыл. Под это готов дать еще 4 байта на объект. Даже 8 дам, так и быть — для ссылки на объект типа (тип же должен быть известен)
Ну вот 4 байта тут, четыре бата там и ты легким движением руки увелиил требования к памяти только для int'ов в два раза
PD>Псевдоязык PD>
PD>class ClassType
PD>{
PD> int type; // не нравится int - возьми иное, возражать не буду, ибо это синглетон
PD> string typename;
PD>};
PD>class Variable
PD>{
PD> ClassType* type;
PD> void* pData;
PD>};
PD>
>>Более того, нет в Javascript'е указателей.
PD>Указатели всегда есть. Их может не быть в языке, ими может быть , нельзя прямо оперировать, но по сути они всегда есть. Потому что это адреса чего-то PD>такого в памяти, с чем имеем дело. В одном языке (С++) они есть явно, в другом (С#) они выступают в виде ссылок и т.д. Вот в Фортране-4 их действительно не было >>И самое более того, ООП там немного совсем не паскалевское.
PD>Ну и что ? Ладно, еще 4 байта дам. Даже 8.
Больше надо давать, больше Ссылку на то, что делает Хром, я давал
M>>JIT способен распознать int's, но не всегда сразу. Не знаю, как работает v8, но, в теории, ему надо набрать статистику вызовов и только потом превратить их в int'ы. Что тоже бесплатно не дается. Везде компромиссы.
PD>Если бы компромиссы...
KV>>Все сказанное выше — весьма неполная подборка проблем, которые должны решить те, кто занимается созданием современного браузера. Странно только, что это понимаю я, ни разу не программист, но не понимаешь ты. Я ведь даже не "разработчик языков программирования" я так, "пристально за ними наблюдающий" в лучшем случае.
PD>Именно потому, что я программист, я это и понимаю. Понимаю, что не могли авторы языка в 1996 году создать его в расчете на необходимость 100 Мб, потому что и памяти такой даже в фантазии тогда не было.
В 1996-м году никому и в голову не приходило, что на странице будет полмиллиона объектов (а ведь Владимир тебе скриншот привел)
PD>Понимаю, что язык отнюдь не самый сложный, даже если придется иметь дело со столь ужасной ситуацией, как недозагруженный текст (Для твоего сведения — любой однопроходной компилятор всегда имеет дело с этой ситуацией, так как просматривает код один раз и, стало быть, при его просмотре в некоем месте можно считать, что последующий код он еще не видел).
Самое смешное, что Владимир говорил не только про JavaScript
KV>>У тебя не будет этого sizeof на данном этапе, в общем случае. Оно появится только в рантайме.
PD>Я тебя не понимаю. Да, конечно, в рантайме. Что, от этого его величина изменится ? Что ты так на рантайм упираешь ? Ну идет в рантайме компиляция вместе с выполнением. Ну в худшем случае это значит, что нужна память для компилятора и рабочей программы. Это еще TP умел на 1 Мб, и без всякой интерпретации. Да, не было там многого, но многое и было. На 1 Мб.
Казалось бы, зачем только ссылки людям даются? Javascript — это не паскаль.
Здравствуйте, Mamut, Вы писали:
M>В 1996-м году никому и в голову не приходило, что на странице будет полмиллиона объектов (а ведь Владимир тебе скриншот привел)
Полмиллиона это не на странице, а в рантайме, т.е. в памяти браузера.
Здравствуйте, Mamut, Вы писали:
M>>>В 1996-м году никому и в голову не приходило, что на странице будет полмиллиона объектов (а ведь Владимир тебе скриншот привел)
I>>Полмиллиона это не на странице, а в рантайме, т.е. в памяти браузера.
M>Хм. Судя по скриншоту — это таки для вкладки, где открыт gmail, ане для всео браузера. Что так же видно по колонке count для этой страницы.
Да, это был снапшот хипа для одной страницы gmail.
Здравствуйте, Mamut, Вы писали:
I>>Полмиллиона это не на странице, а в рантайме, т.е. в памяти браузера.
M>Хм. Судя по скриншоту — это таки для вкладки, где открыт gmail, ане для всео браузера. Что так же видно по колонке count для этой страницы.
Ну так это же в рантайме, а не на странице Или ты под страницей имел ввиду вкладку браузера ?
I>>>Полмиллиона это не на странице, а в рантайме, т.е. в памяти браузера.
M>>Хм. Судя по скриншоту — это таки для вкладки, где открыт gmail, ане для всео браузера. Что так же видно по колонке count для этой страницы.
I>Ну так это же в рантайме, а не на странице Или ты под страницей имел ввиду вкладку браузера ?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
I>>>JS V8 делает тоже самое, но уже в памяти. PD>>А c ТурбоПаскалем ты знаком, нет ? WH>ТурбоПаскалем статически типизированный язык. WH>Ты конечно можешь не верить но разница в компиляции статически типизированного языка и динамически типизированного огромна. WH>Я бы даже сказал там нет почти ничего общего. WH>В случае со статикой мы можем сгенерировать машинный код не запуская программу. WH>В случае с динамикой это сделать нельзя ибо набор полей и методов у объекта будет известен только во время исполнения программы. WH>Апеллировать к паскалю глядя на то как компилятр жабаскрипта кушает память просто глупо. WH>Ибо там работают принципиально разные алгоритмы.
Динамическая типизация была в FoxBase 1.0 для DOS в 1989 году. Там не было классов, но переменная могла изменить тип, скажем, с числового на строчный. А это тоже меняет набор "методов" (сложение чисел и конкатенация строк — это не одно и то же)
Да, там был интерпретатор. Работало все это в 640 Кб. Не надо думать, что только сейчас все открыли — все это давно открыто.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Динамическая типизация была в FoxBase 1.0 для DOS в 1989 году. Там не было классов, но переменная могла изменить тип, скажем, с числового на строчный. А это тоже меняет набор "методов" (сложение чисел и конкатенация строк — это не одно и то же) PD>Да, там был интерпретатор. Работало все это в 640 Кб. Не надо думать, что только сейчас все открыли — все это давно открыто.
Ну и как быстро он работал?
Здравствуйте, Cyberax, Вы писали:
PD>>Да, там был интерпретатор. Работало все это в 640 Кб. Не надо думать, что только сейчас все открыли — все это давно открыто. C>Ну и как быстро он работал?
Нормально для машины с тактовой в 4.77 MHz. Программа видимых задержек в интерфейсе из-за него не имела.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Динамическая типизация была в FoxBase 1.0 для DOS в 1989 году. Там не было классов, но переменная могла изменить тип, скажем, с числового на строчный. А это тоже меняет набор "методов" (сложение чисел и конкатенация строк — это не одно и то же) PD>Да, там был интерпретатор. Работало все это в 640 Кб. Не надо думать, что только сейчас все открыли — все это давно открыто.
Повторю еще раз V8 это КОМПИЛЯТОР жабаскрипта, а не интерпретатор.
Там принципиально иной алгоритм.
И работает этот алгоритм ОЧЕНЬ СИЛЬНО БЫСТРЕЕ чем интерпретаторы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нормально для машины с тактовой в 4.77 MHz. Программа видимых задержек в интерфейсе из-за него не имела.
А ты всетки сравни скорость с тем что дает V8.
Ты же у нас тут всех за производительность порвать готов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Динамическая типизация была в FoxBase 1.0 для DOS в 1989 году. Там не было классов, но переменная могла изменить тип, скажем, с числового на строчный. А это тоже меняет набор "методов" (сложение чисел и конкатенация строк — это не одно и то же) PD>>Да, там был интерпретатор. Работало все это в 640 Кб. Не надо думать, что только сейчас все открыли — все это давно открыто. WH>Повторю еще раз V8 это КОМПИЛЯТОР жабаскрипта, а не интерпретатор. WH>Там принципиально иной алгоритм. WH>И работает этот алгоритм ОЧЕНЬ СИЛЬНО БЫСТРЕЕ чем интерпретаторы.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Да, там был интерпретатор. Работало все это в 640 Кб. Не надо думать, что только сейчас все открыли — все это давно открыто. C>>Ну и как быстро он работал? PD>Нормально для машины с тактовой в 4.77 MHz. Программа видимых задержек в интерфейсе из-за него не имела.
Как оно работало по сравнению с Паскалем?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Нормально для машины с тактовой в 4.77 MHz. Программа видимых задержек в интерфейсе из-за него не имела. WH>А ты всетки сравни скорость с тем что дает V8.
Что сравнить ? FoxBase 1989 года на PC XT 640 Kb 4.77 MHz и Js на Duo 4 Gb 3 GHz ?
WH>Ты же у нас тут всех за производительность порвать готов.
Здравствуйте, Cyberax, Вы писали:
C>Как оно работало по сравнению с Паскалем?
Конечно, Паскаль быстрее. Мы все были довольны, когда в первых версиях Delphi стало возможным добраться к .dbf файлам, минуя этот самый FoxBase (уже, впрочем, FoxPro). Ну и сам язык не сравнить .
Но и на FoxBase/Pro было вполне терпимо.
Я же не о том говорю, что интерпретатор мог быть сравним со скоростью с компилятором. Я о том. что интерпретатор или полукомпилятор — это совсем не такая уж страшная вещь, требующая сотни Мб памяти из-за того, видите ли, что там только в рантайме определяется тип переменной, как меня тут уверяют. Все это давно было, и вполне без сотни Мб.
Здравствуйте, Pavel Dvorkin, Вы писали:
C>>Как оно работало по сравнению с Паскалем? PD>Конечно, Паскаль быстрее.
Ну вот, а JS сейчас работает сравнимо с компилируемыми языками по скорости.
Здравствуйте, Pavel Dvorkin, Вы писали:
WH>>А ты всетки сравни скорость с тем что дает V8. PD>Что сравнить ? FoxBase 1989 года на PC XT 640 Kb 4.77 MHz и Js на Duo 4 Gb 3 GHz ?
На одном процессоре естественно.
Думаю FoxBase отстанет в десятки раз.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Pavel Dvorkin, Вы писали:
C>>>Как оно работало по сравнению с Паскалем? PD>>Конечно, Паскаль быстрее. C>Ну вот, а JS сейчас работает сравнимо с компилируемыми языками по скорости.
И там было сравнимо. Я, конечно, не мерил, но тоже, наверное, раза в 2-3. Или ты хочешь сказать, что этот js дает ту же скорость, что и IGC++ ? Дотнет не дает, там стабильно 1.5-2 раза, и то, если без LinQ.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
WH>>>А ты всетки сравни скорость с тем что дает V8. PD>>Что сравнить ? FoxBase 1989 года на PC XT 640 Kb 4.77 MHz и Js на Duo 4 Gb 3 GHz ? WH>На одном процессоре естественно. WH>Думаю FoxBase отстанет в десятки раз.
Еще бы. Он ведь за пределами 640 Кб вообще память использовать не умел, он же ДОСовский. Вот посади js на 640 Кб — тогда и поговорим
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Конечно, Паскаль быстрее. C>>Ну вот, а JS сейчас работает сравнимо с компилируемыми языками по скорости. PD>И там было сравнимо. Я, конечно, не мерил, но тоже, наверное, раза в 2-3.
Примерно в 100 раз. У меня товарищ писал крестики-нолики на FoxPro — там можно было визуально его отлаживать. Т.е. было глазами видно что там исполняется.
PD>Или ты хочешь сказать, что этот js дает ту же скорость, что и IGC++ ?
С разницей в разы.
PD>Дотнет не дает, там стабильно 1.5-2 раза, и то, если без LinQ.
Враньё. ICC на большинстве бенчмарков не сильно лучше .NET, а кое-где хуже.
Здравствуйте, Pavel Dvorkin, Вы писали:
WH>>>>А ты всетки сравни скорость с тем что дает V8. PD>>>Что сравнить ? FoxBase 1989 года на PC XT 640 Kb 4.77 MHz и Js на Duo 4 Gb 3 GHz ? WH>>На одном процессоре естественно. WH>>Думаю FoxBase отстанет в десятки раз. PD>Еще бы. Он ведь за пределами 640 Кб вообще память использовать не умел, он же ДОСовский. Вот посади js на 640 Кб — тогда и поговорим
Интерпретатор — без проблем. И он будет работать примерно так же.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Еще бы. Он ведь за пределами 640 Кб вообще память использовать не умел, он же ДОСовский. Вот посади js на 640 Кб — тогда и поговорим
Вот у меня на машине сейчас 4 гига. Я лишнюю сотню метров не замечу, а вот разницу в производительности на порядок очень даже замечу.
А что касается 640кб да не вопрос. Только получится интерпретатор который будет все также тормозить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>Конечно, Паскаль быстрее. C>>>Ну вот, а JS сейчас работает сравнимо с компилируемыми языками по скорости. PD>>И там было сравнимо. Я, конечно, не мерил, но тоже, наверное, раза в 2-3. C>Примерно в 100 раз. У меня товарищ писал крестики-нолики на FoxPro — там можно было визуально его отлаживать. Т.е. было глазами видно что там исполняется.
Смотря что. Но насчет 100 раз — сильно сомневаюсь. При тактовой 4.77 такое просто никуда бы не годилось. А FoxBase программы работали.
PD>>Или ты хочешь сказать, что этот js дает ту же скорость, что и IGC++ ? C>С разницей в разы.
Так из-за разов весь спор и идет. Не о порядке же речь, если что-то на порядок медленнее — и говорить не о чем, в корзину — и все.
PD>>Дотнет не дает, там стабильно 1.5-2 раза, и то, если без LinQ. C>Враньё. ICC на большинстве бенчмарков не сильно лучше .NET, а кое-где хуже.
Ну не надо. IGC в среднем несколько лучше VC++, а тот стабильно в 1.5 — 2 раза лучше .net. Но предлагаю эту тему не развивать — тут и без нас об этом столько понампсано...
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Pavel Dvorkin, Вы писали:
WH>>>>>А ты всетки сравни скорость с тем что дает V8. PD>>>>Что сравнить ? FoxBase 1989 года на PC XT 640 Kb 4.77 MHz и Js на Duo 4 Gb 3 GHz ? WH>>>На одном процессоре естественно. WH>>>Думаю FoxBase отстанет в десятки раз. PD>>Еще бы. Он ведь за пределами 640 Кб вообще память использовать не умел, он же ДОСовский. Вот посади js на 640 Кб — тогда и поговорим C>Интерпретатор — без проблем. И он будет работать примерно так же.
Так если интерпретатор, компилятор или вообще транслятор любого вида будет работать с той же скоростью на 640 Кб — это и будет доказательством моей правоты! Более того, я подозреваю, что пусть не на 640 Кб, а на 5-10 Мб все это и должно работать — от исходного js текста до финтифлюшки на экране. Вместо с броузером
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну не надо. IGC в среднем несколько лучше VC++, а тот стабильно в 1.5 — 2 раза лучше .net.
Вот только не надо выдавать клинические случаи за стабильный результат.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я же не о том говорю, что интерпретатор мог быть сравним со скоростью с компилятором. Я о том. что интерпретатор или полукомпилятор — это совсем не такая уж страшная вещь, требующая сотни Мб памяти из-за того, видите ли, что там только в рантайме определяется тип переменной, как меня тут уверяют. Все это давно было, и вполне без сотни Мб.
И в этом же контексте по полмиллиона и более объектов в хипе ?
Здравствуйте, Pavel Dvorkin, Вы писали:
C>>Примерно в 100 раз. У меня товарищ писал крестики-нолики на FoxPro — там можно было визуально его отлаживать. Т.е. было глазами видно что там исполняется. PD>Смотря что. Но насчет 100 раз — сильно сомневаюсь. При тактовой 4.77 такое просто никуда бы не годилось. А FoxBase программы работали.
Да. Так как всё что им надо было делать — это байндить формы и данные. А формочки там вполне себе машинным кодом обрабатывались.
PD>>>Или ты хочешь сказать, что этот js дает ту же скорость, что и IGC++ ? C>>С разницей в разы. PD>Так из-за разов весь спор и идет. Не о порядке же речь, если что-то на порядок медленнее — и говорить не о чем, в корзину — и все.
Любой интерпретатор медленнее более-менее оптимизированного JIT-компилированного кода раз в 100. Позор не знать этого.
PD>>>Дотнет не дает, там стабильно 1.5-2 раза, и то, если без LinQ. C>>Враньё. ICC на большинстве бенчмарков не сильно лучше .NET, а кое-где хуже. PD>Ну не надо. IGC в среднем несколько лучше VC++, а тот стабильно в 1.5 — 2 раза лучше .net. Но предлагаю эту тему не развивать — тут и без нас об этом столько понампсано...
Да-да. Посмотри на Shootout.
Здравствуйте, Pavel Dvorkin, Вы писали:
C>>Интерпретатор — без проблем. И он будет работать примерно так же. PD>Так если интерпретатор, компилятор или вообще транслятор любого вида будет работать с той же скоростью на 640 Кб — это и будет доказательством моей правоты! Более того, я подозреваю, что пусть не на 640 Кб, а на 5-10 Мб все это и должно работать — от исходного js текста до финтифлюшки на экране. Вместо с броузером
Правоты в чём? Что интерпретатор можно написать в минимальном объёме кода? Так в этом никто не сомневался.
Речь идёт о том, что СЕЙЧАС он нафиг никому не нужен будет из-за его тормозов.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Смотря что. Но насчет 100 раз — сильно сомневаюсь. При тактовой 4.77 такое просто никуда бы не годилось. А FoxBase программы работали.
Годилось и еще как. 15 лет назад интерпретатор мог работать в 100 раз медленее компилера и это было круто.
Джава первых версий была медленее где то в 30 раз относительно С++.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Я же не о том говорю, что интерпретатор мог быть сравним со скоростью с компилятором. Я о том. что интерпретатор или полукомпилятор — это совсем не такая уж страшная вещь, требующая сотни Мб памяти из-за того, видите ли, что там только в рантайме определяется тип переменной, как меня тут уверяют. Все это давно было, и вполне без сотни Мб.
I>И в этом же контексте по полмиллиона и более объектов в хипе ?
I>Врешь, ведь.
Ну и ну. Полмиллиона объектов на памяти в 640 Кб. М-да. Переутомление у тебя ?
Здравствуйте, Cyberax, Вы писали:
C>Любой интерпретатор медленнее более-менее оптимизированного JIT-компилированного кода раз в 100. Позор не знать этого.
Нет, не позор. Я не могу сравнивать твои JIT по причине того, что нет тут у меня никаких интерпретаторов, но вот интерпретатор Бейсика для Ямахи был хоть и медленнее компилятора, но уж никак не в 100 раз, так как если бы он был медленнее в 100 раз, то при 2 GHz вообще бы ничего не работало. С тех пор я с интерпретаторами дел не имел.
C>Да-да. Посмотри на Shootout.
Здравствуйте, Pavel Dvorkin, Вы писали:
C>>Любой интерпретатор медленнее более-менее оптимизированного JIT-компилированного кода раз в 100. Позор не знать этого. PD>Нет, не позор. Я не могу сравнивать твои JIT по причине того, что нет тут у меня никаких интерпретаторов, но вот интерпретатор Бейсика для Ямахи был хоть и медленнее компилятора, но уж никак не в 100 раз
Именно в 100 раз. Я на x86 (4МГц) на GWBasic'е делал задержки как пустые циклы в 500-1000 итераций. У меня до сих пор исходники даже остались.
PD>так как если бы он был медленнее в 100 раз, то при 2 GHz вообще бы ничего не работало. С тех пор я с интерпретаторами дел не имел.
Ну вот я и говорю — позор не знать.
C>>Да-да. Посмотри на Shootout. PD>Хватит с меня дискуссий здесь на эту тему.
Ну так признай, что был неправ.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>чтобы под указатель было выделено много памяти, надо чтобы он на массив показывал A>>так вышеупомянутый RefPtr<NamedNodeMap> m_attributeMap как раз на массив и указывает PD>Вообще-то Map вряд ли массив, ну да ладно.
вообще-то map побольше места сожрёт, чем "массив"
PD>Но если массив — чему его размер равен? Как определяется ? Если, как я предполагаю, это map атрибутов, то сколько там этих атрибутов у ноды ? 10 ? Допускаю. 100 ? Тоже допускаю, но вряд и у всех нод столько атрибутов. 10000 ? Что-то плохо верится. А ведь 10000 атрибутов, да по 16 байт на атрибут — это лишь жалкие 160 (ну пусть 320) Кбайт.
что уже половина он пресловутых 640кил и там не по 16, там собственно атрибут от ноды отличается отсутствием атрибутов, а основа у них одна и та же.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Да, там был интерпретатор. Работало все это в 640 Кб. Не надо думать, что только сейчас все открыли — все это давно открыто. C>>Ну и как быстро он работал?
PD>Нормально для машины с тактовой в 4.77 MHz. Программа видимых задержек в интерфейсе из-за него не имела.
Тормозило оно в 640 K на XT. Вот на AT — более-менее прилично работало.
Здравствуйте, Pavel Dvorkin, Вы писали:
C>>Ну так признай, что был неправ.
PD>В чем ?
Да куда ни ткни, ты не прав.
Сначала кидаешь утверждение что де памяти под объекты для Html надо максимум в несколько раз больше чем текста, потом споришь с тем, что надо в 10-100 раз больше и просишь показать пример, потом сам же выдвигаешь оценку, по которой памяти нужно не в разы, а в 100 раз больше.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В С++ это нечто называется vtable. Тип изменить нельзя, поэтому указатель на vtable для данной переменной никогда не изменяется. А дай возможность его изменить — и будет тебе динамическая типизация. PD>При изменении типа , возможно, изменится размер, понадобится реаллокация.
А layout кто менять будет или расширять блок памяти для новых членов?
А почему в этом самом js есть эта пресловутая динамическая типизация ?
Из глубоких идейных соображений ?
Да нет. Миллиарды строк кода без нее написаны. По существу, все серьезное ПО написано на статически типизируемых языках. И никаких особенно проблем не было при этом. Значит, вполне можно было бы и без нее обойтись.
А она есть. Почему ?
Я не обсуждаю, почему она есть во всяких новомодных языках. Там ее специально ввели, пожертвовав быстродействием. И этим новомодным языкам не 15 лет, придумывались они, когда памяти было много. А в js зачем ?
Ответ очень прост.
js изначально задуман как простенький язык для управления броузером. Даже и не язык, а так, скрипт какой-то. Мелочи и пустяки всякие делать. Вот есть язык для управления исполнением встроенных команд ОС, то есть язык bat-файлов, ну вот вам язык для управления броузером.
А теперь представь себе, что на языке bat-файлов начали программы рендеринга битовых карт писать. Модифицировали его, кое-что добавили, и под управлением интерпретатора cmd — стретчинг битмэпов. То-то весело будет.
А на js — начали.
А начали потому, что захлестнула нас голландская болезнь роста объема памяти. Не будь этого роста — никто и не стал бы приспосабливать этот лобзик к лесозаготовкам. А так — сделали миллион лобзиков и стройными рядами пошли валить сосны.
Вот и валят.
А теперь пару слов насчет безопасности.
Тут я в твою область внедряюсь, ты специалист, а я дилетант в ней. Можно и по шее получить.
И все же попробую.
Вот есть ОС Windows линии NT. В ней есть своя система безопасности.
Наверное, в ней дырки были, но на саму систему вроде как никто не покушался ? Она вроде как ничего, работает ?
А она почти что и не менялась с NT 3.1. А NT 3.1 на 16 Мб работала. И процессы там были, как и сейчас, и взаимодействовали они, и все это в 16 Мб укладывалось.
Значит , можно было уложить ?
А другие ОС в 1980-е- 90-е годы были ? В них безопасность обеспечивалась ? На памяти того времени, порядка 1-2 Мб ? Unix, кстати, не в 2000 году появился, и не в 1990, и даже не в 1980. А, страшно сказать, в 1969. Если бы кто-то в 1969 году сказал бы, что для обеспечения безопасности надо 100 Мб, его тихо отправили бы в Белые Столбы. Без первача и без халвы.
Здравствуйте, Cyberax, Вы писали:
PD>>В С++ это нечто называется vtable. Тип изменить нельзя, поэтому указатель на vtable для данной переменной никогда не изменяется. А дай возможность его изменить — и будет тебе динамическая типизация. PD>>При изменении типа , возможно, изменится размер, понадобится реаллокация. C>А layout кто менять будет или расширять блок памяти для новых членов?
Здравствуйте, Mamut, Вы писали:
WH>>>А что касается 640кб да не вопрос. Только получится интерпретатор который будет все также тормозить.
PD>>Ладно, давай заканчивать (это ко всем веткам относится).
M>Действительно, стоит заканчивать. Если ты даже ссылки
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да нет. Миллиарды строк кода без нее написаны. По существу, все серьезное ПО написано на статически типизируемых языках. И никаких особенно проблем не было при этом. Значит, вполне можно было бы и без нее обойтись.
Не всё. Очень большая часть написана на динамически типизируемых.
Здравствуйте, 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>>>При изменении типа , возможно, изменится размер, понадобится реаллокация. 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, у меня к Паскалю еще в институте идиосинкразия появилась.
Угу. «Паскаль враз компилится» и т.п. А выше тебе примеры того, с чем современным реализациям яваскрипта надо работать постоянно, на сотнях тысяч объектов. А ты говоришь ну и пусть
Здравствуйте, 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) А. Эйнштейн
P>>Я ничего не говорил про TP, у меня к Паскалю еще в институте идиосинкразия появилась.
M>Угу. «Паскаль враз компилится» и т.п. А выше тебе примеры того, с чем современным реализациям яваскрипта надо работать постоянно, на сотнях тысяч объектов. А ты говоришь ну и пусть
Здравствуйте, Mamut, Вы писали:
M>var a = { M> v: 1, M> method: function() { return this.v; } M>}; // какой тип у a?
В рантайме будет известно или нет ?
M>Что ты там говорил про TP?
То же самое. Все отличие в том, что в рантайме, когда тип выяснится, по указателю на объект типа получишь все его методы и т.д. И вызовешь.
Вот сравни. С++
Невиртуальная функция. Какую функцию вызывать — известно на этапе компиляции. Компилятор строит call по ее адресу.
Виртуальная функция. Какую функцию вызывать — на этапе компиляции неизвестно. Компилятор строит call по адресу, который лежит в "объекте виртуальных функций данного типа " (vtable[i], проще говоря). На vtable есть указатель в каждом объекте.
А теперь
Статический объект. Тип его известен на этапе компиляции. Методы вызываются прямо (о виртуальных не говорю).
Динамический объект. Тип его будет известен в некий момент рантайма. Метод надо вызывать из "объекта методов и полей данного типа", поля брать оттуда же (в объектной модели Windows такая штука называется переменной типа "тип").
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mamut, Вы писали:
M>>var a = { M>> v: 1, M>> method: function() { return this.v; } M>>}; // какой тип у a?
PD>В рантайме будет известно или нет ?
Это будет известно только в рантайме.
M>>Что ты там говорил про TP?
PD>То же самое. Все отличие в том, что в рантайме, когда тип выяснится, по указателю на объект типа получишь все его методы и т.д. И вызовешь.
Это — ключевое отличие. В ТП да и любом другом статически типизированном языке на этапе компиляции известна вся информация о типах. Весь код генерируется на основе этих типов.
В динамически тпизированном языке ты такого сделать не можешь, пока ты не получишь этот объект в рантайме.
PD>Вот сравни. С++
PD>Невиртуальная функция. Какую функцию вызывать — известно на этапе компиляции. Компилятор строит call по ее адресу. PD>Виртуальная функция. Какую функцию вызывать — на этапе компиляции неизвестно. Компилятор строит call по адресу, который лежит в "объекте виртуальных функций данного типа " (vtable[i], проще говоря). На vtable есть указатель в каждом объекте.
500 000 объектов. У каждого — не только функции, но и каждое поле является таким массивом. В каждом массиве каждый объект потенциально — еще один такой массив.
PD>А теперь
PD>Статический объект. Тип его известен на этапе компиляции. Методы вызываются прямо (о виртуальных не говорю). PD>Динамический объект. Тип его будет известен в некий момент рантайма. Метод надо вызывать из "объекта методов и полей данного типа",
Какого типа? Я что, зря расписывал тебе варианты развития событий?
PD>поля брать оттуда же (в объектной модели Windows такая штука называется переменной типа "тип").
Откуда оттуда же?
ЗЫ. Мне понравилось, как ты легко скипнул две части моего ответа — про динаически типизируемый тип и про комбинацию динамической типизации объектов и динамической типизации типов.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Да ну ? Ну-ка, расскажи, что имеет компилятор VC++ 2008 С++ сверх того, что было в BC 5.5. Кроме оптимизации. Впрочем, она и там была, вот только сравнивать не берусь.
I>Неужели BC 5.5 умеет некоторые фичи из C++0x или умеет компилить для дотнета ? Или может он умеет x64 или IA-64 ?
См. выделенное. В VC++ 2008 нет поддержки C++0x. Компиляция для /CLR отличается только тем, на какой язык идет кодогенерация, сама же компиляция. BC (правда, не 5.5, а 4.5) умел генерировать на 16 и 32 бита, а VC 2008 — на 32 и 64 . IA-64 не имеет к делу отношения при создании приложений под x86/64.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Да ну ? Ну-ка, расскажи, что имеет компилятор VC++ 2008 С++ сверх того, что было в BC 5.5. Кроме оптимизации. Впрочем, она и там была, вот только сравнивать не берусь. WH>Попробуй при помощи BC 5.5 собрать boost.
Хороший аргумент, ничего не скажешь. Естественно, это может и не получиться. Кстати, это может и под VC6 не получиться, из-за мелких деталей (та же область определения переменной в for). Но если ты можешь существенные отличия C++ BC 5.x от VC++ 200x привести — давай сюда. Кроме, конечно, Borland и Microsoft Specific.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот сравни. С++
Ну давай сравним.
PD>Невиртуальная функция. Какую функцию вызывать — известно на этапе компиляции. Компилятор строит call по ее адресу.
Такой роскоши в динамически типизированных языках не вообще.
PD>Виртуальная функция. Какую функцию вызывать — на этапе компиляции неизвестно. Компилятор строит call по адресу, который лежит в "объекте виртуальных функций данного типа " (vtable[i], проще говоря). На vtable есть указатель в каждом объекте.
Получили адрус таблици.
Получили адрес функции.
Вызвали.
3 машинные инструкции.
PD>Статический объект. Тип его известен на этапе компиляции. Методы вызываются прямо (о виртуальных не говорю).
В динамически типизированных языках таких нет.
PD>Динамический объект. Тип его будет известен в некий момент рантайма. Метод надо вызывать из "объекта методов и полей данного типа", поля брать оттуда же (в объектной модели Windows такая штука называется переменной типа "тип").
Обращения к методам и полям происходит одинаково.
1)Лезем в хештаблицу и по имени поля получаем значение. Имя обычно интернированно, чтобы можно было сравнивать указатели на строки.
2)Если не нашли то берем хештаблицу прототипа и goto 1
И так при обращении ко всем методам и ко всем полям.
В случае с методами нужно еще проверить что то что мы достали является функцией и принимает нужное колличество аргументов.
Ну как тебе накладные расходы на каждый вызов?
Попробуй придумать алгоритм который позволит свести вызов хотябы к десятку машинных инструкций.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
PD>>В рантайме будет известно или нет ?
M>Это будет известно только в рантайме.
Ну да, я это и имел в виду.
M>Это — ключевое отличие. В ТП да и любом другом статически типизированном языке на этапе компиляции известна вся информация о типах. Весь код генерируется на основе этих типов.
M>В динамически тпизированном языке ты такого сделать не можешь, пока ты не получишь этот объект в рантайме.
Да, да, конечно, ну я же ниже об этом и пишу.
PD>>Вот сравни. С++
PD>>Невиртуальная функция. Какую функцию вызывать — известно на этапе компиляции. Компилятор строит call по ее адресу. PD>>Виртуальная функция. Какую функцию вызывать — на этапе компиляции неизвестно. Компилятор строит call по адресу, который лежит в "объекте виртуальных функций данного типа " (vtable[i], проще говоря). На vtable есть указатель в каждом объекте.
M>500 000 объектов. У каждого — не только функции, но и каждое поле является таким массивом. В каждом массиве каждый объект потенциально — еще один такой массив.
Дима, ну разберись ты хоть наконец! В С++ vtable для каждого типа хранится в одном экземпляре! В одном, понимаешь! На каждый тип — одна vtable на весь EXE. А у объектов нет никаких массивов! У всех объектов данного типа есть всего 4 байта на объект — указатель на vtable. 100 будет объектов или миллион — все равно vtable (массив) будет одна. И будет она иметь размер в 4 Кбайта, если методов там 1024 (реально чуть поменьше, в начале vtable что-то лежит).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>См. выделенное. В VC++ 2008 нет поддержки C++0x.
А ты уверен, что BC 5.5 поддерживает С++ стандарт хотя бы как VC++ ? У борланда всегда были проблемы с этим.
>Компиляция для /CLR отличается только тем, на какой язык идет кодогенерация, сама же компиляция.
А этого мало, да ?
>BC (правда, не 5.5, а 4.5) умел генерировать на 16 и 32 бита, а VC 2008 — на 32 и 64 .
Фигня какая, подумаешь. Ты в курсе, что 64 бита это совсем другая оптимизация ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хороший аргумент, ничего не скажешь. Естественно, это может и не получиться. Кстати, это может и под VC6 не получиться, из-за мелких деталей (та же область определения переменной в for).
Ну так большая часть буста под него и не соберается. И совсем даже не из-за for'а.
PD>Но если ты можешь существенные отличия
А что поддержка языковых конструкций это какбы уже не существенно?
PD>C++ BC 5.x от VC++ 200x привести — давай сюда. Кроме, конечно, Borland и Microsoft Specific.
BC 5.x я уж и не помню когда последний раз видел.
Но помню что Borland C++ Builer 6(если мне не изменяет скалероз) был просто кошмарен по сравнению с VC++7. Глюки. Куча правильного кода не компилировалась...
VC++7.1 стала намного лучше поддерживать шаблоны.
Что появилось в VC++8 я честно говоря не помню.
Ибо С++ последний раз видел года 2 назад и видеть больше не хочу.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ну давай сравним.
PD>>Невиртуальная функция. Какую функцию вызывать — известно на этапе компиляции. Компилятор строит call по ее адресу. WH>Такой роскоши в динамически типизированных языках не вообще.
Такую фразу я при всем желании не понимаю.
PD>>Виртуальная функция. Какую функцию вызывать — на этапе компиляции неизвестно. Компилятор строит call по адресу, который лежит в "объекте виртуальных функций данного типа " (vtable[i], проще говоря). На vtable есть указатель в каждом объекте. WH>Получили адрус таблици. WH>Получили адрес функции. WH>Вызвали. WH>3 машинные инструкции.
Верно. Не совсем, правда — ты забыл множественное наследование, но без него — верно.
WH>Обращения к методам и полям происходит одинаково. WH>1)Лезем в хештаблицу и по имени поля получаем значение. Имя обычно интернированно, чтобы можно было сравнивать указатели на строки.
Не знаю, как там хеш-таблица устроена, но в trie-дереве несколько переходов в среднем — и мы у цели. Как правило, названия полей хорошо отличаются, по первым нескольким буквам. Расходы на trie дерево не существенны — одно дерево на тип, а не на экземпляр, а типов не 500 тысяч.
WH>2)Если не нашли то берем хештаблицу прототипа и goto 1
Протототип — это тип-родитель ? Если да — зачем ? В С++ в vtable лежат адреса всех виртуальных функций, как родных, так и унаследованных. Не десятки же тысяч там их. А даже хоть и десятки тысяч — не все ли равно ?
WH>И так при обращении ко всем методам и ко всем полям.
И в С++ при каждом вызове виртуальной функции выполняются 3 команды, о которых ты писал выше. Аргумент не пойдет.
WH>В случае с методами нужно еще проверить что то что мы достали является функцией и принимает нужное колличество аргументов.
Это можно там же в элементе trie-дерева хранить.
WH>Ну как тебе накладные расходы на каждый вызов?
В 3 команды не уложишься, но и не так уж много будет.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>См. выделенное. В VC++ 2008 нет поддержки C++0x.
I>А ты уверен, что BC 5.5 поддерживает С++ стандарт хотя бы как VC++ ? У борланда всегда были проблемы с этим.
Нет, не уверен. Впрочем, VC++ тоже не все поддерживает, например, в throw(type) в описании функции он просто игнорирует type.
throw(type)
The function can throw an exception of type type. However, in Visual C++ .NET, this is interpreted as throw(...).
Но все это хоть и неприятно, а мелочи. Да и какое это имеет значение по существу вопроса ? Возможно, BC не будет компилировать что-то , что компилирует VC++ или наоборот. Но мы, кажется, не портирование обсуждаем, а сравниваем языки. На 99% они совпадают, потому что со времен BC 5.x и до C+0x язык не менялся. А оставшийся % оставим тем, кто будет портировать, это их проблемы.
>>Компиляция для /CLR отличается только тем, на какой язык идет кодогенерация, сама же компиляция.
I>А этого мало, да ?
Конечно. Да и при чем тут /CLR ? Хорошо, давай останемся в рамках неуправляемого кода.
>>BC (правда, не 5.5, а 4.5) умел генерировать на 16 и 32 бита, а VC 2008 — на 32 и 64 .
I>Фигня какая, подумаешь. Ты в курсе, что 64 бита это совсем другая оптимизация ?
А ты в курсе, что 16 бит — это не только другая оптимизация, но и другая модель памяти (неплоская), да не одна, а целых 5 (tiny, small, ...)? Ты в курсе, как там адреса формируются ? память адресуется ? Ты хоть что-то о huge-указателях слыхал и как под них память выделяется, хоть что-то знаешь ?
Flat модель намного проще сегментированной 16-битной модели, и писать под нее компилятор намного проще.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Невиртуальная функция. Какую функцию вызывать — известно на этапе компиляции. Компилятор строит call по ее адресу. WH>>Такой роскоши в динамически типизированных языках нет вообще. PD>Такую фразу я при всем желании не понимаю.
А если добавить одну букву?
PD>Не знаю, как там хеш-таблица устроена, но в trie-дереве несколько переходов в среднем — и мы у цели. Как правило, названия полей хорошо отличаются, по первым нескольким буквам. Расходы на trie дерево не существенны — одно дерево на тип, а не на экземпляр, а типов не 500 тысяч. На экземпляр!
Да именно так!
В жабаскрипте нет классов.
PD>Протототип — это тип-родитель ? Если да — зачем ? В С++ в vtable лежат адреса всех виртуальных функций, как родных, так и унаследованных. Не десятки же тысяч там их. А даже хоть и десятки тысяч — не все ли равно ?
В жабаскрипте нет классов.
PD>И в С++ при каждом вызове виртуальной функции выполняются 3 команды, о которых ты писал выше. Аргумент не пойдет.
Кто бы сомневался. Ты же представления не имеешь о том что поисходит за пределами С++.
И хуже того ты даже не пытаешься понять что происходит вокруг.
Ты даже не ходишь по ссылкам что тебе дают.
PD>В 3 команды не уложишься, но и не так уж много будет.
Ну да... несколько сот тактов на каждый чих это конечно не много.
При том что статика српавляется с этим за единици тактов.
В V8 из-за тяжолой магии большенство вызовов делается за десяток тактов.
Всеравно медленно но существенно быстрее наивной реализации.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Хороший аргумент, ничего не скажешь. Естественно, это может и не получиться. Кстати, это может и под VC6 не получиться, из-за мелких деталей (та же область определения переменной в for). WH>Ну так большая часть буста под него и не соберается. И совсем даже не из-за for'а.
Ну и что ?
PD>>Но если ты можешь существенные отличия WH>А что поддержка языковых конструкций это какбы уже не существенно?
Если бы мы портирование обсуждали — существенно. Но мы язык обсуждаем. А он на 99% тот же. Оставшийся % может создать серьезную головную боль при портировании, но к обсуждению языка отношения не имеет. Вот C+0x — это да.
WH>BC 5.x я уж и не помню когда последний раз видел.
Я помню. Примерно так в 2000. Потом в 2005 делал перенос своей гипертекстовой системы, которую когда-то написал на BC 3.1-5.0, на VC++.
WH>Но помню что Borland C++ Builer 6(если мне не изменяет скалероз) был просто кошмарен по сравнению с VC++7. Глюки. Куча правильного кода не компилировалась...
С билдером я не работал всерьез, но что слышал — совпадает с твоей точкой зрения. BC5 был... так себе. Вот BC 3.1 был хорош — для своего времени и своих возможностей. Но это, конечно, еще не нынешний С++.
WH>VC++7.1 стала намного лучше поддерживать шаблоны. WH>Что появилось в VC++8 я честно говоря не помню.
Практически ничего. Появилось в VC++ 2010 — С+0x
WH>Ибо С++ последний раз видел года 2 назад и видеть больше не хочу.
Здравствуйте, WolfHound, Вы писали:
PD>>Не знаю, как там хеш-таблица устроена, но в trie-дереве несколько переходов в среднем — и мы у цели. Как правило, названия полей хорошо отличаются, по первым нескольким буквам. Расходы на trie дерево не существенны — одно дерево на тип, а не на экземпляр, а типов не 500 тысяч. WH>На экземпляр! WH>Да именно так! WH>В жабаскрипте нет классов.
Типы есть или нет ?
PD>>И в С++ при каждом вызове виртуальной функции выполняются 3 команды, о которых ты писал выше. Аргумент не пойдет. WH>Кто бы сомневался. Ты же представления не имеешь о том что поисходит за пределами С++.
Ну и ну. Ты мне про то, что в js это должно делаться на каждый вызов. Я тебе — что и в С++ тоже на каждый вызов. Для js это, конечно, существенно, а для C++ — это неважно. Вместо этого надо меня обсудить. Вот такая у тебя аргументация, а потом обижаетесь, что я дискутировать не хочу.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Хороший аргумент, ничего не скажешь. Естественно, это может и не получиться. Кстати, это может и под VC6 не получиться, из-за мелких деталей (та же область определения переменной в for). WH>>Ну так большая часть буста под него и не соберается. И совсем даже не из-за for'а. PD>Ну и что ?
И то что вот эта фраза: PD>Если бы мы портирование обсуждали — существенно. Но мы язык обсуждаем. А он на 99% тот же.
БРЕД! Язык не поменялся но вот уровень поддержки языка в разных компиляторах отличается очень существенно.
С++ очень сложный и запутанный. Правильно поддержать все его навороты очень не простая задача.
И уж поверь мне я в свое время очень хорошо изучил все его навороты.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Господи, Alex, ну уж от тебя я такого не ждал. Неужели ты впрямь считаешь, что в С++ я не найду способа переместить объект ? Какое мне дело до соседних блоков, что за чепуха ? Эта проблема сто лет назад решена. Используется двойной указатель, на место, где лежит указатель на объект.
Да прекрасно я этот подход знаю, он ещё в Apple Mac использовался.
PD>Вот и все. Цена решения — 4 байта на объект.
Плюс одна индирекция.
Здравствуйте, Pavel Dvorkin, Вы писали:
WH>>На экземпляр! WH>>Да именно так! WH>>В жабаскрипте нет классов. PD>Типы есть или нет ?
Они там весьма забавные.
Формально каждый объект имеет свой тип ибо любому объекту в любой момент могут изменить набор полей.
PD>Ну и ну. Ты мне про то, что в js это должно делаться на каждый вызов. Я тебе — что и в С++ тоже на каждый вызов. Для js это, конечно, существенно, а для C++ — это неважно. То что в JS на каждый вызов делается на 2-3 порядка больше действий это нихрена не существенно?
Я тебя правильно понял?
PD>Вместо этого надо меня обсудить. Вот такая у тебя аргументация, а потом обижаетесь, что я дискутировать не хочу.
Конечно. Ты же такуешь как тетерев. А вот в TP. А вот в С++.
А про то что жабаскрипт имеет существенно иную семантику и исполняется очень сильно по другому не понимаешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>А этого мало, да ?
PD>Конечно. Да и при чем тут /CLR ? Хорошо, давай останемся в рамках неуправляемого кода.
С таким подходом из VC++ Турбо Паскаль получится.
PD>А ты в курсе, что 16 бит — это не только другая оптимизация, но и другая модель памяти (неплоская), да не одна, а целых 5 (tiny, small, ...)? Ты в курсе, как там адреса формируются ? память адресуется ? Ты хоть что-то о huge-указателях слыхал и как под них память выделяется, хоть что-то знаешь ?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Господи, Alex, ну уж от тебя я такого не ждал. Неужели ты впрямь считаешь, что в С++ я не найду способа переместить объект ? Какое мне дело до соседних блоков, что за чепуха ? Эта проблема сто лет назад решена. Используется двойной указатель, на место, где лежит указатель на объект. C>Да прекрасно я этот подход знаю, он ещё в Apple Mac использовался.
Так зачем тогда этот вопрос поднял и меня пугать начал соседними блоками ?
PD>>Вот и все. Цена решения — 4 байта на объект. C>Плюс одна индирекция.
Увы. Но не такая уж дорогая плата за перемещаемость.
JScript
Microsoft JScript — это открытая реализация языка JavaScript компании Netscape. JScript — это высокопроизводительный язык написания сценариев для разработки активного содержимого веб-страниц. Применение JScript позволяет разработчикам связать и автоматизировать использование большого количества объектов на веб-страницах, включая элементы управления ActiveX и программы Java. Microsoft Internet Explorer создан для интерпретации сценариев JScript, внедренных в веб-страницы.
Это я правильно понял, что JScript есть реализация JavaScript ?
А это из MSDN
Creating Your Own Classes
The class statement defines classes. By default, class members are publicly accessible, which means that any code that can access the class can also access the class member. For more information, see JScript Modifiers.
Classes with Fields
Fields define the data used by an object and are similar to the properties in a prototype-based object. Here is an example of a simple class that has two fields. An instance of the class is created with the new operator:
Copy Code
class myClass {
const answer : int = 42; // Constant field.
var distance : double; // Variable field.
}
var c : myClass = new myClass;
c.distance = 5.2;
print("The answer is " + c.answer);
print("The distance is " + c.distance);
Может, конечно, я перепутал javascript и jscript, может , это и существенная разница. По крайней мере в IE именно Jscript, а у него вроде есть классы.
Я не имею дело со всеми этими скриптами, для меня — один черт.
Здравствуйте, Ikemefula, Вы писали:
PD>>Конечно. Да и при чем тут /CLR ? Хорошо, давай останемся в рамках неуправляемого кода.
I>С таким подходом из VC++ Турбо Паскаль получится.
Нет, получится GNU C++ или ICC++
PD>>А ты в курсе, что 16 бит — это не только другая оптимизация, но и другая модель памяти (неплоская), да не одна, а целых 5 (tiny, small, ...)? Ты в курсе, как там адреса формируются ? память адресуется ? Ты хоть что-то о huge-указателях слыхал и как под них память выделяется, хоть что-то знаешь ?
I>Конечно знаю
А если знаешь, то мог бы и сообразить, что компиляция на 16 бит по сравнению с компиляцией на 32 бита намного больше отличается, чем на 32 и 64.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>С таким подходом из VC++ Турбо Паскаль получится.
PD>Нет, получится GNU C++ или ICC++
Ни то, ни другое, потому что про оптимизации ты уже скипнул.
I>>Конечно знаю
PD>А если знаешь, то мог бы и сообразить, что компиляция на 16 бит по сравнению с компиляцией на 32 бита намного больше отличается, чем на 32 и 64.
А ведь было "и в лучшем случае они будут иметь такой же процент функционала от сегодняшних компиляторов, какой имеет линукс среди десктопов"
Итого — оптимизации оказались несущественным функционалом, тонкости стандарта — тоже, CLR — туда же, 64 — обратно туда же.
То есть ты просто подгоняешь под свое мнение все аргументы
http://code.google.com/apis/v8/design.html — очень простой текст
PD> Copy Code PD>class myClass { PD> const answer : int = 42; // Constant field. PD> var distance : double; // Variable field. PD>}
PD>var c : myClass = new myClass; PD>c.distance = 5.2; PD>print("The answer is " + c.answer); PD>print("The distance is " + c.distance);
PD>Может, конечно, я перепутал javascript и jscript, может , это и существенная разница. По крайней мере в IE именно Jscript, а у него вроде есть классы. PD>Я не имею дело со всеми этими скриптами, для меня — один черт.
Конечно существенная О чем и речь — со скриптами не работаешь, зато рассказываешь про безалаберное программирование.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Вот и все. Цена решения — 4 байта на объект. C>>Плюс одна индирекция. PD>Увы. Но не такая уж дорогая плата за перемещаемость.
Многократное торможение из-за срыва предсказателя, а так да, ничего.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А можно подробнее ? Я, например, перенес свой проект с BC++ на VC++. Не знаю, что ты имеешь в виду под уровнем поддержки, но перенос прошел без особых проблем.
Например VC++7 не поддерживает частичную специализацию, а VC++7.1 поддерживает.
PD>А уж на GNU C++ переводить — все, никак невозможно. Не может же там быть тот же уровень поддержки! Он вообще из юникса, в Windows — не родной. Пойди в форум по С++ и скажи там всем,
Там в отличии от тебя люди грамотные и знают что разные компиляторы поддерживают разное колличество фич С++.
Старые меньше новые больше.
PD>что из-за уровня поддержки они должны перенос VC++ <-> GNU C++ немедленно прекратить!
Лично нарвался на баг в GCC когда переносил написанный на VC++ код.
Долго думал как уговорить его сделать то что мне надо.
Подробности уже не помню. Давно это было.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
PD>>Увы. Но не такая уж дорогая плата за перемещаемость. C>Многократное торможение из-за срыва предсказателя, а так да, ничего.
??? Что за многократное торможение из за одной команды mov (почему это virtual не приводит к многократному торможению, фактически тот же подход, только в иной упаковке)
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>А можно подробнее ? Я, например, перенес свой проект с BC++ на VC++. Не знаю, что ты имеешь в виду под уровнем поддержки, но перенос прошел без особых проблем. WH>Например VC++7 не поддерживает частичную специализацию, а VC++7.1 поддерживает.
PD>>А уж на GNU C++ переводить — все, никак невозможно. Не может же там быть тот же уровень поддержки! Он вообще из юникса, в Windows — не родной. Пойди в форум по С++ и скажи там всем, WH>Там в отличии от тебя люди грамотные и знают что разные компиляторы поддерживают разное колличество фич С++. WH>Старые меньше новые больше.
Ладно, хватит, честное слово. Я, конечно, человек неграмотный, ты грамотный, ну и на здоровье. Я буду программы переносить, если мне потребуется, а ты можешь оставаться с уровнем поддержки.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Может, конечно, я перепутал javascript и jscript, может , это и существенная разница. По крайней мере в IE именно Jscript, а у него вроде есть классы.
Это не стандартное расширение и оно полностью на совести мелкософт.
PD>Я не имею дело со всеми этими скриптами, для меня — один черт.
Осталось перестать судить о том в чем ты не комптентен.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Понимаешь, все эти аргументы бледнеют перед одним простым фактом — компиляторы, которые работают в 1-2 Мб, сделать можно. A>>и в лучшем случае они будут иметь такой же процент функционала от сегодняшних компиляторов, какой имеет линукс среди десктопов PD>Да ну ? Ну-ка, расскажи, что имеет компилятор VC++ 2008 С++ сверх того, что было в BC 5.5. Кроме оптимизации. Впрочем, она и там была, вот только сравнивать не берусь.
эка ты взял и выкинул большую часть функционала из рассмотрения. там ещё кодогенератор есть — берёшься сравнивать? или с твоей колокольни всё что за пределами языковых конструкций — непонятная неважная фигня?
PD>>>Я просто констатирую факт — пока памяти было мало, они занимали эту малую память и работали с приличной скоростью. Значит, это можно сделать. A>>ставить скорость сборки выше скорости выполнения результата это суметь надо PD>Где это я ее ставил ? Выделил специально для тебя.
да вот прямо выше: "кроме оптимизации". кому нужна "приличная скорость" и "малое потребление памяти" компилятором, если результат безбожно тормозит?
PD>>>Я бы понял, если бы речь шла о языке, на порядки более сложном. Но этого нет. Вот и все. A>>это типа здесь сказано, что сложность компилятора зависит исключительно(или в большей мере) от сложности языка? PD>Именно так.
цитата дня
PD>Компилятор (я не оговорился) с Бейсика на Ямахе работал в 64 Кб. С VB6 его там не разместить.
тут на форуме вряд ли кто-то будет против, если какая-то часть конкурентов так и останется на уровне той ямахи
но ради прикола можешь попробовать в него впихать wpo и векторизатор
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>А ты в курсе, что 16 бит — это не только другая оптимизация, но и другая модель памяти (неплоская), да не одна, а целых 5 (tiny, small, ...)? Ты в курсе, как там адреса формируются ? память адресуется ? Ты хоть что-то о huge-указателях слыхал и как под них память выделяется, хоть что-то знаешь ? I>>Конечно знаю PD>А если знаешь, то мог бы и сообразить, что компиляция на 16 бит по сравнению с компиляцией на 32 бита намного больше отличается, чем на 32 и 64.
неужто компиляция под 16бит сложнее чем на 32/64, при том что с 32 там напихали всяких симдов, а huge указатель ты описываешь сам, и компилятору не надо париться с автоназначением типов указателей?
и ещё -mcmodel=<small|medium|large|kernel...>, совсем даже не на 16бит
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Понимаешь, все эти аргументы бледнеют перед одним простым фактом — компиляторы, которые работают в 1-2 Мб, сделать можно. A>>и в лучшем случае они будут иметь такой же процент функционала от сегодняшних компиляторов, какой имеет линукс среди десктопов PD>Да ну ? Ну-ка, расскажи, что имеет компилятор VC++ 2008 С++ сверх того, что было в BC 5.5. Кроме оптимизации.
кстати, а у BC 5.5 была поддержка openmp или каких других параллельных фенек?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Увы. Но не такая уж дорогая плата за перемещаемость. C>>Многократное торможение из-за срыва предсказателя, а так да, ничего. PD>??? Что за многократное торможение из за одной команды mov (почему это virtual не приводит к многократному торможению, фактически тот же подход, только в иной упаковке)
И ты ещё гордишься тем что знаешь как железо работаешь?
PD>И что за срыв такой ? Какого предсказателя ? http://en.wikipedia.org/wiki/Branch_predictor — в последних Intel'ах они научились пайплайнить непрямые вызовы, но вот двойные непрямые вызовы не оптимизированы.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>Увы. Но не такая уж дорогая плата за перемещаемость. C>>>Многократное торможение из-за срыва предсказателя, а так да, ничего. PD>>??? Что за многократное торможение из за одной команды mov (почему это virtual не приводит к многократному торможению, фактически тот же подход, только в иной упаковке) C>И ты ещё гордишься тем что знаешь как железо работаешь?
PD>>И что за срыв такой ? Какого предсказателя ? C>http://en.wikipedia.org/wiki/Branch_predictor — в последних Intel'ах они научились пайплайнить непрямые вызовы, но вот двойные непрямые вызовы не оптимизированы.
Тьфу ты, черт! Я что, должен загадки разгадывать ? Я просто не понял,о чем речь идет.
Но это совсем уж просто. Никакого срыва не будет.
// создаем
object* p = new object;
object** pp = &p;
// понадобилось использовать
object* p = *pp;
p->field1 = ...;
p->field2 = ...;
p->field3 = ...;
Между обращениями к полям объект перехать не может. Кто его может передвинуть ? Другой поток ? Мы не в дотнете, GC тут нет, значит , другой поток может быть только мной же созданный. Не может другой поток модифицировать эту структуру одновременно с тем, что и первый поток ее модифицирует — такие вещи надо под критическую секцию ставить, независимо от того, идет эта модификация с переаллокацией или нет.
С++ велик и могуч! Переезжать объекты в нем могут, но перезжать они будут строго под моим контролем в мной назначенное время
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>А ты в курсе, что 16 бит — это не только другая оптимизация, но и другая модель памяти (неплоская), да не одна, а целых 5 (tiny, small, ...)? Ты в курсе, как там адреса формируются ? память адресуется ? Ты хоть что-то о huge-указателях слыхал и как под них память выделяется, хоть что-то знаешь ? I>>>Конечно знаю PD>>А если знаешь, то мог бы и сообразить, что компиляция на 16 бит по сравнению с компиляцией на 32 бита намного больше отличается, чем на 32 и 64. A>неужто компиляция под 16бит сложнее чем на 32/64, при том что с 32 там напихали всяких симдов, а huge указатель ты описываешь сам, и компилятору не надо париться с автоназначением типов указателей?
Ты просто не в курсе того, о чем судишь.
huge указатель я назначаю сам, да, а вот для выделения памяти под него придется добавлять несколько элементов в LDT, потому что в 16-битной модели сегмент не может превышать 64 К. Поэтому вот такое
huge char* p = new char[128K]
потребует 2 вызова AllocSelector (вроде так называлась, не помню)
И когда его значение станет равно
xxxx:0FFFFh
и будет p++, он должен превратиться в
xxxx+8 : 0
что, как сам понимаешь, одной командой inc не сделаешь.
И все это компилятор должен в код заложить. Или библиотека компилятора.
Добавлю пару слов: мне тоже в свое время приходилось иметь дело с FoxBase/FoxPro. По-моему, в 90-е с клонами dBase III работали все без исключения. Потому я кое-что знаю и о динамической типизации. И у меня есть основания думать, что присваивание переменной значения, тип которого отличается от текущего, обходится несколько дороже, чем думает Павел.
А твой пост про JS для меня оказался весьма познавательным. Я никогда не имел с ним дела. А коллег его быстродействие на стороне клиента устраивало далеко не всегда.
PD>>>В рантайме будет известно или нет ?
M>>Это будет известно только в рантайме.
PD>Ну да, я это и имел в виду.
M>>Это — ключевое отличие. В ТП да и любом другом статически типизированном языке на этапе компиляции известна вся информация о типах. Весь код генерируется на основе этих типов.
M>>В динамически тпизированном языке ты такого сделать не можешь, пока ты не получишь этот объект в рантайме.
PD>Да, да, конечно, ну я же ниже об этом и пишу.
PD>>>Вот сравни. С++
PD>>>Невиртуальная функция. Какую функцию вызывать — известно на этапе компиляции. Компилятор строит call по ее адресу. PD>>>Виртуальная функция. Какую функцию вызывать — на этапе компиляции неизвестно. Компилятор строит call по адресу, который лежит в "объекте виртуальных функций данного типа " (vtable[i], проще говоря). На vtable есть указатель в каждом объекте.
M>>500 000 объектов. У каждого — не только функции, но и каждое поле является таким массивом. В каждом массиве каждый объект потенциально — еще один такой массив.
PD>Дима, ну разберись ты хоть наконец! В С++ vtable для каждого типа хранится в одном экземпляре! В одном, понимаешь! На каждый тип — одна vtable на весь EXE. А у объектов нет никаких массивов! У всех объектов данного типа есть всего 4 байта на объект — указатель на vtable. 100 будет объектов или миллион — все равно vtable (массив) будет одна. И будет она иметь размер в 4 Кбайта, если методов там 1024 (реально чуть поменьше, в начале vtable что-то лежит).
Хорошо, пойдем заново:
Динамически типизируемые переменные:
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?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Между обращениями к полям объект перехать не может. Кто его может передвинуть ? Другой поток ? Мы не в дотнете, GC тут нет, значит , другой поток может быть только мной же созданный. Не может другой поток модифицировать эту структуру одновременно с тем, что и первый поток ее модифицирует — такие вещи надо под критическую секцию ставить, независимо от того, идет эта модификация с переаллокацией или нет.
Обычно доступ требуется к одному-двум полям, так что мимо. Опять же, с крит. секциями отдельный вопрос — где и как их ставить?
Дима, я не настолько знаком с js, чтобы ответить тебе на вопросы, связанные со спецификой тех или иных конструкций.
Я просто попробую определиь свою точку зрения.
Тип есть или его совсем нет ? Если язык совершенно бестиповый, то это значит, что с любой переменной можно поступить как угодно. Например, взять да и обратиться в ней к несуществующему полю , и оно вдруг волшебным образом появится. Если это так — готов признать свою неправоту, так как в этом случае понятия типа нет вообще, каждая переменная сама по себе.
Но что-то мне сдается, что это все же не так. К примеру, window.open() написать можно, а window.gotoKishinev() не получится. И вообще я не раз видел алерты с текстом вроде "свойство(метод и т.д) у объекта не найдено. Только не надо мне говорить, что можно сделать наследника или как он там называется с gotoKishinev (см. ниже)
А если тип (в каком угодно смысле) есть — тогда давай выясним, что же это такое — тип. А это просто-напросто собрание общих свойств для всех объектов, к этому типу принадлежащих. И для описания этих свойств нужна одна переменная типа "тип" на каждый тип.
Будут эти типы все известны до рантайма и все переменные будут привязаны к какому-то типу — хорошо. Это значит, что связка от переменной к типу не меняется. Если переменные могут менять тип, но типы меняться не могут, это значит, что связка переменной к типу может меняться, а область данных в общем случае должна быть реаллоцирована. Если еще и новые типы могут образовываться, это значит, что в рантайме могут появляться новые переменные типа "тип" и к ним привязываться существующие или новые переменные.
Но до тех пор, пока не окажется, что каждая переменная имеет свой уникальный тип (то есть типов фактически нет, тип — это же общее для нескольких переменных) — до тех пор все останется именно так. Вот если типы вообще исчезнут — тогда другое дело.
А пока это так, вся информация, касающаяся типа, должна храниться в переменной типа тип. Один раз.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Между обращениями к полям объект перехать не может. Кто его может передвинуть ? Другой поток ? Мы не в дотнете, GC тут нет, значит , другой поток может быть только мной же созданный. Не может другой поток модифицировать эту структуру одновременно с тем, что и первый поток ее модифицирует — такие вещи надо под критическую секцию ставить, независимо от того, идет эта модификация с переаллокацией или нет. C>Обычно доступ требуется к одному-двум полям, так что мимо.
Ой ли ? В том же Win API обычно перед вызовом функции надо заполнить всю структуру, все ее поля.
>Опять же, с крит. секциями отдельный вопрос — где и как их ставить?
Странный вопрос. Предположим, никакой переаллокации и двойных указателей нет, а просто два потока могут модифицировать одну и ту же структуру. Надеюсь, тебе не надо объяснять, как ее защищать с помощью крит. секции ? А с переаллокацией в этом плане вообще-то ничего не менятся — то же самое изменение структуры, только несколько посложнее.
PD>Но до тех пор, пока не окажется, что каждая переменная имеет свой уникальный тип (то есть типов фактически нет, тип — это же общее для нескольких переменных) — до тех пор все останется именно так. Вот если типы вообще исчезнут — тогда другое дело.
По сути так и есть. Потому что у каждой переменной в каждый данный момент времени может просто так появиться новое поле. Или новый метод:
var a = function(){}; // назовем тип а TypeA0var b = new a(); // у b тип TypeA0
a.prototype.f = function(){}; // у a поменялся тип... так же поменялся тип у весх
// образованных от a объектов. Назовем его TypeA1
// в этой точке у b тип TypeA1
// но
b.aa = function(){}; // у b остались все методы и св-ва из TypeA1, но тип b изменился,
// так как мы добавили новый метод. Тип стал TypeB0
a.prototype.f2 = function(){}; // у a опять поменялся тип... так же поменялся тип у весх
// образованных от a объектов. Назовем его TypeA2
// то есть сейчас в b есть:
// - все методы и свойства типа TypeA0
// - все методы и свойства типа TypeA1
// - все методы и свойства типа TypeB0
// - все методы и свойства типа TypeA2
// и все это вместе организует некий тип TypeB1, который присущ только переменной b
b.f() // есть такая
b.aa() // есть такая
b.f2() // есть такая
// ноvar c = new a();
c.f() // есть такая
c.aa() // нет такой
c.f2() // есть такая
// казалось бы, у с должен быть тип TypeA2
// но
c.aa = function(){ alert(this); }; // внезапно у с организовался новый тип, TypeC,
// который включает в себя все методы и св-ва из TypeA2
Здравствуйте, Pavel Dvorkin, Вы писали:
C>>Обычно доступ требуется к одному-двум полям, так что мимо. PD>Ой ли ? В том же Win API обычно перед вызовом функции надо заполнить всю структуру, все ее поля.
Ли ой. Выкинь нафиг свой Win API подальше и посмотри на код тех же веб-приложений.
>>Опять же, с крит. секциями отдельный вопрос — где и как их ставить? PD>Странный вопрос. Предположим, никакой переаллокации и двойных указателей нет, а просто два потока могут модифицировать одну и ту же структуру. Надеюсь, тебе не надо объяснять, как ее защищать с помощью крит. секции ?
Надо.
PD>А с переаллокацией в этом плане вообще-то ничего не менятся — то же самое изменение структуры, только несколько посложнее.
Только начинаются вопросы с тем где расставлять спинлоки. При каждом обращении — нельзя, слишком дорого.
Нужно делать safepoint'ы. Следующая сложность — как их сделать эффективно.
Здравствуйте, Cyberax, Вы писали:
C>Ли ой. Выкинь нафиг свой Win API подальше и посмотри на код тех же веб-приложений.
Выкинуть его нельзя — без него под Windows эти web-приложения работать не будут
>>>Опять же, с крит. секциями отдельный вопрос — где и как их ставить? PD>>Странный вопрос. Предположим, никакой переаллокации и двойных указателей нет, а просто два потока могут модифицировать одну и ту же структуру. Надеюсь, тебе не надо объяснять, как ее защищать с помощью крит. секции ? C>Надо.
PD>>А с переаллокацией в этом плане вообще-то ничего не менятся — то же самое изменение структуры, только несколько посложнее. C>Только начинаются вопросы с тем где расставлять спинлоки. При каждом обращении — нельзя, слишком дорого.
Я не спорю, что обдумывать надо. Но отмечу, что и задача сама порядком-таки надуманная. Нет в С++ обычно никакой переалокации и не нужна она для большиства объектов. А если нужна, то для этих, которым надо, можно и обдумать.
Кстати, этот прием с двойным указателем не единственный.
Здравствуйте, Mamut, Вы писали:
PD>>Но до тех пор, пока не окажется, что каждая переменная имеет свой уникальный тип (то есть типов фактически нет, тип — это же общее для нескольких переменных) — до тех пор все останется именно так. Вот если типы вообще исчезнут — тогда другое дело.
M>По сути так и есть. Потому что у каждой переменной в каждый данный момент времени может просто так появиться новое поле. Или новый метод:
<skipped>
Дело не в этом. То, что тип может меняться, я в предыдущем постинге обсуждал.
А насчет "так и есть" хм.
var a = function(){}; // назовем тип а TypeA0var b = new a(); // у b тип TypeA0
Уже тут ясно, что общий тип есть. Ты его TypeA0 назвал. Переменных 2, тип один. Да, он генерируется в рантайме, но см. на этот счет предыдущее мое письмо. Но все равно — переменных не столько же, сколько типов. Вот если их и впрямб стане столько же, тогда будь добр выкинуть понятие типа вообще (на что оно мне нужно, если у каждой переменной он свой ?), тогда действительно придется все в переменной, а не в типе хранить.
А пока что у тебя строчка
var a = function(){}; // назовем тип а TypeA0
создает новый тип (в моих терминах — создает переменную типа "тип", а строчка
var b = new a(); // у b тип TypeA0
привязывает переменную (создает сначала, конечно) к этой переменной типа "тип"
a.prototype.f = function(){};
Ну что же. Создана новая переменная типа "тип" (TypeA1, для простоты обсуждать ее отношения с типом TypeA0 не буду, будем считать, что это самостоятельный тип), переменная a теперь привязана к этой переменной типа "тип".
И т.д.
А в реальной жизни переменные будут чаще использоваться со свои текущим типом, а не тип менять. И будет их этого типа не одна-две, а десятки, сотни и тысячи, все одного типа, все на одну переменную типа "тип" ссылаются.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Тип есть или его совсем нет ? Если язык совершенно бестиповый, то это значит, что с любой переменной можно поступить как угодно. Например, взять да и обратиться в ней к несуществующему полю , и оно вдруг волшебным образом появится.
Почти что так
PD>Но что-то мне сдается, что это все же не так. К примеру, window.open() написать можно, а window.gotoKishinev() не получится. И вообще я не раз видел алерты с текстом вроде "свойство(метод и т.д) у объекта не найдено. Только не надо мне говорить, что можно сделать наследника или как он там называется с gotoKishinev (см. ниже)
Не надо наследника делать, можно просто добавить метод и "тип" тут же изменится.
PD>А если тип (в каком угодно смысле) есть — тогда давай выясним, что же это такое — тип. А это просто-напросто собрание общих свойств для всех объектов, к этому типу принадлежащих. И для описания этих свойств нужна одна переменная типа "тип" на каждый тип.
Не просто собрание, а еще и последовательность добавления методов-свойств в объект.
То есть, добавляя a, b, c и gotoKishinev это один тип. А если сначала gotoKishinev а потом a, b, c — это будет другой тип.
PD>Если еще и новые типы могут образовываться, это значит, что в рантайме могут появляться новые переменные типа "тип" и к ним привязываться существующие или новые переменные.
Они не только могут, но и образовываются и делается это чуть не на каждом вызове метода.
PD>Но до тех пор, пока не окажется, что каждая переменная имеет свой уникальный тип (то есть типов фактически нет, тип — это же общее для нескольких переменных) — до тех пор все останется именно так. Вот если типы вообще исчезнут — тогда другое дело.
PD>А пока это так, вся информация, касающаяся типа, должна храниться в переменной типа тип. Один раз.
Как бэ хранится один раз, но для оптимизаций различных нужна куча всяких приседаний.
Компилер того же С++ все эти оптимизации делает при компиляции, а здесь все это нужно сделать в рантайме.
Здравствуйте, Mamut, Вы писали:
M>По сути так и есть. Потому что у каждой переменной в каждый данный момент времени может просто так появиться новое поле. Или новый метод:
[Код скипнут].
Такое я бы не взялся реализовывать на Фортране. Впрочем, это может говорить только о недостаточном знании мною Фортрана.
Я вот сейчас посмотрел ресурсы по JavaScipt для полных чайников. Пришел к выводу, что вещи, показанные в твоем коде, применяются чаще, чем некоторые об этом думают. Прав ли я? Если да, не мог бы ты подкинуть какой-нибудь реальный случай, когда срочно требуется изменить тип уже существующей переменной? Я бы покопался, но, поскольку я ни одной строки кода на JS не написал, то не могу отличить реальные случаи от, скажем так, учебных.
PD>>>Но до тех пор, пока не окажется, что каждая переменная имеет свой уникальный тип (то есть типов фактически нет, тип — это же общее для нескольких переменных) — до тех пор все останется именно так. Вот если типы вообще исчезнут — тогда другое дело.
M>>По сути так и есть. Потому что у каждой переменной в каждый данный момент времени может просто так появиться новое поле. Или новый метод:
PD><skipped>
PD>Дело не в этом. То, что тип может меняться, я в предыдущем постинге обсуждал.
PD>А насчет "так и есть" хм.
PD>
PD>var a = function(){}; // назовем тип а TypeA0
PD>var b = new a(); // у b тип TypeA0
PD>
PD>Уже тут ясно, что общий тип есть. Ты его TypeA0 назвал. Переменных 2, тип один. Да, он генерируется в рантайме, но см. на этот счет предыдущее мое письмо. Но все равно — переменных не столько же, сколько типов. Вот если их и впрямб стане столько же, тогда будь добр выкинуть понятие типа вообще (на что оно мне нужно, если у каждой переменной он свой ?), тогда действительно придется все в переменной, а не в типе хранить.
PD>А пока что у тебя строчка
PD>var a = function(){}; // назовем тип а TypeA0
PD>создает новый тип (в моих терминах — создает переменную типа "тип", а строчка
PD>var b = new a(); // у b тип TypeA0
[/jva]
PD>привязывает переменную (создает сначала, конечно) к этой переменной типа "тип"
[java]
PD>a.prototype.f = function(){};
PD>Ну что же. Создана новая переменная типа "тип" (TypeA1, для простоты обсуждать ее отношения с типом TypeA0 не буду, будем считать, что это самостоятельный тип), переменная a теперь привязана к этой переменной типа "тип".
PD>И т.д.
Почему ты так упорно не хочешь читать дальше первых двух строчек?
var a = function(){};
var b = new a();
a.prototype.f = function(){};
b.aa = function(){}; // у b теперь новый тип, подмножеством которого является A
// при этом сам тип A никуда не делся:var c = new a();
b.f() // есть такая функция, потому что она есть в типе A
b.aa() // есть такая функция, потому что она есть в типе B
c.f() // есть такая функция, потому что она есть в типе A
c.aa() // ошибка, нет такой функции, потому что она есть тольков типе B, уникально для переменной b
Выделенное убивает все твои рассуждения о типах.
PD>А в реальной жизни переменные будут чаще использоваться со свои текущим типом, а не тип менять. И будет их этого типа не одна-две, а десятки, сотни и тысячи, все одного типа, все на одну переменную типа "тип" ссылаются.
В реальной жизни такие изменения типов сплошь и рядом. Важно, что рантайм должен уметь эти финты ушами делать в любой момент для любого объекта любого типа — менять тип, расширять тип, создавать новый тип. Для каждого из сотен тысяч объектов, каждый из которых потенциально обладает уникальным типом.
Здравствуйте, Pavel Dvorkin, Вы писали:
A>>кстати, а у BC 5.5 была поддержка openmp или каких других параллельных фенек? PD>Конечно! Авторы его предсказали будущее и можно было программировать для любой параллельной архитектуры , которая появится вплоть до 2050 года
то есть, говоря:
Ну-ка, расскажи, что имеет компилятор VC++ 2008 С++ сверх того, что было в BC 5.5
ты имел в виду что можно рассказывать лишь о том, что было во времена bc5.5? или просто не устраивает, что 2008 всё-таки что-то имеет сверх?
Здравствуйте, Mamut, Вы писали:
M>Почему ты так упорно не хочешь читать дальше первых двух строчек?
M>// при этом сам тип A никуда не делся:
M>var c = new a();
Ну и на здоровье. Я разве говорил, что он исчез ?
M>b.f() // есть такая функция, потому что она есть в типе A
Отлично. В описании типа A есть такая функция.
M>b.aa() // есть такая функция, потому что она есть в типе B
То же.
M>c.f() // есть такая функция, потому что она есть в типе A
То же
M>c.aa() // ошибка, нет такой функции, потому что она есть тольков типе B, уникально для переменной b
То же.
M>Выделенное убивает все твои рассуждения о типах.
Не понял, почему.
Тип A содержит описание f
Тип B содержит описание aa
Переменная c типа A, вызвать f можно, а aa нельзя, потому как нет ее в типе A
M>В реальной жизни такие изменения типов сплошь и рядом.
Я не сопрю, но все же, думаю, использований без изменения типа больше ? На порядки, наверное. Все же в основном переменные заводят для того, чтобы с ними что-то сделать, а не тут же, не использовав, немедленно сменить ей тип и опять, не использовав, смнить тип
Важно, что рантайм должен уметь эти финты ушами делать в любой момент для любого объекта любого типа — менять тип, расширять тип, создавать новый тип. Для каждого из сотен тысяч объектов, каждый из которых потенциально обладает уникальным типом.
Эээ, вот тут-то самое интересное.
Рантайм должен это делать — бесспорно.
Но он должен также сообразоваться с тем, как часто происходят изменения типов и использование. Вот в этом вся хитрость и есть.
Дима. я смотреть не буду, нет никакого желания и времени разбираться в том, что мне, в общем, не нужно. Я не спорю, может они и неплохое решение сделали, но похоже, все же очень дорогое.
Ты все же мне так и не ответил на мой вопрос. Если бы в 2000 году остановилось развитие железа, то что, современные сайты со всем этим js и т.д в принципе не могли быть созданы ?
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>Важно, что рантайм должен уметь эти финты ушами делать в любой момент для любого объекта любого типа — менять тип, расширять тип, создавать новый тип. Для каждого из сотен тысяч объектов, каждый из которых потенциально обладает уникальным типом.
PD>Эээ, вот тут-то самое интересное. PD>Рантайм должен это делать — бесспорно. PD>Но он должен также сообразоваться с тем, как часто происходят изменения типов и использование. Вот в этом вся хитрость и есть.
Боюсь, что если тут начать строить адаптивные алгоритмы, реализация станет возможной только за бесконечное время при наличии неограниченных ресурсов.
PD>Дима. я смотреть не буду, нет никакого желания и времени разбираться в том, что мне, в общем, не нужно. Я не спорю, может они и неплохое решение сделали, но похоже, все же очень дорогое.
Смелое утверждение. Из "нет желания разбираться" и "мне не нужно" следует "очень дорогое". Логики не понял. У меня на нетбуке это решение, как я понимаю, работает.
PD>Ты все же мне так и не ответил на мой вопрос. Если бы в 2000 году остановилось развитие железа, то что, современные сайты со всем этим js и т.д в принципе не могли быть созданы ?
А ты вспомни, какие были возможности у сайтов 10 лет назад? Сколько было Интернет-магазинов? Когда появились первые форумы? Уменьши себе канал до 64 К и попробуй зайти с него, да хотя бы сюда, на RSDN, а потом расскажи, что из этого вышло.
Здравствуйте, Mamut, Вы писали:
M>>>Почему ты так упорно не хочешь читать дальше первых двух строчек? M>>>// при этом сам тип A никуда не делся:
M>>>var c = new a(); PD>>Ну и на здоровье. Я разве говорил, что он исчез ?
M>>>b.f() // есть такая функция, потому что она есть в типе A PD>>Отлично. В описании типа A есть такая функция.
M>>>b.aa() // есть такая функция, потому что она есть в типе B PD>>То же.
M>То же что?
В описании типа B есть функция aa
M>Угу. Только переменная b случайно оказывается двух типов одновременно. Потому что любое изменение типа A повлечет изменения и в переменной b.
Так, стоп. Если переменные могут быть двух типов одновременно (ты вроде мне до сих пор такого не говорил), то это значит, что концепция несколько усложняется. В этом случае переменная должна иметь не ссылку на переменную типа тип, а ссылку на список таких переменных. Вот и все.
PD>>Переменная c типа A, вызвать f можно, а aa нельзя, потому как нет ее в типе A
M>Потом ты делаешь это: M>
M>c.new_field = неважно_что
M>
M>Какого типа будет переменная c?
Видимо, нового типа. Но если потом написать
d = c;
то d будет этого же нового типа. Никуда не денешься Есть понятие тип или нет ? Ты мне упорно доказываешь, что типы могут плодиться. Я с этим и не спорю. Но типы все же есть или нет ?
M>Ссылку, как это делает рантайм я уже приводил.
Как он делает в конкретной реализации. Почему ты решил, что я должен в ней разобраться в деталях и высказапть, что бы я сделал иначе ?
M>Действительно. смотреть не буду, разбираться не буду, но уверен, что был бы я, всю бы архитектуру с нуля переписал, ага.. Хороший подход, ничего не скажешь Но я повторяюсь
.
PD>>Ты все же мне так и не ответил на мой вопрос. Если бы в 2000 году остановилось развитие железа, то что, современные сайты со всем этим js и т.д в принципе не могли быть созданы ?
M>В принципе не могли бы быть созданы. Причины я привел тут
. Появились бы другие способы достичь того же, или чего-то похожего. Ты, кстати, сам себе ответь — почему интерфейс уровня GMail'а не появился в 2000-м году? И с какой сокростью он бы работал, если бы появился. Хотя...
Ну не появился он просто потому, что на все нужно время, да и компанию Google не за 5 минут сделали, да и для этого Gmail никаких дисков того времени не хватило бы, да и скорости Интернета тоже. Много тут причин. Но, положа руку на сердце, разве этот gmail так уж на порядок лучше того же hotmail или даже mail.ru ? Что-то лучше. что-то хуже, а если всерьез говорить — потратили молщность на украшательство. Почта — она штука банальная, тут по существу мало что можно изменить, а вот всякие фантики приделывать можно до бесконечности, благо ресурсы позволяют.
>Достаточно поставить в виртуалку win 98/me, и запустить тот же gmail.
Вот именно. А mail.ru работает. И если я вынужден с почтой почему-то работать только с виртуалки (странная ситуация, но на минуту допустим), то я все же письмо прочитаю с mail.ru
M>>>>b.f() // есть такая функция, потому что она есть в типе A PD>>>Отлично. В описании типа A есть такая функция. M>>>>b.aa() // есть такая функция, потому что она есть в типе B PD>>>То же.
M>>То же что?
PD>В описании типа B есть функция aa
M>>Угу. Только переменная b случайно оказывается двух типов одновременно. Потому что любое изменение типа A повлечет изменения и в переменной b.
PD>Так, стоп. Если переменные могут быть двух типов одновременно (ты вроде мне до сих пор такого не говорил),
Разговариваю со стенкой, честное слово. Выделено выше.
По буквам:
var a = function(){};
var b = new a();
a.prototype.f = function(){}; // меняем сам тип A, а не переменную A
b.aa = function(){};
a.prototype.f2 = function(){}; // меняем сам тип A, а не переменную A
b.f() // есть такая, потому что тип A
b.aa() // есть такая, потому что тип B
b.f2() // есть такая, потому что тип A
Что из этих 7 срочек тебе непонятно? Нет, я понимаю, что ты опять увидишь только первые две. Поэтому повторяю, там семь строчек кода, а не две.
Внимательно смотрим на последнюю строчку. Внезапно мы видим в b функцию из типа A. При том, что тип у переменной b давно уже не A.
PD>то это значит, что концепция несколько усложняется. В этом случае переменная должна иметь не ссылку на переменную типа тип, а ссылку на список таких переменных. Вот и все.
Ага. Внезапно у нас появился список типов. Для каждой переменной (вернее — для каждого объекта в системе). То ты легким движением руки удваиваешь количество памяти для объектов
(ага, те самые два абзаца со слов "Ты набросаешь свою первую реализацию V8").
PD>>>Переменная c типа A, вызвать f можно, а aa нельзя, потому как нет ее в типе A
M>>Потом ты делаешь это: M>>
M>>c.new_field = неважно_что
M>>
M>>Какого типа будет переменная c?
PD>Видимо, нового типа. Но если потом написать
PD>d = c;
PD>то d будет этого же нового типа. Никуда не денешься Есть понятие тип или нет ? Ты мне упорно доказываешь, что типы могут плодиться. Я с этим и не спорю.
я тебе показываю, что потенциально каждая переменная обладает отдельным типом. и что взаимодейтсвие типов в яваскрипте чтуок посложнее, чем тебе кажется.
PD>Но типы все же есть или нет ?
Есть. Они могут плодиться. Они могут изменяться для конкретно данного объекта, но не для остальных объектов, могут меняться для всех объектов вообще и т.п.
M>>Ссылку, как это делает рантайм я уже приводил. PD>Как он делает в конкретной реализации. Почему ты решил, что я должен в ней разобраться в деталях и высказапть, что бы я сделал иначе ?
Потому что ты же якобы пытаешься понять, почему, что да как? Но при этом не прилашаешь ни малейшего усилия, чтобы разобраться Тебе приведена ссылка на один из самых быстрых на данный момент движков яваскрипта.
M>>Действительно. смотреть не буду, разбираться не буду, но уверен, что был бы я, всю бы архитектуру с нуля переписал, ага.. Хороший подход, ничего не скажешь Но я повторяюсь
.
PD>>>Ты все же мне так и не ответил на мой вопрос. Если бы в 2000 году остановилось развитие железа, то что, современные сайты со всем этим js и т.д в принципе не могли быть созданы ?
M>>В принципе не могли бы быть созданы. Причины я привел тут
. Появились бы другие способы достичь того же, или чего-то похожего. Ты, кстати, сам себе ответь — почему интерфейс уровня GMail'а не появился в 2000-м году? И с какой сокростью он бы работал, если бы появился. Хотя...
PD>Ну не появился он просто потому, что на все нужно время, да и компанию Google не за 5 минут сделали, да и для этого Gmail никаких дисков того времени не хватило бы,
Помимо гугла были и другие компании. MS. Yahoo.
PD>да и скорости Интернета тоже. Много тут причин. Но, положа руку на сердце, разве этот gmail так уж на порядок лучше того же hotmail или даже mail.ru ? Что-то лучше. что-то хуже, а если всерьез говорить — потратили молщность на украшательство. Почта — она штука банальная, тут по существу мало что можно изменить, а вот всякие фантики приделывать можно до бесконечности, благо ресурсы позволяют.
Опять ты прицепился к серверному функционалу. Я тебе говорю про интерфейс. Повторю во второй раз, в 2000-м году интернет выглядел так: http://thedesigned.com/2009/09/22/electronic-retail-store-websites-in-the-year-2000/ ты открой ссылку, не поленись. Тода же любой чих сложнее, чем простое выпадающее меню, безбожно тормозил. Сейчас я могу спокойно работать в Google Docs и не париться по поводу скорости яваскрипта.
>>Достаточно поставить в виртуалку win 98/me, и запустить тот же gmail.
PD>Вот именно. А mail.ru работает. И если я вынужден с почтой почему-то работать только с виртуалки (странная ситуация, но на минуту допустим), то я все же письмо прочитаю с mail.ru
при чем тут mail.ru?
PD>Дима, убедительная просьба — давай заканчивать.
Давно было пора заканчивать. Потому что разговор со стенкой интересен только в дурдоме.
PD>>Дима. я смотреть не буду, нет никакого желания и времени разбираться в том, что мне, в общем, не нужно. Я не спорю, может они и неплохое решение сделали, но похоже, все же очень дорогое.
P>Смелое утверждение. Из "нет желания разбираться" и "мне не нужно" следует "очень дорогое". Логики не понял. У меня на нетбуке это решение, как я понимаю, работает.
Ну что же, попробую объяснить. На примере из собственной практики.
Делали мы сайт. И там надо было некий ppt парсить и на кадры разбивать, а эти кадры в виде отдельных ppt сохранять. Размеры ppt — сотни Кб, а кадров в виде ppt — десятки Кб. Писали на Яве.
Начали искать библиотеку. Нашли. Платная. Триал взял я и начал пробовать. И на одном из ppt — Java Heap Error. При том, что я дал Яве под heap 256 Мб. Без этого JHE почти на всех ppt.
Написал авторам — попросили прислать этот ppt. Послал. Получил ответ, что мол, при парсинге этого ppt у них используется какой-то BufferedImage, и он мол, получился очень большой.
Так вот.
Я не знаю, как внутри себя устроен ppt. И знать не хочу. Не мое это дело.
Но его размер — сотни Кб.
Я допускаю, что для работы надо картинку кадра создать. Но размер этой картинки под экран — примерно 4 Мб.
Так вот.
4 Мб я вам дам.
Если будете очень просить, дам 8.
Если будете слезно умолять — дам 16.
А 20 не дам. Ни при каких условиях.
Не можете делать с buffered image — делайте, черт вас возьми, с unbuffered. Не можете с unbuffered — создавайте, черт вас возьми, этот image вручную через JNI и Win API. В общем, меня все это совершенно не интересует. Я просто одно знаю — для парсинга таких файлов в сотню Кб и при картинке в 4 Мб нечего устраивать Java Heap error при 256 Мб.
Здравствуйте, Mamut, Вы писали:
M>Ага. Внезапно у нас появился список типов. Для каждой переменной (вернее — для каждого объекта в системе). То ты легким движением руки удваиваешь количество памяти для объектов
Уф... Ну конечно, появился список типов, коль ты на 10-м посинге мне объяснил, что может перемнная принадлежать не к одному типу. Сказал бы сразу — я бы сразу и поправился. Подумаешь, новость — в С++ переменная вполне может принадлежать не к одному типу (множественное наследование), и указателей на vtable будет не один, и даже указатель на переменную не будет всегда одним и тем же. Но почему тут удваивается количество памяти — не понимаю. От того, что вместо одной ссылки будет список. память увеличится на двукратный (в байтах) размер этого списка, а вовсе не в 2 раза.
M>Есть. Они могут плодиться. Они могут изменяться для конкретно данного объекта, но не для остальных объектов, могут меняться для всех объектов вообще и т.п.
Это я со стенкой разговариваю. Я же тебе час назад подробно объяснил, что все это я учел.
M>>>В принципе не могли бы быть созданы. Причины я привел тут
. Появились бы другие способы достичь того же, или чего-то похожего. Ты, кстати, сам себе ответь — почему интерфейс уровня GMail'а не появился в 2000-м году? И с какой сокростью он бы работал, если бы появился. Хотя...
PD>>Ну не появился он просто потому, что на все нужно время, да и компанию Google не за 5 минут сделали, да и для этого Gmail никаких дисков того времени не хватило бы,
M>Помимо гугла были и другие компании. MS. Yahoo.
И у них была почта, соответствующая тем объемам дисковой памяти, которые можно было предоставить, скорости Интернета, которая тогда была и т.д. Не понял вопроса.
M>Опять ты прицепился к серверному функционалу. Я тебе говорю про интерфейс. Повторю во второй раз, в 2000-м году интернет выглядел так: http://thedesigned.com/2009/09/22/electronic-retail-store-websites-in-the-year-2000/ ты открой ссылку, не поленись. Тода же любой чих сложнее, чем простое выпадающее меню, безбожно тормозил. Сейчас я могу спокойно работать в Google Docs и не париться по поводу скорости яваскрипта.
Слушай, сделай милость, не надо. Я с mail.ru работал до 2000 года. Вот тебе он сейчас
Красивые картинки справа не в счет, нужны они мне, как рыбке зонтик. А в остальном — весьма похоже. Внутри показать не могу, увы, но там тоже мало что изменилось.
>>>Достаточно поставить в виртуалку win 98/me, и запустить тот же gmail.
PD>>Вот именно. А mail.ru работает. И если я вынужден с почтой почему-то работать только с виртуалки (странная ситуация, но на минуту допустим), то я все же письмо прочитаю с mail.ru
M>при чем тут mail.ru?
PD>>Дима, убедительная просьба — давай заканчивать.
M>Давно было пора заканчивать. Потому что разговор со стенкой интересен только в дурдоме.
Ну тогда тем более надо заканчивать, если ты на такой уровень дискуссии перешел. Все, больше не отвечу.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну что же, попробую объяснить. На примере из собственной практики.
Какое отношение твой пример имеет к системе типов JavaScript, я не понял. Он говорит, во-первых, о криворукости разработчиков библиотеки, которую ты пытался использовать, а во-вторых, об ограниченности твоих ресурсов. Потому что иначе ты бы сам реализовал нужный функционал, не отдавая врагам ни одного лишнего байта.
В случае с библиотекой ты знал, какой функционал она должна реализовать и отсюда вывести примерные технические требования к ней. В случае с интерпретатором JS — "нет ни времени, ни желания разбираться", я правильно процитировал?
P>Какое отношение твой пример имеет к системе типов JavaScript, я не понял. Он говорит, во-первых, о криворукости разработчиков библиотеки, которую ты пытался использовать, а во-вторых, об ограниченности твоих ресурсов. Потому что иначе ты бы сам реализовал нужный функционал, не отдавая врагам ни одного лишнего байта.
Ну извини, на это у меня времени не было. В принципе мог бы.
P>В случае с библиотекой ты знал, какой функционал она должна реализовать и отсюда вывести примерные технические требования к ней. В случае с интерпретатором JS — "нет ни времени, ни желания разбираться", я правильно процитировал?
Правильно. И в случае с библиотекой для ppt не было ни времени, ни желания разбираться с их buffered images и т.п., да и почему я это делать должен, коль скоро они за нее деньги просят ? Просто анализ той задачи говорил о том, сколько там памяти необходимо.
В итоге купили у другой фирмы, за цену в 3 раза дороже, но без JHE.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну извини, на это у меня времени не было. В принципе мог бы.
Именно это я и имел в виду, говоря об ограниченности твоих ресурсов. Но по-прежнему не понимаю, какое отношение приведенный тобой пример имеет к JS.
PD>Правильно. И в случае с библиотекой для ppt не было ни времени, ни желания разбираться с их buffered images и т.п., да и почему я это делать должен, коль скоро они за нее деньги просят ? Просто анализ той задачи говорил о том, сколько там памяти необходимо.
Вот именно. Анализ задачи все сказал. А в случае с JS такой анализ не проводился, верно?
А все просто. Тут где-то пробегала ссылка на страницу с графикой, работающую на JS. И предлагалось ее сравнить, посмотрев в разных браузерах. Я посмотрел. Дак вот в Хроме она летает, а в ФФ — не очень. Железо одно и то же. Иными словами, разработчики интерпретатора в, скажем так, мои требования вписались полностью.И на кой мне разбираться, сколько памяти потребовал их двиг, если все работает и ничто ничему не мешает?
PD>В итоге купили у другой фирмы, за цену в 3 раза дороже, но без JHE.
Ну, за нормально работающий продукт можно и заплатить. Тем более, что ты все равно цену включил в смету и выставил счет заказчику.
Здравствуйте, Privalov, Вы писали:
P>Вот именно. Анализ задачи все сказал. А в случае с JS такой анализ не проводился, верно?
В том-то и дело, что мне интуитивно кажется, что сотни Мб тут не нужны. Точный анализ я не проводил. Аргументы насчет прежних компиляторов, вполне работавших в 1-2 Мб не буду приводить, ты их читал, наверное. Я просто никак не могу поверить, что для подобной задачи так-таки уж необходимы эти десятки Мб. В конце концов все эти действия в броузере, вместе взятые — это сверхусложненный ввод и вывод. Очень сильно усложненный, исключительно. Но все же это не сложные алгоритмы, не NP-полные задачи и не что-то такое, где обрабатываются десятки и сотни Мб входных данных. И я никак не могу поверить, что если бы прогресс железа остановился в 2000 году, то этот ввод-вывод так и не удалось бы сделать. Это при 256 Мб-то ? Это при том, что я видел достаточно сложные программы, которые тем не менее работали в каких-нибудь 256 Кб, а было в них намного более сложное действие, чем красиво вывести текст и картинки и ввести десяток строк с формы.
Не верю!
P>А все просто. Тут где-то пробегала ссылка на страницу с графикой, работающую на JS. И предлагалось ее сравнить, посмотрев в разных браузерах. Я посмотрел. Дак вот в Хроме она летает, а в ФФ — не очень. Железо одно и то же. Иными словами, разработчики интерпретатора в, скажем так, мои требования вписались полностью.И на кой мне разбираться, сколько памяти потребовал их двиг, если все работает и ничто ничему не мешает?
Если бы не мешало. В том-то и дело, что мешает. Вот тут про VS 2010 где-то проскочило, про то, как она 10 сек открывается и про то, с какой скоростью работает. Обидно и больно. Тем более, что я хорошо помню VS6. И когда мой (на работе) Athlon 4200 работает со скоростью (визуальной) чуть ли не хуже, чем комп 10 летней давности, то ничего хорошего об этих тенденциях "бери больше пока дают" я сказать не могу. Мой домашний Phenom 955 пока что не тормозит. Ничего, через пару лет затормозит...
PD>>В итоге купили у другой фирмы, за цену в 3 раза дороже, но без JHE.
P>Ну, за нормально работающий продукт можно и заплатить. Тем более, что ты все равно цену включил в смету и выставил счет заказчику.
Ну платил не я, а именно заказчик. Я лишь рекомендовал один продукт и не рекомендовал другой.
. Появились бы другие способы достичь того же, или чего-то похожего. Ты, кстати, сам себе ответь — почему интерфейс уровня GMail'а не появился в 2000-м году? И с какой сокростью он бы работал, если бы появился. Хотя... Достаточно поставить в виртуалку win 98/me, и запустить тот же gmail.
В конце 2002-го года я как-то смотрел Isometric Client — это была библиотека для того, что сейчас называют "AJAX". Там были поразительные вещи — таскабельные окна, масштабирование, сплиттеры, динамические таблицы (!!!) и т.п. И ещё оно стоило около $10000 на разработчика.
Только вот оно было неюзабельно — тормозило смертельно и глючило по-страшному.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Конечно! Авторы его предсказали будущее и можно было программировать для любой параллельной архитектуры , которая появится вплоть до 2050 года A>>то есть, говоря: A>>
A>>Ну-ка, расскажи, что имеет компилятор VC++ 2008 С++ сверх того, что было в BC 5.5
A>>ты имел в виду что можно рассказывать лишь о том, что было во времена bc5.5? или просто не устраивает, что 2008 всё-таки что-то имеет сверх? PD>Я имел в виду, что спрашивать, была ли в компиляторе 1996 года поддержка openmp не выглядит особенно умной.
в таком контексте весь вопрос "что имеет компилятор VC++ 2008 С++ сверх того, что было в BC 5.5" исключительно неумный. ну или ты считаешь что MS должны были некрофилить все эти годы.
PD>Естественно, сравнивая эти два компилятора, можно говорить только об их общем подмножестве,
я и говорил — общего там столько же, сколько процентов у линуха на десктопе. но ресурсов они должны одинаково жрать, да-да
PD>то есть о компиляции на базовый набор команд x86.
а чем поддержка openmp выбивается из "компиляции на базовый набор x86"?
Здравствуйте, Pavel Dvorkin, Вы писали:
>Очень сильно усложненный, исключительно. Но все же это не сложные алгоритмы, не NP-полные задачи и не что-то такое, где обрабатываются десятки и сотни Мб входных данных. И я никак не могу поверить, что если бы прогресс железа остановился в 2000 году, то этот ввод-вывод так и не удалось бы сделать. Это при 256 Мб-то ?
JS не развивался бы, вместо этого пришлось бы писать на Активиксы. Появилось бы несколько стандартов Активиксов. Может даже идея браузера и html загнулась, а вместо этого появился бы бинарный формат.
Билд программы на С++ может насоздавать временных файлов в десятки и даже сотни раз больше самой программы и это даже не сейчас, а 12 лет назад так было.
Думаешь, если JS все делает в рантайме, то ничего этого создавать не нужно ?
>Это при том, что я видел достаточно сложные программы, которые тем не менее работали в каких-нибудь 256 Кб, а было в них намного более сложное действие, чем красиво вывести текст и картинки и ввести десяток строк с формы. PD>Не верю!
Да уже давно понятно, что дело всего лишь в твоей вере и религии, раз не можешь открыть ссылку да прочитать.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В том-то и дело, что мне интуитивно кажется, что сотни Мб тут не нужны. Точный анализ я не проводил. Аргументы насчет прежних компиляторов, вполне работавших в 1-2 Мб не буду приводить, ты их читал, наверное. Я просто никак не могу поверить, что для подобной задачи так-таки уж необходимы эти десятки Мб.
А вот моя интуиция здесь не работает. Рассуждать о потреблении памяти интерпретатором JS я смогу, только если напишу на нем что-нибудь менее тривиальное, чем Hello, World и погоняю код на разных системах. Иначе это рассуждения домохозяйки.
PD>В конце концов все эти действия в броузере, вместе взятые — это сверхусложненный ввод и вывод. Очень сильно усложненный, исключительно. Но все же это не сложные алгоритмы, не NP-полные задачи и не что-то такое, где обрабатываются десятки и сотни Мб входных данных.
Опять-таки не знаю. Хотя смею предположить, что верстка HTML-страницы на разных мониторах — не самая простая задача. К тому же объемы информации на WEB-страницах несколько больше, чем 10 лет назад. И отобразить их надо быстро. Детали специалисты расскажут, если захотят.
PD>И я никак не могу поверить, что если бы прогресс железа остановился в 2000 году, то этот ввод-вывод так и не удалось бы сделать. Это при 256 Мб-то ? Это при том, что я видел достаточно сложные программы, которые тем не менее работали в каких-нибудь 256 Кб, а было в них намного более сложное действие, чем красиво вывести текст и картинки и ввести десяток строк с формы.
Да, а если бы прогресс остановился в 1968 году, мы бы сейчас дырявили перфокарты, а не сидели на этом форуме, потому что Интернет так и не появился бы. А если бы Холлерит перфокарты не изобрел... В общем, если бы у бабушки была борода, это был бы дедушка.
PD>Не верю!
За веру сражаются в соседнем форуме.
PD>Если бы не мешало. В том-то и дело, что мешает. Вот тут про VS 2010 где-то проскочило, про то, как она 10 сек открывается и про то, с какой скоростью работает. Обидно и больно. Тем более, что я хорошо помню VS6. И когда мой (на работе) Athlon 4200 работает со скоростью (визуальной) чуть ли не хуже, чем комп 10 летней давности, то ничего хорошего об этих тенденциях "бери больше пока дают" я сказать не могу. Мой домашний Phenom 955 пока что не тормозит. Ничего, через пару лет затормозит...
Странно, у меня на нетбуке IDEA или NetBeans работают и не жужжат. Студию я лет 5 не видел. Хотя нет. Запускал недавно посмотреть какой-то проект из наших внутренних. Комп был HP Compaq с Intel Dual Core. Запуск занял какое-то время, а в остальном работало нормально. Заметил, что 2005 несколько удобнее, чем шестерка. Впрочем, я не готов по этому поводу высказывать мнение: очень недолго я в том проекте копался. В качестве вьюера использовать студию действительно неудобно. А так мой рабочий софт неделями не перезапускается.
А тормоза и прочая избыточность далеко не всегда происходят из-за криворуких разработчиков. Я начал было писать соображения по этому поводу, но что-то слишком длинно получилось. Нерациональное использование руководством проекта ресурсов, выделенных на разработку, неумение отличить прототип от релиза и многое другое. Короче, там в разной степени все виноваты.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ты все же мне так и не ответил на мой вопрос. Если бы в 2000 году остановилось развитие железа, то что, современные сайты со всем этим js и т.д в принципе не могли быть созданы ?
Конечно могли бы, но они бы, например, были бы дороже в разработке...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ikemefula, Вы писали:
I>Если бы современным программам на все про все хватало бы одной перфокарты...
С одной стороны, глупо не использовать возросшие мощности на улучшение работы программ.
Но с другой стороны, я согласен с Павлом в том, что авторы современного ПО слишком агрессивны в этом своём стремлении.
Оно и понятно: они на перспективу работают, а не на вчерашний день. Но можно и пользователей понять. Так комфортно, как в TORе и в пятом ворде, я уже нигде тексты не редактировал. Чем современнее становилось ПО, тем тормознее оно работало на актуальных для себя компах...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ikemefula, Вы писали:
E>>Оно и понятно: они на перспективу работают, а не на вчерашний день. Но можно и пользователей понять. Так комфортно, как в TORе и в пятом ворде, я уже нигде тексты не редактировал. Чем современнее становилось ПО, тем тормознее оно работало на актуальных для себя компах...
I>Чем мощнее компы, тем сложнее задачи и больше количество.
Да вроде как задачи-то всё те же. Текст отредактировать, мыло отправить...
I>JS — никакая не тривиальная задача.
JS -- это вообще не задача. Это инструмент. Задача -- написать морду мыльницы. И я совершенно точно знаю, что морду мыльницы можно написать экономичнее, чем это г.мыле сделано...
Ну чиста потому шта таки писал много морд...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ikemefula, Вы писали:
E>>С одной стороны, глупо не использовать возросшие мощности на улучшение работы программ. E>>Но с другой стороны, я согласен с Павлом в том, что авторы современного ПО слишком агрессивны в этом своём стремлении.
I>А у вас у обоих одна и та же болезнь — "не знаю", "не пробовал", "не разбирался", "не специалист" и при этом какие то претензии к авторам.
С чего это ты взял, что я не знаю и не пробовал? Вопрос в том, где не будет тормозить твой текстовый редактор -- на топовом компе послезавтрашнего дня, или будет быстро работать на уже сейчас устаревшем компе средней секретарши -- это всего лишь вопрос ценностного выбора и маркетинговой стратегии. При чём тут вообще претензии к авторам? Они просто делают то, что считают выгодным. При этом понятно, что крупные игроки на рынке коммерческого ПО навязали рынку войну фич. Типа прогресс ПО состоит не в том, что оно становится быстрее, компактнее и безглючнее, а в том, что оно становится фичастее. А "скорее и компактнее" предлагается удовлетворять за счёт прогресса аппаратуры. Но, при этом, IMHO, разрабы ПО опережают прогресс аппаратуры. Вот всё и тормозит на типичном компе...
Прикольно при этом то, что даже разрабы свободного или условно свободного ПО тоже ввязались в войну фич, а вовсе и не скорости, компактности и безглючности...
Видимо после редакторов вроде пятого ворда на эту тему мало что можно нового сказать
Жалко только, что на современных компах он не работает
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Privalov, Вы писали:
PD>>В том-то и дело, что мне интуитивно кажется, что сотни Мб тут не нужны. Точный анализ я не проводил. Аргументы насчет прежних компиляторов, вполне работавших в 1-2 Мб не буду приводить, ты их читал, наверное. Я просто никак не могу поверить, что для подобной задачи так-таки уж необходимы эти десятки Мб.
P>А вот моя интуиция здесь не работает. Рассуждать о потреблении памяти интерпретатором JS я смогу, только если напишу на нем что-нибудь менее тривиальное, чем Hello, World и погоняю код на разных системах. Иначе это рассуждения домохозяйки.
Это будут расуждения о потреблении памяти данным интерпретатором js и в данных условиях. Вот делаем WPF приложение "Hello, World", оно имеет Commit Size 55 Mb. На основании этого делаем вывод, что написание программы "Hello, World", требующей менее 50 Мб, невозможно. А тут кто-то приходит и говорит, что видел "Hello, World" размером в 100 байт...
PD>>В конце концов все эти действия в броузере, вместе взятые — это сверхусложненный ввод и вывод. Очень сильно усложненный, исключительно. Но все же это не сложные алгоритмы, не NP-полные задачи и не что-то такое, где обрабатываются десятки и сотни Мб входных данных.
P>Опять-таки не знаю. Хотя смею предположить, что верстка HTML-страницы на разных мониторах — не самая простая задача. К тому же объемы информации на WEB-страницах несколько больше, чем 10 лет назад. И отобразить их надо быстро. Детали специалисты расскажут, если захотят.
Объемы увеличились (немного), скорость процессора возросла (существеннеее). Верстка к делу не относится, ее не на клиенте делают, а рендеринг идет на данном мониторе, а не на разных. И все равно это не более чем вывод 4 Мб текста и графики в конечном счете в каждый момент времени.
PD>>И я никак не могу поверить, что если бы прогресс железа остановился в 2000 году, то этот ввод-вывод так и не удалось бы сделать. Это при 256 Мб-то ? Это при том, что я видел достаточно сложные программы, которые тем не менее работали в каких-нибудь 256 Кб, а было в них намного более сложное действие, чем красиво вывести текст и картинки и ввести десяток строк с формы.
P>Да, а если бы прогресс остановился в 1968 году, мы бы сейчас дырявили перфокарты, а не сидели на этом форуме, потому что Интернет так и не появился бы. А если бы Холлерит перфокарты не изобрел... В общем, если бы у бабушки была борода, это был бы дедушка.
Не годится такой аргумент. Если бы мы дырявили перфокарты, то не было бы броузеров и не о чем было бы говорить. А вот если бы памяти было 256 Мб, и даже 64 Мб, и даже 16 Мб, то броузеры бы были и как-то с задачей вывести один экран текста и графики справились бы — так, как они справлялись в те времена.
Здравствуйте, Erop, Вы писали:
I>>Чем мощнее компы, тем сложнее задачи и больше количество. E>Да вроде как задачи-то всё те же. Текст отредактировать, мыло отправить...
Потребности у людей не менялись — пообщаться, развлечься и тд.
Текст можешь набирать точно так же как и 15 лет назад — открыл нотпад и пошел херачить. А вот с мылом уже давно не так, потому что мощный комп позволяет удовлетворить больше потребностей, что проявляется в количестве возможностей которые предоставляет аутлук тот же.
E>JS -- это вообще не задача. Это инструмент. Задача -- написать морду мыльницы.
JS это тоже задача, только цель другая.
>И я совершенно точно знаю, что морду мыльницы можно написать экономичнее, чем это г.мыле сделано... E>Ну чиста потому шта таки писал много морд...
Можно. Покажи мыльницу с мордой, которая экономичнее, удобнее, отзывчивее, функциональнее и тд.
Здравствуйте, Erop, Вы писали:
E>С чего это ты взял, что я не знаю и не пробовал? Вопрос в том, где не будет тормозить твой текстовый редактор -- на топовом компе послезавтрашнего дня, или будет быстро работать на уже сейчас устаревшем компе средней секретарши -- это всего лишь вопрос ценностного выбора и маркетинговой стратегии.
Пользуйся нотпадом — он не тормозит даже на древних компах.
>При чём тут вообще претензии к авторам? Они просто делают то, что считают выгодным. При этом понятно, что крупные игроки на рынке коммерческого ПО навязали рынку войну фич.
Вот уже конспироложество полезло. Еще чуть чуть и скажешь что потребность в чтении, общении была навязана сверху
>Типа прогресс ПО состоит не в том, что оно становится быстрее, компактнее и безглючнее,
Именно так — прогресс в этом никогда не состоял. И так в любой отрасли.
>а в том, что оно становится фичастее.
Именно так.Фичи они всегда востребованы на рынке. Это не значит софт ценен списком фич. Это значит, что новые фичи экономят(или дают заработать) бОльше времени/денег, чем старые.
А тормоза — это издержки. Время/деньги важнее.
E>Прикольно при этом то, что даже разрабы свободного или условно свободного ПО тоже ввязались в войну фич, а вовсе и не скорости, компактности и безглючности...
Ты наверное сидел в той же конуре что и Дворкин. Фичи определяют вообще все, это единственное, за что можно покупать софт, если они конечно работают должным образом.
E>Видимо после редакторов вроде пятого ворда на эту тему мало что можно нового сказать E>Жалко только, что на современных компах он не работает
Это тебе его достаточно, а я его и видеть не хочу.
Вот простой пример про фичи — тебе нужно выбрать между почтовыми клиентома, один умеет отсылать-принимать почту , а в другой интергрирован чат, buzz, rss и прочая дрянь.
Если ты берешь первый, стало быть понадобится ее кучка софта если тебе нужны фичи.
Но если тебе нужны фичи — ты можешь взять второй.
Открою тебе большую тайну, которая на самом деле большая банальность, но для тебя до сих пор это именно тайна — софт не нужен пользователю.
Начало длинного объяснения.
И компьютер не нужен.
Ему нужны общение, познанние, развлечение и тд.
Компьютер это только средство.
Соответсвенно людям не интересно изучать десятки видов софта, изучать пакеты вроде офисных и тд.
Им не интересно сидеть и выбирать из перечня софтин какую то конкретную.
Им нужен софт который умеет решать все дела.
Что это за софт, ты уже знаешь — браузер, т.е. единственно настоящий софт который умеет решительно все.
Все остальные софтины, кроме средств разработки, по функционалу стремятся именно к браузеру.
Здравствуйте, Erop, Вы писали:
I>>Текст можешь набирать точно так же как и 15 лет назад — открыл нотпад и пошел херачить. E>Не-не-не! И TOR и пятый Word -- это намного круче блокнота!
То есть тебе уже самому фичи нужны ?
E>Не знаю. Все эти "больше потребностей" -- возможность вставлять картинки и форматирование в текст. Вложения, как раньше были, так и сейчас есть.
Ты про себя говоришь или у тебя есть статистика о том, как ворд используется ?
I>>JS это тоже задача, только цель другая. E>Да нет такой пользовательской задачи, как JS. Ты ещё скажи, что С++ -- это тоже задача.
У тебя какие то проблемы с прочтением "только цель другая" ?
I>>Можно. Покажи мыльницу с мордой, которая экономичнее, удобнее, отзывчивее, функциональнее и тд. E>Не знаю. Про "удобнее" и "функциональнее" -- это абстракиця всё. Так как неизмеримо.
Ну так и нехрен гнать.
E>Про "отзывчивее" -- смешно написал. Любая мыльница с, так сказать, "позапрошлого витка прогресса железа" "отзывчивее" всего нынешнего УГ.
См. выше — нехрен гнать, если не можешь алтернативы предложить.
E>А про "функциональнее", так в том-то и поинт. Что часть этой "функциональности" занафиг никому не упёрлась, и добавили её только потому. что ресурсы у компов бесплатные, а конкуренция идёт по фичам и только.
Как правило, пользователи выбирают много функциональные сервисы. Потому как общение не сводится к отправке почты. Это и чаты и социальные сети и тд и тд и тд.
>Тем не менее война фич несомненно ухудшает ВСЕ участвующие продукты.
Ты все еще в каменном веке живешь.
E>Да и то, что GMail какой-то там мегаотзывчивый -- это всё песни. Отзывчивый он на моём ноуте, на котором я продакшин код нашей системы на несколько лимонов LOC компилю. А на нетбуке, например, он тормозит и чахлый очень. А всё потому, что нетбук часто "тока что с мороза" бывает, и при этом ещё и памяти там не много...
Нетбук — мертвая ветка эволюции.
E>так что бесплатность ресурсов -- это таки иллюзия, а то, что память, например, это приемлемая плата за ненужные фичи -- это просто маркетинговое враньё. Надо же как-то версию номер N+1 впаривать?
Ты самое главное взял и скипнул, вобщем, ты как был трололо, так и остался трололо.
Здравствуйте, Ikemefula, Вы писали:
E>>С чего это ты взял, что я не знаю и не пробовал? Вопрос в том, где не будет тормозить твой текстовый редактор -- на топовом компе послезавтрашнего дня, или будет быстро работать на уже сейчас устаревшем компе средней секретарши -- это всего лишь вопрос ценностного выбора и маркетинговой стратегии.
I>Пользуйся нотпадом — он не тормозит даже на древних компах.
При чём тут нотепад?
I>Вот уже конспироложество полезло. Еще чуть чуть и скажешь что потребность в чтении, общении была навязана сверху
Это ты так думаешь, а не я.
И потом при чём тут конспироложество, вообще? То, что рынку крупными игроками навязана та, или иная модель -- это экспериментальное наблюдение, а не конспироложество.
>>Типа прогресс ПО состоит не в том, что оно становится быстрее, компактнее и безглючнее, I>Именно так — прогресс в этом никогда не состоял. И так в любой отрасли.
Это просто неправда. Например, я ещё помню времена, когда ОС конкурировали именно по скорости, надёжности и компактности. Тот же лялих себе долго-долго это в мегаплюс записывал. Не знаю, записывает ли сейчас
Я думаю и ты их вспомнишь, если напряжёшься. Они закончились всего лет восемь назад
>>а в том, что оно становится фичастее.
I>Именно так.Фичи они всегда востребованы на рынке. Это не значит софт ценен списком фич. Это значит, что новые фичи экономят(или дают заработать) бОльше времени/денег, чем старые.
Это тоже маркетинговое враньё. Во-первых, лично тебе приносят пользу только те фичи, КОТОРЫЕ ТЫ ИСПОЛЬЗУЕШЬ, а те, которые не используешь -- приносят вред
Во-вторых, фичи они тоже разные бывают...
Вот как сильно возрос список лично тебе нужных фич текстового редактора, со времён 7-го ворда, например?
I>А тормоза — это издержки. Время/деньги важнее.
Ну так я же написал, что куда оптимизировать -- это вопрос ценностного выбора и маркетинговой стратегии (ну типа совсем УГ выпускать стрёмно, и из-за репутационных потерь и из-за того, что бренд загубишь) E>>Прикольно при этом то, что даже разрабы свободного или условно свободного ПО тоже ввязались в войну фич, а вовсе и не скорости, компактности и безглючности...
I>Ты наверное сидел в той же конуре что и Дворкин. Фичи определяют вообще все, это единственное, за что можно покупать софт, если они конечно работают должным образом.
Нет. Если бы это было так, то не было бы облегчённых версий, например.
Скажем я дома использую хомяк файна, а не его профессиональную версию. Как ты думаешь, почему?
При этом я использую хомяк одного из последних, тем не менее, хотя на нетбуке, использую всё же пятёрку. Тоже, как ты думаешь, почему?
Мало того, я ещё больше утверждаю.
1) Большинство пользователей не понимают, что у каждой фичи есть стоимость владения. Так что каждая неиспользуемая фича -- это убыток.
Например, я пользовался очень навороченными телефонами, а потом осознал, что это мне не надо, и теперь юзаю очень простую звонилку. Зато маленькую и с длинной батарейкой. И дешёвую довольно
2) Большинство пользователей вообще не дают себе труда как-то систематизировать свои действия и сценарии работы. Так что они вообще не могут понять какие фичи им нужны, какие нет, а какие конкретно мешают и снижают производительность. Например, большинство известных С++ разрабов, в большинстве известных мне проектов склонны переусложнять код
E>>Видимо после редакторов вроде пятого ворда на эту тему мало что можно нового сказать E>>Жалко только, что на современных компах он не работает
I>Это тебе его достаточно, а я его и видеть не хочу.
Почему? Как думаешь, какой фичи современного форда тебе не хватит в пятом?
Наверное красных волнистых линий снизу? А там и так уже "всё было".
Но если тебе не хватит-го, который ты, скорее всего не видел, так как под винду он вроде как не выпускался, то может скажешь чего тебе не хватает в седьмом, например?
I>Вот простой пример про фичи — тебе нужно выбрать между почтовыми клиентома, один умеет отсылать-принимать почту , а в другой интергрирован чат, buzz, rss и прочая дрянь.
I>Если ты берешь первый, стало быть понадобится ее кучка софта если тебе нужны фичи.
I>Но если тебе нужны фичи — ты можешь взять второй.
Я возьму первый, так как редко всё сразу бывает хорошо.
I>Открою тебе большую тайну, которая на самом деле большая банальность, но для тебя до сих пор это именно тайна — софт не нужен пользователю. I>Начало длинного объяснения. I>И компьютер не нужен.
Я согласен с этим тезисом.
I>Ему нужны общение, познанние, развлечение и тд. I>Компьютер это только средство.
Причём неудачно. Удачное -- это, например, римские термы
I>Им нужен софт который умеет решать все дела.
Я считаю, что эта модель навязана крупными производителями ПО. Программы в современных ОС довольно таки бесшовно склеены. Так что нет нужды беря мыльницу, брать в комплекте ещё и rss. Тем более, что подавляющему большинству пользователей rss вообще не нужен. Нужны новости с сайта, например. И это уж головная боль сайта, как доставить новости пользователю. А то, что при этом сейчас принято юзать уневерсальные всемогутеры, так это так пользователей воспитали.
Вот одно время было можно кухонными комбайнами пользоваться, а потом до многих таки дошло, что кофемолка, блендер, миксер, эл/мясорубка, тестораскаточная машинка и ещё пара ОТДЕЛЬНЫХ, удобных приборов намного лучше. Это всего лишь мода и ценностный выбор
Вот автомашина у тебя электричество для дачи вырабатывает, например? Нет? А почему, ведь она может в принципе?
I>Что это за софт, ты уже знаешь — браузер, т.е. единственно настоящий софт который умеет решительно все.
Полный бред. Браузер почти ничего полезного не умеет. То, что всё надо делать через б., который при этом должен быть х. -- это маркетинговое враньё, распространяемое гуглом. Просто потому, что ему так выгодно.
Вот смотри, на домашнем компе, я
смотрю кино/слушаю музыку (это на одном, отдельном)
пишу и редактирую тексты
пользуюсь всяким специфическим софтом, вроде бюджетирования и планирования рационов спортивных походов, например.
Храню приватную инфу
Хожу по нету.
Ну и что из этого умеет браузер?
I>Все остальные софтины, кроме средств разработки, по функционалу стремятся именно к браузеру.
Тоже бред. Скажем касперский, файнридер, винамп туда нифига не стремятся вроде как...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Antikrot, Вы писали:
A>нормальный пользователь хочет фич, плюшек и возможность попить чай/кофе пока тормозит ворд,
Это нормальная офисная планктонина так хочет, а не пользователь. Некоторым таки надо результат и поскорее, а не восемь часов за зряплаты штанишки протирать
A>а отдельные личности почему-то решили, что надо пользователя ткнуть мордой в текстовый экран и заставить набивать текст/код на скорость — естественно, они в пролёте. к тому же, война фич даёт работу много кому, и это правильно.
Ой, да хоть порнодвижок себе в ворд исталльте и тахайтесь с вордом на здоровье!
Но я бы хотел иметь возможность пользоваться нетормозным текстовым процессором...
Я лично, для себя...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Да и то, что GMail какой-то там мегаотзывчивый -- это всё песни. Отзывчивый он на моём ноуте, на котором я продакшин код нашей системы на несколько лимонов LOC компилю. А на нетбуке, например, он тормозит и чахлый очень. А всё потому, что нетбук часто "тока что с мороза" бывает, и при этом ещё и памяти там не много...
это всё временная фигня. нетбуки будут развиваться в сторону умощнения (я так думаю). мы всё это проходили и с десктопами, и с мобилами, и много ещё с чем.
Здравствуйте, Erop, Вы писали:
A>>нормальный пользователь хочет фич, плюшек и возможность попить чай/кофе пока тормозит ворд, E>Это нормальная офисная планктонина так хочет, а не пользователь.
если, как ты сказал, даже писатели "свободного" повелись, значит это устраивает большинство. по вопросам надобностей меньшинств — это к cyberax'у, он у нас тут толерастией болен.
E>Некоторым таки надо результат и поскорее, а не восемь часов за зряплаты штанишки протирать
и солнце, кстати, ещё высоко
E>Но я бы хотел иметь возможность пользоваться нетормозным текстовым процессором... E>Я лично, для себя...
ну и напиши для себя. только если каждый так сделает — получим бардак как с кучей разных линухов. вот и делают "все возможные фичи в одной программе".
Здравствуйте, Ikemefula, Вы писали:
I>Т ж говорил что фунункционал не главное, а главное — скорость, компактность и тд.
Ты споришь про абстрактные какие-то продукты. А я тебе пытаюсь пояснить, что текстовый редактор и мыльница уже 15 лет назад умели всё, что на самом деле нужно. И умели это неплохо. А ты опять про свой ноутпад. А речь не про ноутпад, а про войну фич.
E>>И потом при чём тут конспироложество, вообще? То, что рынку крупными игроками навязана та, или иная модель -- это экспериментальное наблюдение, а не конспироложество. I>Это конспироложество. Ты вообще можешь хоть как то объяснить, каким образом было навязано это дело ?
Так же как и любая мода. Вот как iPhone навязан, например? Хорошие PR + маркетинг,..
I>И сейчас и раньше в первую очередь конкурировали по фичам для пользователя, а потом — по перформансу и тд.
Ну перфоманс был одной из ВАЖНЫХ фич...
E>>Это тоже маркетинговое враньё. Во-первых, лично тебе приносят пользу только те фичи, КОТОРЫЕ ТЫ ИСПОЛЬЗУЕШЬ, а те, которые не используешь -- приносят вред I>Так враньё или приносят таки пользу ?
Ну те, которые ТЕБЕ НА САМОМ ДЕЛЕ нужны, приносят пользу, а те, которые нет -- пользу уносят. Если вторых много больше, чем первых, польза в среднем может стать отрицатльной
I>Естественно, лишние фичи(для конкретного пользователя) усложняют софт и это одна из центральных проблем в софтостроении, которая до сих пор решения не имеет.
Да имеет она решение. Просто то решение, которое выгодно пользователям не выгодно производителям ПО. Конфликт интересов групп...
I>С вордом я почти не сталкиваюсь. В таких программах уже давно развитие в основном идет за счет юзабилити.
То есть тебя бы устроил ворд 10-15 летней давности. Так?
I>У конкУрентов микрософта продукты очень часто и быстрее и компактнее, однако толку пока не видно, их даже впарить забесплатно не всегда можно.
Дык главная фишка ворда -- это то, что он везде есть. Она побеждает всё.
Но вот я, например, для редактирования своих текстов вордом сильно не всегда пользуюсь, ты. я так понял, тоже...
I>Потому что тебе нужны вполне конкретные фичи, а не их отсутствие. То есть даже хомяк файна ты берешь сначала из за фич, а потом уже из за скорости и тд.
Не, именно файна я беру из-за точности. А хомяк, чтобы не парить себе мозг сложными фичами про версии. И это при том, что я там все фичи знаю
E>>При этом я использую хомяк одного из последних, тем не менее, хотя на нетбуке, использую всё же пятёрку. Тоже, как ты думаешь, почему? I>см выше.
А вот ресурсы оказываются дороже фич. А современный рынок ПО такого выбора почти не даёт...
I>Да, но отсутствие неиспользуемой фичи может оказаться еще большим убытком.
Может, но не обязано. Вопрос сложный. Часто всё ровно наоборот происходит. Стоимость освоения новой фичи вообще превышает всю выгоду от её использования за всё время
I>Ты сто пудов пользовался говном вроде нокии и только потом "осознал"
Нокией не пользовался вообще, но я не понимаю, почему ты считаешь её "говоном"?
И, тем не менее, когда была первая война фич в телефонах и я ушёл в конце концов на простые звонилки, тоглда нокия была лидером рынка, и соответствовала выбору миллионов и могла навязать много чего юзерам.
I>Конечно, потому за них продумывают и анализируют другие люди, а потребители действуют интуитивно — вызывает положительные ощущение, пользуются. Вызывает дискомфорт — не пользуются.
Ну да, но эти люди ставят цель заработать денег себе, а не съэкономить усилий пользователю. Такой вот потреблятский рынок в ПО сформировался.
Вот в автомобилях, например, загогулина вырулила к тому, что ты сам решаешь, какие фичи тебе на борту нужны, а какие нет. А вот в ПО так пока не делают
I>То есть откажешься от нужной фичи что бы все остальные работали хорошо ?э
Конечно. Если это не какая-то супер0пупер мега нужная фича, например основная функциональность
Скажем, я легко откажусь от фоновой проверки орфографии, если за это получу производительность. Мне не жалко кнопочку нажать, а ждать пока компик протупиться жалко
I>Так поступают ПРОФЕССИОНАЛЬНЫЕ пользователи. I>Для обычных пользователей отсутствие мелкой фичи может вылиться и выливается в недельный геморрой.
Это просто от того, что у них сформирована такая модель поведения. Реально нужных фич очень мало, и они все везде давно реализованы
I>Ага, которые были доступны примерно одному из тысячи, при том что компьютер доступен примерно каждому пятому-десятому.
Это где он так доступен?
Кроме того, не понятно, что мешает сейчас сделать заведение вроде терм доступным каждому желающему?
Ну термы тебе не нравятся, можно про пабы потереть
I>Такие тенденции вообще везде. В любой отрасли. Миниатюризация + увеличение возможностей.
Дык это особенность последних несколько десятков лет. Одноразовые всемогутеры на полгода, которые потом надо заменить ещё более одноразовым ещё более всемогутером...
Это такая бизнес-модель эпохи НТТР. Если удаётся навязать в каком-то сегменте рынка такое поведение потребителям, то дальше хорошие вещи делать не надо, надо делать вещи, которые можно хорошо впарить.
I>Я все чаще вижу, как люди машину используют как медиа-центр для дискотек на даче.
И это что, удобно? Или качество звука хорошее получается?
I>Это еще до гугла произошло. Просто мало кто заметил и по этой причне гугл и заработал деньги.
Да гугол это продвигает, а перед этим M$ продвигала, которая хотела ентерпрайз на свой IE6 подсадить. Вот так маркетинговую политику и заточили...
Да и неудобно же это нифига. Удобно иметь несколько простых интерфейсов для конкретных вещей.
Вот телевизор -- это удобно. И магнитофон с радио -- удобно. А комп, в качестве медиацентра -- источник наслаждения от секса с компом, а не от музыки и кино
А если про тенденции говорить, то все идут в телефоны сейчас, и прочие мобилы. И там лишняя прокладка в виде браузера нафиг не упёрлась
E>>Вот смотри, на домашнем компе, я E>>смотрю кино/слушаю музыку (это на одном, отдельном) E>>пишу и редактирую тексты E>>пользуюсь всяким специфическим софтом, вроде бюджетирования и планирования рационов спортивных походов, например. E>>Храню приватную инфу E>>Хожу по нету.
E>>Ну и что из этого умеет браузер?
I>Абсолютно всё, кино, музыку, тексты,
Хреново он это умеет. Особенно тексты редактировать и НОРМАЛЬНО кино показывать. Нормально -- это с 5.1 или 7.1 звуком + выбор камеры, языка, титров, 3D, и т. д...
I>бюджетирование, планирование, приватная инфа.
Соответственно браузер встаёт и идёт лесом
I>Ну а по нету, ясное дело, ты браузером ходишь.
Ну вот это он и умеет. Но всё хуже и хуже, кстати.
I>Винамп это отстой. Другие плейеры именно к браузеру и стремятся. Касперский — это системный софт, он вобщем то никаких потребностей не удовлетворяет. Файнридер — специализированый, он тоже никаких потребностей не удовлетворяет.
Не понимаю, что значит "никаких потребностей не удовлетворяет"? Зачем тогда его ставить?
И почему винамп отстой? Зачем прослушивалке музыки браузер?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Antikrot, Вы писали:
A>это всё временная фигня. нетбуки будут развиваться в сторону умощнения (я так думаю). мы всё это проходили и с десктопами, и с мобилами, и много ещё с чем.
Да тоже упрутся.
Мощность она же небесплатная. Мощность -- это значит больший вес при меньшем времени жизни...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Это будут расуждения о потреблении памяти данным интерпретатором js и в данных условиях. Вот делаем WPF приложение "Hello, World", оно имеет Commit Size 55 Mb. На основании этого делаем вывод, что написание программы "Hello, World", требующей менее 50 Мб, невозможно. А тут кто-то приходит и говорит, что видел "Hello, World" размером в 100 байт...
Ну да, разные интерпретаторы js в одинаковых условиях отработают по-разному. Один памяти меньше съест, а другой по времени лучше окажется. Но причем здесь "Hello, World" на WPF? Я понимаю, пятница, неделя тяжелая была. И тем не менее, не вижу связи первого предложения в абзаце со следующими.
PD>Объемы увеличились (немного), скорость процессора возросла (существеннеее). Верстка к делу не относится, ее не на клиенте делают, а рендеринг идет на данном мониторе, а не на разных. И все равно это не более чем вывод 4 Мб текста и графики в конечном счете в каждый момент времени.
10 лет назад разве были страницы с таким объемом картинок, как сейчас? Я помню, один мой приятель, делая себе WEB-страничку, неслабо напрягался, чтобы размер ее не превышал 30 К. А сейчас только одна картинка на странице мегабайт весить может. Это, по-твоему, немного? Поищи по RSDN, посмотри на вес анимированных GIF-ов.
PD>Не годится такой аргумент. Если бы мы дырявили перфокарты, то не было бы броузеров и не о чем было бы говорить. А вот если бы памяти было 256 Мб, и даже 64 Мб, и даже 16 Мб, то броузеры бы были и как-то с задачей вывести один экран текста и графики справились бы — так, как они справлялись в те времена.
Это и не был аргумент. Вести дискуссию в стиле "если бы" — даже не смешно. Можно говорить все, что угодно и в любой форме. Так что можешь расценивать мое "если бы" как продолжение твоего "если бы".
Вот ты ругал давеча Visual Studio 2005 за тормоза и хвалил VS 6. Я 10-12 лет назад за то же самое ругал VS 6, вспоминая с тоской, как хорошо работает Developer Studio 4 на Pentium-100 в 16 Мб.
Заметим, что связь нужна. И (ох уж эти "если бы!") в альтернативной реальности вместо компьютерных сетей она могла бы быть построена на других решениях.
Может быть, js сейчас не является самым удачным решением для скриптов на клиентской стороне. Рынок не всегда выбирает лучший вариант. Может быть, нужно что-то принципиально иное. Не знаю. Но раз имеем, что имеем, придется соответствовать. И, похоже, пока соответствует. Chrome нормально живет рядом с IDEA и парой открытых окон OOWriter.
Re[41]: Перешёл на личности -- значит... ну сам знаешь ;)
Здравствуйте, Ikemefula, Вы писали:
I>>>JS это тоже задача, только цель другая. E>>Да нет такой пользовательской задачи, как JS. Ты ещё скажи, что С++ -- это тоже задача. I>У тебя какие то проблемы с прочтением "только цель другая" ?
А у тебя, видимо, с прочтением слова "пользовательской"?
Может обойдёмся без перехода на личности?
I>Ну так и нехрен гнать.
Нк по мне, так почти любая мыльница удобнее г. мыла...
I>См. выше — нехрен гнать, если не можешь алтернативы предложить.
В смысле? Ну the Bat, например...
E>>А про "функциональнее", так в том-то и поинт. Что часть этой "функциональности" занафиг никому не упёрлась, и добавили её только потому. что I>Как правило, пользователи выбирают много функциональные сервисы. Потому как общение не сводится к отправке почты. Это и чаты и социальные сети и тд и тд и тд.
Дык это завоевание агрессивного маркетинга. И что это доказывает, кроме того, что маркетинг -- мощная штука, а индейцы с папуасами, в своё время меняли золото на стеклашки, но выводы из этого сделали продавцы, а не покупатели?
>>Тем не менее война фич несомненно ухудшает ВСЕ участвующие продукты. I>Ты все еще в каменном веке живешь.
Давай ты будешь обсуждать идеи, а не меня. Где именно я живу, я всё равно знаю лучше тебя, и ты тут некомпетентен и ничего интересного не скажешь. Разве что новое ругательство какое сообщишь...
I>Нетбук — мертвая ветка эволюции.
Давно? Мне вот, например, удобно.
I>Ты самое главное взял и скипнул, вобщем, ты как был трололо, так и остался трололо.
Опять блин какашками кидаешься, вместо аргументов? Думаешь убедительно выходит?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ikemefula, Вы писали:
I>При этом пользователю надо не текст и почта, а общение. А для этого надо побольше тех самых фич.
Как сказал в своё время Горин -- "для этого надо совсем другое"...
IMHO, для общения надо не фичи, а желающие с тобой общаться.
Интересно, не мог бы ты перечислить пять фич, которые увеличивают число желающих общаться с тобой. Надеюсь ты не про боты?
Опять же общение, оно разное бывает. Бывает глубокое, интересное, неслучайное. А бывает так, в режиме "сделаем это по быстрому".
Второе, IMHO, это просто суррогат. Почти на уровне ботов.
И лично мне так кажется, что если "фичи" используются для абстрактного "общения", то они просто ухудшают его качество, и всё...
IMHO, тезис о том, что для лучшего удовлетворения потребности в общении, нужно насыщать мыльницы фичами, столь же неверен, как тезис, что для увеличения количества любви в мире надо сауны переоборудовать в публичные дома...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
I>>Умели только редактировать текст, чуть лучше чем нотпад, и умель только отсылать почту. E>Ты можешь просто и понятно объяснить, какой именно фичи тебе не хватало в пятом ворде, например? E>Если не помнишь/не видел пятого, что весьма вероятно, то какой не хватало в 7-м?..
Я же сказал, что с вордом сталкиваюсь не часто.
I>>Не нужна пользователю почта. Ему надо общаться. E>Не. Чтобы общаться надо вообще другое. Надо не в компе сидеть, а идти к людям, тусовать где-то и т. п. E>Для развлечений тоже самое.
И поэтому люди просиживают в социальных сетях чуть не все рабочее время ?
E>А сколько ты фич на браузер не навернёшь, общение лучше от этого не станет. Так что давай не будем повторять маркетинговое враньё?
Загляни в свой профайл и посмотри количество сообщений. Это общение или маркетинговое вранье ?
E>Утверждать, что пользователям нужно общаться, поэтому им нужны чаты и соц. сети, это примерно тоже самое, что утверждать, что людям нужно счастье, поэтому им нужны наркотики...
Попробуй подумать, что побуждает тебя писать столько сообщений. Может у тебя какая то другая потребность но она тем не менее есть.
E>Кроме того, если кому-то нужна социальная сеть, то ему нужна социальная сеть. Так бывает. Соц. сети легко вызывают зависимость. Так же как и героин.
В социальных сетях люди развлекаются, общаются и тд. Ничего удивительно — усилий ноль, эффекта море.
I>>Общение включает в себя не только отсылку и прием почты, но и чаты и социальные сети и прочую дрянь. E>Ты сам понимаешь, что все эти "фичи для общения" -- это дрянь. Почему же ты утверждаешь, что пользователи нуждаются в дряни?
Я не считаю что это дрянь. И я хорошо понимаю, что если люди просиживают целые дни в социалках, то они точно обрадуются мессенгеру, который интегрирует эти социалки в одной программе.
E>IMHO, вполне понятно, что их на эту дрянь осознанно подсаживают, с целью паразитировать потом на возникшей у человека зависимости.
Да, наверняка это производители софта навязали идею, что с одноклассником очень круто побеседовать много лет после школы. Как это я сразу не догадался то.
I>>По этой причине нынешние почтовики такую потребность как общение удовлетворяют гораздо лучше, чем раньше. E>Да ну? Что это за "нынешние почтовики" такие? Вот, например, я общаюсь с коллегами в одном закрытом театральном чате, и тут. И иногда обмениваюсь инфой с руководителями тургрупп, на всяких спец. ресурсах. И в какой же почтовик это всё интегрировано, можно узнать?
Ну так я тебе давно сказал, что ты в конуре живешь. Хочешь рсдн интегрировать — открой для себя рассылку, ннтп или рсс хотя бы.
I>>Никто не навязывал. Пользователи приняли. Реклама всего лишь ускорила этот процесс. E>Что они приняли? Что вообще нового/хорошего/нужного в аймобилко? Прибор для измерения ускорений? И то не ново было...
Старые фичи работают просто, понятно, удобно и приятно.
Я вроде уже говорил, что есть нефункциональные фичи, до тебя это никак не дойдет.
I>>Приняли потому что удобно, просто, функционально. E>Я так не считаю. Я считаю, что 99% пользователей купили себе аймобилко потому, что это круто и модно, а не потому, что это как-то там удобно или функционально.
Ну так это и неудивительно. Сколько я тебя помню, ты все время рассказываешь мне, что у меня не может быть моего мнения
I>>Он и сейчас важен, только никогда самой главной фичей не будет. E>Это не правда. Кому как и когда. Когда припекает, то главная функциональность выходит на первый план. А когда пофиг всё, то шашечки становятся важнее...
Это чушь. Функциональность всегда на первом месте. А вот если годами забивать на нефункциональые возможности, то конечно люди захотят нечто, что будет просто работать.
I>>Это и ежу понятно. И сейчас лишние фичи в таких продуктах как Офис вообще не мешают. E>Так ты определись, вредят ли лишние фичи, или нет?
Я уже давно определился и внятно объяснил.
E>Вот я уверен, что вредят. Но обсуждать именно это нужно в отдельном топике, IMHO.
Фичи нельзя рассматривать отдельно от реализации. Функциональное нельзя рассматривать отдельно от нефункционального.
I>>Ты про них и не знаешь, пока не понадобятся и только по этому ты утверждаешь что их там нет. E>Кого и где нет? И про кого я это утверждаю?
Про офис. Ты ведь рассказывашеь, что никаких фич не добавилось Они добавились, только ты про них не знаешь.
E>Ты не понимаешь, как тебе вредят фичи ворда про которые ты не знаешь?
Перечитай предыдущее сообщение, а то твои слова на генератор бреда похожи.
I>>Нет и ответ на это был даден. Старым вордом очень тяжело пользоваться. E>Почему? Чего в нём не хватает? Кстати, кто такой "старый ворд"? 2-й? 5-й? 6-й? 7-й? 2000-й?
Примерно любой до 2007го. 1997 я пользовад примерно 10 лет.
Риббона не хватает, банально, да ?
I>>У меня есть VS2010, это основной редактор. Еще есть Onenote 2011. Ворд — раз в месяц и я не хочу того говна которое было 10-15 лет назад. E>Так что именно тебе не нравилось в старом ворде, или что хорошего появилось в новом?
Риббон. У тебя , походу, какие то проблемы с вордом. Сколько раз тебе повторить, что бы ты понял, что вордом я пользую очень мало ?
I>>Во первых, из за фич. Именно набор фич делает софтину файном. А точность это еще одна фича, только нефункциональная. E>Не понимаю о чём речь. Файном файн делает то, что им можно распознать страничку И НЕ ПРАВИТЬ ЕЁ ПОТОМ. Это основаня главная и единственная фича.
Это ты так думаешь. Между тем файн это набор фич, функциональных и нефункциональных.
Точность — это нефункциональная фича.
E>Вторая важная фича -- это если уж пришлось править, то удобно смотреть что было нарисовано в
Только что сказал, что в файне только одна и единственная фича и тут же про вторую рассказываешь.
У тебя какие то проблемы с русским языком ?
I>>Судя по твоим выступлениям, ты понятия не имеешь, что такое нефункциональные фичи а между тем на это огромный спрос. E>Ну ты объясни, что это такое.
Точность — это нефункциональная фича. Юзабилити — это еще целый набор таких фич.
E>Второй тезис состоит в том, что спрос на большинство фич, хотя бы и огромный, создан искусственно. И на самом деле они не нужны.
На самом деле людей очень много. Больше, чем ты можешь себе представить.
Интересы у всех разные.
Писать по пять версий редактора что бы удовлетворить всех — это уже пройденый этап.
Пишется одна, которая покрывает 95%, остальные идут к конкурентам.
E>Первый тезис состоит в том, что обилие фич, особенно не сильно нужных, не стоит тотального утяжеления ПО...
Автомобиль это уже давно больше чем 4 колеса и двигатель внутреннего сгорания. Это обязательно еще целый вагон фич.
Иди купи автос и скажи что бы выкинули три сиденья да багажник, потому что ты де в одиночку хочешь кататься и тебе все это не надо
С софтом идея та же самая — редактор это Ворд. Табличный процессор — Эксель. Почтовик — Аутлук.
Набор обязательных фич. И пользователю это выгоднее, потому что мелкие редакции гораздо сложнее продавать, сопровождать, разрабатывать и тд.
E>>>А вот ресурсы оказываются дороже фич. А современный рынок ПО такого выбора почти не даёт... I>>Какие ресурсы ? Самый главный ресурс это время. Нынешние фичи его экономят гораздо лучше, чем те что были 10 лет назад. E>Примеры будут?
Переписка с друзьями. Щас в гугле можно мышом на раз сделать то, для чего 10 лет назад нужны были десятки сайтов и программ.
E>Давай рассмотрим редактор текста и мыльницу. Раз уж мы про это говорим. Какие такие фичи, скока времени экономят, при каких раскладах...
Все это доступно из почтовика. 10 лет назад здесь нужно было минимум 6 програм. Сейчас это один сайт — gmail.
E>А то пока что ты показал, как переделав мыльницу в чат-переросток можно сжечь сколько угодно времени, а не сэкономить
А это не твоё дело. Главное что он потратил время как ему надо, а не на ожидание обновление страницы, что было нормой 10 лет назад.
I>>Это значит что фича по факту отсутствует. E>Нет не значит. Она по факту присутствует, и навязывается даже. Так как фичу заказали маркетологи,
Это ты думаешь что она присутствует.
Маркетологам известно, что фича это только то, чем можно легко и просто пользоваться.
А вот девелоперы вроде тебя думают что фича это то что они пишут, максимум — то что будет присутствовать.
E>Ещё раз, что за фичи в современном ворде делают его ДЛЯ ТЕБЯ лучше, по сравнению с 7-м или 5-м? И откуда ТЫ ЛИЧНО узнал, что именно эти фичи, а не какие-то другие?
Ты дурак или у тебя с русским языком проблемы ?
E>1) Сейчас выгодно делать так, чтобы пользователю захотелось проапгрейдлится. Решения "на века" нынче мало кто предлагает
Нет здесь никаких тонкостей. Риббон 10 лет назад при всем желании нельзя было родить.
E>2) На короткое время "нравится/не нравится" можно сильно сместить при помощи PR и рекламы.
Только на короткое. А дальше надо удерживать качественным исполнением.
I>>Автомобиль это длинный перечь обязательных фич которые ты менять не можешь. E>В смысле? Есть много ОЧЕНЬ разных автомобилей, и в каждой модели ещё есть широкие варианты кастомизации, обчно...
Размеры, цвет, углы наклона руля. А ты купи машину с тремя колесами или без сидений и багажника.
Я вот хочу купить Мерседес вообще без двигателя !
I>>Более того, если ты залезешь в базу аналогов по автомобильным запчастям то сильно удивишься. E>Платформы -- это дело разрабов. Пользователям они до фени.
А цена пользователям до фени или нет ?
I>>Аналоги могут отличаться по цене на порядок при абсолютно одинаковом качестве. E>Да, и дело тут опять же только и исключительно в маркетинге. Тем, не менее, у автомобилей нет войны фич.
Война точно такая же и фичи точно так же постепенно мельчают, как с офисными пакетами.
E>Дык оно не поедет. ОСНОВНАЯ ФУНКЦИОНАЛЬНОСТЬ не заведётся без задних колёс.
Ну и что ? Кому какое дело как ктото будет автос пользовать ?
I>>В софте все идет к тому же — обязательный перечень фич для определенных пакетов. E>Примеры, можно?
ворд, эксель, ide
>Вот у автомобилей, которые, кстати, сильно сложнее софта, всё просто. Есть основные эксплуатационные характеристики. Ну там, шумность в салоне, как оно рулится, динамика, материалы салона, место в салоне, место в багажнике, безопасность, экономичность, надёжность и ремнотопригодность и т. д. А есть "бантики". Ну, там, встроенный mp3 проигрыватель, например. Вот по бантикам автомобили почти не конкурируют, а по экономичности или тяговитости -- очень даже.
Это все фичи, а ты говоришь войны нет
E>А в современном ПО, грубо говоря, всем пофиг скока оно будет бензина кушать, главное, чтобы можно было машину на ходу перекрашивать, и в бардачке было отделение для презервативов, а пассажирское сиденье позволяло заюзать максимум поз из "Кама Сутры"...
Стоимость владения разная. Бензином ты за год можешь половину стоимости авто потратить. А железо компьютерное стоит буквально копейки.
Если комп будет стоит как авто, а софт — как бензин расходоваться, все будет точно так же — будут экономить и байты и биты.
I>>Наоборот. Они просто не умеют пользоваться компьютером, софтом. Для этого нужны годы опыта. А вот у тебя именно сформированая модель поведения. E>Ну и, тем не менее, телефизором или авто они тоже не умеют пользоваться профессионально. Тем не мене, модель поведения другая. E>И в одежде, напирмер, и в еде, тоже другая.
Везде разные модели поведения. Я вот обувь беру первую что на ногу налезет, а вот ноутбук выбираю очень долго. А ножи так и вовсе годами.
ничего удивительного нет, нельзя человека описать одной формулой, как тебе хочется.
I>>Где есть вода и другие ресурсы это уже есть. И обычно складывается так, что в этих же странах и компьютеров больше всего. E>Чего? Где в Москве, например, я могу в аналог римских терм сходить?
Да.
E>Я наверное как-то не так, как ты понимаю это понятие. По мне так нет никакого *ложества. Есть просто групповые интересы производителей. Если производителям удаётся навязать
"навязать" == конспироложество.
E>Вот последние 10 лет в области общения/развлечения доминирует модель НТТР. То есть чем новее метод, тем лучше. А вот в области питания нифига. А вот 200 лет назад эти области не отличались, например. Так в чём же принципиальная разница между хлебом и зрелищами?
Сходство и тогда и сейчас — еда вызывает положительные ощущения, организм вырабатывает стимул в виде эндорфинов при поступлении еды. А разница в том, что зрелищами насытиться не получится.
Сейчас ты практически не тратишь энергии на развлечения, это объясняет почему популярны компьютеры.
E>А что именно удобно? То, что машину нельзя глушить? То, что она пердит наприроде? То, что нельзя, в случае дождика в дом пойти?
Удобно, что не надо на себе нести 100 кг аппаратуры. В дом идти никто не запрещает. А к выхлопам городские привыкли.
E>По идее бумбокс средней паршивости, в качестве "музыки для дачи" превосходит таки машину по всем статьям. E>Качество звука я обсуждать тут не буду, просто потому, что это тут тоже очень далёкий офтоп.
Бумбокса этого и слышно рядом с машиной не будет.
Ты хоть раз видел серьезную акустику для автоса ? Там внутри салона до 100 и более децибел, оглохнуть можно. Никакой бумбокс такой громкости не даст. Нету бумбоксов такой мощности.
I>>Очевидно — хорошая автомобильная аккустика дешевле на несколько порядков варианта А, несравнимо легче варианта Б и намного качественнее варианта В. E>Да ладно уж там. Хорошая автомобильная акустика хороша, когда ты её в салоне слушаешь, а не рядом с тачкой
Ты не видел хорошей акустики вероятно, когда весь багажник под сабвувер, колонки и прочую дрянь.
E>Кроме того, для дискотеки, уровня "автомагнитола из открытой дверцы", не надо "полно аппаратуры", однако.
Я уже и не знаю, как бы тебя из конуры выманить то
E>Так это они когда уже всех сделали. А до этого очень даже продвигала. Или ты думаешь вся индустрия написания ентерпрайза под IE сама собой возникла?
Продвигали, а потом взяли и забили. С мобильными приложениями было тоже самое.
I>>И то и другое редкое говно. Телевизоры все больше становятся похожими на компьютеры, E>Ой, правда, что ли? И как много настроек есть в твоём телеке? Хотя бы сотня наберётся? А на администрирование компа можно потратить бесконечные ресурсы...
Я втыкаю антену в комп и не надо ничего администрировать, только тюнер запустить
E>Это зависит. Но у меня, например, есть DVD-игралка. Она ни разу не ноут. А у соседей есть несколько игровых приставок для детей. (Мы против комп. игр для детей). Так приставки тоже на компы ничем не похожи. Там диск вставляешь и играешь. И всё.
Старьё.
E>У тебя есть какая-то идея, про функциональные и нефункциональные фичи.
Это не моя идея. Просто ты про это ничего не знаешь.
I>>Вылезь из конуры хоть на пять минут ? E>В смысле? Ты зранишь приватную инфу в гугле? Или что?
Ты плохо понимаешь, какие нынче возможности в вебе.
E>В моём случае, я комп использую утилитарно. Либо как источник аудио и видио сигнала, либо как устройство для обработки информации, либо для доступа в нет. Я, кстати, обычно для каждой из этих целей использую разные компы. Так что если бы их всемогутность была бы ограничена, я бы только радовался.
Не валяй дурку, отвечай, какую потребность удовлетворяет Касперский — общение, развлечение, познание и тд.
I>>Для покупки, скачивания и тд. Вот нарыл ты музыки чуток и хочешь найти остальные треки или альбомы ? E>Мне лично для покупки музыки винамп не нужен. Это наоборот, держателю прав нужно, чтобы мне было удобно из винампа найти и купить.
Не для покупки, так для скачивания. Какая разница ?
E>А всё как-то по старинке предпочитаю. Я вот и книжки предпочитаю выбирать в уютном книжном, с диванчиками и кофе, а не по банерам в браузере
Здравствуйте, Erop, Вы писали:
I>>При этом пользователю надо не текст и почта, а общение. А для этого надо побольше тех самых фич. E>Как сказал в своё время Горин -- "для этого надо совсем другое"...
E>IMHO, для общения надо не фичи, а желающие с тобой общаться.
Спасибо, просветил.
E>И лично мне так кажется, что если "фичи" используются для абстрактного "общения", то они просто ухудшают его качество, и всё...
Объясни это посетителям социальных сетей.
E>IMHO, тезис о том, что для лучшего удовлетворения потребности в общении, нужно насыщать мыльницы фичами, столь же неверен, как тезис, что для увеличения количества любви в мире надо сауны переоборудовать в публичные дома...
А тебя не пугает что табак и алкоголь свободно продаются ?
Нет бы людям закончить курсы счастья и жить всю жизнь в блаженстве, так они, быдло тупое, идут зарабатывать деньги и тратят их на бухло и курево.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Это будут расуждения о потреблении памяти данным интерпретатором js и в данных условиях. Вот делаем WPF приложение "Hello, World", оно имеет Commit Size 55 Mb. На основании этого делаем вывод, что написание программы "Hello, World", требующей менее 50 Мб, невозможно. А тут кто-то приходит и говорит, что видел "Hello, World" размером в 100 байт...
P>Ну да, разные интерпретаторы js в одинаковых условиях отработают по-разному. Один памяти меньше съест, а другой по времени лучше окажется. Но причем здесь "Hello, World" на WPF? Я понимаю, пятница, неделя тяжелая была. И тем не менее, не вижу связи первого предложения в абзаце со следующими.
Связь очень простая, она к пятнице отношения не имеет. Если есть WPF программа "Hello, World", требующая 55 Мб, то из этого не следует, что для написания программы "Hello, World" жизненно необходимо 55 Мб. Если есть интерпретатор js, требующий 100 Мб, то из этого не следует... ну ты понял.
PD>>Объемы увеличились (немного), скорость процессора возросла (существеннеее). Верстка к делу не относится, ее не на клиенте делают, а рендеринг идет на данном мониторе, а не на разных. И все равно это не более чем вывод 4 Мб текста и графики в конечном счете в каждый момент времени.
P>10 лет назад разве были страницы с таким объемом картинок, как сейчас? Я помню, один мой приятель, делая себе WEB-страничку, неслабо напрягался, чтобы размер ее не превышал 30 К. А сейчас только одна картинка на странице мегабайт весить может. Это, по-твоему, немного? Поищи по RSDN, посмотри на вес анимированных GIF-ов.
А при чем тут GIF ? Их, что js анимирует разве ? А разве 10 лет назад не было картинок под пол-Мб ? Ну не GIF, так JPG уж точно были.
PD>>Не годится такой аргумент. Если бы мы дырявили перфокарты, то не было бы броузеров и не о чем было бы говорить. А вот если бы памяти было 256 Мб, и даже 64 Мб, и даже 16 Мб, то броузеры бы были и как-то с задачей вывести один экран текста и графики справились бы — так, как они справлялись в те времена.
P>Это и не был аргумент. Вести дискуссию в стиле "если бы" — даже не смешно. Можно говорить все, что угодно и в любой форме. Так что можешь расценивать мое "если бы" как продолжение твоего "если бы".
Эту фразу я могу расценить только как for(i=0, i < 3; i++) "если бы"
P>Вот ты ругал давеча Visual Studio 2005 за тормоза и хвалил VS 6. Я 10-12 лет назад за то же самое ругал VS 6, вспоминая с тоской, как хорошо работает Developer Studio 4 на Pentium-100 в 16 Мб.
Я с ними всеми тремя (включая еще и VS5) работал. У меня наилучшие воспоминания именно о VS6. VS2003 я пустил впервые на той же машине, где была VS6, Но даже когда я машину сменил, она работала медленнее.
P>Может быть, js сейчас не является самым удачным решением для скриптов на клиентской стороне. Рынок не всегда выбирает лучший вариант. Может быть, нужно что-то принципиально иное. Не знаю. Но раз имеем, что имеем, придется соответствовать. И, похоже, пока соответствует. Chrome нормально живет рядом с IDEA и парой открытых окон OOWriter.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Связь очень простая, она к пятнице отношения не имеет. Если есть WPF программа "Hello, World", требующая 55 Мб, то из этого не следует, что для написания программы "Hello, World" жизненно необходимо 55 Мб. Если есть интерпретатор js, требующий 100 Мб, то из этого не следует... ну ты понял.
У тебя какое то патологическое непонимание проблемы.
Для JS не надо 100мб.
Память(много меньше 100мб) нужна для JS V8 — то есть для движка с топовым перформансом.
Ты даже представить не можешь, насколько JS V8 обошел конкурентов.
P>>10 лет назад разве были страницы с таким объемом картинок, как сейчас? Я помню, один мой приятель, делая себе WEB-страничку, неслабо напрягался, чтобы размер ее не превышал 30 К. А сейчас только одна картинка на странице мегабайт весить может. Это, по-твоему, немного? Поищи по RSDN, посмотри на вес анимированных GIF-ов.
PD>А при чем тут GIF ? Их, что js анимирует разве ? А разве 10 лет назад не было картинок под пол-Мб ?
Не было таких картинок в вебе. Их скачивать надо было очень долго.
PD>Я с ними всеми тремя (включая еще и VS5) работал. У меня наилучшие воспоминания именно о VS6. VS2003 я пустил впервые на той же машине, где была VS6, Но даже когда я машину сменил, она работала медленнее.
Вот представь — VC6 генерировал страшно избыточный код для шаблонов в С++.
Здравствуйте, Ikemefula, Вы писали:
E>>Если не помнишь/не видел пятого, что весьма вероятно, то какой не хватало в 7-м?.. I>Я же сказал, что с вордом сталкиваюсь не часто.
Ну ты же очень резко против ворда 10+-летней давности? То есть примерно так 7-го. Наверное есть причина?
I>>>Не нужна пользователю почта. Ему надо общаться. E>>Не. Чтобы общаться надо вообще другое. Надо не в компе сидеть, а идти к людям, тусовать где-то и т. п. E>>Для развлечений тоже самое. I>И поэтому люди просиживают в социальных сетях чуть не все рабочее время ?
Очень сильно не все люди. В соц. сетях могут просиживать те, кто не работают, и делают это за компом, к тому же.
Вот прикинь, сантехник, водитель, артист балета, операционистка в банке, комбайнёр, и вообще почти всё сельское хозяйство, строитель, военный, и очень много кто ещё не просиживают рабочее время в соц. сетях.
Мало того, сидение в соц. сетях ещё и разрушительно. Оно разрушительно для личности и для карьеры. Некоторые это осознают и самоограничивают себя. Кстати, я бы вот, например, с радостью юзал бы фичу. что типа не более N сообщений в сутки. И где же она?
В советское время была аналогичная тема -- курилка. И что, ты утверждал бы, что курение необходимо для общения?
E>>А сколько ты фич на браузер не навернёшь, общение лучше от этого не станет. Так что давай не будем повторять маркетинговое враньё? I>Загляни в свой профайл и посмотри количество сообщений. Это общение или маркетинговое вранье ?
В основном это не общение. Если это рассматривать как общение, то это очень некачественный суррогат.
I>Попробуй подумать, что побуждает тебя писать столько сообщений. Может у тебя какая то другая потребность но она тем не менее есть.
Я знаю что, но обсуждать это не буду.
I>В социальных сетях люди развлекаются, общаются и тд. Ничего удивительно — усилий ноль, эффекта море.
Всё ровно наоборот. Усилий море тратится, а эффекта -- 0.
I>Я не считаю что это дрянь. И я хорошо понимаю, что если люди просиживают целые дни в социалках, то они точно обрадуются мессенгеру, который интегрирует эти социалки в одной программе.
Ну вот ты тоже сознательно готов подсаживать людей на то, что сам ты называешь дрянью...
Вот так групповые интрересы производителей ПО и работают. Без всяких теорий заговора...
I>Да, наверняка это производители софта навязали идею, что с одноклассником очень круто побеседовать много лет после школы. Как это я сразу не догадался то.
Ты правда думаешь, что в "одноклассниках" люди общаются с одноклассниками? Разве что, в смысле с "представителями своей соц. группы"
Кстати, с одноклассниками через много лет общаться нифига не круто. Вот у нас в школе регулярно проходят "вечера школьных друзей". Ну народ иногда встречается, что-то трёт, но потом общение не продолжается. А вот суррогат-общение в "одноклассниках" как-то где-то возможно.
I>Ну так я тебе давно сказал, что ты в конуре живешь. Хочешь рсдн интегрировать — открой для себя рассылку, ннтп или рсс хотя бы.
Нет, так интегрировать я не хочу. Я хочу "из коробки"
I>Я вроде уже говорил, что есть нефункциональные фичи, до тебя это никак не дойдет.
Я так понимаю, что ты так называешь "бантики" они же "свистелки и перделки" и фичи вроде "общая эргономичность".
Дык вот, "общая эргономичность" она либо навязана рекламой, либо сильно индивидуальна. Второго толка была достигнута в трубках уже давно, первого сорта — -не так давно достигли. Но когда пользователям аймобилко посоветовали держать трубу особым образом, а не так как ИМ УДОБНО, то это, IMHO, ярко демонстрирует первого тут сорта "общая эргономичность" или "второго".
А "бантики" нужны, в основном, только потому, что они модные, то есть разрекламированные...
Если ты имеешь в виду какие-то ещё "нефункциональные фичи", то расскажи о них
E>>Я так не считаю. Я считаю, что 99% пользователей купили себе аймобилко потому, что это круто и модно, а не потому, что это как-то там удобно или функционально. I>Ну так это и неудивительно. Сколько я тебя помню, ты все время рассказываешь мне, что у меня не может быть моего мнения
А ты как считаешь, какой процент пользователей выбрал iPhone потому, что сравнил несколько моделей, попробовал то и сё, заценил фичи, цены, и прочие свойства продукта и ОСОЗНАННО выбрал, а какой потому, что стало модно?
I>Это чушь. Функциональность всегда на первом месте. А вот если годами забивать на нефункциональые возможности, то конечно люди захотят нечто, что будет просто работать.
Да ну. Вот тот же самый аймобилко с его проблемами с антеной, которую не видно из кулачка. Ради "бантика" пожертвовали основной функциональностью -- устойчивостью связи. И прикинь, да, прокатило. Не отзывали трубу, не было массовых возвратов и т. д.
А почему собственно? Да потому, что у айМобилко основная функциональность -- это демонстрировать продвинутость владельца. А надёжная и качественная связь -- пофигу. Так же как и возможность юзать трубу на улице зимой, например
I>Я уже давно определился и внятно объяснил.
Ну ты то говорил, что лишние фичи -- это основная нерешённая проблема современного софтостроения, а теперь говоришь, что не мешают. Какое-то противоречие усматриваю я в словах твоих
I>Про офис. Ты ведь рассказывашеь, что никаких фич не добавилось Они добавились, только ты про них не знаешь.
Не-не-не. Я рассказываю что никаких НУЖНЫХ МНЕ не добавилось
I>Перечитай предыдущее сообщение, а то твои слова на генератор бреда похожи.
Попробуй найти курсы, где учат вести себя корректно...
I>Примерно любой до 2007го. 1997 я пользовад примерно 10 лет. I>Риббона не хватает, банально, да ?
Риббон -- прямое следствие перегруженности фичами. Было бы фич в 10 раз меньше, было бы хорошо и без него.
I>Риббон. У тебя , походу, какие то проблемы с вордом. Сколько раз тебе повторить, что бы ты понял, что вордом я пользую очень мало ?
Не. Ты утверждаешь, что 1997 (это, видимо, 7-й?) было невозможно пользоваться. Я хочу понять почему. Я так понял, что из-за того, что уже и 7-й был перегружен фичами? Да?
E>>Не понимаю о чём речь. Файном файн делает то, что им можно распознать страничку И НЕ ПРАВИТЬ ЕЁ ПОТОМ. Это основаня главная и единственная фича. I>Это ты так думаешь. Между тем файн это набор фич, функциональных и нефункциональных.
А откуда ты это знаешь? Я вот, например, ежегодно общаюсь с людьми. которые фичерлист на след. версию согласовывают
I>Точность — это нефункциональная фича.
Точность -- это основа маркетинговой политики файна. Это самое главное, что там есть. Самая суть. И разрабы это хорошо понимают и за каждую долю процентика удавятся. А ты, такой умный, рассказываешь мне, что это нефункциональная фича, якобы, и что она сильно не одна.
Ну и кому мне верить? Тем, кто непосредственно фичерлист составляют, или твоему анализу?
Я, кстати, ещё одну фичу забыл -- файн хорошо сканирует для целей OCR. ФСЁ. Остальные фичи, вроде поддержки албанского языка или возможность выбора шрифта для показа текста без форматирования -- это всё неважные мелочи. Покупателям на них глубоко пофиг. Не пофиг на них журналистам, которые пишут обзоры. Хороше, если по чесноку пишут, а не прикормленные какие...
E>>Вторая важная фича -- это если уж пришлось править, то удобно смотреть что было нарисовано в I>Только что сказал, что в файне только одна и единственная фича и тут же про вторую рассказываешь.
Как я написал выше, есть ещё и третья. Но конкретно вторая, сильно уступает по важности первой. И в хомяке, кстати, её нету.
I>Точность — это нефункциональная фича. Юзабилити — это еще целый набор таких фич.
Точность, хотя бы измерима. Но, по мере прогресса технологий, она постепенно превращается в аналог мегапикселей у фотиков. Из реальной фичи превращается в фуфел. А юзабилити -- это вообще полностью неверифицируемое понятие. Если у чела создать уверенность, что если ему неудобно держать аймобилко так, чтобы оно ещё и связь не теряло, то это он урод, а не аймобилко гавно. То он немедленно САМ СЕБЕ "признается", что на самом-то деле ему удобно, конечно.
Это вообще давно известное дело, что нет обуви удобнее кирзачей + портянки Просто те, кому не удобно, ещё не научились правильно юзать
I>На самом деле людей очень много. Больше, чем ты можешь себе представить. I>Интересы у всех разные.
Конечно разные. Но это не мешает смотреть на конкретные истории конкретных людей. А не на "людей в среднем". У людей в среднем, как известно, одно яйцо и одна грудь...
I>Писать по пять версий редактора что бы удовлетворить всех — это уже пройденый этап. I>Пишется одна, которая покрывает 95%, остальные идут к конкурентам.
Конечно, только ты пропускаешь ещё один момент. На самом деле деньги делятся не так. Пишется одна, которая как-то удовлетворяет 75%, а потом ещё рекламой с PR дожимают до того, что 95% думает, что их удовлетворяет. А 5% просто идут лесом...
Потому, что конкуренты тоже метят в эти 95%, а не в 5% оставшиеся
I>Иди купи автос и скажи что бы выкинули три сиденья да багажник, потому что ты де в одиночку хочешь кататься и тебе все это не надо
У меня был автомобиль без переднего пассажирского. ВАЗ 2108...
А ещё пикапы бывают. Типа есть два сиденья, а всё пространство сзади -- под груз.
I>С софтом идея та же самая — редактор это Ворд. Табличный процессор — Эксель. Почтовик — Аутлук.
Так навязана не эта идея, а совсем другая. Та, что "редактор для всех" может так же быть ядром системы документооборота, например... I>Набор обязательных фич. И пользователю это выгоднее, потому что мелкие редакции гораздо сложнее продавать, сопровождать, разрабатывать и тд.
Я вот не понимаю, какой смысл ты вкладываешь в это "выгоднее"? Типа простой редактор будет стоить дороже ворда? Что-то как-то не верю...
I>Переписка с друзьями. Щас в гугле можно мышом на раз сделать то, для чего 10 лет назад нужны были десятки сайтов и программ.
Возможно я как-то не так понимаю, кто такие "друзья", но вот лично мне для переписки с друзьями десятки программ не были нужны никогда. Мыла и обычной гражданской почты всегда хватало...
E>>Какие такие фичи, скока времени экономят, при каких раскладах...
I>1. чат I>2. бузз I>3. доки I>4. фоты I>5. почта I>6. видео I>7. календарь
I>Все это доступно из почтовика. 10 лет назад здесь нужно было минимум 6 програм. Сейчас это один сайт — gmail.
И как и когда это всё "экономит время"? IMHO гмыл заточен под УНИЧТОЖЕНИЕ времени!
I>А это не твоё дело. Главное что он потратил время как ему надо, а не на ожидание обновление страницы, что было нормой 10 лет назад.
При чём тут выделенное?
Попробуй по каналу, который был 10 лет назад, и на компе, который был 10 лет назад с гмылом поработать, узнаешь как много времени ты сэкономишь...
У меня, кстати, в домашнем хозяйстве вполне используются и более старые компы. И я НЕ ИСПЫТЫВАЮ НУЖДЫ в их апгрейде...
I>Маркетологам известно, что фича это только то, чем можно легко и просто пользоваться.
Не, это то, что можно легко впарить.
I>Ты дурак или у тебя с русским языком проблемы ?
Напиши, пожалуйста, письмо модераторам, и попроси тебя забанить.
Либо извинись.
I>Нет здесь никаких тонкостей. Риббон 10 лет назад при всем желании нельзя было родить.
1) Почему?
2) Зачем нужен Риббон, если нет перегруженности фичами?
I>Только на короткое. А дальше надо удерживать качественным исполнением.
А дальше нужно впаривать следующую версию, а не удерживать
I>Размеры, цвет, углы наклона руля. А ты купи машину с тремя колесами или без сидений и багажника.
Без сидений -- легко. Пикап видел?
Без багажника -- тоже легко. Машинки ультракомпактные видел?
С тремя колёсами -- тоже легко. Просто такие ТС принято называть мотоциклами.
Ещё пожелания будут?
I>Я вот хочу купить Мерседес вообще без двигателя !
Это легко сделать, но это не будет машиной. Купи себе брелок от этой фирмы, например
Вообще без двигла -- это отсутсвие ОСНОВНОЙ ФУНКЦИОНАЛЬНОСТИ. А без магнитолы, например, это отсутствие бантика.
Ещё ты можешь захотеть, без тормозов, например, но такую тачку нельзя будет эксплуатировать. Так что тоже не будет ОСНОВНОЙ ФУНКЦИОНАЛЬНОСТИ. Ферштейн?
Ты в целом, хотя бы, понимаешь, что рынок браузеров и рынок тачек как-то по разному устроены? Что производители браузеров все хотят сделать топ модель феррари, а производители тачек пытаются угадать, что будут брать.
I>А цена пользователям до фени или нет ?
Нет, не до фени. Но покупают они автомобиль, а не запчасти.
I>Война точно такая же и фичи точно так же постепенно мельчают, как с офисными пакетами.
Да ну? Ну покажи мне маркетолога, который впаривает тачку потому, что органы управления расположены революционно-новым мега-удобным методом?
А вот на риббоне своём MS целую версию залудила
I>Ну и что ? Кому какое дело как ктото будет автос пользовать ?
Что-то я не понял о чём ты. Я утверждаю, что на рынке легковушек конкуренция в первую очередь идёт по РЕАЛЬНО нужным фичам. И только во вторую фичам, которые определяют степень модности. При этом перегрузка фичами -- это скорее плохо, чем хорошо.
А вот в ПО всё ровно наоборот.
I>ворд, эксель, ide
Что-то я не понял. Ты хочешь сказать, что у ворда есть его, обязательный для него фичерлист? Или ты что-то другое хотел сказать?
I>Это все фичи, а ты говоришь войны нет
"Война фич", это когда вместо улучшения существующих, всё время придумывают новые...
I>Стоимость владения разная. Бензином ты за год можешь половину стоимости авто потратить. А железо компьютерное стоит буквально копейки.
Кому как. Я вот знаю много людей, которые на комп детям КОПЯТ...
I>Везде разные модели поведения. Я вот обувь беру первую что на ногу налезет, а вот ноутбук выбираю очень долго. А ножи так и вовсе годами. I>ничего удивительного нет, нельзя человека описать одной формулой, как тебе хочется.
Где это ты увидел, что мне это хочется? Мне наоборот не нравится то, что рынок ПО повернулся к тому, что все пишут один и тот же клон ворда, совершенно не понятно для чего, кстати.
I>>>Где есть вода и другие ресурсы это уже есть. И обычно складывается так, что в этих же странах и компьютеров больше всего. E>>Чего? Где в Москве, например, я могу в аналог римских терм сходить? I>Да.
Дарагой коллега! "Да" плохой ответ на вопрос "где?". Попробуй ответить ещё раз, пожалуйста...
I>"навязать" == конспироложество.
Ты не веришь в то, что существует PR и реклама?
I>Сходство и тогда и сейчас — еда вызывает положительные ощущения, организм вырабатывает стимул в виде эндорфинов при поступлении еды. А разница в том, что зрелищами насытиться не получится.
Зато едой не получится развлечься. И от депрессии она не помогает, а наоборот, вредит, в отличии от общения. И что?
Почему сейчас в еде система ценностей консервативная, а в развлечениях инновационная?
I>Сейчас ты практически не тратишь энергии на развлечения, это объясняет почему популярны компьютеры.
Про энергию не понял. Какой энергии? Психической? Лично меня комп более 8 часов в день выматывает, например...
I>Удобно, что не надо на себе нести 100 кг аппаратуры. В дом идти никто не запрещает. А к выхлопам городские привыкли.
А! Так это всё та же модель PR-навязывания! Типа "принюхайтесь и сразу полюбите"
Кстати, неужели у тебя автомузЫка 100 кило весит? Обычно там весьма посредственные динамики + компактный уселок.
Нормальный бумбокс с отстёгивающимися колонками рвёт почти любую автомузыку. Места занимает мало, весит тоже. Да и стоит немного. Его можно просто на даче хранить, кстати...
I>Бумбокса этого и слышно рядом с машиной не будет.
Не знаю, наверное то, что я имею в виду, это не бумбоксы. Но у меня, например, есть такая хреновина, которую можно носить на плече, например. Или как чемодан, за ручку. Весит кило 8 наверное. Там есть небольная центральная часть и две пристёгиваемые к ней колонки. Когда колонки отстёгнуты, их можно разнести метров на 7 друг от друга. Мощность у этого дивайса, IMHO, слишком большая даже. Качество звука среднее-хорошее. Скока стоил не помню, потому, что недорого.
I>Ты хоть раз видел серьезную акустику для автоса ? Там внутри салона до 100 и более децибел, оглохнуть можно. Никакой бумбокс такой громкости не даст. Нету бумбоксов такой мощности.
Не 100 ДБ в САЛОНЕ -- это конечно круто. А показать всем вокург, что у тебя такая музычка есть -- ещё круче.
Но если мы всё ещё про дискотеку на даче, то не совсем понятно, какая разница скока в салоне? Важно скока СНАРУЖИ...
А ещё важно низы там как слышно и верхи и стерео и т. д...
I>Ты не видел хорошей акустики вероятно, когда весь багажник под сабвувер, колонки и прочую дрянь.
Пардон, а зачем это вообще надо? В смысле когда машину как ТС юзают? Кроме того я не верю, что вот этакую хреновину часто юзают для выездов на дачи. А шашлыки они как везут? На коленках, да? Или они просто с колёсами приезжают, закидываются и втыкают под сабвуфер?
В любом случае автомобильную музыку сделать сложнее, чем аналогичную неавтомобильную. И стоит автомобильная ДОРОЖЕ. I>Продвигали, а потом взяли и забили.
Так они весь рынок скушали. Двигать стало некого...
I>>>И то и другое редкое говно. Телевизоры все больше становятся похожими на компьютеры, E>>Ой, правда, что ли? И как много настроек есть в твоём телеке? Хотя бы сотня наберётся? А на администрирование компа можно потратить бесконечные ресурсы... I>Я втыкаю антену в комп и не надо ничего администрировать, только тюнер запустить
Не-не-не! Это не телевизор. Это комп. Ты про телефизор расскажи! Или ты как с вордом, "лет 10 не пользовался уже"?
I>Старьё.
В смысле? 2009 года выпуска.
E>>У тебя есть какая-то идея, про функциональные и нефункциональные фичи. I>Это не моя идея. Просто ты про это ничего не знаешь.
Не, во-первых, я не говорил ничего про авторство. Я говорил про содержимое головы.
Во-вторых, общепринятая идея совсем другая, чем та, что ты демонстрируешь
I>Ты плохо понимаешь, какие нынче возможности в вебе.
Хорошо понимаю. Но это не подвигает меня хранить приватную инфу там.
I>Не валяй дурку, отвечай, какую потребность удовлетворяет Касперский — общение, развлечение, познание и тд.
Стабильность работы комп. оборудования. У меня чуть больше трёх потребностей, извини...
E>>А всё как-то по старинке предпочитаю. Я вот и книжки предпочитаю выбирать в уютном книжном, с диванчиками и кофе, а не по банерам в браузере I>Ну так ты ретроград, вдобавок, эгоцентричный.
Ты опять ярлыки навешиваешь. И даже не замечаешь, похоже.
Я же книжки и музыку по банерам не выбираю не потому, что я ретроград, а потому, что так хорошую книжку и музыку не выберешь. Так выберешь МОДНУЮ. А уж сделать так, чтобы в сознании потребителя "модная" равнялось "хорошая", а "не выбирает как все" равнялось "эгоцентричный ретроград" -- это уже забота маркетинга и PR...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ikemefula, Вы писали:
I>>>При этом пользователю надо не текст и почта, а общение. А для этого надо побольше тех самых фич. E>>Как сказал в своё время Горин -- "для этого надо совсем другое"... E>>IMHO, для общения надо не фичи, а желающие с тобой общаться. I>Спасибо, просветил.
Ну, то есть ты отказываешься от тезиса, что для общения нужны фичи?
E>>И лично мне так кажется, что если "фичи" используются для абстрактного "общения", то они просто ухудшают его качество, и всё... I>Объясни это посетителям социальных сетей.
Зачем? Они сами поймут, или не поймут...
Хорошо бы, хотя бы, чтобы на них перестали давить через PR и рекламу...
E>>IMHO, тезис о том, что для лучшего удовлетворения потребности в общении, нужно насыщать мыльницы фичами, столь же неверен, как тезис, что для увеличения количества любви в мире надо сауны переоборудовать в публичные дома...
I>А тебя не пугает что табак и алкоголь свободно продаются ?
Где именно он свободно продаётся?
В РФ и табак и алкоголь зарегулирован по самое не балуйся. Например и то и то обложено акцизом. И то и другое нельзя употреблять на рабочем месте, и то и то нельзя продавать несовершеннолетним. И то и то нельзя продавать рядом со школами, стадионами и т. д. Алкоголь во многих местах в РФ нельзя продавать вечером. Сигареты во многих местах нельзя иметь на витрине... И т. д. и т. п...
I>Нет бы людям закончить курсы счастья и жить всю жизнь в блаженстве, так они, быдло тупое, идут зарабатывать деньги и тратят их на бухло и курево.
Не все. А в целом я за духовный рост, как альтернативу потреблятства. А ты, значит, нет?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Связь очень простая, она к пятнице отношения не имеет. Если есть WPF программа "Hello, World", требующая 55 Мб, то из этого не следует, что для написания программы "Hello, World" жизненно необходимо 55 Мб. Если есть интерпретатор js, требующий 100 Мб, то из этого не следует... ну ты понял.
Ну, для написания "Hello, World!" 55 Мб не требуется. Можно обойтись notepad, edlin, экстремалам вообще хватит copy con: hello.c. А вот для выполнения — другое дело. C-версия "Hello, World!" весит на несколько порядков больше ассемблерной, а функциональность одна и та же у обеих версий. Какой вывод? C не нужен?
Мой комментарий, разумеется, к делу не относится. Как и твой, впрочем. Потому что рассуждений о "Hello, World!" на C явно недостаточно для обоснования потребления памяти интерпретатором js. Ты веришь, что много, я считаю, нужны тесты, замеры. С точки зрения домашнего пользователя скорость работы Chrome нравится мне больше, чем FireFox. При этом мне еще ни разу не пришлось останавливать программы, чтобы освободить для Chrome память.
P>>Я помню, один мой приятель, делая себе WEB-страничку, неслабо напрягался, чтобы размер ее не превышал 30 К. А сейчас только одна картинка на странице мегабайт весить может. Это, по-твоему, немного?
PD>А при чем тут GIF ? Их, что js анимирует разве ? А разве 10 лет назад не было картинок под пол-Мб ? Ну не GIF, так JPG уж точно были.
Вместо GIF я вполне мог сказать JPG. Кстати, где я говорил, что js их анимирует? 10 лет назад картинки в полмегабайта в Интернете разве были? С теми ресурсами загрузки сайта с такими картинками часами можно было ждать.
P>>Это и не был аргумент. Вести дискуссию в стиле "если бы" — даже не смешно. Можно говорить все, что угодно и в любой форме. Так что можешь расценивать мое "если бы" как продолжение твоего "если бы".
PD>Эту фразу я могу расценить только как for(i=0, i < 3; i++) "если бы"
Разумеется. Зачем тогда начал эти "если бы"?
PD>Я с ними всеми тремя (включая еще и VS5) работал. У меня наилучшие воспоминания именно о VS6. VS2003 я пустил впервые на той же машине, где была VS6, Но даже когда я машину сменил, она работала медленнее.
Я VS5 (точнее, еще DS5) пропустил. А от 6-ки избавиться не удалось. А ты, видимо, запускал их на P-133 с 32 Мб. Там разница, быть может, не так заметна. А на 16 — очень даже.
P>> Chrome нормально живет рядом с IDEA и парой открытых окон OOWriter.
PD>Да живет, кто же спорит...
Здравствуйте, Erop, Вы писали:
I>>Спасибо, просветил.
E>Ну, то есть ты отказываешься от тезиса, что для общения нужны фичи?
Ты хочешь на другой контекст спрыгнуть ? Валяй.
E>Зачем? Они сами поймут, или не поймут... E>Хорошо бы, хотя бы, чтобы на них перестали давить через PR и рекламу...
Я уже понял, что тебе рекламщики говорят даже по чем ностальгировать.
I>>А тебя не пугает что табак и алкоголь свободно продаются ? E>Где именно он свободно продаётся?
Однако, когда я объясню, скорее всего ты забудешь с чего все начиналось
I>>Нет бы людям закончить курсы счастья и жить всю жизнь в блаженстве, так они, быдло тупое, идут зарабатывать деньги и тратят их на бухло и курево. E>Не все. А в целом я за духовный рост, как альтернативу потреблятства. А ты, значит, нет?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Откуда сведения про несколько порядков ? По крайней мере, в MS-DOS вполне можно было написать С-шную, сравнимую по размерам с асмовской. В Win API тоже. Может, раза в 1.5-2 будет длиннее, но уж никак не на порядок. Есть такие способы, есть
В MS-DOS на ассемблере вполне можно уложиться в несколько десятков байтов. Это проверяется очень просто На TC/BC++ — не меньше нескольких К. Жаль, ни TASM, ни BC++ тех времен не осталось, а от фонаря ассемблерный код приводить не хочется. Там должно быть как-то так:
mov dx, offset hello
mov ah, 9h
int 21h
int 20h
...........
hello db "Hello, World!", $
для COM-файла, разумеется. Чтобы на заголовке сэкономить. И, ЕМНИП, вместо int 20h можно ret поставить.
Но не транслировал. В C-версии подключается модуль c0.asm (ЕМНИП), который много чего делает. Исполняемый файл не может быть меньшего размера, чем этот модуль. Да еще printf (ну ладно, puts). Но разница заметна невооруженным глазом.
С помощью известных способов можно сократить размер C-версии, но есть ли в этом смысл?
P>> Ты веришь, что много, я считаю, нужны тесты, замеры.
PD>Нужен анализ, серьезный анализ исходного кода и запросов.
Разумеется. На самом деле нужно и то и другое. Проблема только в ограниченности ресурсов. При такой сложности продукта всегда существует вероятность что-то пропустить.
PD>Нигде не сказал, но сказал именно про анимированный. А от замены GIF на JPG ничего не изменится — js в обоих случаях ни при чем.
В контексте поиска по RSDN. Чтобы далеко не бегать. Тут почти все GIF-ы анимированные. И все весьма тяжелые.
>>10 лет назад картинки в полмегабайта в Интернете разве были?
PD>Были. За 0.5 Мб точно не поручусь, но вот 200-300 Кб точно были. Грузились медленно, да.
PD>Ну не надо так. 40-50 Кбайт/сек тогда у меня было. А это всего 4 секунды.
Так все-таки медленно или нет?
В те времена хороший канал (> 64 К) в наших краях считался роскошью. Да что там 64 К, я предприятия видел, где выделенку делали на 33.6 К. И целый отдел на этом канале сидел. В таких условиях картинки особо не посмотришь. Это сейчас у меня дома 2 мб, и меня спрашивают "а чего так мало".
PD>На 16 я VS6 не запускал, только VS5
Тогда тебе придется поверить мне на слово. Я не замерял скорости. Но DS4 была быстрее всех на 16.
PD>Да я же не говорю, что он помирает... Просто очень уж много кушает.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Откуда сведения про несколько порядков ? По крайней мере, в MS-DOS вполне можно было написать С-шную, сравнимую по размерам с асмовской. В Win API тоже. Может, раза в 1.5-2 будет длиннее, но уж никак не на порядок. Есть такие способы, есть
P>В MS-DOS на ассемблере вполне можно уложиться в несколько десятков байтов. Это проверяется очень просто На TC/BC++ — не меньше нескольких К. Жаль, ни TASM, ни BC++ тех времен не осталось, а от фонаря ассемблерный код приводить не хочется. Там должно быть как-то так: P>
P> mov dx, offset hello
P> mov ah, 9h
P> int 21h
P> int 20h
P>...........
P>hello db "Hello, World!", $
P>
P>для COM-файла, разумеется. Чтобы на заголовке сэкономить. И, ЕМНИП, вместо int 20h можно ret поставить.
Да, так.
P>Но не транслировал. В C-версии подключается модуль c0.asm (ЕМНИП), который много чего делает. Исполняемый файл не может быть меньшего размера, чем этот модуль. Да еще printf (ну ладно, puts). Но разница заметна невооруженным глазом. P>С помощью известных способов можно сократить размер C-версии, но есть ли в этом смысл?
Ну мы же академический вопрос изучаем. Сократить под Windows недолго — надо указать точку входа свою, а стандартную библиотеку C/C++ не использовать вообще. printf заменяется на WriteConsole. Размер будет ненамного больше, чем на асме.
>>>10 лет назад картинки в полмегабайта в Интернете разве были?
PD>>Были. За 0.5 Мб точно не поручусь, но вот 200-300 Кб точно были. Грузились медленно, да.
PD>>Ну не надо так. 40-50 Кбайт/сек тогда у меня было. А это всего 4 секунды.
P>Так все-таки медленно или нет?
Так все-таки, это определялось js или скоростью Интернета ? Если тебя сейчас посадить на 19200 — тоже будет не очень быстро
P>В те времена хороший канал (> 64 К) в наших краях считался роскошью. Да что там 64 К, я предприятия видел, где выделенку делали на 33.6 К. И целый отдел на этом канале сидел. В таких условиях картинки особо не посмотришь. Это сейчас у меня дома 2 мб, и меня спрашивают "а чего так мало".
Я был в LAN.
PD>>На 16 я VS6 не запускал, только VS5
P>Тогда тебе придется поверить мне на слово. Я не замерял скорости. Но DS4 была быстрее всех на 16.
Вполне верю. Деградируем
PD>>Да я же не говорю, что он помирает... Просто очень уж много кушает.
P>Хороший аппетит — признак здоровья, нет?
Если только речь не идет о модели, неудовлетворенной желудочно, с которой имел дело твой однофамилец
PD>>>Это будут расуждения о потреблении памяти данным интерпретатором js и в данных условиях. Вот делаем WPF приложение "Hello, World", оно имеет Commit Size 55 Mb. На основании этого делаем вывод, что написание программы "Hello, World", требующей менее 50 Мб, невозможно. А тут кто-то приходит и говорит, что видел "Hello, World" размером в 100 байт...
P>>Ну да, разные интерпретаторы js в одинаковых условиях отработают по-разному. Один памяти меньше съест, а другой по времени лучше окажется. Но причем здесь "Hello, World" на WPF? Я понимаю, пятница, неделя тяжелая была. И тем не менее, не вижу связи первого предложения в абзаце со следующими.
PD>Связь очень простая, она к пятнице отношения не имеет. Если есть WPF программа "Hello, World", требующая 55 Мб, то из этого не следует, что для написания программы "Hello, World" жизненно необходимо 55 Мб. Если есть интерпретатор js, требующий 100 Мб, то из этого не следует... ну ты понял.
PD>>>Объемы увеличились (немного), скорость процессора возросла (существеннеее). Верстка к делу не относится, ее не на клиенте делают, а рендеринг идет на данном мониторе, а не на разных. И все равно это не более чем вывод 4 Мб текста и графики в конечном счете в каждый момент времени.
P>>10 лет назад разве были страницы с таким объемом картинок, как сейчас? Я помню, один мой приятель, делая себе WEB-страничку, неслабо напрягался, чтобы размер ее не превышал 30 К. А сейчас только одна картинка на странице мегабайт весить может. Это, по-твоему, немного? Поищи по RSDN, посмотри на вес анимированных GIF-ов.
PD>А при чем тут GIF ? Их, что js анимирует разве ? А разве 10 лет назад не было картинок под пол-Мб ? Ну не GIF, так JPG уж точно были.
Потому что нынешний веб-сайт — это не только 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'ом.
Но да,я помню, все твои представления о вебе остались на уровне 2000-го года, это мы помним. И что дальше своей песочницы ты высовывать носа не хочешь и не собираешься.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Откуда сведения про несколько порядков ? По крайней мере, в MS-DOS вполне можно было написать С-шную, сравнимую по размерам с асмовской. В Win API тоже. Может, раза в 1.5-2 будет длиннее, но уж никак не на порядок. Есть такие способы, есть
P>>для COM-файла, разумеется. Чтобы на заголовке сэкономить. И, ЕМНИП, вместо int 20h можно ret поставить.
PD>Да, так.
P>>С помощью известных способов можно сократить размер C-версии, но есть ли в этом смысл?
PD>Ну мы же академический вопрос изучаем. Сократить под Windows недолго — надо указать точку входа свою, а стандартную библиотеку C/C++ не использовать вообще. printf заменяется на WriteConsole. Размер будет ненамного больше, чем на асме.
Ну, разница между исполняемыми модулями не так заметна в винде, во-первых потому, что из ассемблерной программы тоже нужно будет вызывать WriteConsole, при этом еще параметры подготовить. А что нужно сделать с C-версией, тебе один кэп подсказал. Но все равно это пляски с бубном. А в MS-DOS полсотни байт ассемблерной версии против 4-6 К на C. Вот и 2 порядка разницы. В DOS тоже можно выпилить все лишнее из c0.asm, но лично я никогда бы этим заниматься не стал бы.
PD>Так все-таки, это определялось js или скоростью Интернета ? Если тебя сейчас посадить на 19200 — тоже будет не очень быстро
Без широких каналов JS не стал бы таким, какой он есть, imho. Это просто мнение обывателя, подтверждать я его не буду. Вот если поставить современный процессор с комплект с 1 Мб, ему просто негде развернуться будет.
PD>Вполне верю. Деградируем
Неужели последние версии Студии включают только мертвый код и свистоперделки? Я правда его давно не видел.
P>>Хороший аппетит — признак здоровья, нет?
PD>Если только речь не идет о модели, неудовлетворенной желудочно, с которой имел дело твой однофамилец
Там не аппетит был, а недоработка. Такое случается в любом НИИ. (В том, где я однажды был на ученом совете, образец вернулся из области пластических деформаций в область упругих). А вот движок js память использует для дела. Вот тебе ссылка. Там еще о проблемах, которые доставляет js разработчикам интерпретатора. Статья об удалении мертвого кода их js, но источник проблем тот же, что и в нашем случае. Динамика — это вам не статика. В js ее, похоже, слишком до фига.
Здравствуйте, Privalov, Вы писали:
PD>>Ну мы же академический вопрос изучаем. Сократить под Windows недолго — надо указать точку входа свою, а стандартную библиотеку C/C++ не использовать вообще. printf заменяется на WriteConsole. Размер будет ненамного больше, чем на асме.
P>Ну, разница между исполняемыми модулями не так заметна в винде, во-первых потому, что из ассемблерной программы тоже нужно будет вызывать WriteConsole, при этом еще параметры подготовить. А что нужно сделать с C-версией, тебе один кэп подсказал. Но все равно это пляски с бубном. А в MS-DOS полсотни байт ассемблерной версии против 4-6 К на C. Вот и 2 порядка разницы. В DOS тоже можно выпилить все лишнее из c0.asm, но лично я никогда бы этим заниматься не стал бы.
Да никто и не предлагает. Но вообще аргумент насчет порядков не верен ИМХО. Мы тут сейчас просто размер стартового кода обсуждаем, какое это имеет значение. А вот если сделать серьезную программу, так , чтобы объем стартового кода был в % мал, то разница между С++ и asm будет невелика.
PD>>Так все-таки, это определялось js или скоростью Интернета ? Если тебя сейчас посадить на 19200 — тоже будет не очень быстро
P>Без широких каналов JS не стал бы таким, какой он есть, imho. Это просто мнение обывателя, подтверждать я его не буду. Вот если поставить современный процессор с комплект с 1 Мб, ему просто негде развернуться будет.
Кому, процессору ? Вполне смог бы развернуться — скажем, для решения задач, требующих большого количества вычислений.
PD>>Вполне верю. Деградируем
P>Неужели последние версии Студии включают только мертвый код и свистоперделки? Я правда его давно не видел.
Они ее упорно портят. Зачем-то перевели интерфейсную часть на WPF, теперь это еще медленее работать стало.
P>>>Хороший аппетит — признак здоровья, нет?
PD>>Если только речь не идет о модели, неудовлетворенной желудочно, с которой имел дело твой однофамилец
P>Там не аппетит был, а недоработка. Такое случается в любом НИИ. (В том, где я однажды был на ученом совете, образец вернулся из области пластических деформаций в область упругих). А вот движок js память использует для дела. Вот тебе ссылка. Там еще о проблемах, которые доставляет js разработчикам интерпретатора. Статья об удалении мертвого кода их js, но источник проблем тот же, что и в нашем случае. Динамика — это вам не статика. В js ее, похоже, слишком до фига.
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>Неужели последние версии Студии включают только мертвый код и свистоперделки? Я правда его давно не видел.
PD>Они ее упорно портят. Зачем-то перевели интерфейсную часть на WPF, теперь это еще медленее работать стало.
Нативная разработка там уже просто побочный эффект.
Начиная с 2001й, развивается только дотнетовская часть.
Самая лучшая нативная поддержка в VS 98, вот так то.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Ему насрать на безопасность, на компиляцию скриптов, на то, что хром один таков, что рвет на клочья файрфоксы, сафарей, опер и ослов.
Обнаруженные уязвимости позволяют удаленному пользователю обойти некоторые ограничения безопасности и скомпрометировать целевую систему.
1. Уязвимость существует из-за ошибки использования после освобождения при использовании API документа во время его обработки. Удаленный пользователь может выполнить произвольный код на целевой системе.
2. Уязвимость существует из-за ошибки использования после освобождения при обработке SVG стилей. Удаленный пользователь может выполнить произвольный код на целевой системе.
3. Уязвимость существует из-за ошибки использования после освобождения при обработке разветвленных SVG элементов. Удаленный пользователь может выполнить произвольный код на целевой системе.
4. Уязвимость существует из-за ошибки утверждения при обработке курсора на Linux системах.
5. Уязвимость существует из-за ошибки состояния операции при обработке консоли. Удаленный пользователь может скомпрометировать целевую систему.
6. Уязвимость существует из-за ошибки, связанной с диалоговым окном загрузки файла. Удаленный пользователь может вызвать повреждение памяти на Mac OS. Уязвимость относится к: www.securitylab.ru/vulnerability/396984.php #1
7. Уязвимость существует из-за неизвестной ошибки, относящейся к геолокации. Удаленный пользователь может вызвать повреждение памяти и выполнить произвольный код на целевой системе.
8. Уязвимость существует из-за неизвестной ошибки, относящейся к обработке Khmer. Удаленный пользователь может вызвать повреждение памяти и выполнить произвольный код на целевой системе.
9. Уязвимость существует из-за того, что приложение не запрашивает разрешение пользователя на доступ расширения к истории посещенных страниц.
Всё сказанное выше — личное мнение, если не указано обратное.
Т.е. Несмотря на все, что я тут писал, народ либо не понимает, либо не читает... Печально.
Поставь себе уязвимую версию хрома и попытайся проэксплуатировать эти уязвимости. Ну скажем, запусти на целевой системе калькулятор или получи доступ к DOM соседней вкладки. Эксплойты уже есть, дерзай.
А то я уже устал объяснять, чем этот браузер отличается от других : может хоть так станет понятнее
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Т.е. Несмотря на все, что я тут писал, народ либо не понимает, либо не читает... Печально.
KV>Поставь себе уязвимую версию хрома и попытайся проэксплуатировать эти уязвимости. Ну скажем, запусти на целевой системе калькулятор или получи доступ к DOM соседней вкладки. Эксплойты уже есть, дерзай.
KV>А то я уже устал объяснять, чем этот браузер отличается от других : может хоть так станет понятнее
Мне и так жить не скучно. Никакого желания нет эксплоиты под хром тестировать.
А в сказки про невероятную надёжность и безопасность я перестал верить много лет назад, уже после выхода SP1 для XP. Я в универе тогда учился, своего компа не было и мне очень нужен был работающий офис в комп. зале, хотя бы на одной машине. Девочка на кассе помочь отказалась, админ где-то потерялся.
Именно тогда я познакомился с маленькой софтинкой "getadmin".
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Фанатик, Вы писали:
KV>>А то я уже устал объяснять, чем этот браузер отличается от других : может хоть так станет понятнее
Ф>А в сказки про невероятную надёжность и безопасность я перестал верить много лет назад
Выделенное, не имеет ни малейшего отношения к обсуждаемой теме. Никто 100% безопасность здесь не обещал. Но проэксплуатировать те уязвимости тебя не получится. Нет, произвольный код ты наверное выполнишь (как минимум, одним из эксплоитов), держа в уме грабли, расставленные для эксплойто-писателей ASLR'ом и успешно обойдя DEP. Но этот код не сможет ни выполнить какие-либо системные вызовы, ни достучаться до других процессов. И что даст потенциальному атакующему подобная уязвимость? А в другом браузере (кроме IE, как это ни странно), она бы дала полный контроль над системой.
Ф>, уже после выхода SP1 для XP. Я в универе тогда учился, своего компа не было и мне очень нужен был работающий офис в комп. зале, хотя бы на одной машине. Девочка на кассе помочь отказалась, админ где-то потерялся. Именно тогда я познакомился с маленькой софтинкой "getadmin".
...эксплуатирующей в различных реинкарнациях, LPE уязвимости, актуальные для конкретных версий винды. И? Вывод?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Нет, произвольный код ты наверное выполнишь (как минимум, одним из эксплоитов)... Но этот код не сможет ни выполнить какие-либо системные вызовы, ни достучаться до других процессов.
Я что-то неправильно понимаю в выражении "произвольный код"?
Ф>>, уже после выхода SP1 для XP. Я в универе тогда учился, своего компа не было и мне очень нужен был работающий офис в комп. зале, хотя бы на одной машине. Девочка на кассе помочь отказалась, админ где-то потерялся. Именно тогда я познакомился с маленькой софтинкой "getadmin".
KV>...эксплуатирующей в различных реинкарнациях, LPE уязвимости, актуальные для конкретных версий винды. И? Вывод?
Вывод таков: если уж залезли каким-нибудь мизинцем какой-нибудь ноги через левое ухо, то выяснив версию системы подбираем соответствующий "getadmin".
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Фанатик, Вы писали:
Ф>Здравствуйте, kochetkov.vladimir, Вы писали: KV>>Нет, произвольный код ты наверное выполнишь (как минимум, одним из эксплоитов)... Но этот код не сможет ни выполнить какие-либо системные вызовы, ни достучаться до других процессов. Ф>Я что-то неправильно понимаю в выражении "произвольный код"?
Видимо да, неправильно. Данное выражение означает, что может быть выполнен, например, такой код:
LONG Code = RegCreateKey(HKEY_CURRENT_USER, szKeyName, &hKey);
но оно совершенно не гарантирует, что после его выполнения, в Code будет что-то, отличное от ERROR_ACCESS_DENIED.
Ф>>>, уже после выхода SP1 для XP. Я в универе тогда учился, своего компа не было и мне очень нужен был работающий офис в комп. зале, хотя бы на одной машине. Девочка на кассе помочь отказалась, админ где-то потерялся. Именно тогда я познакомился с маленькой софтинкой "getadmin". KV>>...эксплуатирующей в различных реинкарнациях, LPE уязвимости, актуальные для конкретных версий винды. И? Вывод? Ф>Вывод таков: если уж залезли каким-нибудь мизинцем какой-нибудь ноги через левое ухо, то выяснив версию системы подбираем соответствующий "getadmin".
"Выяснив версию продукта, выбираем актуальный для нее эксплоит". Нет, это не вывод, это формулировка. Ты ведь зачем-то это говорил? Что-то пытался этим сказать?
KV>но оно совершенно не гарантирует, что после его выполнения, в Code будет что-то, отличное от ERROR_ACCESS_DENIED.
Вообще-то HKCU на запись открыт. Как бы иначе сам броузер что-то в реестре сохранял ? HKLM — другое дело.
А если более серьезно, то в рамках модели Windows защититься от атаки посторонним софтом, работающем на той же window station, невозможно. Для XP это безусловно так, начиная с Висты — можно для приложений с elevated privileges, для остальных по-прежнему нельзя. Это связано с наличием хуков. единственный надежный способ — пересадить приложениеина иную оконную станцию, там его враги не достанут, но его никто и не увидит
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Фанатик, Вы писали:
Ф>>Здравствуйте, kochetkov.vladimir, Вы писали: KV>>>Нет, произвольный код ты наверное выполнишь (как минимум, одним из эксплоитов)... Но этот код не сможет ни выполнить какие-либо системные вызовы, ни достучаться до других процессов. Ф>>Я что-то неправильно понимаю в выражении "произвольный код"?
KV>Видимо да, неправильно. Данное выражение означает, что может быть выполнен, например, такой код:
KV>
KV>но оно совершенно не гарантирует, что после его выполнения, в Code будет что-то, отличное от ERROR_ACCESS_DENIED.
Даже не представляю как этого достичь. Самому процессу ведь разрешено реестр использовать, а в HKCU постоянно что-то пишется (напр положение и размер окна)...
Ф>>>>, уже после выхода SP1 для XP. Я в универе тогда учился, своего компа не было и мне очень нужен был работающий офис в комп. зале, хотя бы на одной машине. Девочка на кассе помочь отказалась, админ где-то потерялся. Именно тогда я познакомился с маленькой софтинкой "getadmin". KV>>>...эксплуатирующей в различных реинкарнациях, LPE уязвимости, актуальные для конкретных версий винды. И? Вывод? Ф>>Вывод таков: если уж залезли каким-нибудь мизинцем какой-нибудь ноги через левое ухо, то выяснив версию системы подбираем соответствующий "getadmin".
KV>"Выяснив версию продукта, выбираем актуальный для нее эксплоит". Нет, это не вывод, это формулировка. Ты ведь зачем-то это говорил? Что-то пытался этим сказать?
Всё равно какая версия OS (по крайней мере Windows), последний эксплоит который я видел вроде бы до Windows 7 работает (включительно ли — не знаю), поэтому запуск левого кода компроментирует систему.
Всё сказанное выше — личное мнение, если не указано обратное.
KV>>но оно совершенно не гарантирует, что после его выполнения, в Code будет что-то, отличное от ERROR_ACCESS_DENIED. Ф>Даже не представляю как этого достичь. Самому процессу ведь разрешено реестр использовать, а в HKCU постоянно что-то пишется (напр положение и размер окна)...
http://msdn.microsoft.com/en-us/library/bb625957.aspx + все, что я рассказывал Павлу здесь, в этой теме.
KV>>"Выяснив версию продукта, выбираем актуальный для нее эксплоит". Нет, это не вывод, это формулировка. Ты ведь зачем-то это говорил? Что-то пытался этим сказать? Ф>Всё равно какая версия OS (по крайней мере Windows), последний эксплоит который я видел вроде бы до Windows 7 работает (включительно ли — не знаю), поэтому запуск левого кода компроментирует систему.
Да, безусловно, везде, где есть уязвимости, есть возможность их эксплуатировать. Насколько успешно в плане реализации информационных угроз — другой вопрос. Но возможность есть. Уязвимости — это ровно такие же баги как и все остальные, отличающиеся от обычных ошибок всего лишь наличием одного свойства. Ошибки были, есть и будут, следовательно, уязвимости тоже. Но из того, что "все равно разломают, если захотят" совершенно не следует, что какие-либо меры по обеспечению безопасности бесполезны. Приведенный пример с уязвимостями очень показателен, кстати. Вот они вроде и есть, но их эксплуатация затруднена настолько, насколько это возможно в рамках архитектуры хрома. Да, можно атаковать открытую вкладку (целевой процесс, в терминах хрома), но преодолев DEP и ASLR. Далее можно либо пытаться пробить песочницу, в которой выполняется процесс (для этого, необходимо, чтобы она также была уязвима) либо попытаться атаковать брокер-процесс (и он тоже должен быть уязвимым), отправкой malformed IPC-запроса, f уже из него пытаться атаковать систему.
Что несколько более сложно, чем старые-добрые уязвимости "раз — и готово". О том и речь
Здравствуйте, Pavel Dvorkin, Вы писали:
KV>>но оно совершенно не гарантирует, что после его выполнения, в Code будет что-то, отличное от ERROR_ACCESS_DENIED. PD>Вообще-то HKCU на запись открыт. Как бы иначе сам броузер что-то в реестре сохранял ? HKLM — другое дело.
Павел, вот ты сейчас меня конкретно расстроил, кроме шуток. Знаешь почему? Потому что я достаточно много всего написал здесь, привел все необходимые ссылки, после которых бы вопроса о "Как бы иначе сам броузер что-то в реестре сохранял?" просто не возникло. У меня нет времени, даже безотносительно моего желания, еще раз расписывать все это и приводить все те же ссылки.
PD>А если более серьезно, то в рамках модели Windows защититься от атаки посторонним софтом, работающем на той же window station, невозможно.
Защититься вообще, в приницпе, невозможно где бы то ни было. Но если бы ты не называл integrity levels "дошлепком", а почитал что это и какие возможности дает разработчику, то уверенности в возможности разграничения доступа в рамках одной пользовательской сессии, у тебя бы, глядишь, было бы побольше.
PD>Для XP это безусловно так, начиная с Висты — можно для приложений с elevated privileges, для остальных по-прежнему нельзя. Это связано с наличием хуков. единственный надежный способ — пересадить приложениеина иную оконную станцию, там его враги не достанут, но его никто и не увидит
Ты не поверишь, но достаточно серьезная работа, направленная на вынесение каждого процесса, даже не в песочницу, нет, в отдельную виртуальную машину, тоже ведется, причем довольно успешно. Правда, на базе линукса. Проблемы с "никто не увидит" там также решают с помощью RPC собственного приготовления, а архитектура всей системы, очень напоминает хромовскую, только на стероидах.
Здравствуйте, kochetkov.vladimir, Вы писали:
Ф>>Всё равно какая версия OS (по крайней мере Windows), последний эксплоит который я видел вроде бы до Windows 7 работает (включительно ли — не знаю), поэтому запуск левого кода компроментирует систему.
KV>Видимо, речь идет как раз о том сплоите, из которого я пример с созданием ветки реестра выдрал: http://cr4sh-0x48k.livejournal.com/44815.html ?
нет, я о том эксплоите, который мыщъх здесь упоминал
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Фанатик, Вы писали:
Ф>Здравствуйте, kochetkov.vladimir, Вы писали:
Ф>>>Всё равно какая версия OS (по крайней мере Windows), последний эксплоит который я видел вроде бы до Windows 7 работает (включительно ли — не знаю), поэтому запуск левого кода компроментирует систему.
KV>>Видимо, речь идет как раз о том сплоите, из которого я пример с созданием ветки реестра выдрал: http://cr4sh-0x48k.livejournal.com/44815.html ?
Ф>нет, я о том эксплоите, который мыщъх здесь упоминал
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не могли авторы языка в 1995 году закладывать в него или что-то с ним связанное с потребностью в 100 Мб. Просто не могли и все! Если бы они предложили язык, для работы с котороым надо иметь 100 Мб — они бы просто в посмешище превратились. Не было такой памяти! И рассчитывать. что тактовая увеличится в 30 раз, они тоже не могли - не было еще закона Мура, в течение 80-х и начала 90-х тактовая росла медленно (помню 386-40, потом 486-66, потом P-70, потом P-100 )
Эммм. Вообще-то, "закон" Мура был сформулирован в 1965 году.
И гласит он что каждые два года количество транзисторов на кристалле удваивается. Не тактовая частота, а количество транзисторов. Увеличение частоты может идти в ногу с увеличением числом транзисторов, а может и не идти. Транзисторы — это и дополнительные конвейеры, спороцессоры, кэши, ядра и прочие примочки, которые увеличивают быстродействие (или объем памяти) при той же тактовой частоте.
Здравствуйте, Erop, Вы писали:
A>>это всё временная фигня. нетбуки будут развиваться в сторону умощнения (я так думаю). мы всё это проходили и с десктопами, и с мобилами, и много ещё с чем.
E>Да тоже упрутся. E> Мощность она же небесплатная. Мощность -- это значит больший вес при меньшем времени жизни...
Или просто другая технология.
В нетбуках не шарю, но выбирал домашний сервер с Атомным процессором.
Две последовательные модели — одна на Атом 230 + чипсет 945, другая на Атом 510 + чипсет ICH9R
Вторая модель значительно производительнее, и при этом — потребляет меньше электроэнергии и меньше греется. Размеры материнок и процессоров — совпадают.
Есть куда развиваться нетбукам. Может когда и упрутся, но мощность у них еще подрастет в разы.
Здравствуйте, fmiracle, Вы писали:
E>> Мощность она же небесплатная. Мощность -- это значит больший вес при меньшем времени жизни...
F>Или просто другая технология.
Дык в рамках ЛУЧШЕЙ технологии всё равно будем иметь размен мощности на экономичность
То есть легко может так оказаться, что на новой технологии будет выгоднее увеличить время жизни, а не мощность устройства
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Ок, еще раз, последний, очень подробно и по полочкам. Считай это ответом и на все остальные твои сообщения тут, на которые я не успел ответить.
Если нам не помогут, то мы тоже никого не пощадим.
