Здравствуйте, 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>Кстати, маленькое замечание. Если серьезно увеличивать расходы памяти — растет время. Просто потому, что на обработку этой памяти оно потребно.
Спасибо тебе капитан очевидность.

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

A>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>чтобы под указатель было выделено много памяти, надо чтобы он на массив показывал
A>так вышеупомянутый RefPtr<NamedNodeMap> m_attributeMap как раз на массив и указывает

Вообще-то Map вряд ли массив, ну да ладно.

Но если массив — чему его размер равен? Как определяется ? Если, как я предполагаю, это map атрибутов, то сколько там этих атрибутов у ноды ? 10 ? Допускаю. 100 ? Тоже допускаю, но вряд и у всех нод столько атрибутов. 10000 ? Что-то плохо верится. А ведь 10000 атрибутов, да по 16 байт на атрибут — это лишь жалкие 160 (ну пусть 320) Кбайт.

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

PD>Слушай, тебя на конюшне или в дворницкой воспитывали ? Ты не мог бы более парламентские выражения выбирать ?
Я предпочитаю объяснять просто и доходчиво.

PD>По сущесиву — я не читаю код на незнакомом мне языке и не комментирую его.
Я тебе дал ссылку на код на С++. Но ты и ее проигнорировал.

Здравствуйте, 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>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 метрах. и ведь конкуренты отъедают не сильно меньше... отсюда у разработчиков отмазка, что по другому делать не надо и все равно не получится.

Здравствуйте, 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>Нет, не полезу я в эту дискуссию. Во-первых, я не согласен с этим (он вполне годится как язык управления броузером), а во-вторых, мне просто эта дискуссия надоела. Пусть кто-нибудь другой тебе возразит из адептов этих языков, а мне-то что — я их не сторонник.

PD>А зачем мне их уговаривать ? Я просто констатирую факт — выбрав js в качестиве языка и броузер в качестве среды, они сели в лужу, потому что применили топор для создания ажуронй мебели. Или лобзик для постройки деревянного забора. Выбери сам сравнение, которое больше нравится.
Тебе не кажется что в этих двух абзацах ты противоречишь сам себе.

PD>То есть скажем просто — 15 (или 10) лет назад было выбрано неправильное направление развития, и мы пожинаем плоды этого.
Именно так.

PD>Если бы полумали как следует, то js,
Те кто умеет думать динамически типизируемый язык придумать не могут.
Динамическая типизация возникает из-за желания быстро наговнокодить не думая о долгосрочных последствиях.

PD>Ну если надо автомобиль заставить летать, то , конечно, надо еще быстрее. Но лучше все же взять самолет.
Браузеры не поддерживают самолет по тому что его не используют сайты.
Сайты не используют самолет по тому что его не поддерживают браузеры.
Фсе! Приплыли.

PD>Остается лишь малость — доказать, что требует. А вот в этом я не уверен.
Послушай лекцию узнаешь куда они память девают.

PD>Не за что. Просто прими это к сведению, прежде чем уповать на гигабайты. А то можешь получить прямо противоположный эффект.
Я уповаю исключетельно на измерения.

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

PD>Я просто там ничего относящегося к делу там не нашел. Ну реализация калькулятора, ну в байт-код, ну и что ? Может, он и хороший, но какое отношение к делу имеет ?
Прямое. Я тебе показываю как работают интерпретаторы.
А то ты судя по твоим словам не знаешь.

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

PD>А интерпретатор с JS как-то работал. И программа тоже.

Никто же не спорит о том, как именно работал.

Поставь в виртуалках две системы — старую вындоус 95 и новую xp-32 c новым хромом.

Виртуалки нужны что бы сравнение было корректным, без виртуалки нынче 95-ку не запустить.

Запусти один и тот же JS-файл замерь время, память и приходи сюда каяться

В старой версии, например, каждый вызов метода это тупой перебор по имени и сравнение строк.

В новой этого уже не будет.

Здравствуйте, 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 непредставимы.
И что это за вычисления такие?

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

C>>А чего бы и нет? Особенно, если во время миграции нужно проводить вычисления, которые в чистом SQL непредставимы.
WH>И что это за вычисления такие?
Скажем, у меня были в БД только исходные данные для payroll'а, надо добавить результат их вычисления для того, чтобы по ним можно строить отчёт. Как ты понимаешь, вычисление payroll'а — это почти вся бизнес-логика. Запихнуть её в одни update не получится.

Или другой пример был, в поле "Company Name" было имя компании вместе с её адресом (слажали товарищи до меня). Нужно было во время миграции распихать его по полям. Можно было "распихиватель" сделать на SQL, но намного проще его написать было на Скале.

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

C>Скажем, у меня были в БД только исходные данные для payroll'а, надо добавить результат их вычисления для того, чтобы по ним можно строить отчёт. Как ты понимаешь, вычисление payroll'а — это почти вся бизнес-логика. Запихнуть её в одни update не получится.
1)Не понимаю. Ибо не знаю что такое payroll.
2)Сваливать исходные данные и производные данные в одну кучу кривь.

C>Или другой пример был, в поле "Company Name" было имя компании вместе с её адресом (слажали товарищи до меня). Нужно было во время миграции распихать его по полям. Можно было "распихиватель" сделать на SQL, но намного проще его написать было на Скале.
Зачем тут динамическая типизация не понятно.

Здравствуйте, 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 пользуюсь. Код приходилось писать ровно один раз.