Здравствуйте, 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, Вы писали:
PD>>>Я же не о том говорю, что интерпретатор мог быть сравним со скоростью с компилятором. Я о том. что интерпретатор или полукомпилятор — это совсем не такая уж страшная вещь, требующая сотни Мб памяти из-за того, видите ли, что там только в рантайме определяется тип переменной, как меня тут уверяют. Все это давно было, и вполне без сотни Мб.
I>>И в этом же контексте по полмиллиона и более объектов в хипе ?
I>>Врешь, ведь.
PD>Ну и ну. Полмиллиона объектов на памяти в 640 Кб. М-да. Переутомление у тебя ?
Это был намёк на твои сравнения. JS работает с кол.вом объектов в памяти большим чем количество байт в памяти с которым работал Турбо Паскаль.
Здравствуйте, Pavel Dvorkin, Вы писали:
C>>Ну так признай, что был неправ.
PD>В чем ?
Да куда ни ткни, ты не прав.
Сначала кидаешь утверждение что де памяти под объекты для Html надо максимум в несколько раз больше чем текста, потом споришь с тем, что надо в 10-100 раз больше и просишь показать пример, потом сам же выдвигаешь оценку, по которой памяти нужно не в разы, а в 100 раз больше.
Поскольку ты попросил не продолжать развивать эту тему, а я уже успел открыть окно януса для написания ответа тебе, то скажу еще одну вещь, не совсем по теме — чтобы поправить самого себя, и потом умолкну
Не хочу лукавить, я не могу однозначно отнести себя к одному из лагерей систем типизации, хотя и недвусмысленно высказался в прошлом сообщении. Мне кажутся весьма разумными доводы Wolfhound'а, твои и многих других о том, что в динамических языках нет никаких преимуществ. Разбираясь с основами компиляторостроения, пытаясь понять нутря немерла, я стал понимать какие именно оптимизации позволяет провернуть статическая типизация, какие преимущества неизменяемые структуры имеют перед изменяемыми, еще раз убедился насколько глубокую поддержку IDE можно обеспечить в таких языках (первым ярким впечатлением был решарпер) и т.д и т.п. В общем, все то, что в динамических языках если не отсутствует вообще, то хотя бы тяжело реализуемо и совсем не той же степени. С одной стороны...
С другой же, я ежедневно наблюдаю десятки нод телекоммуникационного оборудования, которыми управляет код на динамическом языке. Знаешь что из себя представляет одна такая нода в комании где я работаю? Железку, простой которой в течении 10 минут выливается в тысячи долларов ущерба. Железку, в которой поток трафика идет круглосуточно, обеспечивая голосовую связь тысяч, одновременно активных абонентов. Железку, прекрасно работающие скрипты для которой пишут инженеры, прошедшие базовый курс обучения. Железку, в которой некорректно написанный код не обрушит всю ноду целиком, даже если сильно этого захотеть. Железку, которая никогда не падала за все время моей работы там.
Есть и другие ноды, от другого производителя. Ими управляет код на каком-то подмножестве С++. Не могу сказать ничего плохого о стабильности таких нод. Но любое изменение программного обеспечения там выливается в копеечку, потому что разбираться во всей этой лапше вызовов, ньюансов управления памятью и граблей, связанных с тем, что может натворить глючный код, умеет только вендор этих железок.
Т.е., с другой стороны я наблюдаю применение динамического языка в настолько критичной и нагруженной, а главное реальной системе, что мой разум отказывается принимать доводы, которые приводят сторонники статической типизации. Да, возможно, железки первого типа были блестяще спроектированы и реализованы педантичными шведами, а второго — делали индусы по заказу корейцев, нанятых японцами, выполняющими госзаказ китайцев. Может быть. Но факт остается фактом и его тяжело игнорировать.
Вот поэтому в дальнейшем, я пожалуй воздержусь от критики той или иной системы типизации, но с интересом буду следить за подобными обсуждениями Что же до яваскрипта, то это едва ли не единственный такой язык, прошедший путь от средства реализации микроскриптиков до серьезных серверных систем (я о node.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 много.
Здравствуйте, 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 кто менять будет или расширять блок памяти для новых членов?
WH>>А что касается 640кб да не вопрос. Только получится интерпретатор который будет все также тормозить.
PD>Ладно, давай заканчивать (это ко всем веткам относится).
Действительно, стоит заканчивать. Если ты даже ссылки
Здравствуйте, Mamut, Вы писали:
WH>>>А что касается 640кб да не вопрос. Только получится интерпретатор который будет все также тормозить.
PD>>Ладно, давай заканчивать (это ко всем веткам относится).
M>Действительно, стоит заканчивать. Если ты даже ссылки
WH>>>>А что касается 640кб да не вопрос. Только получится интерпретатор который будет все также тормозить.
PD>>>Ладно, давай заканчивать (это ко всем веткам относится).
M>>Действительно, стоит заканчивать. Если ты даже ссылки
не удосуживаешься смотреть, а размахиваешь турбопаскалем направо-налево с криками «нипанимаю»
PD>Дима, я просто устал от этой дискуссии. Владимиру я ответил сегодня, он как-никак ТС, а больше никому не буду. Извини.
Ну как бы ты не особо и не отвечаешь
Ты спашиваешь: объясните, а то в TP все просто
Тебе дают ссылку на дизайн V8, где все показано даже картинками.
Ты спрашиваешь (не глядя на картинку): объясните, а то в TP все просто
Тебе отвечают, расписывая архитектуру браузера, пробелмы, возникающие при реализации всего этого дела и т.п.
Ты спрашиваешь (не читая): объясните, а то в TP все просто
Ну и т.п.
Пол-моему, в этом топике все расписано и разжевано достаточно четко. Но диалог какой-то односторонний получается
