Здравствуйте, Ikemefula, Вы писали:
I>В старые добрые времена, когда программисты были умными, а программы — быстрыми и компактными, был написан интерпретатор JS.
Для полноты картины надо добавить, что в "старые добрые времена" программиста, который захотел бы написать что-то сложное на JavaScript, немедленно отправили бы в дурку.
Сейчас это безумие вошло в моду, и здравый смысл только еле-еле пищит где то в углу "а на _уя вообще писать на JS, когда есть куча языков, которые намного быстрее, удобнее и надежнее?"
M>>>>Так что иди учи основы. Или задай свой вопрос в форуме по Win API. M>>>>[/q]
PD>>>Ну и что ? Или ты считаешь, что здесь что-то неверно? То есть можно ожидать в GUI потоке и не принять эти меры ? Если считаешь — то это в некотором противоречии с тем, что ты писал, будто знаешь, как писать ожидание в GUI потоке. А если это верно, а некий автор этого не знает, то ему надо учить основы. Что я ему еще могу посоветовать-то ?
M>>Твоя точка зрения — сугубо академическая, к реальному миру имеющая мало отношения.
PD>А можно все же указать, что в той фразе неверно ? Вместо голословных утверждений — твоя мол, точка зрения академическая ?
Это не голословное утверждение, а эмпирически доказанный факт
M>>«Я не собираюсь читать, что вы мне пишите, PD>Читал. >>я не собираюсь открывать ни одной ссылки что вы мне присылаете PD>Не собираюсь, верно. Объяснил вот здесь сегодня почему PD>http://rsdn.ru/forum/flame.comp/4052754.1.aspx
В моем ответе там видно, как ты «читал». Ага, Мамут принуждал тебя исходники читать, ага. Ниже.
>>я не собираюсь понимать ни одной цифры, что вы мне пишите. PD>Передергивание.
Да разве? Напомнить тебе твой ответ на первое сообщение в этом топике?
>>НО! У меня есть мнение по преметам,в которых я абсолютно не разбираюсь, поэтому я буду выборочно брать из ваших сообщений то, что мне захочется, создавать собственные ветряные мельницы и успешно с ними бороться. А на ваши доводы мне глубоко наплевать с высокой колокольни». PD>Ну а это никаким комментариям не подлежит, разве что вот этому PD>http://rsdn.ru/forum/flame.comp/4052722.1.aspx
PD>>>Оно ведь, само по себе (вранье это) заставляет сильно засомненваться в справедливости твоих утверждений, даже ничего не зная об их сути. Потому что если для их отстаивания нужно лгать, то это само по себе ставит их под сомнение.
M>>Если бы ты читал хоть одно мое утвержедение M>>Если бы ты читал хоть чьи-либо утвержддения M>>Если бы ты перешел хоть по одной ссылке, что тебе показали M>>Если бы ты попытался разобраться хоть в чем-то, о чем тебе говорили
M>>То тогда я бы согласился, что я вру.
PD>Если бы ты не повторял десять раз одно и то же, а попробовал понять, какие аргументы я принимаю, а какие нет, какие аргументы я выдвигаю, то тебе не пришлось бы десять раз писать одно и то же.
Ты принимаешь только те аргументы, которые тебе хочется. Которые укладываются в придуманную тобой картину мира. Ниже
M>>Но ты же веришь только голосам в своей голове
PD>Поверь, вот тут ты глубоко неправ.
О да. Напомнить диалог с тобой?
Был выдвинут тезис, что сейчас браузеру нужно больше ресурсов для обрабтки инофрмации. Внимание было заострено на JS. Ну да ладно.
Ты: А вот Turbo Pascal компилировал в минимуме памяти и очень быстро.
К сожалению в запарке тут мы тебя не остановили. потому что любой умный человек остановился бы и спросил: а при чем тут собственно, компиляция? Она и в яваскрипте сверхшустрая. Дело-то не только в компиляции, но и в выполнении.
Пример. Есть у меня приложение. Mail.app. Занимает на диске 77.5 мегабайт. Но при работе, сволочь, отжирает в общей сложности до 200 метров памяти. То, что получается на диске — это компиляция. То, что получается во время работы — это выполнение. И, как ни странно, Javascript в браузере не только компилируется, но и выполняется.
Но ты заладил: компиляция, компиляция, турбо паскаль, память. При чем тут компиляция? На это нет ответа. Когда я тебе попытался на это указать (пример с Фотошопом, дважды) ты решил это просто проигнорировать.
И тут внезапно оказывается, что javascript да — не просто компилируется, он еще и выполняется! ВНЕЗАПНО, ваш к.о. Со сборщиком мусора. С JIT'ом. С оптимизаторами кода (вроде dead code elimination). С ограничениями по безопасности (вроде cross-domain ajax). И выполняется быстро. Несмотря на динамическую типизацию и прочие радости.
А потом ВНЕЗПНО в браузере оказывается не только Javascript. В нем есть еще вагон и маленькая тележка технологий, часть из которых может дополнительно манипулироваться Javascript'ом.
Тут тебе и сложнейшие правила отрисовки и управления содержимым, которые десктоп-приложениям даже и не снились. Что простейший insertNode из Javascript'а вызывает reflow/redraw всего документа (или не вызывает — но для этого надо проводить дополнительные выисления и оптимизации).
Тут тебе и попытка упечь в песочницу принципиально неуправляемые плагины вроде flash'а, чтобы его падение (которое у Flash'а глобальное для приложения) не утянуло в могилу весь браузер.
Тут тебе работа с диким количеством технологий — от трансформаций шрифтов до векторной графики до микроформатов.
И еще вагон и маленькая тележка других технологий, о которых я тебе говорил три или четыре раза. Тебе напомнить твою реакцию? «не пугай меня аббревиатурами, как-будто в 200-м году не было JPEG/GIF».
Какие, к черту, JPEG/GIF? Я тебе о них говорил? Это ты так читаешь? Это ты так принимаешь аргументы? И так — повсюду, во всех обсуждениях. Ты себе придумал какой-то мирок и любые факты, которые тебе неприятны или непонятны ты просто отметаешь в сторону, не читая.
Вот тебе факт:
Твои слова: "[старый интерпретатор] должен был бы и без всякой компиляции на нынешних Athlon/Dual/i7 летать."
Ikemefula проводит тест
, который разбивает этот довод в пух и прах. Твоя реакция? «IE8 неправильно спроектирован, и выбранная версия NN мне не нрравится»
Тьфу черт. И этот человек еще себя, видимо, профессором считает и что-то студентам преподает
Вот тебе факт:
Твои слова: "Если бы развитие остановилось на уровне 200-го года, современные браузеры/сайты не появились бы?"
Я тебе привожу причины, почему не появились бы. Твоя реакция в конце-концов? «не пугай меня аббревиатурами, как-будто в 200-м году не было JPEG/GIF»
Да черт побери, они были. Но в списке было в четыре раза больше технологий, которых в 2000-м году не было. Но зачем об этом думать? Они-то не помещаются в твою картину мира, поэтому ты решил увидеть только JPEG и GIF
Вот тебе факт, пусть и оффтопный:
Твои слова: «Не вижу, чем последние студии лучше, чем BC++ 5.5»
Тебе показывают фичи. Твоя реакйия? «Нет, давайте сравнивать только фичи, которые были в BC++»
Ты еще имеешь смелость утверждать, что ты хоть каки-то аргументы воспринимаешь?
Здравствуйте, Klatu, Вы писали:
K>Да-да, я знаю, обычное объяснение для любого идиотизма. K>"просто так получилось по историческим причинам, и теперь приходится работать с тем что есть" K>Это не отменяет всей идиотичности ситуации, тем не менее.
Ситуация нормальная. Динамика в силу ряда причин почти единственно возможный способ скриптования клиентской части.
PD>А мне-то, (как пользователю) — не все ли равно, какие там айсберги ? Я раньше видел картинки на экране и сейчас вижу их. Покрасивее все стало, да, кое-что добавилось. И я никак не могу принять, что эти добавления и красивости так уж требуют роста потребляемых ресурсов в 10 и более раз.
Домашнее задание: расчехлить антикварную машинку (хотя бы пентиум), запустить на ней свой любимый антикварный браузер, и попробовать, к примеру, пописать на этом сайте. Посмореть, в десять раз или не в десять рост ресурсов произошёл. Заранее уверен: это поможет обрести просветление.
Дело в том, что люди очень быстро привыкают к хорошему и перестают его замечать. Ну вот, например, мало кто помнит, что в 1998 году браузеры не могли показывать полноцветный JPEG — была палитра из 216 "safe internet colors". Что банальная текстовая табличка размером в 1 мегабайт могла завесить IE 3.0 минут на десять. Что в 1997 году MS Word 6.0 под windows 3.30 на 486 DX2 66 на page down тратил по 40 секунд. Что в windows 95 дефолнтым режимом было "отображать только рамочку при перетаскивании окна", а режим "show window contents while dragging" вообще включался через Microsoft Plus вплоть до OSR2.
Просто тогда это было нормально, и никто о лучшем и не мечтал.
Да и возможности, которых так "не заметно", они тоже интересны. Ну вот ексель научился показывать больше 65535 строк и 255 столбцов — подумаешь, ерунда. Или там цвета фона в ячейках можно выбирать из всей TrueColor палитры, а не из 16. Кто это заметит? А ведь из всех этих мелочей и складывается объем кода и памяти.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Klatu, Вы писали:
K>В принципе согласен, потребление растет непропорционально. Причем у меня есть четкое ощущение, что типичный офиснодевелоперский софт на типичной машине стабильно становится медленнее. То есть, закон Гейтса всё-таки победил закон Мура
K>Но проблема тут не в том, что "программисты ленятся", это всё на самом деле большая системная проблема.
Дело не в том. что они ленятся. Лень тут вообще не аргумент. Осталось бы памяти 32 Мб на машине — я бы посмотрел, как они ленились бы. Всех ленивых тут же и уволили бы, потому что их софт не работал бы.
Тут ИМХО другое. Начну издалека.
С++ многие ругают за то, что в нем очень легко наступить на грабли и (по определению В. Кочеткова) выстрелить себе в ногу. Не спорю — легко. Но С++ (а впрочем, и паскаль, а впрочем, и другие языки) — это был мощный отсеивающий фактор. Те, кто не был в состоянии писать на нем без стрельбы (или хотя бы без частой стрельбы) по своим конечностям, либо уходили из программирования, либо писали на Visual Basic, ниша которого была строго очерчена работой на заказ, а продаваемых программы с которого практически не было. Иными словами, программисту необходимо было преодолеть некий барьер по своему уровню профессиональной грамотности, чтобы стать С++ девелопером. Это, впрочем, и сейчас так.
А появление этих самых управляемых и интерпретируемых языков привело к тому, что этот барьер исчез. Средний уровень программистов резко понизился. Вот недавно тут проскочило такое , один написал — у меня завтра интервью, могут спросить про обход двоичного дерева сверху вниз, помогите. Читаешь такое — не знаешь, то ли плакать, то ли смеяться. Чем тебе помочь — на первый курс разве что помочь чтобы зачислили ? А ведь пройдет он чего доброго, это интервью (одна надежда — спросят про виртуальный деструктор и будет еще один "девелопер". Научится он понемногу всяким Ты.ИдиСюда и А_ты.Кто_ты_такой и будет нас потом здесь поучать , как правильно из абстракций код строить и его рефакторить
В сущности, большинство из них попросту не знают того, что раньше было обязательным. Они просто не понимают, где они сорят памятью, где используют неэффективные алгоритмы — они их реализации не знают, они метод вызывают! Им ничего не стоит вместо O(N) устроить O(N^2) — просто потому, что внутренности от них скрыты. Им ничего не стоит воспользоваться "красивой" реализацией чего-то, совсем не задумываясь о том, как эту реализацию реализовать будет некая исполняющая система.
А их к этому поощряют. Зато короче будет. Зато нагляднее будет. Зато поддерживать легче будет. В общем-то верно. И короче, и нагляднее, и поддерживать и т.д. Только вот все это за счет эффективности работы самой программы.
K>В принципе, выражается одной фразой — "некогда точить пилы, пилить надо!!!".
И это тоже. Некогда их обучать, писать программы надо
K>Недоделанные программы, недоделанные библиотеки, кривые недоделанные языки. Всё это кое-как скрепляется заплатками, соплями и слезами девелоперов и отправляется в "релиз". И еще проблемы совместимости с предыдущими версиями, такими же кривыми и недоделанными. И с каждой новой версией все эти слои заплаток и соплей растут как снежный ком
Здравствуйте, Eugeny__, Вы писали:
E__>В том-то и дело.
E__>Например, вот тут краткое описание возможностей современной IDE. Причем практически каждая из приведенного списка фич сама по себе сильно(некоторые — в разы) сложнее всей IDE для паскаля. Очень рекомендую Павлу для ознакомления. Там не сухие доки, а нормальное описание человеческим языком с картинками — читается легко. Просто для ознакомления.
Смотри, как на это может ответить Дворкин:
"Ну что там такого в этом списке ? Navigation and Search ? Да Search был в турбопаскале а это 20 лет назад !
Code Duplicates Detection ? Так пишите нормально и учитесь код читать и не нужны будут такие фичи."
I>>Вобщем ничего нового ты не добавил
PD>И не пытался.
А ты даже не попытался понять или даже прочитать, что тебе написали. В частности,
IE 8 — это бровзер иногда дает окошко, что дескать скрипт сильно медленно работает и предлагает выключить скрипт.
Это то, чем ты попытался «срезать» Икемефулу.
При этом Икемефула в пух и прах разнес,в частности, твою теорию о том, что интерпретатор 10-летней давности должен работать быстро на современном железе. Видимо, способностью воспринимать информацию (причем поданую максимально просто — в виде таблички с цифрами) ты тоже не обладаешь.
Увы. Тебя тоже можно зачислять на полочку к шеридану и хаттабу.
Здравствуйте, Mamut, Вы писали:
M>Предлагаю сначала показать мне, где я тебе предлагаю заглянуть в исходники, а только потом что-то об этих исходниках говорить
M>Все остальное скипнуто по вполне понятным причинам.
Павел сам сказал, что нужно анализировать исходники. Ссылка есть в твоем предыдущем посте. Правда, несколько позже он сказал, что на фиг оно не нужно. И на это ты дал ссылку в том же посте. Я, с твоего разрешения воспользуюсь им, когда буду ему отвечать. Сейчас внезапно выяснилось, что заказчик платит за работу, а не за чтение длинных постов на форуме и за написание еще более длинных ответов на них. Бюджет не резиновый.
Здравствуйте, LuciferSaratov, Вы писали:
LS>Это ещё что. Если посмотреть на 3D-шутеры, картина еще более удручающая: Wolfenstein 3D прекрасно работал на 80286 20Mhz и 640Kb ОЗУ с софтовым рендерингом, а Crysis'у подавай два ядра по два с половиной гигагерца, два гига памяти и аппаратный графический ускоритель. LS>Так он еще и в десять раз дольше вольфенштейна запускается, разучились писать однозначно.
Дело не в том, что многие программы потребляют ресурсов больше, чем их аналоги 10-летней давности. Это само по себе нормально. Дело в том, что они потребляют их непропорционально новым возможностям. Грубо говоря, если этих возможностей стало в 2 раза больше, то и потреблять ресурсов можно в 2, пусть в 4, пусть в 8 раз больше, а не в 20 и не больше. Просто раньше, добавляя нечто, заботились о том, чтобы это нечто было эффективно реализовано и не увеличивало те же расходы памяти в 2 раза, а то можно и с рынка вылететь, потому что машин, где это будет работать, окажется 1%, а сейчас можно писать как бог на душу положит, захватывать ресурсов намного больше, чем алгоритмически требуется и оправдывать все это тем, что их много.
PD>Только пожалуйста, не занимайтесь теоретическим обоснованием той неэффективности, которую вы делаете.
PD>(естественно, ничего личного)
PD>Вот эту последнюю фразу мне мои оппоненты и не простят.
Простят. Но только если теоретическое обоснование эффективности с другой стороны не будет пассами руками и рассказами про турбо паскаль.
I>>P.S. Пока не залез в твой профайл мне все все время казалось что имею дело с подростком — вчерашним студентом.
PD>который каким-то образом ухитрился работать в 80-е годы на ТурбоПаскале.
PD>
Обрати внимание на поведение. Ему пдевать, что ему указывают на гигантские дыры в его рассуждениях (и не мение гигантские лакуны в его знаниях). Он предпочитает из всего сообщения выбрать одно предложение и ответить на него.
Здравствуйте, Mamut, Вы писали:
M>Покажи мне эти языки для клиентского скриптинга в браущере с покрытием хотя бы 50% рынка браузеров
Да-да, я знаю, обычное объяснение для любого идиотизма.
"просто так получилось по историческим причинам, и теперь приходится работать с тем что есть"
Это не отменяет всей идиотичности ситуации, тем не менее.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Сидели бы себе и по сей день на 640кб.
I>>С сайтами происходит тоже самое.
PD>Если бы память (и процессор) разрабатывали китайцы или индусы , то нынешний i7 и 4GB заняли бы всю твою квартиру
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Если поиск в БД на 4 Мб занимает минуту — программиста уволить с волчьим билетом, и все переписать. PD>>Я нечто подобное сам писал. Поиск в своем собственном файле (хочешь — назови его БД , хоть и не телефонов. Только поиск этот занимал не минуту, а 5-10 мсек. PD>>И память при этм не транжирил. Был там mmf на базу (она была примерно так 300 Мб), маппировались страницы, а больше никакой памяти и не выделялось. Зачем ?
G>У меня ощущение, что ты над нами издеваешься. G>"Третий раз объясняю, уже сам все понял, а они не понимают" (с) анекдот
G>Ну замени в моем тексте поиск на "сделать некую очень ресурсоемкую операцию" и 4Мб на 4Гб (пусть на винте лежат).
Тогда ответ прост. Пишите эту ресурсоемкую операцию, используя увеличенное количество ресурсов. Но сначала докажите, что она ресурсоемкая.
И если мне начнут доказывать, что поиск в БД на 4 Гб таков, что без этого увеличения затрат ресурсов идет 1 минуту — программиста уволить и все переписать.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Просто раньше, добавляя нечто, заботились о том, чтобы это нечто было эффективно реализовано и не увеличивало те же расходы памяти в 2 раза, а то можно и с рынка вылететь, потому что машин, где это будет работать, окажется 1%, а сейчас можно писать как бог на душу положит, захватывать ресурсов намного больше, чем алгоритмически требуется и оправдывать все это тем, что их много.
В принципе согласен, потребление растет непропорционально. Причем у меня есть четкое ощущение, что типичный офиснодевелоперский софт на типичной машине стабильно становится медленнее. То есть, закон Гейтса всё-таки победил закон Мура
Но проблема тут не в том, что "программисты ленятся", это всё на самом деле большая системная проблема.
В принципе, выражается одной фразой — "некогда точить пилы, пилить надо!!!".
Недоделанные программы, недоделанные библиотеки, кривые недоделанные языки. Всё это кое-как скрепляется заплатками, соплями и слезами девелоперов и отправляется в "релиз". И еще проблемы совместимости с предыдущими версиями, такими же кривыми и недоделанными. И с каждой новой версией все эти слои заплаток и соплей растут как снежный ком
Здравствуйте, Mamut, Вы писали:
M>>>>>Не говоря уже о том, что эта программа во время выполнения не занимается JIT'ом, оптимизацией и т.д. и т.п. (опять повторяюсь). A>>>>не провоцируй, а то ведь вспомнит про p-code M>>>ээээ. чо? A>>да вики же я в том смысле, что "ещё когда умели правильно писать и руки не кривые были", уже были "виртмашины", и таки частенько это было подложено именно под паскаль M>Ааааа. Я думал, он просто уже говорил об этом, и удивился
не, если бы он говорил, мы бы узнали что хром-говно, а jit умели делать ещё в 70е и на memsize -> 0
но он сказал ровно противоположное:
>Не говоря уже о том, что эта программа во время выполнения не занимается JIT'ом, оптимизацией и т.д. и т.п. (опять повторяюсь).
Это уж точно. На 64 Кбайтах
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здесь сказано про броузер ? Речь идет о программах вообще. В частности, для компиляторов + IDE это верно : в ДОС они занимали , естественно, 1 Мб (ну иногда больше, за счет expanded памяти, BC++ 3.1), а сейчас VS 2010 без открытого solution — 82 Мб, только сейчас посмотрел.
Были бы тогда на машинах по 4 гига памяти и те программы тоже занимали бы столько памяти.
И вообще не красиво сначала кидать заявления по одному поводу (об интерпретаторах JS), а потом переводить стрекли на IDE.
Сравинивать BC++ и VS 2010 — это все рано что сравнивать жопу с пальцем. Кривой компилятор и "IDE" в которой окромя подсветки синтаксиса и MDI-интерфейса ничего не было и IDE поддерживающую тучу языков и платформ, мрожество дизайнеров, средства управления версиями, тесты, рефакторинги и реалтайм-проверку синтаксиса и семантики, интллисенс и многое другое — это даже не смешное сравнение. Это просто глупое сравнение.
Ты еще сравни Форд T и Форд Мондео. А чё Форд-Т наверно меньше бензина жрал. Да и мог ездить на очень низкоактановом бензине. А насколько он (наверно) был легче?
Короче трава была зеленее, а небо голубее — это самовнушение стариков, а не реальность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
В старые добрые времена, когда программисты были умными, а программы — быстрыми и компактными, был написан интерпретатор JS.
Павел Дворкин:
"Я — в своей правоте уверен. По очень простой причине — я все это видел своими глазами и работал с этим. Я готов допустить, что нынешние языки и средства сложнее тех, что были 10-20 лет назад, в 5-10 раз. Но я никак не могу согласиться с тем, что они сложнее в 100 раз. Если бы я видел, что нынешнее ПО требует в 10 раз больше памяти и быстродействия , чем ПО 10-20 летней давности. я бы и слова не сказал. Но когда я вижу, что потребности в памяти увеличились в 100 раз, скорость процессора — в 50-100, в все вопят — памяти мало, программы тормозят (и это правда), то объяснение только одно — разучились писать как следует."
Стало быть надо проверить насколько были быстры прежние интерпретаторы и за счет чего перформанс, за счет процессора или усилий разрабов. То есть — проверяем, летает ли старый интерпретатор на нынешних процах (Дворкин "должен был бы и без всякой компиляции на нынешних Athlon/Dual/i7 летать.").
То есть если старый интерпретатор будет летать на нынешних конфигурациях, стало быть программисты пишут код безалаберно и головой не думают.
Тестовый энв — Win7 64 Q8200(2.33Ghz) 4Gb 1GHz Bus, Affinity — CPU 0(не заметил что это влияет на результаты), все тесты были выполнены по несколько раз что бы исключить случайные факторы. Все участники находятся в равных условиях.
Опровергателям-малолеткам вроде _Raz_ — результаты теста могут сравниваться только для конкретной версии теста и бОльшие цифры значат лУчший результат !
Фаворит гонки — великий и ужасный, несправедливо убиенный NN 6.2.3 (4.7.9 похоже умеет только пародию на JS и ничего с ней сделать нельзя,но предположим, разрабы в 6.2.3 были как минимум такими же умными, как и те что писали 4.7.9)
Тест не проходи — NN уходит на покой на 89%, но зато есть промежуточные результаты. Тест пришлось прогнать раз десять,потому что NN валился при копировании текста в клипборд.
"...А процессора по сравнению с 90-ми — на 2 порядка. Плюс многоядерность. Так что прежний интерпретатор (если бы он был хорошо написан) должен был бы и без всякой компиляции на нынешних Athlon/Dual/i7 летать."
"Вообще-то интерпретатооры умели писать и раньше, и работали они достаточно быстро. А с тех пор быстродействие процессоров очень — таки возросло, а язык JS вроде как не очень усложнился.."
"Каждому юзеру вполне хватило бы, я так думаю, 16-32 Мб за глаза. Хватало же, когда памяти на машине было именно столько. Что с тех пор радикально нового в JS появилось ?"
"Что за чудная такая задача — интерпретатор с несложного, в общем-то, языка, к тому же большая часть кода в котором есть вызовы браузера (всякие document.open и window.on_не_знаю_что)"
PD>>>Ну и как ? Сильно отличается ?
G>>про это тут тебе уже писали где-то. про раскрытие веток и подобное.
PD>Охотно верю. Но вот незадача — в Windows95 эти ветки в treeview умели раскрывать довольно таки шустро, правда, вне броузераЮ зато на 8 Мб. Доказательство простое — — regedit же работал! А там уж не меньше порой ключей одного уровня, чем сообщений в любом топике на всех уровнях.
Павел начал смещать приоритеты. Не сумев разобраться, что за технологии используются браузерами, он решил сместить акценты на то, что мы все идиоты и не лечимся, и все, что делается в браузере, по отдельности достижимо вне него на более скромных ресурсах.
То есть, если бы он не был теоретиком, засевшим в конце 90-х (в лучшем случае), он бы смог приводить такие аргументы:
— например, iPad/iPhone показывают HD-видео в ограниченных ресурсах (как по процессору, так и по памяти)
— например, iPad/iPhone/что-нить-еще могут делать что-то еще (например, редактировать документы или рисовать) в ограниченных ресурсах (как по процессору, так и по памяти)
— например, iPad/iPhone/что-нить-еще могут делать что-нибудь еще в ограниченных ресурсах
ну и т.п.
Что до него в упор не доходит — то, что браузер умеет все это вместе и одновременно, и что пользователю на десткопе нужно именно это.
Не говоря уже о многом другом, о чем он ни сном ни духом (то технологий о моделей безопасности и т.п.)
M>>Покажи мне эти языки для клиентского скриптинга в браущере с покрытием хотя бы 50% рынка браузеров
K>Да-да, я знаю, обычное объяснение для любого идиотизма. K>"просто так получилось по историческим причинам, и теперь приходится работать с тем что есть" K>Это не отменяет всей идиотичности ситуации, тем не менее.
Вообще-то, покрытие рынка — это, практически, единственный критерий, про который можно говорить JS невероятно хорош по очень многим параметрам (и плох по тем же ) — легкость в обучении, легкость в написании. Это, наверное, единственный язык программирования, в котором AG применяется достаточно плотно и активно даже людьми, которые в жизни не занли, что такое ФП, ФВП и т.п.
10 лет тому назад таких языков, считай, и не было (разве что, наверное, питон, но не уверен).
Здравствуйте, WolfHound, Вы писали:
I>>Ситуация нормальная. Динамика в силу ряда причин почти единственно возможный способ скриптования клиентской части. WH>Назови хоть одну.
Разные версии html, css, браузеров, файлов, отсутствие файлов. С динамикой не возникает никаких проблем.
Здравствуйте, Pavel Dvorkin, Вы писали:
>В частности, для компиляторов + IDE это верно : в ДОС они занимали , естественно, 1 Мб (ну иногда больше, за счет expanded памяти, BC++ 3.1), а сейчас VS 2010 без открытого solution — 82 Мб, только сейчас посмотрел.
Это ещё что. Если посмотреть на 3D-шутеры, картина еще более удручающая: Wolfenstein 3D прекрасно работал на 80286 20Mhz и 640Kb ОЗУ с софтовым рендерингом, а Crysis'у подавай два ядра по два с половиной гигагерца, два гига памяти и аппаратный графический ускоритель.
Так он еще и в десять раз дольше вольфенштейна запускается, разучились писать однозначно.
Здравствуйте, Antikrot, Вы писали:
A>передёргиваешь тут исключительно ты. вот буквально в цитате выше. следуя твоим же словам, надо сравнивать не общее потребление памяти VS, то только ту память, что используется под фичи, которые есть в BC. что весьма и весьма проблематично, и ты это прекрасно знаешь.
Ну если уж именно о таком сравнении речь пошла, то ответ простой.
В IDE VC++ до 2010 я не вижу ничего такого, чего не было в BC++ 5.0. Можно привести десятки новых возможностей, но это все будет мелкие улучшения. Принципиально ничего нового нет. Я готов допустить, что под эти возможности надо еще несколько Мб, но не в 5-10 раз же!
(В скобках. Мне запомнился один комментарий в эхе тех времен. Обсуждался новый BC 5.0. Кто-то сказал примерно следующее : "Увы, но , видимо, в России этому компилятору не жить — он эффективно работает на машинах с не менее чем 32 Мб ОП, а таких машин у нас немного". Заметь, не требует сам 32 Мб, а на машине должно быть не менее 32 Мб)
В IDE VC++ 200x (кроме 2010) я не вижу ничего такого, чего не было в IDE VC6.Можно привести десятки новых возможностей, но это все будет мелкие улучшения. Принципиально ничего нового нет. Я готов допустить, что под эти возможности надо еще несколько Мб, но не в 5-10 раз же!
VS 2010 перевели на WPF. Аллах их знает, чего они хотели этим добиться, внешне интерфейс изменился мало, но в итоге потребности по памяти возросли с 34 Мб (2008) до 80 Мб (при неоткрытом solution). Ну и загружается она секунд 10-15.
Кроме того, появление новых возможностей отнюдь не означает, что потребности в памяти должны пропорционально возрастать. Динамическую загрузку и выгрузку никто не отменял. Я не берусь привести примеры для IDE, она достаточно сложна, но вот ICQ, которая у меня когда-то работала на машине с 8 Мб и которой, как сейчас уверяют, нужно до 100 Мб — пример классический. Новых фич там много, не спорю, но в 99% ICQ используется так же, как и 10 лет назад, то есть для пересылки SMS. А поэтому сидели бы все эти новые фичи в виде DLL на диске и ждали, когда их позовут.
Здравствуйте, Pavel Dvorkin, Вы писали:
G>>Вопрос, почему ты игнорируешь, то что тебе говорят люди которые более компетентны в этом вопросе чем ты?
PD>Потому что люди, которые считают себя более кометентными, вместе с этой компетентностью приняли правила игры в этой отрасли, а поэтому взглянуть на эту проблему, отринув эти правила игры, не могут. Люди, которые очень компетентны в разработке автомобиля, не поверят, что с двигателем внутреннего сгорания можно сделать что-то такое, что будет летать — их компетентность давно их научила тому, что рожденный ездить летать не может
Все, я сдаюсь. Это религия, а религия как известно не подчиняется здравому смыслу.
PD>>Фантастика! Все, сдаюсь. Раз уж при 3.2 GHz, 4 ядрах, 4 GB памяти, черт знает каком количестве каких компьютеров у самой Google и скоростью Интернета в несколько Мбит/сек научились редактировать один документ несколькими пользователями — все, я сдаюсь.
I>Заметь — ты снова спрыгнул с темы.
I>Было сказано про гугловые вебпроложения, а ты " редактировать один документ ".
Сейчас в 40 сообщениях он тебе расскажет, что он не прыгул с темы, а просто сделал замечание, что его студенты это зхнают и умеют и иди в WinAPI, а потом «устанет» от спора.
Здравствуйте, Pavel Dvorkin, Вы писали:
G>>про это тут тебе уже писали где-то. про раскрытие веток и подобное.
PD>Охотно верю. Но вот незадача — в Windows95 эти ветки в treeview умели раскрывать довольно таки шустро, правда, вне броузераЮ зато на 8 Мб. Доказательство простое — — regedit же работал! А там уж не меньше порой ключей одного уровня, чем сообщений в любом топике на всех уровнях.
Внимание, ты начинаешь отнимать хлеб у Шеридана. Оценивать производительность виндовой гуи по линуксовой это его прерогатива!
А если серьезно, ты сам не понимаешь, что сравниваешь теплое с мягким?
Здравствуйте, Eugeny__, Вы писали:
E__>Очень удачный пример. Но дело в том, что под понятием "редактирование картинки" можно понимать как "изменение цвета одного из пикселей"(а что, этим инструментом можно вполне добиться любого результата, но нужно быть изрядным задротом), так и "интеллектуальное выделение, применение сотен фильтров, хитрые алгоритмы при изменении размеров, работа со слоями и еще много-много блекджека и шлюх возможностей, облегчающих жизнь дизайнеру". Так вот для всех этих фич тоже нужна память, и немало.
Я буду не против, если исключительно для этих целей вы будете использовать память в броузере. Правда, я подозреваю, что это надо делать не на js, а как-то иначе. Но когда вам просто надо нарисовать картинку из тега img — давайте все же обойдитесь width*height*4 байт.
PD>Вот если бы размер экрана увеличился с тех пор раз так в 10 — другое дело. Или страница имела бы размер так примерно Мб 50 против 5
Бойся чего-либо желать, ибо желаемое исполнится: 640x480x1 = 307200 байт. 1440*900*4 = 5184000 байт. Итого, размер экрана вырос в 16.875 раз.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Детский лепет. UI-поток даже теоретически не может принять меры по реагированию на что бы то ни было в ожидании каждого мьютекса. В частности, он может встать на мьютексе в совершенно невинно выглядящем месте, просто потому, что там где-то внутрях сработала LoadLibrary. Странно, что человек с таким загибом пальцев про Win32 этого не знает.
Если хочешь это обсудить — welcome в форум по Win32, там я готов в этом обсуждении участвовать. Здесь это офтопик.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>1."В броузер в принципе ничто не мешает засунуть что угодно". Это тезис. PD>2. "Тебе про ActiveX напомнить ?" Это пример, демонстирующий один из вариантов этого "что угодно". И не более, как легко понять.
PD>Так что целью этого высказывания является именно тезис , а вовсе не этот пример. Поэтому обсуждать его в ином контексте не имеет смысла.
Ах вот ты что имел в виду. Извини — я сразу не понял. Видишь ли, некоторые вещи я (как и многие другие) привык считать очевидными, поэтому интерпретирую всё с учётом такого профессионального сдвига. Ок, поясню подробнее:
Под "засунуть" в твоей фразе любой веб-девелопер подумает "засунуть со стороны сайта". Понимаешь? Особенность веба — в том, что мы не контролируем браузер. Мы контролируем только наш сайт. С точки зрения веб-девелопера, браузер — это платформа. Нам не очень хочется иметь дело с несколькими десятками реальных платформ. Лично тебе хорошо — ты пишешь под конкретную версию конкретной операционной системы. Представь, что тебе предложили спортировать твою тщательно вылизанную программу на iOS под A4.
Это один аспект.
Другой аспект — безопасность. Для JS предприняты специальные меры, которые изолируют пользовательскую машину от зловредных приложений на нём. Даже для ActiveX это уже невозможно; а для приложения, которое вознамерится всунуть в браузер что-то совсем кустарное — тем более. Поэтому, требуя от людей чего-то скачать и поставить, ты, мягко говоря, рискуешь нарваться на отказ.
Если ты — мега сайт с высокой посещаемостью, и дорогими гарантиями подлинности (SSL сертификаты с подтверждением — для сайта, для кода, и так далее), то ещё можно рискнуть.
Но те же особенности имеет обычное коробочное ПО.
В итоге получается, что в принципе засунуть что-либо в браузер в твоём понимании мешает здравый смысл.
А в жизни у тебя выбор между JS, Flash, Java Applet и ActiveX. Двое из которых — тихий ужос. Микрософт пытается добавить к списку субплатформ Silverlight. Как видим, пока что даже софтверный гигант с капитализацией Газпрома не может "засунуть в каждый броузер что угодно".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
G>>Ну то есть ты не в курсе что такие утвеждения контрпримерами не опровергаются?
PD>А примерами доказываются ? Мне в качестве примера Google дают, он — доказательство, так ? А то, что для других сайтов все это не нужно — не годится в качестве аргумента ? Хорошенькое получается дело — примеры что-то доказывают, а контрпримеры — ничего. Тогда уж считать надо — сколько примеров, а сколько контрпримеров. И какова их роль, конечно, тоже.
Ты что правда не знаешь? Это же основы логики.
Контрпримером опровергается утверждение вида: для всех А верно В
но
Контрпримером не опровергается утверждение вида: для некоторых А верно В
то есть утверждение
"Все сайты стали требовать много ресурсов" опровергается твоим контрпримером.
Но утверждение "Некоторые сайты стали требовать много ресурсов" твоим кнотрпримером не опровергается.
. Надеюсь к чему-то прийти. В идеале — прояснить и этот вопрос. В свое время Нильсу Бору стоило немалых усилий доказать Эйнштейну справедливость квантовой теории.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Опять передергивания пошли. Надоело. Какие все ? Я всего лишь Ikemefula объяснял, что он не знает. Я кого-то идиотом хоть раз назвал ? Я хоть где-то написал, что я один знаю, а больше никто ? Где ?
I>Представь себе, ты на форуме преподавателей основ программирования.
I>Тут приходит некто и говорит "Преподавание основ программирования нынче безалаберное, никто толком не может ничего объяснить студентами."
I>Какая будет реакция посетителей ?
А ты думаешь, я сам на 100% уверен, что оно идет правильно ? Это не матанализ, там методики отработаны десятилетиями. А у нас даже нет стабильной программы, и быть не может, потому что пока ее сделаешь, она устареет. А у нас нет даже учебников. Литературы навалом, а учебников нет. А "освой программирование на ... за 21 день" или "самое полное руководство по ..." — это не учебник совсем.
Сейчас придет модератор и распатронит всю эту дискуссию. kernel-mode в одну сторону, мютексы в другую, а это вот в третью
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Netscape 3.0 Gold. Ему, правда, не 10 лет, а немного побольше. С NN 4.x началось ухудшение.
Паш, но ведь все же очевидно. Netscape 3 — это полное дерьмо (по современным меркам) которое не может нормально открыть большую часть современных сайтов. Потребляет он меньше памяти потому, что писался он для того железа. За малое потребление ресурсов приходится платить убогостью отображения, урезанной функциональностью и т.п.
Неужели для тебя не очевидно, что если бы Netscape 3 удовлетворял бы потребности пользовтелей и при этом выигрывал бы производительности и потреблении ресурсов, то хоть кто-то стал бы качать себе все эти ФаерФоксы, Девятые Эксплореы и Хромы?
Очевидно же, что потребитель голосует скачиванием и использованием. И он голосует не за 6 метров, а за качество. Причем понятие "качество" — это довольно сложное, составное понятие. И скорость или потребление ресурсов в этом понятии только отдельные составляющие.
Скажем сейчас я пишу это письмо на ФаерФоксе 3.6.3. Он отожрал 200 метров. Много это? Ну, по меркам 1995-го года — это невероятно много. Тогда просто нельзя было поставить на десктоп столько памяти. Но мне на это наплевать! У меня 4 гига этой самой памяти. Вот то что он подтормаживает при вводе текста меня немного раздражает, но в замен я имею реалтайм-проверку правописания и качественное оторажение контента. И я готов терпеть некоторые тормоза в замен на другие составляющие качества.
Я знаю что есть более быстрый Хром, но его качество меня не устраивает просто потому, что в мое понятие качества входит наличие некторых фич (плагивнов, проверки орфографии и т.п.), которых нет в Хроме.
Ну, а качество Netscape-а вообще не приемлемо для меня. И плевать мне, что он потреблял 6 метров. Кстати 6 супротив 200 — это все же не 100 раз. Но даже если бы это было 120 раз мне было бы на это плевать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
I>Раньше тоже кстати кричали, только компьютер был не у каждого, как сейчас и просто криков было мало.
И не просто раньше. В свое время велись довольно шумные войны Assembler vs Fortran. Ассебблерщики обвиняли программистов на ЯВУ, в частности, Фортране, ровно в том же, в чем Павел обвиняет своих оппонентов. И где сейчас тот ассемблер?
I>>В старые добрые времена, когда программисты были умными, а программы — быстрыми и компактными, был написан интерпретатор JS.
K>Для полноты картины надо добавить, что в "старые добрые времена" программиста, который захотел бы написать что-то сложное на JavaScript, немедленно отправили бы в дурку. K>Сейчас это безумие вошло в моду, и здравый смысл только еле-еле пищит где то в углу "а на _уя вообще писать на JS, когда есть куча языков, которые намного быстрее, удобнее и надежнее?"
Покажи мне эти языки для клиентского скриптинга в браущере с покрытием хотя бы 50% рынка браузеров
Здравствуйте, Ikemefula, Вы писали:
I>Ситуация нормальная. Динамика в силу ряда причин почти единственно возможный способ скриптования клиентской части.
Назови хоть одну.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Динамика действительно кажется более удобной, с этим я согласен.
Оно тебе кажется исключительно из-за узости твоего крогозора.
Надо иногда вылезать за приделы С++. Вотнапример как язык для браузеров со статической типизацией может выглядет.
Сейчас для клиента генерируется жабаскрипт но ни что не мешает засунуть ur прямо в браузер.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я вроде как ничего о том, как его построить, не писал, нет ? Я лишь высказал некоторые соображения, касающиеся построения компиляторов (трансляторов) в прошлом и сейчас и соотнесения этого с размерами потребной памяти опять же в прошлом и сейчас.
Возможно, ты хотел высказать некоторые соображения, при этом безо всякого желания вникнуть в сложность задачи стоящей перед разработчиками нынешних интерпретаторов.
Вобщем, доведут тебя турбопаскали и борлады до цугундера P>>Какую веру, ты о чем?
PD>Так я и подвергаю . Подвергаю более или менее ставшие общепринятыми в определенных кругах концепции.
Для начала хорошо бы понять задачу, а то вместо этого "а мои студенты...", "а турбопаскаль на ямахе" и тд.
PD>>...Я лишь высказал некоторые соображения, касающиеся построения компиляторов (трансляторов) в прошлом и сейчас и соотнесения этого с размерами потребной памяти опять же в прошлом и сейчас.
P>При этом проигнорировав, скажем так, некоторые различия вежду ТурбоПаскалем и js.
Нет, не проигнорировав, а просто не говоря об этом, поскольку это само собой разумееется. Я же не утверждал, что надо интерпретатор JS в 640 Кб запихнуть. Вопрос тоньше — соответствует ли увеличение потребности в ресурсах усложнению языка (если оно есть).
PD>>А те, кто не прошел — разбазаривают. И те, кто прошел, порой тоже.
P>Не факт. Во всяком случае, интерпретатор js не подтверждает твой тезис.
Не знаю. Меня тут Мамут тысячекратно обвинял в том, что я не хочу заглянуть в исходники. А я действительно не хочу. Зачем ? Ну загляну я в них, и что дальше ? Дальше возможны следующие варианты
1. Я их анализирую и говорю, где можно лучше сделать . Понятно, что это несерьезно, мне на это и месяцев не хватит.
2. Я их анализирую и, потрясенный их мощью, изяществом и оптимальностью, признаю себя неправым. Тоже не реально и по той же причине.
А вот контрпример. Показывают мне некую IDE, занимает 80 Мб без открытого солюшена, и говорят — смотри, как хорошо сделано. А я говорю — не очень-то хорошо. Да ты ничего не понимаешь, отвечают мне. Посмотри исходники и убедись.
А я отвечаю — не нужны мне ваши исходники, и не буду я их смотреть. По очень простой причине — вот вам IDE почти с теми же возможностями (ну немного лучше, да), но занимает она всего 35 Мб (до чего я дожил — защищаю IDE, которая занимает 35 Мб . И ее исходники мне тоже не нужны. И смотреть, как там устроено, я не буду, и рекомендовать ничего никому не буду. Я просто констатирую — вот вам IDE почти с теми же возможностями и с потребностью в памяти в 2.5 раза меньше. Это вы обоснуйте — зачяем вам понадобилось в 2.5 раза увеличить, на что вы их потратили ? На то, чтобы с WinForms (опять до чего я дожил — WinForms защищаю на WPF перевести ?
Речь идет, как наверное понял, о VS2010 vs. VS 2008. Правда, сомневаюсь, что мне MS покажет исходники
PD>>Да. Теоретическм основам теории алгоритмов, структур данных и т.д.
P>Расшифруй. Применение неподходящего контейнера еще не является нарушением законов. Это незнание законов.
Незнание законов не освобождает от ответственности (не принимай всерьез, не удержался)
>Потому что контейнер работает в полном соответствии с этими законами. А разработчика в студенчестве преподы на лабах по структурам данных плохо гоняли.
Применение неподходящего контейнера есть нарушение закона. Разумееется, не законов поведения этого контейнера, а законов теории алгоритмов, которая определяет, какой алгоритм (и соответствующий контейнер, но это частности) должен применяться для решения той или иной задачи. Зачем, спрашивается, тысячи и тысячи математиков и программистов эти алгоритмы и структуры данных анализировали и искали наилучшее решение, если можно наивным программированием запустить нечто, на порядок по времени/памяти хуже, лишь бы работало. Зачем Кнут quicksort придумал и зачем ее потом годами анализировали — пузырек прекрасно работает и всегда дает правильный результат. Вот это и есть нарушение законов. Это и есть постройка моста с быками в полреки.
>>>Или тем, что сказал: требования к памяти противоречат требованиям ко времени реакции на запрос?
PD>>А это один из законов. Но не все тут так просто.
P>Конечно. Разработчики движка V8 пошли по пути сокращения времени отклика. С их точки зрения эта характеристика важнее остальных. И мои ощущения пользователя подтверждают, что их решение обосновано. Раз на нетбуке работает быстро и соседним приложениям не мешает, мне, потребителю, все равно, какие там законы они нарушили. Когда существующее положение меня устраивать перестанет, я возьму продукт конкурента.
Дело не в том, какие законы они нарушили. Дело в гораздо более серьезном.
Мне тут уже столько раз доказывали, что разработчики v8 сделали все идеальным образом, что я готов (на одну строчку) с этим согласиться. Как тот китайский сервер, который в конце концов убедили, что пароль "МаоЦзедун"
Допустим, что в этом случае это именно так. Но я вижу множество случаев, когда это далеко не так. А просто транжирят память без зазрения совести.
А если это так — почему я должен верить, что для v8 это так ? Потому что меня Мамут пытается в этом убедить ?
А поскольку таких продуктов, в которых память транжирится самым беспардонным образом, то страдает все же технология, потому что в ней укореняются принципы, противоречащие ее базовым законам.
P>Законы информатики не изобретены человеком, а открыты. Как я уже сказал, неправильное применение контейнера или алгоритма не является их нарушением, потому что оные контейнер или алгоритм работают в соответствии с ними вне зависимости от того, как их используют.
См. выше.
PD>>Построить мост с быками толщиной в спичку нельзя — рухнет. А вот построить его с быками шириной в полреки — можно, угрохать чертову прорву сил и средств, а в итоге получить решение, ничем не лучшее чем то, которое бы получилось на основе положений сопромата и т.д.
P>Мост в полреки означает неверный расчет смет.
Нет, это просто незнание основ сопромата и т.д. Вот если я его начну строить — я именно такое и построю. Под суд неохота, если он рухнет . А сметы определяются технической стороной дела — тем же сопроматом.
P>Поинтересуйся как-нибудь, почему прорывает водопровод, причем в одно и то же время.
У кого ?
P>Почему? Как это не компетентен? Ты в самом деле думаешь, что пользователь не в состоянии отличить хороший софт от плохого?
Да. Равно как я не могу отличить хороший (по внутреннему устройству) самолет от плохого. Я могу в лучшем случае сказать, что кресла тут хорошие или нет.
>А ничего, что в своей предметной области твой заказчик значительно компетентнее тебя?
Ничего.
>И точно знает, что ему нужно.
Он знает что ему нужно в своей предметной области, а не в том, как это можно реализовать в неизвестной ему области.
>А вот как сделать то, что нужно — в этом заказчик полагается на тебя.
Вот именно. А я (не я лично) говорю ему на основании своих представлений, что для этой задачи меньше 100 Мб нельзя и меньше i7 тоже. А это мнение мне не заказчик формировал, а я его сам на основе каких-то соображений сделал. А они верны или нет — не заказчику судить. Может, тут 386-DX хватит
>Так что к его мнению ты будешь внимательно прислушиваться, и совершенно никого не интересует твое к этому мнению отношение.
Буду. Если он мне скажет, что программа делает не то, что надо или не так — непременно буду. Но о том, какие средства употреблять и какие затраты памяти и т.д. должны быть — не ему говорить и не мне слушать.
P>Дак ведь и в самом деле денег мало и deadline неотвратим, как крах мирового империализма. А существование подобных утилит входит в смету. И перерасход из-за на фиг никому не нужной оптимизации в этих местах вряд ли будет одобрен заказчиком.
Да все правда, я же уже 5 раз с этимм согласился. Но еще раз — это же значит, что технология определяется не законами науки, а наличными деньгами. К чему такая технология придет, которая готова наплевать на свои принципы, если заплатят ?.
P>>>Техзадание с заказчиком обсудили? Утвердили? В рамки укладываешься? Есть запас прочности по предельным нагрузкам раза в полтора-два? Где здесь, в таком случае, неэффективность?
P>Еще раз: заказчик знает, что он хочет. Умный заказчик попросит техзадание от нескольких исполнителей, а потом еще и экспертам покажет.
Это годится, когда есть разные разработчики, если одна команда может предложить решение, намного лучшее, чем другая. Если все предлагают решение одного качества, сообразуясь в основном не с тем, как это можно хорошо сделать, а в основном с тем, сколько заказчик на это готов потратить — мы получим отот всех одно и то же.
>А подписание акта сдачи-приемки работ иногда становится хорошим квестом для исполнителя. Особенно когда он начинает рассуждать о неправильных контейнерах. Заказчика это не интересует. Ему нужна хорошо работающая программа сегодня, а не идеальная неизвестно когда.
См. выше.
PD>>Дело в том, что применяя некий метод некоего класса надо не хвататься за этот класс и этот метод на том основании, что он решает задачу, а поинтересоваться — с какими затратами. Если у нас есть метод сортировки, то если он N*logN — это хорошо, если N^2 — может быть иногда приемлемо, а если N^3 — то это безобразие и ничего больше. И даже если сортируется массив на 100 элементов один раз в минуту — это все равно безобразие и ничего больше! И если в той же сортировке заводится дополнительный массив N^2, то это тоже безобразие. И линейный — тоже.
P>Такие вещи везде и всегда зависят от конкретных условий. Ты, наверное, знаешь, что 100 элементов пузырьком сортируются столь же эффективно, как и быстрым алгоритмом.
Я же и сказал — иногда приемлемо.
>А иногда выделение массива дает выигрыш в скорости. пример — быстрая сортировка на Фортране IV.
Ты о том, что quicksort требует стека и его на Ф4 динамически не выделить ? Согласен, но это лишь следствие ограничений Ф4.
P>Но все же существует разница между ТурбоПаскалем и js.
Я одно не пойму — с чего вы все решили, что я этой разницы не вижу и требую уложить нынешний интерпретатор js в 640 Кб ? Я привожу TP в качестве некоей реперной точки для рассуждений, вот и все.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Опять передергивания пошли. Надоело. Какие все ? Я всего лишь Ikemefula объяснял, что он не знает. Я кого-то идиотом хоть раз назвал ? Я хоть где-то написал, что я один знаю, а больше никто ? Где ?
I>Представь себе, ты на форуме преподавателей основ программирования.
I>Тут приходит некто и говорит "Преподавание основ программирования нынче безалаберное, никто толком не может ничего объяснить студентами."
I>Какая будет реакция посетителей ?
От посетителей зависит. Лично я — попрошу аргументы, с которыми, возможно, соглашусь, а может и нет. А почему бы не послушать мнение человека , даже если я о нем ничего не знаю ? Есть такое понятие — профессиональный кретинизм, слышал, наверное ? Так вот у этого некто как минимум его нет, потому что он не преподаватель, а со стороны. Пусть скажет, что он думает. Если явная чепуха — спорить не буду, пропущу мимо ушей. А вдруг совсем не чепуха ?
Здравствуйте, Pavel Dvorkin, Вы писали:
G>>Ваша дискуссия выглядит так: G>>Ребятки, чего это ваш агрегат со скоростью 60 км/час движется ? G>>Так это, траффик, машин много стало в 21 веке, быстрее сложно в городе ездить, даже на феррари. G>>Неее. Ничего не знаю, я еще 20 лет назад из жигулей 70кмч под горку выжимал, говно ваша феррари.
PD>А чего это ваша "феррари" все же под горку со скоростью 60 км/час движется ? Там, где нет трафика, нет машин, да и дорога стала намного шире ?
Ну то есть какие-то аргументы тебе все-таки доступны? Ок, может тогда вернемся к обсуждению того, что
— появилось в веб программировании за эти годы
— появилось в современных ИДЕ за эти годы
— как сравнивать время компиляции со временем выполнения и метры с килограммами
итд.
Почему когда тебе дают ответ, что современный популярный веб сайт это огромное количество кода оперирующего огромным количеством данных, ты это игнорируешь?
Почему когда тебе дают ответ, что современная ИДЕ это не просто текстовый редактор, а, например, она держит в памяти AST всего(зачастую огромного) проекта в любой момент времени (да и апдейтит его на каждый чих и весьма хитро меняет его), ты это игнорируешь?
итд.
Даже Шеридан хотя бы пытается воспринимать аргументацию аппонентов. Почему к этому оказывается неспособен преподаватель ВУЗа?
Здравствуйте, Pavel Dvorkin, Вы писали:
G>>Ну то есть какие-то аргументы тебе все-таки доступны? Ок, может тогда вернемся к обсуждению того, что
PD>Нет, не буду. Я уже все аргументы изложил. Коротко — непропорциональность роста потребления ресурсов и роста возможностей.
Так рост потребления возможностей ты померять не можешь! Во-первых потому что ты просто не знаешь эти новые возможности (и слышать об этом не хочешь), во-вторых потому что ты сам не знаешь методики измерения этой сложности, в том числе и потому, что ты регулярно в этом топике сравниваешь килограммы с километрами.
Здравствуйте, Pavel Dvorkin, Вы писали:
G>>Так рост потребления возможностей ты померять не можешь! Во-первых потому что ты просто не знаешь эти новые возможности (и слышать об этом не хочешь)
PD>Я (как пользователь) их на экране вижу. И роста их на порядок — не вижу.
Открой Google документс. Эта штукенция позволяет одновременное редактирование одного документа разными пользователями.
15 лет, даже 10 лет назад на тогдашних технологиях даже и мечтали про такое.
Ни много ни мало — Гугловые вебприложения вроде docs,gmail заруливают в минуса _десктоп_ офис времен 15 летней давности.
I>Открой Google документс. Эта штукенция позволяет одновременное редактирование одного документа разными пользователями.
I>15 лет, даже 10 лет назад на тогдашних технологиях даже и мечтали про такое.
Фантастика! Все, сдаюсь. Раз уж при 3.2 GHz, 4 ядрах, 4 GB памяти, черт знает каком количестве каких компьютеров у самой Google и скоростью Интернета в несколько Мбит/сек научились редактировать один документ несколькими пользователями — все, я сдаюсь.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Оптимизатору в режиме Debug делать нечего A>а после этого с тобой вообще не о чем говорить
не хочешь — не говори. Мог и не говорить с самого начала. А организовать код так, чтобы оптимизатор находился в некоей DLL и она подгружалась когда надо, вполне возможно.
Здравствуйте, Mamut, Вы писали:
M>Здравствуйте, FR, Вы писали:
FR>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Вот если бы размер экрана увеличился с тех пор раз так в 10 — другое дело. Или страница имела бы размер так примерно Мб 50 против 5
M>Ну, если брать 10 лет тому назад, то можно брать (1920 * 1200) / (800 * 600) = 4.8
Сейчас достаточно часто бывает и 2 * (1920 * 1200) / (800 * 600) = 9.6
И при этом во времена 800*600 не было никаких сглаживаний текста и тем более ClearType-ов (за счет чего еще на 3 умножить можно).
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Сетевые игры немного другой расклад. Там конкретные версии сервера, клиентов и более удобные протоколы, что снимает огромную часть вопросов например с безопасностью, временем отклика и тд.
PD>Так поставьте эти самые версии и протоколы А точнее — используйте соответствующие средства и не создавайте из мух слонов.
Нужно что бы для работы требовалось ровно одно приложение — браузер.
Просто подумай — гуглдокс работает независимо от того, какая у пользователя архитектура компьютера, ОС, версия браузера.
Твои "самые версии и протоколы " это вагон проблем с деплойментом, сопровждением и тд и тд и тд.
PD>>Не, не. Такое заявить должен любой. js сложнее С++ в N раз — тут ничего ещещ не сказано. Гора больше мыши в N раз — что, неверно ?
P>Я ведь заявил на весь форум, что не знаю js. По-твоему логично, если я сейчас начну сравнивать его с C++, который, кстати, тоже видел последний раз пару лет назад, а может больше? Да за такое сравнение меня сразу в дурдом отправят, потому что рассуждать о том, чего не знаешь — это симптом. А я, по мнению окружающих, пока в порядке.
Ну се ля ви.
P>>>И как сюда вписывается JS? Он появился позже названных тобой продуктов. Тогда это не интерполяция, а экстраполяция. А там все сложнее. Ну и опять про выполнение забыл.
PD>>Конечно, экстраполяция. Всегда экстраполяция. На кой мне интерполяция — обсудить, сколько должен бы занимать несозданный компилятор ?
P>А про выполнение опять не вспомнил.
Что-то я никак не пойму, почему и ты и Мамут пристали ко мне с этим выполнением. Я решительно не понимаю, какое это отношение имеет к потребностям компилятора. TP-чистый компилятор, при выполнении он не участвует, даже если компилируем в память. Он не интерпретатор!!!
Но если уж так хочется получить от меня ответ про выполнение — пожалуйста.
Программа "Hello, World" будет занимать несколько Кб
Та же программа, если к ней добавить массив на 60 Кб — 60 с чем-то Кб
Если что-то посерьезнее написать — может, и сотня понадобится.
Если уж очень серьезное (по меркам DOS, конечно) — займем все 640 минус то, что заняли MS-DOS и BIOS
Если компилятор для Win16 возьмем — потенциально до 16 Мб, предел для 16-битной модели
Для Win32 TP не было, это уже Дельфи. Там — как обычно в Win32
Ну и что интересного тут ты нашел ?
PD>>Стараюсь
P>Значит, не всегда, все-таки. Ясно, чудес не бывает. И как тогда?
Тогда это будет значить, что я не был достаточно профессионален и не сумел найти правильное решение. Плохо то есть. Придется, скорее всего, все с начала.
PD>>Не-а, не выйдет. Лететь слишком долго будет, а меня уволят за слишком частый отдых
P>Тогда подумай над оптимизацией процесса разработки.
Ну так я и подумал. Коротко — сначала думать, потом делать, а не сначала делать, а потом думать — что же мы наделали
PD>>Да, было так. Прикидки были только в уме. Я не делал тестовых примеров, потому что и так понимал, во что мне что обойдется.
PD>>Почему ? Есть же в конце концов простые соображения. O(N), O(NLogN), O(N^2), однопроходный, двухпроходный, время чтения с диска...
P>Только строгий анализ и тесты. Всегда можно нарваться на особый случай. Например, диск находится в сети. И все эти O меняются в зависимости от условий.
А что это за такой ососбый случай наличия диска в сети ? Мне, например, было точно известно, что в сети он не будет, поскольку дурных нема — запускать процесс, который и без того идет 5 часов, еще и с сетевого диска. Но если бы это было допустимо — принял бы во внимание.
PD>>Да я и не спорю, что это удобнее. И сколько им памяти нужно, не знаю. Но не уверен, что именно столько, сколько действительно необходимо для такой задачи.
P>Но, похоже, уже веришь, что больше, чем нужно. Без всяких на то оснований. А основание простое. Сравни TP 1 и TP 7.
И не только. Сравни твой любимый PL/1, сравни компиляторы RSX-11, добавь сюда компиляторы MS-DOS всех и всяческих языков, их тогда много было, добавь компиляторы Win16 и Win32 , созданные до того, как начал резко расти объем ОП...
P>Я тебе привел пример, где выделение лишней памяти существенно сокращает время выполнения функции. Реализация Quicksort на Ф4 из-за отсутствия в последнем рекурсии требует дополнительного массива. Может, тебе это покажется надуманным, но это реальный пример из реального проекта.
Несомненно. На Ф4 без рекурсии — несомненно.
>А потом я что-то увлекся. Так все-таки, почему этот дополнительный массив — не аргумент? Классика ведь: время экономится за счет увеличения требуемой памяти. Все строго в рамках закона.
Где, на Ф4 ? Там иначе просто невозможно. На Win32 ? Я тебе тут разные способы приведу, как выделить и при этом не выделить и т.д.
>>>Или я что-то забыл? Тогда покажи нерекурсивный quicksort без "лишней" памяти.
PD>>Не знаю такого
P>Вот именно. И что, повторю, с дополнительным массивом? Получается, что нужен он? все-таки аргумент?
Что-то я запутался совсем.
В Ф4 — нужен, потому что иначе нельзя. Выделить постоянно. Иных средств нет.
Не в Ф4 — есть, а поэтому можно выделять и освобождать.
О чем спор-то ?
P>>>>>Если ты будешь писать на C нерекурсивную версию быстрой сортировки, зная, что вызываться она будет постоянно, неужели на каждом шаге будешь память выделять/освобождать?
P>>>Вот опять. Не употреблял, а рассуждаешь. Я говорю здесь о том, что сам сделал. MSF 5.1 рекурсию не поддерживал.
PD>>А Ф4 ОС РВ — да. В документации было написано. А я документации верю
P>Я, в общем, тоже. Хотя иногда нахожу в ней неточности. Тогда, может, почитаешь про js? Многие вопросы уйдут за пару часов, а на остальные тебе, думаю, в форуме ответят.
Почему-то вы все решили, что я его совсем уж не знаю. Вот о Хаскеле, действительно, высказываться не буду — я его совсем не знаю. А о js представление вполне имею.
В ленте новостей их стало раза в 2 больше.
В курсе валют — тоже. Впрочем, это настраиваемо и сейчас и тогда было.
Опросы — и там и тут.
Добавили ленты новостей от cnews, autonews, так что размер всего документа вырос раза в 2-3. Ай-яй-яй...
Рекламных баннеров было намного меньше. И это очень хорошо. А сейчас для их блокировки надо всякие AdBlock использовать
И ради этого надо было от 128 Мб к 4 Gb переходить ? И ради этого надо броузеру давать память размером во всю память 2001 года ?
Здравствуйте, Eugeny__, Вы писали:
E__>А что ты предлагаешь? Сейчас писать так, как будто памяти 32 мб? Внимание, вопрос: а кто за это будет платить?. Такая оптимизация при широком функционале банально дорого стоит. В самом прямом смысле, в зеленых бумажках. Но это если говорить про себестоимость. Цена же на рынке такой оптимизации близка к нулю. Получается товар, у которого себестоимость превышает рыночную цену — нафиг, снимаем с производства. И налаживаем производство новых фич — это как раз востребовано. E__>Да, дешевле взять готовую либу для решения задачи, пусть она потянет за собой еще десяток, и сожрет N мегабайт памяти, а не писать свой велосипед и тем более не париться с ассемблерами там всякими. Это как пример.
Ничего я не предлагаю. Я не настолько наивен, чтобы предложить идти против течения. Я просто говорю : делаете так — делайте, только бога ради не оправдывайте свои деяния глубокими философскими соображениями и не доказывайте. что, мол, иначе нельзя. А просто скажите — дали нам миллион, вот мы его и транжирим ...
Здравствуйте, genre, Вы писали:
PD>>Думаю, что да. Может, не на 32, но уж на 256 да.
PD>>Контрвопрос к тебе — а если бы рост памяти остановился на 256 Мб — следовало бы из этого, что сайты, аналогичные gmail или фейсбук вообще не могли бы быть созданы, в принципе ?
G>в том виде в котором они существуют сейчас — нет.
То есть 256 Мб ОП недостаточно в принципе, чтобы решить такую задачу. Любыми способами ?
Подтверди, пожалуйста, свой "нет" (или ответь иначе).
K>Но проблема тут не в том, что "программисты ленятся", это всё на самом деле большая системная проблема. K>В принципе, выражается одной фразой — "некогда точить пилы, пилить надо!!!".
K>Недоделанные программы, недоделанные библиотеки, кривые недоделанные языки. Всё это кое-как скрепляется заплатками, соплями и слезами девелоперов и отправляется в "релиз". И еще проблемы совместимости с предыдущими версиями, такими же кривыми и недоделанными. И с каждой новой версией все эти слои заплаток и соплей растут как снежный ком
Так было всегда. В том числе и когда трава была зеленее и небо голубее. Приводимый в пример BC++ — это дико не стабильный продукт имеющий море недоработок. По сути назвать то что он компилировал С++-ом вообще нельзя — это некий клон С++ который в основном являлся подвидом, но при этом имел и ряд явно нестандартных расширений и ляпов.
Скажу больше так дела обстоят не только в программировании. Тоже самое в производстве и услугах.
А секрет тут прост. Качество продукта не определяется только лишь количеством глюков или недоработок. Оно определяется множеством факторов производители стараются балансировать между ними. Скажем С/С++ позволяет на сегодня получить за время Х продукт с большей скоростью и меньшим потреблением ресурсов, но при этом менее надежный. На повышение надежности нужно или затратить существенно больше времени или выбрать другие средства разработки. Скажем тот же дотнет. И если пользователь готов платить за фичи большим потреблением ресурсов, то зачем ломать копья и заниматься? И наоборот, если рынок требует максимально оптимизированного решения и при этом надежного, то скорее всего придется заплатить функциональностью.
Короче, мы можем выполнить работу быстро, качественно, надежно! Выберите два любые два варианта!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Влад, попробуй все же понять, о чем я. Попробуй, прежде чем критиковать. Дело ведь совсем не в Хроме и не в js.
VD>Да я давно это понял. Большую часть твоих сообщений во всех форумах можно выразить старой до боли фразой — "Небо раньше было зеленее, а трава голубее" .
Влад, можешь мне на один вопрос ответить ?
Вот представь себе — прихожу я к тебе в 1988 году, и говорю : мне стало достоверно известно, что в 2010 году память будет 256 Мб, тактовая 667 MHz, скорость сети на соединении с американским сервером 10 Мбит/сек.
Заметь, я говорю про 2010 год, а конфигурацию привел 2000 года! Кроме скорости сети.
Напомню, типичная конфигурация компьютера в СССР тогда — 286/1Мб/12-16MHz. 386 уже появился, но мы же в СССР...
Ты мне говоришь, скорее всего, что это бред. Что увеличение ресурсов с 1981 по 1988 отнюдь не дает оснований для такого прогноза.
Я тебя убеждаю, что это не бред, что мои данные точные, и мне удается тебя убедить.
После этого я говорю — а знаешь ли, что в 2010 году найдутся люди, которые скажут. что при такой конфигурации невозможно будет решить задачу, которая в конечном счете сводится к созданию картинки размером в несколько экранов и изменении этой картинки в лучшем случае десяток раз в секунду ? И это при том, что большую часть работы по формированию этой картинки возьмет на себя ОС (напомню, что в DOS тебе пришлось бы TTF растеризовать самому и jpg рисовать тоже, через видеоадаптер).
И ты бы не сказал, что это уж окончательный и бесповоротный бред ?
Здравствуйте, Eugeny__, Вы писали:
E__>Потому что задача — не "раскрыть тривью", а "реализовать дерево, структура и способ отображения которого передаются с сервера, и отображаются корректно и единообразно во всех системах без установки дополнительного ПО". Вот эта задача с помощью стандартного тривью не решается. Потому сравнивать просто некорректно.
Вот это уже лучше.
Структура и способ с сервера — это к делу не относится. Или ты считаешь, что с помощью windows treeview нельзя изображать дерево, структура которого передается с сервера ? Вполне можно. Кстати, тот же регедит может показывать удаленный реестр. Не сервер, конечно, но тоже по сети.
А вот насчет корректно и единообразно — тут я согласен. Надо корректно и единообразно. Например, работа с файлами в нынешних системах делается корректно и примерно однообразно, потому что когда-то взяли юниксовскую модель работы с ними и портировали в другие ОС. А до этого было очень уж не единообразно — в Фортране одно, в ПЛ/1 другое и т.д.
Так может, надо было просто взять да и сформулировать эти общие правила для клиентов, изображающих это все ? А то ведь мало того, что они на разных платформах изображаются все равно по-разному, так ведь и на одной платформе в разных броузерах тоже. И порядочную часть своего времени вы тратите на то, чтобы это прилично выглядело в разных броузерах.
А между тем в любом броузере это отображается в некоем прямоугольнике некоторых размеров. В одних ОС его окном называют, в других, может, как-то иначе. Но от этого он прямоугольником быть не перестает.
И jpg, к примеру файлы вполне-таки самодостаточны и от ОС независимы.
И ttf шрифты тоже. О сглаживании можно было тоже договориться.
И т.д.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Но когда вам просто надо нарисовать картинку из тега img — давайте все же обойдитесь width*height*4 байт.
ты забыл 54 байта на заголовок
Здравствуйте, Privalov, Вы писали:
P>Помнишь, я говорил об одном разработчике, чей опыт вдруг стал для него балластом? Ему однажды здорово сказали: "Вы остановились на уровне ДОС ЕС 60-х годов и НЕ ХОТИТЕ двигаться дальше". Искренне желаю тебе никогда такого не слышать.
Решил я закончить свое учаcтие в этой дискуссии. Хватит все же
Но вот эта твоя фраза — ИМХО удачна, для того, чтобы тут и закончить.
А закончить несколько вольным офтопиком.
Вот был такой век — IV от р.х. Век, в котором фактически и погибла великая древняя римско-греческая цивилизация. Но до того, как она погибла, был один император — Юлиан. Юлиан Отступник, как его называют.
Он попытался реанимировать принципы и религию древнего Рима. Конечно, ничего у него не вышло. Вскоре он погиб. Говорят, перед смертью он сказал : "Ты победил, галилеянин!"
Думаю, он и раньше это понимал. Понимал, что дело его безнадежно.
А иначе не мог.
Есть роман Мережковского про него. Там , может, самая сильная сцена — когда Юлиан смотрит на свару святых христианских отцов, спорящих об истинности того или другого толкования новой религии. Ортодоксов, ариан...
Смотрит с презрением. С презрением интеллигентного язычника на всю эту свару на предмет чистого словоблудия.
Так вот, иногда я себя этим Юлианом чувствую. И понимаю, что дело, которое я отстаиваю, вполне безнадежно. Увы.
Так что, уважаемые господа, добро пожаловать в Новое Программмистское Средневековье. Welcome, как говорится. Времени у вас будет, чтобы все свои принципы осуществить, и с избытком. Европейское Средневековье почти тысячу лет продолжалось.
Правда, боюсь, что ваши постройки смогут сравниться с готическими храмами разве что по размерам. В остальном они будут больше похоже на усовершенствованные коровники. Зато с рендерингом по фронтону и баннерами со всех сторон.
Успехов! Сейчас ваше время.
Только об одном помните. Возрождение все же будет! Ох, как не скоро будет.
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Pavel Dvorkin, Вы писали:
G>>>Ну то есть какие-то аргументы тебе все-таки доступны? Ок, может тогда вернемся к обсуждению того, что
PD>>Нет, не буду. Я уже все аргументы изложил. Коротко — непропорциональность роста потребления ресурсов и роста возможностей.
G>Так рост потребления возможностей ты померять не можешь! Во-первых потому что ты просто не знаешь эти новые возможности (и слышать об этом не хочешь), во-вторых потому что ты сам не знаешь методики измерения этой сложности, в том числе и потому, что ты регулярно в этом топике сравниваешь килограммы с километрами.
В том-то и дело.
Например, вот тут краткое описание возможностей современной IDE. Причем практически каждая из приведенного списка фич сама по себе сильно(некоторые — в разы) сложнее всей IDE для паскаля. Очень рекомендую Павлу для ознакомления. Там не сухие доки, а нормальное описание человеческим языком с картинками — читается легко. Просто для ознакомления. Для затравки — анализ кода на лету.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
P>>Но, как выясняется, вполне достаточно, чобы рассуждать, как правильно построить для незнакомого языка интерпретатор. PD>Я вроде как ничего о том, как его построить, не писал, нет ?
О нет, как построить, ты не писал. Ты рассуждал о том, как он должен работать, что одно и то же
И сколько нужно оптимизаций, чтобы увеличивая на n, получить увеличение в 1000 раз ?
там же рассуждаешь об архитектуре. фигня, что в JS ты ни ухом ни рылом? И в том, как работают современный интерпретаторы/компиляторы JS тоже?
Оптимизацию под быстродействие совсем не всегда необходимо сочетать с дополнительным расходом памяти. Можно изменить алгоритм, лучшим способом разместить данные и т.д.
Пространные рассуждения про память. С реальностью ничего общегоне имеющие (опять вылезла цифра в 100 мегабайт, кстати). На это тебе ясно и на пальцах объяснил Владимир
я не настолько знаком с js, чтобы ответить тебе на вопросы, связанные со спецификой тех или иных конструкций. (но рассуждать насчет архитектуры начну — М.)
В том-то и дело, что мне интуитивно кажется, что сотни Мб тут не нужны... В конце концов все эти действия в броузере, вместе взятые — это сверхусложненный ввод и вывод. Очень сильно усложненный, исключительно.
Другие тесты перформанса не пошли, разбираться не стал.
Acid 3 — 18/100 + креш
Gmail в Base Html ест 33-40 в Сhrome 7 супротив 20 мб NN 6.2.3
JS версию NN показать не может, а Chrome отъедает 120мб при том, что включены фичи — контакты, чат, документы, куча ярлыков, куча заголовков + кучка всякой всячины из Labs.
I>Тест не проходи — NN уходит на покой на 89%, но зато есть промежуточные результаты. Тест пришлось прогнать раз десять,потому что NN валился
при копировании текста в клипборд.
I>Running: 89% completed. I>Richards: 11.4 I>DeltaBlue: 19.5 I>Crypto: 35.8 I>RayTrace: 48.1 I>EarleyBoyer: 27.5 I>RegExp: 96.6
I>IE 8 — это бровзер иногда дает окошко, что дескать скрипт сильно медленно работает и предлагает выключить скрипт.
I>Score: 99.9 I>Richards: 54.7 I>DeltaBlue: 58.5 I>Crypto: 45.3 I>RayTrace: 105 I>EarleyBoyer: 176 I>RegExp: 129 I>Splay: 286
I>Mozilla 3.6.6
I>Score: 457 I>Richards: 1336 I>DeltaBlue: 86.7 I>Crypto: 1057 I>RayTrace: 365 I>EarleyBoyer: 390 I>RegExp: 293 I>Splay: 818
I>Chrome 7
I>Score: 5551 I>Richards: 4298 I>DeltaBlue: 5162 I>Crypto: 3497 I>RayTrace: 5858 I>EarleyBoyer: 13516 I>RegExp: 2411 I>Splay: 10960
I>IE9, как то жиденько, всего вдвое быстрее чем IE8 и в 10 раз медленнее основных конкурентов.
I>Score: 190 I>Richards: 61.9 I>DeltaBlue: 66.1 I>Crypto: 70.3 I>RayTrace: 225 I>EarleyBoyer: 234 I>RegExp: 696 I>Splay: 857
I>Mozilla 4.0 beta всего вдвое медленнее чем Хром
I>Score: 2596 I>Richards: 5229 I>DeltaBlue: 3257 I>Crypto: 3286 I>RayTrace: 1374 I>EarleyBoyer: 3378 I>RegExp: 1101 I>Splay: 2782
I>Mozilla 1.0.6 — тест не проходит, вероятно из за того же бага что и в NN, т.к. ядро почти одно и то же.
I>Running: 89% completed. I>Richards: 97.8 I>DeltaBlue: 102 I>Crypto: 64.1 I>RayTrace: 113 I>EarleyBoyer: 112 I>RegExp: 102
I>Mozilla 1.5
I>Score: 91.8 I>Richards: 89.3 I>DeltaBlue: 91.0 I>Crypto: 54.3 I>RayTrace: 99.5 I>EarleyBoyer: 94.9 I>RegExp: 87.2 I>Splay: 151
I>Mozilla 2.0
I>Score: 107 I>Richards: 101 I>DeltaBlue: 107 I>Crypto: 79.8 I>RayTrace: 111 I>EarleyBoyer: 112 I>RegExp: 104 I>Splay: 141
I>>Тест не проходи — NN уходит на покой на 89%, но зато есть промежуточные результаты. Тест пришлось прогнать раз десять,потому что NN валился I>при копировании текста в клипборд.
I>>Running: 89% completed. I>>Richards: 11.4 I>>DeltaBlue: 19.5 I>>Crypto: 35.8 I>>RayTrace: 48.1 I>>EarleyBoyer: 27.5 I>>RegExp: 96.6
I>>IE 8 — это бровзер иногда дает окошко, что дескать скрипт сильно медленно работает и предлагает выключить скрипт.
I>>Score: 99.9 I>>Richards: 54.7 I>>DeltaBlue: 58.5 I>>Crypto: 45.3 I>>RayTrace: 105 I>>EarleyBoyer: 176 I>>RegExp: 129 I>>Splay: 286
I>>Mozilla 3.6.6
I>>Score: 457 I>>Richards: 1336 I>>DeltaBlue: 86.7 I>>Crypto: 1057 I>>RayTrace: 365 I>>EarleyBoyer: 390 I>>RegExp: 293 I>>Splay: 818
I>>Chrome 7
I>>Score: 5551 I>>Richards: 4298 I>>DeltaBlue: 5162 I>>Crypto: 3497 I>>RayTrace: 5858 I>>EarleyBoyer: 13516 I>>RegExp: 2411 I>>Splay: 10960
PD>>Если ты программмируешь, к примеру, для микроконтроллеров, то можно, не изучая некий язык для web-а, сделать вывод о том, что он тебе не нужен ?
P>Боюсь, придут сейчас пара спецов по микриконтроллерам и скажут точно, что нужно и что не нужно.
Ну пусть скажут.
P>И JS что, только для web-а, ты уверен?
Нет, конечно. Но не для микроконтроллеров.
В сущности, вопрос простой, не знаю, зачем ты его поднял. Есть предметная область задачи. Есть некий незнакомый мне язык. Обычно чтения первых страницы сайта (книги) по этому языку достаточно, чтобы понять, годится он мне или нет для этой предметной области. Мне не обязательно знать js на уровне профессионалов, чтобы понять, что он для написания драйверов ядра не очень годится
PD>>Я не имею дело с микроконтроллерами, но то, с чем я имею дело, также говорит о том, что ни один динамический язык мне не нужен — просто в силу быстродействия.
P>Я тоже не программировал микроконтроллеры, но работать в предложенных тобой условиях мне приходилось. P>
P>Вот если бы было введено ограничение по количеству переменных в программе (вот тебе 100 на программу и крутись как хочешь
Было, было. От нечего делать мы в аспирантские времена запрограммировали какой-то простенький расчет для Искра-124. Там было сколько-то регистров, а насчет ОП не помню, была ли вообще. Вот и крутились.
P>В любом проекте есть часть, выполняющая основную работу и "группа поддержки": всякие утилиты, идущие по расписанию. Например, архивирование логов, закачка данных из внешнего источника. Такие вещи ты тоже предлагаешь писать на C++, экономя байты и выжимая микросекунды? Думаю, ни один заказчик не потянет такое. Бюджет у него, а, стало быть, и у тебя, не резиновый. Даже при полном отсутствии конкурентов ты пролетаешь, а вместе с тобой и твой заказчик. И если ты действительно делаешь такое на C++ и встраиваешь в основной проект, подумай: большую часть времени эти полезняшки просто занимают память.
Вот тут один любопытный момент возникает.
С точки зрения экономии расходов заказчика и своего времени — да.
А с точки зрения технологии программирования ? Науки информатики ? Можно ли оправдать экономией денег заказчика то, что эта программа делается вопреки их законам ?
Если ты ответишь да — значит, этой науки уже нет. Потому что можно делать вопреки ее рекомендациям, оправдывая это тем, что иначе денег не хватит.
Я прекрасно понимаю, что ты мне ответишь. Денег-то не хватит! Программа поэтому сделана не будет! И куда ты со своими принципами и наукой ?
Ответ очень прост.
Делаете так — делайте. Ограничен у вас бюджет — делайте неэффективно. Получайте свои деньги и радуйтесь. В общем, на все согласен. Кроме одного
Только пожалуйста, не занимайтесь теоретическим обоснованием той неэффективности, которую вы делаете.
(естественно, ничего личного)
Вот эту последнюю фразу мне мои оппоненты и не простят. В сущности, они же понимают, что делают неэффективно, что можно бы и получше. Но бюджет... но дедлайн но ... Вот и приходится писать не очень качественно. Сначала это самого раздражает. Надо бы посидеть, подумать, как это лучше сделать, потом время потратить на программирование и отладку. Но времени нет, а есть класс, а у него есть метод, вставил его — и готово. Черт его знает, что у него там внутри, у этого класса, и как работает этот метод, но работает же!
Потом... о, потом происходит хорошо известное психологам событие. Человек постепенно втягивается в эту новую обстановку и начинает принимать ее правила игры. И больше всего его теперь раздражают те, кто эти новые правила не принял и время от времени напоминают ему — а помните, как раньше умели ? а помните, как раньше Вы умели (это, конечно, не ко всем относится). И ему теперь во что бы то ни стало надо доказать, что те, кто ему это напоминают, решительно неправы, во всем неправы. И доказывая им эту неправоту, они ведь гораздо больше себе доказывают, что они были правы, перейдя в новую веру. Потому что как можно жить в новой вере. если в глубине души шевелится червячок, который то и дело напоминает (пусть даже подсознательно) — а ведь и ты когда-то умел! а может, все же надо признать, что то, что ты сейчас делаешь, не очень...
M>>Нет. Не нахожу. В качестве носителя истинной истины выступаешь тут только ты.
M>>
M>> Если GUI поток ожидает мютекса (а хоть бы и еще чего-то) и не принял меры по реагированию во время ожидания на возможный пользовательский ввод — автору нужно идти учить основы. Независимо от приоритетов.
M>>Так что иди учи основы. Или задай свой вопрос в форуме по Win API.
PD>Ну и что ? Или ты считаешь, что здесь что-то неверно? То есть можно ожидать в GUI потоке и не принять эти меры ? Если считаешь — то это в некотором противоречии с тем, что ты писал, будто знаешь, как писать ожидание в GUI потоке. А если это верно, а некий автор этого не знает, то ему надо учить основы. Что я ему еще могу посоветовать-то ?
Твоя точка зрения — сугубо академическая, к реальному миру имеющая мало отношения.
M>>Твоя общая позиция в этих спорах: «все, кто пишут программы, что мы тут обсуждаем, тупые идиоты, один я знаю, как надо и студенты у меня легко это показывают»
PD>Опять передергивания пошли. Надоело. Какие все ? Я всего лишь Ikemefula объяснял, что он не знает. Я кого-то идиотом хоть раз назвал ? Я хоть где-то написал, что я один знаю, а больше никто ? Где ?
PD>Врать-то зачем ? Неужели, чтобы доказать свою точку зрения, надо обязательно прибегать к столь примитивному вранью ?
Это не вранье, а краткое описание твоего отношения. И оно, если в кратце, выглядит так:
«Я не собираюсь читать, что вы мне пишите, я не собираюсь открывать ни одной ссылки что вы мне присылаете, я не собираюсь понимать ни одной цифры, что вы мне пишите. НО! У меня есть мнение по преметам,в которых я абсолютно не разбираюсь, поэтому я буду выборочно брать из ваших сообщений то, что мне захочется, создавать собственные ветряные мельницы и успешно с ними бороться. А на ваши доводы мне глубоко наплевать с высокой колокольни».
PD>Оно ведь, само по себе (вранье это) заставляет сильно засомненваться в справедливости твоих утверждений, даже ничего не зная об их сути. Потому что если для их отстаивания нужно лгать, то это само по себе ставит их под сомнение.
Если бы ты читал хоть одно мое утвержедение
Если бы ты читал хоть чьи-либо утвержддения
Если бы ты перешел хоть по одной ссылке, что тебе показали
Если бы ты попытался разобраться хоть в чем-то, о чем тебе говорили
M>>Тогда почему ты не слушаешь нас, а несешь всякую чушь про компиляторы и GIf/JPEG, не пытаясь даже предпринять даже малейшие попытки понять, о чем тебе говорят?
PD>Я несу чушь про GIF/JPEG ?
PD>Вот все, что я о них сказал
PD>http://rsdn.ru/forum/flame.comp/4051285.aspx
PD>>Да хватит меня аббревиатурами пугать. Ты бы уж хоть подумал прежде чем их список сюда постить. JPEG 10 лет назад не было ? Под JPEG сколько памяти-то надо ? Flash на чем написан-то ?
M>>Что из этого умеет 4.7 на 6 мегабайтах? Кусок (и то не полный) HTML'я, кусок (и то неполный) CSS, кусок (и то неполный) Javascript'а... И все. PD>>Конечно, JPEG и GIF не умеет. (тут я забыл смайлик поставить, зря)
PD>Ну и Privalov'у кое что мимоходом
PD>http://rsdn.ru/forum/flame.comp/4046330.aspx
PD>Вот и все.
PD>Так что поздравляю вас, гражданин, соврамши. В очередной раз.
А тебе не кажется странным, что в том списке в четыре раза больше технологий, которых не было в 2000-м году, чем только GIF и JPEG.
Превожу. Специально для тебя:
Я: Список из технологий, бОльшая часть из которых на 2000-й год не существовала
Ты: Да хватит меня аббревиатурами пугать. Ты бы уж хоть подумал прежде чем их список сюда постить. JPEG 10 лет назад не было ? Под JPEG сколько памяти-то надо ? Flash на чем написан-то ?
Выбрать из всего списка только то, что тебе нужно, и подменить этим весь остальной список — это и есть чушь.
Говорить о чем-то, абсолютно в этом не разбираясь, — это и есть чушь. Потому что список я не зря привел. Но, чтобы это понять, нужно чуть-чуть поработать мозгом.
Здравствуйте, Mamut, Вы писали:
P>>Так и объяснение, почему так, ты получил достаточно аргументированное. Я читал. И это в КСВ.
M>Этим ты его не убедишь. Десяток технологий, которых в 20-м не существовало он легко приводит к JPEG/GIF. В общем, по его улыбочке на эту фразу и так видно
Да, и, сдается мне, я могу понять, почему. Озвучивать пока не буду. Надеюсь, что ошибаюсь.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mamut, Вы писали:
M>>А ты даже не попытался понять или даже прочитать, что тебе написали. В частности, M>>
M>>IE 8 — это бровзер иногда дает окошко, что дескать скрипт сильно медленно работает и предлагает выключить скрипт.
M>>Это то, чем ты попытался «срезать» Икемефулу.
PD>Да все я понял. Просто после того, как я 20 или около того раз нажал "No", чтобы понять, чем все это закончится, мне это просто надоело и я отправил скриншот.
Ты мен можешь объяснить смысл этого скринншота в контексте этой ветке?
PD>Ничего не скажешь, хорош язык и исполняющая среда, в которых выполнение некоего кода может привести к тому, что приложение будет unresponsable. Если бы я написал десктопное приложение на любую тему и в нем выдал бы мессаджбокс "извините, у меня тут длительная операция, так что мое окно может перестать реагировать на ваши нажатия" — могу себе представить, что было бы...
Все вопросы — к создателям IE8. В Сафари stop script останавливает выполнение скрипта в таких случаях.
M>>При этом Икемефула в пух и прах разнес,в частности, твою теорию о том, что интерпретатор 10-летней давности должен работать быстро на современном железе. Видимо, способностью воспринимать информацию (причем поданую максимально просто — в виде таблички с цифрами) ты тоже не обладаешь.
PD>Да ничего он не разнес. Для того, чтобы что-то серьезное утверждать, надо не брать тесты, специально подобранные этой командой, а самые разные тесты, проверяющие самые разные фичи языка.
Ты не поверишь. Именно это, этот тест и проверяет.
PD>А в таком виде — это все пустая трата времени. И уж тем более не сравнивать с NN 6.x — это просто была неудачная линия, которая вскоре и прекратила свое существование.
Более того, помимо твоего утверждения, что интерпретатор 10-летней давности будет быстро работать сегодня, были развенчаны и некоторые другие твои утверждения:
— Что расход по памяти увеличился в 100 раз
— Что программы тормозят (тормозят как раз старые программы на более новом железе)
— Что интерпретаторы работали достаточно быстро
— Что каждому юзеру вполне хватило бы 16-32 Мб за глаза (опровергается жрущим 53 мегабайта Нетскейпом)
Здравствуйте, Klatu, Вы писали:
K>Для полноты картины надо добавить, что в "старые добрые времена" программиста, который захотел бы написать что-то сложное на JavaScript, немедленно отправили бы в дурку. K>Сейчас это безумие вошло в моду, и здравый смысл только еле-еле пищит где то в углу "а на _уя вообще писать на JS, когда есть куча языков, которые намного быстрее, удобнее и надежнее?"
Здравствуйте, Mamut, Вы писали:
M>Покажи мне эти языки для клиентского скриптинга в браущере с покрытием хотя бы 50% рынка браузеров
В некотором царстве, в некотором государстве были лобзики. Промышленность была такая — лобзики делали. А дерево из другой страны получали. Уже распиленное.
Но в какой-то момент им это дерево поставлять перестали. Решили они валить лес сами. Пошли в тайгу и взяли с собой лобзики.
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>Ты мен можешь объяснить смысл этого скринншота в контексте этой ветке?
PD>Посмеяться.
Это можно
>>Все вопросы — к создателям IE8. В Сафари stop script останавливает выполнение скрипта в таких случаях.
PD>И что ? И то и другое — не решение, потому что при этом надо делать так, чтобы исполнение кода не мешало работе интерфейса. Эти вопросы в начальном курсе программирования для десктопоных приложений рассматриваются — хоть на Win API, хоть на дотнете, на чем угодно.
Конечно не решение. Быстрые браузеры такое окошко не показывают. Мне IE нравится тем, что под ним сайты качественно показываются,а вот перформанс конечно слабенький.
M>>Ты не поверишь. Именно это, этот тест и проверяет.
PD>Я не намерен ни верить, ни не верить.
"Войны не объявлять, мира не подписывать, армию — распустить" @
M>>Ага, то есть тебе уже и браузеры не нравятся. Называй браузер 10-летней давности, который тебе нравятся, проведем сравнение на более обширных SunSpider (http://www2.webkit.org/perf/sunspider/sunspider.html) и Dromaeo (http://dromaeo.com/)
PD>Netscape 3.0 Gold. Ему, правда, не 10 лет, а немного побольше. С NN 4.x началось ухудшение.
Господи, да не пройдет ни один из тестов вообще !
Дашь ссылку — протестирую
M>>- Что расход по памяти увеличился в 100 раз
PD>Где именно я говорил про то, что в 100 раз ?
Вот твои слова:
"Но когда я вижу, что потребности в памяти увеличились в 100 раз, скорость процессора — в 50-100, в все вопят — памяти мало, программы тормозят (и это правда), то объяснение только одно — разучились писать как следует."
PD>Вот специально поставил NN 4.7 под XP Mode есть. Virtual Size 6 Мб.
Запусти на нем тест а мы посмеемся.
M>>- Что программы тормозят (тормозят как раз старые программы на более новом железе)
PD>Угу.Я этот тест от v8 попробовал в ie8 под XP Mode. XP Mode не реагировала на Ctrl-Alt-Del около минуты.
А какое отношение JS V8 имеет к IE8 ? Специально для тебя что ли редакцию выпустили ?
PD>NN 4.7 таки занимает сейчас 6 Мб и вполне работал таки 10 лет назад на машине, где было 32 Мб всего, и занимал, я полагаю, тогда не больше , чем сейчас (см. выше). И многопользовательский режим у него был, хотя и неважно сделан. Так что грош цена всем этим доказательствам твоим.
Через час или два будут результаты NN 4.7.9 cупротив JS V8 и возможно IE6
PD>Ну и т.п.
Посмотрим, как ты будешь выкручиваться в очередной раз.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Ikemefula, Вы писали:
I>>Ситуация нормальная. Динамика в силу ряда причин почти единственно возможный способ скриптования клиентской части. WH>Назови хоть одну.
Динамика действительно кажется более удобной, с этим я согласен. Но благими намерениями вымощена дорога известно куда. Можно в конце концов придумать замечательный язык по своим возожностям, но если для работы с ним нужно 500 Мб — в корзину его. Ну а то, что без динамики прямо-таки нельзя решить задачу красивого вывода в окно некоторго количества текста и картинок хоть с применением CSS, хоть с чем-то еще — не выдерживает никакой критики.
Здравствуйте, WolfHound, Вы писали:
I>>Разные версии html, css, браузеров, файлов, отсутствие файлов. С динамикой не возникает никаких проблем. WH> Отсутствие проблем достигается исключительно ручным тестированием под всеми популярными браузерами.
Ручное тестирование нужно даже если сборка статическая. Я бы сказал — особенно в этом случае.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здесь сказано про броузер ? Речь идет о программах вообще. В частности, для компиляторов + IDE это верно : в ДОС они занимали , естественно, 1 Мб (ну иногда больше, за счет expanded памяти, BC++ 3.1), а сейчас VS 2010 без открытого solution — 82 Мб, только сейчас посмотрел.
PD>Вот поэтому я и не хочу с тобой дискутировать. Показывать тебе твои передергивания каждый раз — охота мне время на это тратить!
передёргиваешь тут исключительно ты. вот буквально в цитате выше. следуя твоим же словам, надо сравнивать не общее потребление памяти VS, то только ту память, что используется под фичи, которые есть в BC. что весьма и весьма проблематично, и ты это прекрасно знаешь.
Здравствуйте, LuciferSaratov, Вы писали:
LS>Здравствуйте, Pavel Dvorkin, Вы писали:
>>В частности, для компиляторов + IDE это верно : в ДОС они занимали , естественно, 1 Мб (ну иногда больше, за счет expanded памяти, BC++ 3.1), а сейчас VS 2010 без открытого solution — 82 Мб, только сейчас посмотрел.
LS>Это ещё что. Если посмотреть на 3D-шутеры, картина еще более удручающая: Wolfenstein 3D прекрасно работал на 80286 20Mhz и 640Kb ОЗУ с софтовым рендерингом, а Crysis'у подавай два ядра по два с половиной гигагерца, два гига памяти и аппаратный графический ускоритель. LS>Так он еще и в десять раз дольше вольфенштейна запускается, разучились писать однозначно.
Ну, геймдев очень, очень специфическая и довольно хаотичная отрасль. Разрешения ростут(а с ними и дикие тормоза), запросы по графике и AI — тоже. Запросы по играбельности меняются. По тематике тоже неясно. Цены на игры невысоки(их и так вчёрную пиратят, повысишь цену — вообще ничего не получишь). Зарплаты обычно невысоки — если проект погорит(ну вот не понравится геймерам что-то, и пиши пропало), то все, покойся с миром. Нанимать мегаспецов, чтобы они за больший деньги сделали производительную гейму глупо. Не понравится игрокам баланс, или еще что-то — и деньги на ветер: купят(скачают), расскажут друзьям и на форумах "не бери — говно" — и плакали денежки. и плевать, что оно работает с 100500 фпс на древнем железе — в неинтересную игру никто играть не будет(а как сделать достоверно интересную, не знает никто). А в интересную — будут, даже если для этого нужно обновить комп.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
PD>>VS 2010 перевели на WPF. Аллах их знает, чего они хотели этим добиться, внешне интерфейс изменился мало, но в итоге потребности по памяти возросли с 34 Мб (2008) до 80 Мб (при неоткрытом solution). Ну и загружается она секунд 10-15.
_>продвигают этот самый WPF. не нужен он (особенно такой какой он есть)
Аналогично в свое время VC.NET перетащили на WinForms. Ну там хоть интерфейс существенно изменили, в общем, он, конечно, стал удобнее, чем в VC6, но его можно было изменить и без того, чтобы все это на WinForms перетаскивать.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>С++ многие ругают за то, что в нем очень легко наступить на грабли и (по определению В. Кочеткова) выстрелить себе в ногу. Не спорю — легко. Но С++ (а впрочем, и паскаль, а впрочем, и другие языки) — это был мощный отсеивающий фактор. Те, кто не был в состоянии писать на нем без стрельбы (или хотя бы без частой стрельбы) по своим конечностям, либо уходили из программирования, либо писали на Visual Basic, ниша которого была строго очерчена работой на заказ, а продаваемых программы с которого практически не было.
Может мне не везло в жизни , но говнокодеров на C++ я встречал очень много. Там была и пулеметная стрельба по своим и чужим ногам, и дико неэффективный код, и voodoo programming, и универсальный ответ на все претензии — "но у меня то работает!"
К слову, один из самых адских перлов, который мне встречался, был как раз на C++. Там был совершенно безумный обход дерева — в ширину (без всякой необходимости), на три экрана кода, и с квадратичной сложностью от размера дерева
Здравствуйте, Mamut, Вы писали:
PD>>>>Посмеяться. M>>>Посмеяться с чего? С того, о чем Ikemefulf уже предупредил? PD>>Нет, с того, что авторы броузера не смогли разрулить ситуацию, которую должны мои студенты разрулить.
M>Ооо. Твои студенты умеют писать браузеры? Покажи хоть один.
Опять ? Если я говорю, что они должны знать, как не подвешивать интерфейс, то значит, они должны писать броузеры ?
Все, с меня хватит. Читать дальше не буду и отвечать тоже. Сыт по горло твоей аргументацией.
PD>>>>>Посмеяться. M>>>>Посмеяться с чего? С того, о чем Ikemefulf уже предупредил? PD>>>Нет, с того, что авторы броузера не смогли разрулить ситуацию, которую должны мои студенты разрулить.
M>>Ооо. Твои студенты умеют писать браузеры? Покажи хоть один.
PD>Опять ? Если я говорю, что они должны знать, как не подвешивать интерфейс, то значит, они должны писать броузеры ?
Они должны уметь писать достаточно сложные системы (а браузер — то очень сложная система), а потом только говорить о подвешивании-неподвешивании.
PD>Все, с меня хватит. Читать дальше не буду и отвечать тоже. Сыт по горло твоей аргументацией.
Угу, если бы ты ее хоть раз читал, ага. Напомниаю:
(не моя, Владимира Кочеткова, но на нее я ссылался раза три)
3. Аргументация три: http://code.google.com/apis/v8/design.html (в пятый раз привожу сслыку, кстати)
4. и т.п.
Напомнить твою реакцию?
«Это мне неинтересно»
«Я не собираюсь разбираться»
«Я не знаю»
«Не буду»
и т.п.
Ну и продолжения
«А вот в ТурбоПаскале!»
«А вот JPEG и GIF в 200-м году!»
и т.п.
Так что мы все сови аргументы и факты тебе привели. То, что ты не хочешь (не способен?) их не то, чтобы воспринять, но прочитать хотя бы — это твои проблемы.
Здравствуйте, vitasR, Вы писали:
R>В целом, я согласен с Павлом, но дело вот в чем.
С чем именно ты согласен, что старый JS должен летать на новом железе ?
R>Идет расслоение программистов: самые умные сидят в том же микрософте и гугле и делают суперумные средства разработки и среды выполнения, чтобы тыпорылые массы быдлопрограммеров могли ваять свои говношедевры. Вы тестировали эффективность JS движка, а им как-раз занимались очень умные программеры и делали они это потому что пользуются JS современные "программисты на джаваскрипт".
А Павел говорить что писать разучились, потому что прога не может назнимать 100мб ни на что ни про что и язык детский.
Здравствуйте, vladimir.vladimirovich, Вы писали:
VV>>>MVP Майкрософта. И еще. Культурнее говорить: "покакать". I>>Оно и заметно, что ты такие слова употребляешь
VV>А эта фраза была для Вас, уважаемый.
Глядя как ты постоянно поправляешь других таким образом в это плохо верится...
VV>Я почему-то ждал, что Вы на нее отреагируете. Интересно а Вы знаете почему я оказался прав?
...но может оказаться что тебе надо было показать другим какой ты весь из себя
Но вообще, хорошо, что у тебя рефлекс на меня появляется, скоро будешь гавкать по моей команде
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>...Я лишь высказал некоторые соображения, касающиеся построения компиляторов (трансляторов) в прошлом и сейчас и соотнесения этого с размерами потребной памяти опять же в прошлом и сейчас.
При этом проигнорировав, скажем так, некоторые различия вежду ТурбоПаскалем и js.
PD>А те, кто не прошел — разбазаривают. И те, кто прошел, порой тоже.
Не факт. Во всяком случае, интерпретатор js не подтверждает твой тезис.
PD>>>А с точки зрения технологии программирования ? Науки информатики ? Можно ли оправдать экономией денег заказчика то, что эта программа делается вопреки их законам ?
P>>Что значит "вопреки их законам"? Законам информатики?
PD>Да. Теоретическм основам теории алгоритмов, структур данных и т.д.
Расшифруй. Применение неподходящего контейнера еще не является нарушением законов. Это незнание законов. Потому что контейнер работает в полном соответствии с этими законами. А разработчика в студенчестве преподы на лабах по структурам данных плохо гоняли.
>>Или тем, что сказал: требования к памяти противоречат требованиям ко времени реакции на запрос?
PD>А это один из законов. Но не все тут так просто.
Конечно. Разработчики движка V8 пошли по пути сокращения времени отклика. С их точки зрения эта характеристика важнее остальных. И мои ощущения пользователя подтверждают, что их решение обосновано. Раз на нетбуке работает быстро и соседним приложениям не мешает, мне, потребителю, все равно, какие там законы они нарушили. Когда существующее положение меня устраивать перестанет, я возьму продукт конкурента.
P>>Так денег действительно не хватит.
PD>Я же сказал — этот аргумент серьезный, но к науке информатике отношения не имеет. Если твои разработки прекратят финансировать, тогда ты не сможешь даже как-нибудь что-то запрограммировать. И придется тебе CD-ejector-ы клепать, чтобы на свою науку заработать.
>>И потом, нельзя нарушить законы.
PD>Законы природы нарушить нельзя. А вот законы, сформированные человечеством для своей деятельности — за милую душу. И не только законы, подпадающие под УК.
Законы информатики не изобретены человеком, а открыты. Как я уже сказал, неправильное применение контейнера или алгоритма не является их нарушением, потому что оные контейнер или алгоритм работают в соответствии с ними вне зависимости от того, как их используют.
PD>Построить мост с быками толщиной в спичку нельзя — рухнет. А вот построить его с быками шириной в полреки — можно, угрохать чертову прорву сил и средств, а в итоге получить решение, ничем не лучшее чем то, которое бы получилось на основе положений сопромата и т.д.
Мост в полреки означает неверный расчет смет.
Поинтересуйся как-нибудь, почему прорывает водопровод, причем в одно и то же время.
>>Рекомендациям можно следовать, а можно и нет, все зависит от конкретных условий.
PD>Мнение пользователя меня мало интересует, он не компетентен судить.
Почему? Как это не компетентен? Ты в самом деле думаешь, что пользователь не в состоянии отличить хороший софт от плохого? А ничего, что в своей предметной области твой заказчик значительно компетентнее тебя? И точно знает, что ему нужно. А вот как сделать то, что нужно — в этом заказчик полагается на тебя. Так что к его мнению ты будешь внимательно прислушиваться, и совершенно никого не интересует твое к этому мнению отношение.
>>Скрипт разрабатывается значительно быстрее, чем программа, с этим ты тоже будешь спорить?
PD>Не буду. Но это плохонький аргумент. Он из той же серии — денег мало, сроки на носу и т.д. Он на побочные факторы жмет, а не на технологию.
Дак ведь и в самом деле денег мало и deadline неотвратим, как крах мирового империализма. А существование подобных утилит входит в смету. И перерасход из-за на фиг никому не нужной оптимизации в этих местах вряд ли будет одобрен заказчиком.
P>>Техзадание с заказчиком обсудили? Утвердили? В рамки укладываешься? Есть запас прочности по предельным нагрузкам раза в полтора-два? Где здесь, в таком случае, неэффективность?
PD>Господи, ну уж это не надо. Привлекать тот факт. что заказчик подписал бумагу, в которой пусть даже прописаны характеристики, в качестве аргумента, что они должны быть такими исходя из возможностей техники — это уж слишком. С таким же успехом можно найти индейца племени Ориноко, никогда не видевшего автомобиля и подписать у него техзадание на создание самодвижущейся повозки, едущей со скоростью 40 км/час. Индеец будет в полном восторге, когда вы эту повозку ему представите — его лошадь и 20 км/час не давала
Еще раз: заказчик знает, что он хочет. Умный заказчик попросит техзадание от нескольких исполнителей, а потом еще и экспертам покажет. А подписание акта сдачи-приемки работ иногда становится хорошим квестом для исполнителя. Особенно когда он начинает рассуждать о неправильных контейнерах. Заказчика это не интересует. Ему нужна хорошо работающая программа сегодня, а не идеальная неизвестно когда.
PD>Дело в том, что применяя некий метод некоего класса надо не хвататься за этот класс и этот метод на том основании, что он решает задачу, а поинтересоваться — с какими затратами. Если у нас есть метод сортировки, то если он N*logN — это хорошо, если N^2 — может быть иногда приемлемо, а если N^3 — то это безобразие и ничего больше. И даже если сортируется массив на 100 элементов один раз в минуту — это все равно безобразие и ничего больше! И если в той же сортировке заводится дополнительный массив N^2, то это тоже безобразие. И линейный — тоже.
Такие вещи везде и всегда зависят от конкретных условий. Ты, наверное, знаешь, что 100 элементов пузырьком сортируются столь же эффективно, как и быстрым алгоритмом. А иногда выделение массива дает выигрыш в скорости. пример — быстрая сортировка на Фортране IV.
PD>http://rsdn.ru/forum/dotnet/4049357.1.aspx
P>>А как быть с этим: P>>Не сотвори себе кумира зи начальника, знай, что ты и сам не дурак.
PD>А это тут к чему ? Я вроде как начальников не обсуждал. Но впрочем, принимаю, в следующей модификации : "Не сотвори себе кумира из тех, кто задает правила игры в твоей области, помни, что и сам ты не дурак"
А... Это из студенчества. Твоя формулировка более актуальна.
P>>Все подвергай сомнению.
PD>Так я и подвергаю . Подвергаю более или менее ставшие общепринятыми в определенных кругах концепции.
Но все же существует разница между ТурбоПаскалем и js.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Проблема в том, что поток GUI вообще не имеет права ожидать никакие синхрообъекты, не приняв меры к тому, чтобы обработать пользовательский ввод во время ожидания. Поэтому совершенно не важно, кто там какие объекты создал, владеет (мютекс) и т.д. Поток GUI может их ожидать, но только при условии. что если появится пользовательский ввод , то это ожидание должно быть прервано. Не дождавшись. Для этого специальная функция есть
PD>http://img.meta.ua/rsdnsearch/?q=MsgWaitForMultipleObjects&mode=rank&group=N
Теперь отдельно про ожидание.
Покажи мне аналог MsgWaitForMultipleObjects для Kernel Mode и, заодно, поясни момент с DPC.
PD>...или дать поработать потоку в процессе System с приоритетом 20 (а вот это вполне, я не раз видел ситуацию, когда System загружает процессор на 20-40%)?
Я такое на 100% видел. Ну, сейчас сильно мощные процы, да и неизвестно, где сейчас выполняется эта операция. Вобщем, нужно всего-лишь выставить аттрибот "сжатый" для нескольких крупных папок/дисков, и одновременно нажать "применить". В win2000 и ранее сжатие выполнялось в System, семерки под рукой сейчас нет — так что для нее не уверен.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mamut, Вы писали:
M>>>>Пойду расскажу это авторам Фотошопа... И Unity3D... И еще Word'а (копи=пейст из Internet Explorer'а, ага). И еще... В общем, я повторяюсь. На всех трех ОСях GUI любого мало-мальски сложного приложения хоть раз до подвисал. Чудес не бывает.
>>Читать выделенное до полного понимания.
PD>Ты все же не находишь, что такой тон выглядит довольно глупо ? Звучит так, как будто ты владеешь истиной в последней инстанции, а все, кто с тобой не согласен, должны над этим евангелием от Мамута медитировать с утра до ночи , пока не озарит их божественная благодать сей мудрости.
Нет. Не нахожу. В качестве носителя истинной истины выступаешь тут только ты.
Если GUI поток ожидает мютекса (а хоть бы и еще чего-то) и не принял меры по реагированию во время ожидания на возможный пользовательский ввод — автору нужно идти учить основы. Независимо от приоритетов.
Так что иди учи основы. Или задай свой вопрос в форуме по Win API.
Это как бы не мои слова. Не говоря о многиз других.
Твоя общая позиция в этих спорах: «все, кто пишут программы, что мы тут обсуждаем, тупые идиоты, один я знаю, как надо и студенты у меня легко это показывают»
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>То тогда я бы согласился, что я вру.
PD>Если бы ты не повторял десять раз одно и то же, а попробовал понять, какие аргументы я принимаю, а какие нет, какие аргументы я выдвигаю, то тебе не пришлось бы десять раз писать одно и то же.
Ты вот говоришь про реперные точки, а между тем ничего так и не пояснил про них.
Между тем одной из реперных точек является время отклика в UI — 0.5 с, далее — Acid — 100% и тд.
Расход памяти уже сто лет в обед как перестал учитываться в качестве реперной точки.
Как увязать сюда твой турбпопаскаль или BC++ абсолютно не ясно.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
P>>>При этом проигнорировав, скажем так, некоторые различия вежду ТурбоПаскалем и js.
PD>>Нет, не проигнорировав, а просто не говоря об этом, поскольку это само собой разумееется. Я же не утверждал, что надо интерпретатор JS в 640 Кб запихнуть.
P>А если само собой разумеется, то почему в качестве аргумента ущербности js ты приводишь ТурвоПаскаль? Ссылки даже искать не надо, их полно. Вон у Mamut-а целое собрание
Не совсем так. TP приведен не для доказательства ущербности js (точнее, интерпретатора с него), а для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае. Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб, причем с самых разных языков, и при на порядки более медленных машинах, и вдруг оказалось, что для языка, который, в общем-то, не сложнее намного предыдущих, потребовалось памяти намного больше — что-то здесь подозрительно.
PD>>Вопрос тоньше — соответствует ли увеличение потребности в ресурсах усложнению языка (если оно есть).
PD>>Не знаю. Меня тут Мамут тысячекратно обвинял в том, что я не хочу заглянуть в исходники. А я действительно не хочу. Зачем ?
P>Наверное, чтобы у тебя появились какие-то аргументы в пользу прожорливости js в Chrome.
Ну я же ниже сам ответил. Вопрос-то был явно риторический.
PD>>2. Я их анализирую и, потрясенный их мощью, изяществом и оптимальностью, признаю себя неправым. Тоже не реально и по той же причине.
P>Нереально, что признаешь себя неправым? Извини, не удержался.
Нереально, что я за разумное время смогу проанализировать их до мельчайших подробностей и сделаю вывод, что лучше сделать нельзя
PD>>Речь идет, как наверное понял, о VS2010 vs. VS 2008. Правда, сомневаюсь, что мне MS покажет исходники
P>Не поверишь, не понял. Студия не является моим основным инструментом. У меня 2005. Тяжелее шестерки. IDEA с небольшим проектиком из пары десятков классов сразу 200 метров отбирает, и что? Нормально работает, без тормозов, и никому не мешая, в т. ч. Chrome, с которого я читаю сейчас этот форум.
Я с IDEA не работал, судить не буду. Кто-то тут сказал, что она намного мощнее и студии, и эклипса. Допускаю. Может быть, для тех ее возможностей, которые я даже и не видел, надо намного больше. Кстати, я ничего не имею против того, что VC2010 требует больше, чем VC2008 из-за того, что в VC2010 есть компиляция на лету (по ходу набора подсвечивает ошибки). За это я готов платить. Но в предыдущем сообщении речь шла о студии без открытого солюшена.
P>Во времена MS-DOS, работая с продуктами MS, я использовал make-файлы и текстовый редактор QEdit. PWB запускал крайне редко, в основном, чтобы построить новый проект. Остальное все руками. Ну очень он не нравился мне.
Я только с борландовскими продуктами работал. Впечатления были хорошие.
PD>>Применение неподходящего контейнера есть нарушение закона. Разумееется, не законов поведения этого контейнера, а законов теории алгоритмов, которая определяет, какой алгоритм (и соответствующий контейнер, но это частности) должен применяться для решения той или иной задачи.
P>Для решения одной и той же задачи могут применяться различные алгоритмы и различные контейнеры. Причем оптимальность зависит от множества условий. Ваш К. О.
Да, конечно. Те же конкуренция память — время. И если бы ыбть уверенным, что тут принято именно наилучшее решение, то можно многое допустить. Но уверенности нет. Слишком уж как-то все это больше напоминает принцип "памяти много, чего ее жалеть", нежеди принцип "найдем оптимальное решение".
PD>>Зачем, спрашивается, тысячи и тысячи математиков и программистов эти алгоритмы и структуры данных анализировали и искали наилучшее решение, если можно наивным программированием запустить нечто, на порядок по времени/памяти хуже, лишь бы работало.
P>Алгоритмы не прибиты гвоздями к задачам. Первая, пилотная, версия проекта, именно так и реализуется, наивным программированием. Главное преимущество такого подхода — скорость разработки. И вот если станет ясно, что данный подход не решает поставленную задачу, то с помощью наивного подхода получается значительная экономия средств.
Тут я категорически не согласен. Если бы я так делал то, что я сделал, я бы не сделал ничего, просто потому, что не получив нужной скорости работы (а ее при таком подходе получить нельзя), мне пришлось бы либо выбросить все на помойку и расписаться в своем бессилии, либо начать все с начала. Мне именно надо было продумать структуры данных, чтобы они хорошо подходили под мои алгоритмы работы с ними, и алгоритмы. чтобы они хорошо с этим данными работали, быстро. И пока я все это не продумал, я вообще ничего не писал.
PD>>Зачем Кнут quicksort придумал и зачем ее потом годами анализировали — пузырек прекрасно работает и всегда дает правильный результат. Вот это и есть нарушение законов. Это и есть постройка моста с быками в полреки.
P>Самая популярная тема в КСВ — quicksort vs bubblesort. Win vs Lin курят.
P>Quicksort разработан не Кнутом, а Хоаром,
О черт!!!!!!!! Дико извиняюсь. Конечно, Хоаром. Какой дъявол меня подтолкнул написать про Кнута
>о чем можно прочесть у самого Кнута, а также у Вирта и других авторов. И оптимизирует выполнение он не всегда. Помнишь, что у того же Кнута (или все же Вирта?) про особые случаи сказано?
У кого — не помню, но сказано. Но и я выше написал — "зачем ее потом годами анализировали"
PD>>Допустим, что в этом случае это именно так. Но я вижу множество случаев, когда это далеко не так. А просто транжирят память без зазрения совести. PD>>А если это так — почему я должен верить, что для v8 это так ? Потому что меня Мамут пытается в этом убедить ?
P>Но ты же твердо веришь в то, что это не так. Выше мы видели, что анализ ты проводить не хочешь, но продолжаешь стоять на своем.
Мне повторить аргументы ? Я их вроде как озвучил. Да, это моя позиция.
P>>>Поинтересуйся как-нибудь, почему прорывает водопровод, причем в одно и то же время.
PD>>У кого ?
P>Во дворах, на улице. Как правило, весной и осенью.
Что-то я так и не пойму, при чем тут водопровод.
PD>>Буду. Если он мне скажет, что программа делает не то, что надо или не так — непременно буду. Но о том, какие средства употреблять и какие затраты памяти и т.д. должны быть — не ему говорить и не мне слушать.
P>Хороший, умный заказчик о таких вещах говорить не станет. Выше мы уже это обсудили.
Конечно, не будет. Я просто сказал, о чем я его мнение готов слушать, а о чем нет.
PD>>Это годится, когда есть разные разработчики, если одна команда может предложить решение, намного лучшее, чем другая. Если все предлагают решение одного качества, сообразуясь в основном не с тем, как это можно хорошо сделать, а в основном с тем, сколько заказчик на это готов потратить — мы получим отот всех одно и то же.
P>Нет. У команд отличаются взгляды на жизнь, на разработку. Точки зрения на продукт разные. Одно и то же никак не получится. Вспомни, сколько народу писало бухгалтерии в 90-е. Они что, все одинаковые? И так везде.
Отличаются, да. Только вот если принято, что под эту бухгалтерию надо минимум 20 Мб, то одна команда скажет про 15, а другая про 25. А вот 20 лет назад, когда один "программист" заявил, что ему для расчета зарплаты для организации в несколько сот человек нужно 512 Килобайт и монопольный доступ к машине, над ним вся эта организация смеялась (там в основном программисты работали). И дали 64 Кбайта — зачем больше-то ? В начале 1990-х я сам писал расчет заработной платы для одной птицефабрики с персоналом в несколько сот че человек. Машина СМ-1420, ОП 256 Кб.
PD>>Ты о том, что quicksort требует стека и его на Ф4 динамически не выделить ? Согласен, но это лишь следствие ограничений Ф4.
P>То есть это не считается аргументом? Но ведь память — реальная — выделяется! Причем в расчете на худший случай. Во избежание. И неважно, статически или динамически.
Нет, не считается. Если бы там было динамическое выделение памяти, а автор им бы не воспользовался — тогда да. Но если просто-напросто его нет — что делать-то ? Одно из двух : либо выделять статически, либо отказаться от Фортрана. Нельзя же упрекнуть меня в том. что я не воспользовался возможностями, которых нет.
P>Я думал, ты мне здесь расскажешь, как организовать рекурсию на Ф4. я пробовал, работает, но жутко тормозно. в качестве решения для quicksort не подходит. Лучше массив.
Вообще-то очень многие компиляторы с Ф4 разрешали рекурсию. Насчет тормозно — вопрос скорее по реализации ее на той или иной машине. Я, честно говоря, на Фортране ее, кажется, ни разу не употреблял.
P>>>Но все же существует разница между ТурбоПаскалем и js.
PD>>Я одно не пойму — с чего вы все решили, что я этой разницы не вижу и требую уложить нынешний интерпретатор js в 640 Кб ? Я привожу TP в качестве некоей реперной точки для рассуждений, вот и все.
P>Дак для js он в этом качестве, как я понимаю, не подходит.
Так он для много чего не подходит . Он просто был и вечным укором останется.
О! Идея! А дай-ка я переверну ситуацию.
Задача — совеременным программистам написать компилятор с языка в точности того, каким был ТурбоПаскаль в 198x году! И IDE в точности такую же. Ни на йоту больше. Средства для написания использовать какие угодно.
Здравствуйте, Ikemefula, Вы писали:
I>"Феррари", ака JS V8 рвет в клочья _всех_ нынешних конкурентов, не говоря о прошлых версиях.
И добавлю — в который раз уже — не мешает остальному движению, сиречь, параллельно с ним крутится и другой, весьма прожорливый, софт, и полет нормальный.
Здравствуйте, genre, Вы писали:
G>Так рост потребления возможностей ты померять не можешь! Во-первых потому что ты просто не знаешь эти новые возможности (и слышать об этом не хочешь)
Я (как пользователь) их на экране вижу. И роста их на порядок — не вижу.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не совсем так. TP приведен не для доказательства ущербности js (точнее, интерпретатора с него), а для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае. Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб, причем с самых разных языков, и при на порядки более медленных машинах, и вдруг оказалось, что для языка, который, в общем-то, не сложнее намного предыдущих, потребовалось памяти намного больше — что-то здесь подозрительно.
а самое подозрительное то, что ты отказываешься обсуждать, *зачем* потребовалось много памяти. и сравнивать самую ресурсоёмкую часть — оптимизатор — ты отказался.
G>>Ваша дискуссия выглядит так: G>>Ребятки, чего это ваш агрегат со скоростью 60 км/час движется ? G>>Так это, траффик, машин много стало в 21 веке, быстрее сложно в городе ездить, даже на феррари. G>>Неее. Ничего не знаю, я еще 20 лет назад из жигулей 70кмч под горку выжимал, говно ваша феррари.
PD>А чего это ваша "феррари" все же под горку со скоростью 60 км/час движется ? Там, где нет трафика, нет машин, да и дорога стала намного шире ?
С какого перепугу (перепою?) ты это решил? Наша веррари движется со скоростью, превышающей звуковую в условиях, анпоминающих дороги москвы. В то время когда в 70-х, когда машин не было ты мог на своем тазике выжимать от силы 70-80 кмч.
Тесты, описания технологий и т.п. тебе приводили несколько раз.
P>>>>При этом проигнорировав, скажем так, некоторые различия вежду ТурбоПаскалем и js.
PD>>>Нет, не проигнорировав, а просто не говоря об этом, поскольку это само собой разумееется. Я же не утверждал, что надо интерпретатор JS в 640 Кб запихнуть.
P>>А если само собой разумеется, то почему в качестве аргумента ущербности js ты приводишь ТурвоПаскаль? Ссылки даже искать не надо, их полно. Вон у Mamut-а целое собрание
ссылок.
PD>Не совсем так. TP приведен не для доказательства ущербности js (точнее, интерпретатора с него), а для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае. Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб, причем с самых разных языков, и при на порядки более медленных машинах, и вдруг оказалось, что для языка, который, в общем-то, не сложнее намного предыдущих, потребовалось памяти намного больше — что-то здесь подозрительно.
Внезапно потерялось выполнение. Скомпилированная TP программа при выполнении спокойно может занять намного больше памяти, чем до, во время или после компиляции. Не говоря уже о том, что эта программа во время выполнения не занимается JIT'ом, оптимизацией и т.д. и т.п. (опять повторяюсь).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот когда я вижу программу, перегоняющую 1.5 часовой фильм из mpeg в avi, то я понимаю, какой там объем действий
а я вот в выделенном не уверен, ибо зависит. в принципе, оно вообще может единственно выполнять копирование из файла в файл кусками
PD>А вывести картинку размером 1500*1000
векторную многослойную с хитровывернутым сжатием, ага
PD>>>Потому что люди, которые считают себя более кометентными, вместе с этой компетентностью приняли правила игры в этой отрасли, а поэтому взглянуть на эту проблему, отринув эти правила игры, не могут. Люди, которые очень компетентны в разработке автомобиля, не поверят, что с двигателем внутреннего сгорания можно сделать что-то такое, что будет летать — их компетентность давно их научила тому, что рожденный ездить летать не может
G>>Все, я сдаюсь. Это религия, а религия как известно не подчиняется здравому смыслу.
PD>Есть у психологов такое понятие — "профессиональный кретинизм" — которое означает, что работа человека формирует у него стереотипы, через которые он воспринимает весь окружающий мир, по крайней мере это стереотипы его действий, попыток решения возникающих задач.
Ну этот кретинизм мы наблюдаем точно не у твоих оппонентов. Оппоненты аргументиурют свои позиции, а ты строго игнорируешь все, приводя только к тем кусочкам информации, что тебе известны.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, genre, Вы писали:
G>>Ну то есть какие-то аргументы тебе все-таки доступны? Ок, может тогда вернемся к обсуждению того, что
PD><skipped>
PD>Нет, не буду. Я уже все аргументы изложил. Коротко — непропорциональность роста потребления ресурсов и роста возможностей.
А откуда вообще взялось, что должна быть пропорциональность? Время той же сортировки например тоже не пропорционально растет с ростом количества элементов.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А мне-то, (как пользователю) — не все ли равно, какие там айсберги ? Я раньше видел картинки на экране и сейчас вижу их. Покрасивее все стало, да, кое-что добавилось. И я никак не могу принять, что эти добавления и красивости так уж требуют роста потребляемых ресурсов в 10 и более раз.
В турбопаскале ты любую из этих фич по отдельности мог запрограмировать легко и просто и без потребления ресурсов.
Но фокус в том, что сложность софта и потребления ресурсов растут экспоненциально с ростом требований/возможностей.
Это значит, что количество водопроводного и нефункционального кода увеличивается нелинейно.
Это значит, что количество вспомогательных структур увеличивается нелинейно.
Это значит, что дублирование вообще увеличивается нелинейно.
Во времена турбопаскаля никто толком не думал о выполнении скриптов самом приложении врде того же редактора, а сейчас это обычное дело. тогда — разовые применения, сейчас — обычное дело.
Никто не думал о безопасности, всяких уязвимостях и тд.
Никто не думал про интерграцию приложений кроме специальных случаев.
тогда хватало простецкого интерфейса, сейчас usability и user experience это обязательная вещь.
Тогда были маленькие экраны, щас экраны огромные и могут отображать много больше инфы.
Сейчас все это нужно хором и в обязательном порядке. Соответсвенно сложность и потребления ресурсов растут нелинейно !
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Фантастика! Все, сдаюсь. Раз уж при 3.2 GHz, 4 ядрах, 4 GB памяти, черт знает каком количестве каких компьютеров у самой Google и скоростью Интернета в несколько Мбит/сек научились редактировать один документ несколькими пользователями — все, я сдаюсь.
Заметь — ты снова спрыгнул с темы.
Было сказано про гугловые вебпроложения, а ты " редактировать один документ ".
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Например у разработчиков тогда практически не было профайлеров, а их понятия о x86 были поверхностными, потому как машинный код получался откровенно гнусным.
PD>Еще бы. Тем более, что там был и не x86, а 8080 и CP/M. 8086 будет позже.
Разница то какая ?
Если например найти тот самый код, то я просто уверен что его можно соптимизировать нынешниеми инструментами и по памяти и по быстродействи и заставить генерировать более быстрый код.
PD>Есть у психологов такое понятие — "профессиональный кретинизм" — которое означает, что работа человека формирует у него стереотипы, через которые он воспринимает весь окружающий мир, по крайней мере это стереотипы его действий, попыток решения возникающих задач.
То есть ты хочешь сказать, что работа в IT вынуждает всех присутствующих в данном форуме быть дурачками неспособными оперировать фактами?
А ты молодец!
G>>>Ваша дискуссия выглядит так: G>>>Ребятки, чего это ваш агрегат со скоростью 60 км/час движется ? G>>>Так это, траффик, машин много стало в 21 веке, быстрее сложно в городе ездить, даже на феррари. G>>>Неее. Ничего не знаю, я еще 20 лет назад из жигулей 70кмч под горку выжимал, говно ваша феррари.
PD>>А чего это ваша "феррари" все же под горку со скоростью 60 км/час движется ? Там, где нет трафика, нет машин, да и дорога стала намного шире ?
M>С какого перепугу (перепою?) ты это решил? Наша веррари движется со скоростью, превышающей звуковую в условиях, анпоминающих дороги москвы. В то время когда в 70-х, когда машин не было ты мог на своем тазике выжимать от силы 70-80 кмч.
Смех-смехлм, но я наблюдаю следующий факт: 7-8 лет тому назад я бы не рискнул в браузере разворачивать эту ветку. И любую ветку болmit? чемв dсотню-две сообщений. Потому что гарантированно подвешивало браузер на 5-15 секунд (на монстрах типа Lin vs. Win — и того дольше).
Это — к вопросу о тазиках 10-летней давности. Если ты уверен, что они были быстрыми, пора наконец-то выйти из кабинета на улицу и увидеть реальный мир.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Хорошее замечание. Только вот файлы в VC++ компилируются независимо. Поэтому компилятор может оптимизировать только в пределах файла, а там сотни тысяч классов и методов не будет.
FR>http://msdn.microsoft.com/en-us/library/xbf3tbeh(VS.80).aspx
Дочитал бы мое сообщение до конца, прежде чем постить.
PD>Отптимизацию между файлами делает вторая фаза, вызываемая из линкера. Она доступа к исходникам не имеет. Вот в ней я готов допустить этот рост, и то вряд ли как N^2, так как едва ли в этой оптимизации задействованы все пары методы всех классов — времени на такое не хватит.
M>>О том, что это не текстовый документ — а Rich Text или подобие EXcel'я мы тоже забудем
PD>Ну насчет подобия Excel промолчим. Ваши таблицы в броузере с ним и близко не лежали. А насчет RTF — ну и что ?
Ты бы эта, не позорился, а открыл бы Google Docs и посмотрел бы. Не лежали у него.
M>>Я так думаю, ты уверен, что NN 3.0 Gold с этим, безусловно бы справился
PD>Я так думаю, что NN этим заниматься бы не стал, поскольку не его это дело было при тех скоростях, а вот написать программу, которая делала бы это в локальной сети , вполне можно было и 15 лет назад. Во всяком случае, тут нет ничего невозможного.
Повторяю задачу. Чем теоретизировать, открыл бы Google Docs, и посмотрел бы. NN этим заниматься не стал бы, потому что у него бы лопнул (образно выражаясь) интерпретатор JS'а, среди прочих.
И да, 15 лет тому назад это было невозможно. Даже в локальных сетях.
M>>В пятидесятый раз: он не только компилируется. Он еще и вы.пол.ня.ет.ся. Специально по слогам тебе написал. Могу повторить: выполняется. Написать курсивом: выполняется, полужирным: выполняется. О! Заглавными буквами: ВЫПОЛНЯЕТСЯ.
M>>То, что ТР что-то там компилировал в пределах одного мегабайта разве означало, что конечная программа будет выполняться в пределах 1 мегабайта? Нет.
PD>Ну ты даешь! Повторяю во второй раз — будет, потому что в PC XT на машине всего 1 Мб. Более того, доступно 640 Кб.
Ах, да, старый добрый ДОС. забывать уже стал, старею.
Толкьо что-то мне подсказывает, что ни JIT'а там не было, ни run-time optimizations, ни динамики какой-либо. И Икемефула тут уже говорил, что JS управляет количеством объектов бОльшим, чем памяти было у TP.
Да-да. Только вот ты это старательно и сознатльно игнорируешь.
PD>Ну а уж если тебя интересует именно то, что программа, скомпилированная с TP, не уложится в Мб — ответ настолько прост, что дальше и некуда. Не было больше в MS-DOS. При наличии отсутствия . Так что "занять намного больше памяти, чем до, во время или после компиляции" можно, только не более 1 Мб. PD>А вот какое это имеет отношение к делу — непонятно. Одной программе нужно больше, другой меньше... Укладывались в 640, как правило.
И этот человек рассказывает мне про передергивание фактов.
Интернет мне говорит, что компилятор паскаля мог уложиться в компиляцию under 300 KB памяти. Результирующая программа могла спокойно сжевать 640 KB, не поперхнувшись.
Но нет, ты упорно рассказываешь про компиляцию и только про компиляцию.
TP потом портировали и по винды. Предположим, что поведение компилятора сильно не изменилось. Но вот полученные программы при выполнении могли сожрать всю память, что им могла отдать система.
Но это тебя не волнует. Ты упорно зациклился на компиляции и только на компиляции.
Хотя умный человек давно бы задумался — а что, на компиляции все заканчивается?
G>>>>Ну то есть какие-то аргументы тебе все-таки доступны? Ок, может тогда вернемся к обсуждению того, что
PD>>>Нет, не буду. Я уже все аргументы изложил. Коротко — непропорциональность роста потребления ресурсов и роста возможностей.
G>>Так рост потребления возможностей ты померять не можешь! Во-первых потому что ты просто не знаешь эти новые возможности (и слышать об этом не хочешь), во-вторых потому что ты сам не знаешь методики измерения этой сложности, в том числе и потому, что ты регулярно в этом топике сравниваешь килограммы с километрами.
E__>В том-то и дело.
E__>Например, вот тут краткое описание возможностей современной IDE. Причем практически каждая из приведенного списка фич сама по себе сильно(некоторые — в разы) сложнее всей IDE для паскаля. Очень рекомендую Павлу для ознакомления. Там не сухие доки, а нормальное описание человеческим языком с картинками — читается легко. Просто для ознакомления. Для затравки — анализ кода на лету.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Есть у психологов такое понятие — "профессиональный кретинизм" — которое означает, что работа человека формирует у него стереотипы, через которые он воспринимает весь окружающий мир, по крайней мере это стереотипы его действий, попыток решения возникающих задач.
А как называется у психологов состяние, при котором пациент напрочь отрицает опыт профессионалов, считает, что кругом сговорились враги и дураки, а он сам бы сделал всё в сто раз лучше?
PD>>>Ну ты даешь! Повторяю во второй раз — будет, потому что в PC XT на машине всего 1 Мб. Более того, доступно 640 Кб. M>>Ах, да, старый добрый ДОС. забывать уже стал, старею. PD>Не стареешь, а в детство впадаешь. Сначала в шестилетний возраст, а потом в ясельный. M>>Толкьо что-то мне подсказывает, что ни JIT'а там не было
PD>Не было. Нужен он там как зайцу стоп-сигнал или как тот же JIT современному коду, оттранслированнному с неуправляемого C++. По той же причине.
Действительно. Речь о TP vs JS а Дворкин говорит о С++. Так вот, в современных JS JIT есть.
>>ни run-time optimizations
PD>Ее и сейчас в С++ нет — некому ей заниматься и незачем. И без нее код с ++ быстрее.
Действительно. Речь о TP vs JS а Дворкин говорит о С++. Так вот, в современных run-time optimisations есть.
>>ни динамики какой-либо. И Икемефула тут уже говорил, что JS управляет количеством объектов бОльшим, чем памяти было у TP.
PD>В байтах ? То есть у js объектов 640 тысяч ? для любой страницы ? для Hello,world тоже ?
Какая разница, на любой или не на любой? Факт, который ты намеренно игнорируешь состоит в том, что современный JS способен управлять таким количеством объектов без просаживания в скорости.
M>>Да-да. Только вот ты это старательно и сознатльно игнорируешь.
PD>Да вот , как видишь, не игнорирую.
Ага, перечитай. Заодно скажи мне, с какого перепугу ты приплел сюда С++.
I>>>Зачем писать свой если есть уже готовй ? Его доточить под конкретную задачу — уменьшить потребление памяти при увеличении быстродействия и повышении качества выходного кода.
PD>>То. что они умели писать хороший код — я не спорю, а оптимизировать незачем, потому что этот компилятор никому не нужен. Ты обещал написать свой компилятор + остальное в 64 Кбайтах. Вот и пиши. Можешь на js, можешь на чем-то ином
I>Ты спросил, сколко понадобится памяти — я тебе ответил. Компилятор почти такого же языка у меня есть с исходным кодом
Ну ты помнишь. «мне не нравится этот браузер, поэтому я не верю тестам на нем». Соответственно, «мне не нравится этот компилятор...»
M>И этот человек рассказывает мне про передергивание фактов.
M>Интернет мне говорит, что компилятор паскаля мог уложиться в компиляцию under 300 KB памяти. Результирующая программа могла спокойно сжевать 640 KB, не поперхнувшись.
Ну слава богу, наконец-то ты понял. Насчет того, что он мог и в 300 Кб — может быть, их ведь 7 версий было, первой и 64 хватало.
M>Но нет, ты упорно рассказываешь про компиляцию и только про компиляцию.
Может, хватит лапшу на уши вешать ?
M>TP потом портировали и по винды. Предположим, что поведение компилятора сильно не изменилось. Но вот полученные программы при выполнении могли сожрать всю память, что им могла отдать система.
И какое это отношение к делу имеет. Я хоть что-то про этот компилятор говорил ? А потом бы его наследник — Дельфи, а потом 32-разрядная Дельфи, а потом Delphi.net. Я обязан о них всех сказать ? Я про TP говорил под ДОС, а обо всем остальном говори сам, если хочешь. Сам с собой.
M>Но это тебя не волнует. Ты упорно зациклился на компиляции и только на компиляции.
Опять врешь ? После того, как я тебе показал твою , допустим, ощибку — продолжаешь врать ?
M>Хотя умный человек давно бы задумался — а что, на компиляции все заканчивается?
Видимо, больше тебе ничего не остается, как врать.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
I>Ты, кстати, в курсе, что за 10 лет размер страницы и кол.во скриптов увеличилось примерно в 10 раз ?
I>Твой mail.ru 10 лет назад хорошо если 30кб был, а сейчас он на пол-мега тянет.
Вполне допускаю.
PD>>А Flash на js сделан ?
I>Не знаю, но он работает одновременно с другими фичами в браузере Т.е. ему нужны и процессор и память.
Это верно, конечно, но аргументом таким я бы не гордился. А если там не флеш, а настоящее видео начинает работать ? Ему ведь памяти-то ого-го как надо. Но это ни ваша заслуга, ни упрек вам. И флеш тоже. И прочие ActiveX.
PD>>Краткий вывод — объем памяти в системной части будет больше, в юзеровской — скорее всего нет.
I>В какой это системной ? Рендерер в браузере !
Уффф. В той, которая >= 0x8000000. В системной части адресного пространства, там где ядро (ntoskrnl) и подсистема Win32 (win32k.sys). Ты хоть про Фень Юаня слышал ?
А то, что ты называешь рендерером, есть лишь некий код, который передает тексты подсистеме Win32.
PD>>Еще раз — текст вы не рендерите. Вы только указываете шрифт, string и координаты. А дальше броузер делает CreateFontIndirect, выбирает этот шрифт в HDC, передает строку в TextOut — и на этом его работа закончена. Остальное делает Windows.
I>И так по сто раз ? Ты в своем уме ? Это надо сделать один раз при условии что html или css не менялись.
Уф... Я в своем уме. Битовые карты в формате DDB хранятся в системной части АП. Кешировать можно что угодно, хоть битовые карты, но от этого они в ином месте храниться не перестанут. Просто потому, что битовые карты в формате DDB не могут храниться в юзеровской части АП. И все.
I>А дальше брать закешированую битмапину и выводить ее, например, при прокрутке или переключению страниц.
Совершенно верно
// псевдокод, не транслировать
HDC hdcM = CreateComaptibleDC(hdc);
HBITMAP hBmp = CreateCompatibleBitmap(hdc, cx, cy);
HFONT hFont = CreateFontIndirect(&lf); // какой-то шрифт
SelectOject(hdcM, hBmp);
SelectOject(hdcM, hBmp);
TextOut(hdcM, 100, 200, "компания производит...");
// и вот мы имеет битовую карту hBmp. На ней нарисован текст "компания...". Она хранится в системной области АП. Ее можно скопировать на другую битовую карту, в частности, в окно броузера.
I>Одной битмапины недостаточно, нужно делить страницу на части согласно структуре и все это держать в закешированом виде.
Правильно. Повтори код выше несколько раз.
I>Виндовс всего этого не умеет, потому кеширование это твоя забота, виндовс может восстанавливать контент только для простых случаев.
Я тебе код привел Более того, тут и броузера не надо. Я когда-то давным-давно писал свою гипертекстовую систему, еще когда про HTML ничего не знал, поэтому свой ""язык" придумал Там были и текст и картинки, и я именно так их кешировал.
I>>>Т.е. если не считать ни DOM, ни JS, то окажется что рендеринг сам по себе ёмкая по ресурсам операция.
PD>>Видимо, ты не то понимаешь под рендерингом именно текста. Или не понимаешь, как он делается.
I>Ты уже хорошо показал — TextOut
Я тебе подробнее написал.
I>Единственно правильный вывод графики — это швырять битмапы на экран. Битмап подготавливается бровзером с помощью апи виндовса и собственного функционала и швыряется на экран, после чего битмап этот хранится в памяти рендерера до следующей отрисовки. Если меняется html или сss, рендерер сбрасывает все кеши.
Совершенно верно. Вот я тебе и объяснил, где эти битмапы хранятся.
PD>>Вот, например, в HTML есть строка "Компания разрабатывает чего-то там и т.д.". Длинная строка. Как ее хорошо вывести, то есть как разбить на куски, отформатировать — это ваша и броузера работа, верно. А вот как только для кусков броузер определил, где какой кусок текста будет выведен — все, остальное работа Windows.
I>А второй раз тоже самое надо делать ? Вот крутнул ты страничку, опять что ли будешь отрисовывать это же через Text Out ?
Не обязательно. Если битовая карта не уничтожена, то нет. Но понемногу их все же придется уничтожать — память не резиновая.
I>>>10 лет назад рендеринг был много проще — CSS того же считай не было.
PD>>Еще раз — это не рендеринг. Это форматирование.
I>CSS усложняет рендеринг ! При этом СSS != рендеринг.
(1) CSS усложняет форматирование текста. CSS объясняет, грубо говоря, как его надо нарисовать, какие там отступы, цвета, шрифты и т.д. Это ваша работа. А потом — вывод текста, это работа Windows.
I>>>Ты вообще понимаешь, что такое CSS ?
PD>>Немного понимаю
I>Вряд ли, в противном случае ты бы знал как он влияет на рендеринг.
Я ужу объяснил, выше, см (1)
I>>>Чуть не на каждой страничке сейчас есть баннер на флеше. Ты понимаешь, что такое флеш ? А он сам ест и память и процессор.
PD>>А на чем этот флеш написан ?
I>Какая разница ? Он требует и память и процессор, а кроме него есть кому и процессор и память потреблять.
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>А про выполнение опять не вспомнил.
PD>Что-то я никак не пойму, почему и ты и Мамут пристали ко мне с этим выполнением. Я решительно не понимаю, какое это отношение имеет к потребностям компилятора.
А разве не ты перваы сказал о том, что js в Chrome слишком прожорлив? Речь ведь об исполнении шла, нет? И потом, чем отличается исполнение программы на твоем любимом TP от js, объяснено на этом форуме минимум тремя участниками, причем некоторыми из них — более одного раза, причем так, что даже до меня, смею думать, дошло. Стоит ли захламлять форум еще одним таким же, или очень похожим, постом?
PD>TP-чистый компилятор, при выполнении он не участвует, даже если компилируем в память. Он не интерпретатор!!!
А речь изначально шла об исполнении js в Chrome.
P>>Значит, не всегда, все-таки. Ясно, чудес не бывает. И как тогда?
PD>Тогда это будет значить, что я не был достаточно профессионален и не сумел найти правильное решение. Плохо то есть. Придется, скорее всего, все с начала.
А если двигаться итеративно, то не всегда откат идет до самого начала. Потому что всегда можно вовремя увидеть уход в сторону. Теоретические расчеты, по-моему, стоит проверять экспериментально. Опять же затрты в конечном итоге ниже.
P>>Только строгий анализ и тесты. Всегда можно нарваться на особый случай. Например, диск находится в сети. И все эти O меняются в зависимости от условий.
PD>А что это за такой ососбый случай наличия диска в сети ? Мне, например, было точно известно, что в сети он не будет, поскольку дурных нема — запускать процесс, который и без того идет 5 часов, еще и с сетевого диска. Но если бы это было допустимо — принял бы во внимание.
Сетевой диск — не более, чем пример. Можно обобщить: каждый компонент в отдельности летает, а при интеграции всегда есть шанс поймать нехилые тормоза. И если строить компонент сразу от начала до конца, причину такого поведения выявить, imho, гораздо сложнее, чем если двигаться не спеша. Потому что ты видишь реальное поведение программы. При теоретических расчетах ныкоторыми подробностями всегда пренебрегают, а в них, в этих мелочах, собака и зарыта.
PD>>>Да я и не спорю, что это удобнее. И сколько им памяти нужно, не знаю. Но не уверен, что именно столько, сколько действительно необходимо для такой задачи.
P>>Я тебе привел пример, где выделение лишней памяти существенно сокращает время выполнения функции.
PD>Несомненно. На Ф4 без рекурсии — несомненно.
>>А потом я что-то увлекся. Так все-таки, почему этот дополнительный массив — не аргумент? Классика ведь: время экономится за счет увеличения требуемой памяти. Все строго в рамках закона.
PD>Где, на Ф4 ? Там иначе просто невозможно. На Win32 ? Я тебе тут разные способы приведу, как выделить и при этом не выделить и т.д.
Не понял, ты считаешь, что на Ф4 выделение памяти ускоряет вычисления, а в других системах — нет?
Динамическое выделение/освобождение памяти, ЕМНИП, не самая дешевая операция.
При выполнении тяжелых расчетов удобнее выделять ее сразу везде, где только можно.
Не, ну можно написать свою систему управления памятью, которая будет работать очень быстро. Но этой системе нужна память, которой можно управлять, а ее опять-таки выделяют сразу при запуске. И тогда, с точки зрения системы, объем памяти, занимаемый программой, не меняется, а что происходит внутри программы, ОС не интересует.
И когда в памяти находятся некие данные, она выделена или нет?
P>>И что, повторю, с дополнительным массивом? Получается, что нужен он? все-таки аргумент?
PD>Что-то я запутался совсем. PD>В Ф4 — нужен, потому что иначе нельзя. Выделить постоянно. Иных средств нет. PD>Не в Ф4 — есть, а поэтому можно выделять и освобождать.
PD>О чем спор-то ?
Вопрос в целесообразности постоянного выделения/освобождения. Если такая память мне нужна на каждой итерации, на фига мне все время ее выделять на входе и освобождать на выходе, рискуя, к тому же, нарваться на какой-нибудь OutOfMemory?
PD>Почему-то вы все решили, что я его совсем уж не знаю. Вот о Хаскеле, действительно, высказываться не буду — я его совсем не знаю. А о js представление вполне имею.
Ну так и погоняй на нем скрипты и посмотри, куда его rumntime память девает.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Только давай все же уточним. Выполнить действия для разметки текста (говорю только о нем) сейчас действительно намного сложнее, и это работа броузера. Я не буду спорить насчет 100 или не 100 раз, но в целом верно.
I>Вот про это речь и идёт, это rendering, layout и тд
PD>>Выполнить же действия по рисованию этого текста я тоже не знаю, во сколько раз сложнее, чем раньше. Формат TTF не изменился (правда, OTF добавили), так что если что и усложнилось — то все эти сглаживания и прочие спецэффекты. Но это уже работа не броузера, а Windows, и выполняется она не только для окна броузера, а и для других окон. PD>>Конечно, если вы сами парсите TTF, рисуете сплайны и т.д — тогда это ваши проблемы.
I>А это называется os interaction layer
ok, понял. Надо сначала о терминах договариваться. Я-то подумал, что ты под рендерингом понимаешь создание попиксельного изображения.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хм. Проверил сейчас — действительно странно. В Debug вызывается ассемблерная версия, а в Release при /GL — нечто иное. Интересно. Но суть проблемы не меняет — если бы была только ассемблерная версия, то оптимизация все же невозможна.
просто strcpy — неудачный пример, ибо это intrinsic. для неё есть и "внешняя функция", и "нечто иное" (тупо компилятор имеет внутри себя её реализацию на IL и может делать что хочет).
я сейчас не могу сказать, занимается ли какой компилятор оптимизацией "ассемблерных версий" (но теоретически это возможно — надо иметь дизассемблер внутри )
A>>а чужие — тоже можно, почему нет-то, если я их сам собираю? если конечно тебе всё чужое пришло в бинарном виде (gentoo rulezz!!), то конечно да, обломс. PD>Что значит в бинарном виде ? Тут все в бинарном виде. Ты же lib готов мне дать, без исходников, так ?
значит что у тебя может быть, скажем, буст(он вроде как чужой) скачанный в бинариках, и может быть в сорсах. вот для "в сорсах" я могу сам собрать его либы с /GL. ну для winapi такого счастья конечно не дождёшься, да и вряд ли надо.
>>и оптимизируется она, может быть, даже и на первой фазе (хотя не уверен — но это необязательно, можно сделать хоть в 1ой, хоть во 2ой). A>>вообще, вторая фаза работает не(или не только) с native-кодом, а с дополнительной информацией (c IL-кодом). и если она есть в .lib (а как сделать такой lib, уже сказано, естественно я не про import-lib'ы говорю), то считай на второй фазе доступны "исходники" для этих lib PD>Если код транслирован с С++, то да, на второй фазе доступны эти "исходники".
скажем так, не с С++, а транслирован в формат, поддерживаемый компилятором. в случае с VC вряд ли будет какое разнообразие, а вот для gcc очень может быть
PD>Но что там может быть в них, если код на асме ?
на асме пишут когда считают себя умнее компилятора, так что наверное хорошо что он туда не полезет
Здравствуйте, Mamut, Вы писали:
M>Действительно. Тебе про Фому, а ты про Ерему. M>Тебе: JS y етолько компилируется, но и выполняется M>Ты: Компиляция, Компиляция, Компиляция, Компиляция, Компиляция, Компиляция, Компиляция, Компиляция
Я, конечно, могу допустить, что ты не все в этм треде читаешь.
Но вот это не прочитать ты не мог. Просто потому, что ты оценки поставил. Сегодня в 14:58
А твое сообщение, на которое я сейчас отвечаю, от 16:29
И в том моем сообщении ясно сказано вот что
////
Что-то я никак не пойму, почему и ты и Мамут пристали ко мне с этим выполнением. Я решительно не понимаю, какое это отношение имеет к потребностям компилятора. TP-чистый компилятор, при выполнении он не участвует, даже если компилируем в память. Он не интерпретатор!!!
Но если уж так хочется получить от меня ответ про выполнение — пожалуйста.
Программа "Hello, World" будет занимать несколько Кб
Та же программа, если к ней добавить массив на 60 Кб — 60 с чем-то Кб
Если что-то посерьезнее написать — может, и сотня понадобится.
Если уж очень серьезное (по меркам DOS, конечно) — займем все 640 минус то, что заняли MS-DOS и BIOS
Если компилятор для Win16 возьмем — потенциально до 16 Мб, предел для 16-битной модели
Для Win32 TP не было, это уже Дельфи. Там — как обычно в Win32
Ну и что интересного тут ты нашел ?
////
Как все это понимать ? Я на вопрос о выполнении программа, компилированный TP ответил, хоть и не видел в этом смысла. А ты опять заявляешь, что дескать, я только твержу о компиляции — 8 раз.
Похоже, принцип у теяб прост — лгать, лгать и лгать, авось что-то и останется. Принцип давно известный.
Но мне твои методы надоели. Поэтому твое следующее сообщение (я его еще не открывал) я читать не буду и отвечать тоже. И все последующие в этом форуме тоже.
Bye!
На закуску из Герцена. Выделено мной.
У старика генерала Тучкова был процесс с казной. Староста его взял
какой-то подряд, наплутовал и попался под начет. Суд велел взыскать деньги с
помещика, давшего доверенность старосте. Но доверенности на этот предмет
вовсе не было дано, Тучков так и отвечал. Дело пошло в сенат, сенат снова
решил: "Так как отставной генерал-лейтенант Тучков дал доверенность...
то..." На что Тучков опять отвечал: "А так как генерал-лейтенант Тучков
доверенности на этот предмет не давал, то..." Прошел год, снова полиция
объявляет с строжайшим подтверждением: "Так как генерал-лейтенант... то...",
и опять старик пишет свой ответ. Не знаю, чем это интересное дело кончилось.
Я оставил Россию, не дождавшись решения.
Все это вовсе не исключение, а совершенно нормально. Кокошкин держит в
руках бумагу, в достоверности которой не сомневается, на которой стоит э и
число для легкой справки, в которой написано, что мне разрешается приезд в
Петербург, и говорит: "А так как вы приехали без позволения, то
отправляйтесь назад", и бумагу кладет в карман.
Чаадаев действительно прав, говоря об этих господах: "Какие они все
шалуны!"
Не удержался и решил еще один аргумент озвучить.
P>И из этого тоже. Уж если есть у нас в 5 раз больше памяти за те же деньги, почему бы не использовать? Критерий — максимум эффективности при минимуме затрат. Задача рассматривается комплексно и никак иначе.
Во времена БЭСМ-6 и прочих ЕС памяти было мало, надо было экономить. Согласен.
Во времена Win16 и даже Windows 9x памяти было мало, поэтому надо ее было экономить. Тоже согласен.
А много ее когда-нибудь было ?
Было!
Во времена MS-DOS. Я не шучу. 640 Кб по тем временам — очень много. (вспомни фразу Б. Гейтса насчет 256 Кб)
В 1984 году 1 Мб ОП и примерно 600 Кб доступных уже было. В 1983 году мы примерно так вдесятером мучили одну ЕС-1022 на ВЦ ИОХ АН СССР. С памятью 512 Мб (доступно примерно 400) и быстродействием 70 тысяч операций в секунду. После 1983 года я оттуда ушел, но она еще не один год работала.
А тут 600. И что самое интересное — экономить совершенно не надо. Помешать некому, потому что ОС однопрограммная. Так что бери 100 Кб или все 600 — все равно, никакого профита ни для кого.
И тем не менее писали аккуратно, памятью не бросались, лишнюю не использовали.
Здравствуйте, Ikemefula, Вы писали:
I>Да не гони. Джаваскрипт учится на раз безо всяких книжек и даже туториалов. I>Во первых, он легко понятен любому, кто имел дело с Си-подобным языком. I>Во вторых, в нем достаточно мало фич относительно того же F#
индусы такому подходу апплодируют стоя
O>>Ну конечно. Пока что я наблюдаю ситуацию, что народ бежит со скриптов при первой возможности. I>Странно бегут как то. Каждый год количество джаваскрипта только увеличивается на сайтах. Уже нормальное дело загружать по 1мб этого скрипта.
на сайтах производителей фреймворков? конечно. а вот необходимость загружать идентичный фреймворк с кучи сайтов нормальной я бы не назвал.
Здравствуйте, _Raz_, Вы писали:
I>>Да не гони. Джаваскрипт учится на раз безо всяких книжек и даже туториалов. I>>Во первых, он легко понятен любому, кто имел дело с Си-подобным языком. I>>Во вторых, в нем достаточно мало фич относительно того же F#
_R_>индусы такому подходу апплодируют стоя
Пусть аплодируют. Чем больше индусов будет писать сайты, тем лучше.
_R_>на сайтах производителей фреймворков? конечно. а вот необходимость загружать идентичный фреймворк с кучи сайтов нормальной я бы не назвал.
Поставь себе прокси и посмотри, сколько трафика занимает требует например gmail за месяц и сколько из этого уходит на js.
Можешь даже видео записать, как ты умеешь, и создать еще один почтовый ящик
P>На PC /XT/AT опять памятью швыряться перестали. Там она была припаяна к материнской плате со всеми вытекающими оттута последствиями. На 386 и выше ситуация вновь улучшилась. Вынул SIMM или DIMM из мамки и швырнул его в мусор.
PD>>Было. Почему, если можно было обойтись 100 Кб, обходились 100, а не хватали все 600 ? Это же по соотношению — те же 20 Мб против 120! NN 4.7 против Хрома.
PD>>>>Ответа на него я не получил.
P>Теперь, думаю, получил.
Ты его лучше попроси провести прямую аналогию:
если можно было обойтись 100 Кб, обходились 100, а не хватали все 600.
если можно было обойтись 100 Мб, обходились 100, а не хватали все 4 гига памяти.
Здравствуйте, Mamut, Вы писали:
P>>Вынул SIMM или DIMM из мамки и швырнул его в мусор.
M>Ты его лучше попроси провести прямую аналогию:
M>если можно было обойтись 100 Кб, обходились 100, а не хватали все 600. M>если можно было обойтись 100 Мб, обходились 100, а не хватали все 4 гига памяти.
M>Интересно, как он выкрутится из такого?
Я бы выкрутился очень просто. Чуть раньше памятью швырялись, а теперь ее внезапно стали хватать.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> тогда возвращаюсь к своей посылке : если бы рост объема памяти остановился, скажем, на 256 Мб — он бы не коммерциализировался ? Не думаю. Он бы коммерциализировался вс еравно, но это уложили бы в 32 Мб (броузер etc.).
Может ты все-таки будешь доказывать подобные утверждения? Тут кроме тебя все считают совсем наоборот.
PD>Ну а всякие флешки и баннеры — тут не столько от ОП зависит, сколько от ширины канала.
Ага, конечно. Особенно флэш зависит от ширины канала.
Здравствуйте, Pavel Dvorkin, Вы писали:
A>>а я говорил "полностью", ибо небольшая на взгляд фича может оказаться потяжелее всего остального. A>>и кстати я имел в виду vc++ то есть cl.exe из например 2008ой студии — вот его функционал можно *полностью*, со всеми видимыми и невидимыми фичами, повторить на ресурсах, которые требовал cl.exe из vc6, и не просесть в производительности? (ну пусть +50%, так и быть)
A>>интересный момент — на сколько больше брать памяти? PD>Я думаю, раза в 1.5. И вот почему
про "насколько больше брать памяти" было к
В VC 2010 есть компиляция по ходу набора текста (как в C#, eclipse и т.д.), на это память нужна.
и откуда тут полтора, не пойму. мне почему-то кажется, что тут надо брать больше на столько, сколько жрёт собственно компилятор (в наивном приближении — у меня нет vc2010 и я не могу даже посмотреть как он там компиляет)
PD>Контрвопрос — насколько меньше памяти потреблял компилятор от VC 4.2, 5.0 ? Опять же — от силы раза в 1.5, ну пусть 2. А предположить, что от 4.2 до 6.0 он не развивался,
вообще-то такие предположения неплохо бы обосновать
PD>а тут уж прямо в гору пошел — как-то сомнительно.
тебе вроде как целую гору фич показали новых. так что ещё как в гору.
M>>Попроси его декодировать и показать HD-видео во флэше без ОП (и процессора). Но он же не ответит.
P>Тоже мне бином Ньютона. Покупаешь телевизор, проигрыватель HD-видео, только-то и делов. Тогда и флэш не нужен.
Только поюсь, в HD проигрывателе внезапно может оказаться и памяти больше и процессор мощнее, чем в компьютерах времена DOS'а Непропорционально!!
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>> тогда возвращаюсь к своей посылке : если бы рост объема памяти остановился, скажем, на 256 Мб — он бы не коммерциализировался ? Не думаю. Он бы коммерциализировался вс еравно, но это уложили бы в 32 Мб (броузер etc.).
G>Может ты все-таки будешь доказывать подобные утверждения? Тут кроме тебя все считают совсем наоборот.
Тебя же докаательства такого рода не удовлетворяют. Допустим, я докажу, что 95% сайтов сейчас не лучше, чем 10 лет назад. Ты мне начнешь про 5% оставшихся, а дальше вернемся к исходному положению.
PD>>Ну а всякие флешки и баннеры — тут не столько от ОП зависит, сколько от ширины канала.
G>Ага, конечно. Особенно флэш зависит от ширины канала.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Я просто говорю : делаете так — делайте, только бога ради не оправдывайте свои деяния глубокими философскими соображениями и не доказывайте. что, мол, иначе нельзя. A>>а вопрос-то именно философский. ведь пока ты не покажешь *абсолютно равные по функционалу и производительности* аналоги (с меньшим ресурсопотреблением), не докажешь, что можно иначе. а ты не покажешь, так как их нет PD>Железная логика. Если чего-то на свете нет, значит, этого и быть не может.
мсье теоретик?
сможешь доказать, что это может быть? или только обвинять в распиле можешь?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
I>>>Чем больше индусов будет писать сайты, тем лучше.
PD>>Супер! Умри, Денис, лучше не скажешь! Так им и надо, сайтам
I>Представь себе, если бы китайцы и азиаты всякие не начали клапать компьютеры-железо и тд, то и по сей день, например, оперативная память была бы жутко дорогим ресурсом.
I>Сидели бы себе и по сей день на 640кб.
I>С сайтами происходит тоже самое.
Если бы память (и процессор) разрабатывали китайцы или индусы , то нынешний i7 и 4GB заняли бы всю твою квартиру
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Железная логика. Если чего-то на свете нет, значит, этого и быть не может. A>>мсье теоретик? PD>Нет. Мсье автор программ, от которых требовали как можно большую скорость и при этом не расходовать память понапрасну. Windows.
эти программы тут не причём, если только они не являются полными аналогами тех, что ты обвинил в непомерном расходе ресурсов
A>>сможешь доказать, что это может быть? или только обвинять в распиле можешь? PD>Железная логика. Если я чего-то не могу доказать, значит, этого быть не может
выходит ты просто так, бездоказательно, обвинил немало народу в распиле (считай почти воровстве)?
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>Железная логика. Если чего-то на свете нет, значит, этого и быть не может. A>>>мсье теоретик? PD>>Нет. Мсье автор программ, от которых требовали как можно большую скорость и при этом не расходовать память понапрасну. Windows. A>эти программы тут не причём, если только они не являются полными аналогами тех, что ты обвинил в непомерном расходе ресурсов
Эти программы тут при чем, потому что их можно тоже было написать. руководствуясь этим философскими соображениями
A>>>сможешь доказать, что это может быть? или только обвинять в распиле можешь? PD>>Железная логика. Если я чего-то не могу доказать, значит, этого быть не может A>выходит ты просто так, бездоказательно, обвинил немало народу в распиле (считай почти воровстве)?
Ты про понятие аналогии слышал ? И вообще, давай все же без таких приемов. Я никого ни в чем не обвиняю, и уж тем более в воровстве.
Здравствуйте, Pavel Dvorkin, Вы писали:
G>>в том виде в котором они существуют сейчас — нет.
PD>То есть 256 Мб ОП недостаточно в принципе, чтобы решить такую задачу. Любыми способами ?
PD>Подтверди, пожалуйста, свой "нет" (или ответь иначе).
В твоей формулировке вопроса отсутствует очень важная вещь, а конкретно — точная постановка задачи.
А для точной количественной оценки это необходимо, как, надеюсь, ты понимаешь.
Я считаю, что за разумное время и с разумными затратами и с разумными требованиями по производительности существование сайтов подобных фейсбуку и гмейлу в условиях 256мб в компьютере невозможно. И ведь это мы еще не вспоминаем про бэк-энды этих сайтов, были бы возможны они при отсутствии прогресса в железе?
Здравствуйте, Mamut, Вы писали:
M>Какое отношение это имеет к клиентскому скриптингу? Silverlight/Flash — это вещи в себе с очень слабой интеграцией с браузером
1) Клиентский скриптинг — тяжелое наследие далекого прошлого. Это недостаток, а не достоинство.
2) С интеграцией у сильверлайта (про флаш не в курсе) все в порядке.
Здравствуйте, Mamut, Вы писали:
I>>>В старые добрые времена, когда программисты были умными, а программы — быстрыми и компактными, был написан интерпретатор JS.
K>>Для полноты картины надо добавить, что в "старые добрые времена" программиста, который захотел бы написать что-то сложное на JavaScript, немедленно отправили бы в дурку. K>>Сейчас это безумие вошло в моду, и здравый смысл только еле-еле пищит где то в углу "а на _уя вообще писать на JS, когда есть куча языков, которые намного быстрее, удобнее и надежнее?"
M>Покажи мне эти языки для клиентского скриптинга в браущере с покрытием хотя бы 50% рынка браузеров
Си Шарп не устроит?
По риастату сильверлайт стоит где-то на 65% подключенных к интернету устройств, может у них немного искаженная статистика на 50% точно есть
Здравствуйте, Ikemefula, Вы писали:
I>Поставь себе прокси и посмотри, сколько трафика занимает требует например gmail за месяц и сколько из этого уходит на js.
Очень хороший пример того, что для написания примитивного UI требуются неимоверные усилия на написания огромного количества скриптового кода. В отличии от...
Здравствуйте, Ikemefula, Вы писали:
I>Покажи, что может выступить заменой и что бы а) работало на всех аппаратных платформах б) на всех основных ОС в) во всех основных барузерах
Сильверлайт уже работает, если не на 100%, то 90% покрывает влегкую. Причем совместимость между разными платформами и браузерами у него просто отличная в отличии от html+css+jscript.
Здравствуйте, olegkr, Вы писали:
o> На линуксе есть мунлайт и по слухам оно работает. Для андроида, ифона и блекбери один черт приходится писать в своей среде разработки, если дело выходит за пределы отображения простенькой странички.
На днях общественности был представлен обновленный сайт московского метрополитена, mosmetro.ru
Сайт сделан на Silverlight 4, и это и есть главный фэйл, судя по разъяренным комментариям в блоге разработчика, например:
>Он не будет работать корректно. Никогда. Потому что SL. Точка.
Разьяренные линуксоиды кричат, что под мунлайт он не работает, чему я ни удивлен.
А еще я помню топик (лень ссылку искать), где МС выложила игрушку на сильверлайте, так у половины попытавшихся попробовать на виндах ничего не получилось.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да все я понял. Просто после того, как я 20 или около того раз нажал "No", чтобы понять, чем все это закончится, мне это просто надоело и я отправил скриншот. Ничего не скажешь, хорош язык и исполняющая среда, в которых выполнение некоего кода может привести к тому, что приложение будет unresponsable. Если бы я написал десктопное приложение на любую тему и в нем выдал бы мессаджбокс "извините, у меня тут длительная операция, так что мое окно может перестать реагировать на ваши нажатия" — могу себе представить, что было бы...
Явно переводишь тему разговора.
То что все реализации JS в современных броузерах работают быстрее нежели в броузерах десятилетней давности — это факт?
Факт. Это опровергает твои слова? Опровергает. Даже то что один Хром быстрее уже опровергает.
Так признай свою не правоту, а то ведь твоя позиция выглядит совсем никуда не годной. А вместе с ней и ты сам.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что мне еще сказать ? Ну повторю, если не понимаешь. Было всего 600. Использовали, скажем, 100. А можно было использовать 600, потому что никакого дохода от того, что эти лишние 500 не брать, быть не могло, ибо ОС однопрограммная. 600 — 100 == 500, 600/100 == 5. То есть брали в 5 раз меньше , чем могли бы. А могли бы еще 500 взять, просто так. Но не брали. Так было чем или опять скажешь, что нечем было ?
Сдается мне, пришло время перейти от генерации случайных объемов памяти к более или менее точным расчетам. Ясно, что это вызовет некоторые затруднения, но сделать это необходимо.
Предположим, у нас есть стандартная конфигурация середины 90-х: комп 80386 DX-40, 4 М оперативки. Комп вполне может быть 386 SX/16 c 2 M, для MS-DOS это не имеет никакого значения.
Итак, 640 К основной и еще 384+ К Extended памяти. На компе такой, как у нас, конфигурации вполне реально было получить после загрузки системы приблизительно 620 К. Отлично.
Резидентные программы можно не рассматривать: во-первых, в них сражались за каждый байт, а во-вторых, в предложенной конфигурации они все ушли в HMA или UMB, на усмотрение оптимизатора памяти QEMM.
Рассмотрим, как использовали память распространенные продукты. Командир Нортон, например, брал минимум 300 К. Командир Волков занимал меньше, но все время выделял/освобождал память средствами ОС. Тот и другой состояли из резидентной и транзитной части и умели, запуская приложение, отдать ему память по максимуму.
Утилиты Нортона. Какая из них укладывалась в 100 К? SysInfo, да и то в версии 4.5. Может быть, еще UnErase той же версии. Больше – не знаю. Не будешь же ты, в самом деле, утверждать, что SpeedDisk или Norton disk Destroyer Doctor укладывались в 100 К? А DiskEdit? Он был весьма и весьма увесистый.
PCTools – примерно то же самое.
Настольные БД. Из всех известных мне я попытался бы засунуть в 100 К только dBase III. Что касается остальных, посмотри в доку тех лет: годится любая дополнительная память в любых количествах. Верно, по крайней мере, для FoxPro и Paradox 3.5. Боюсь наврать, Paradox 4.x уже в 1 М просто не влезал.
Текстовые редакторы. Lexicon – помещал тексты в память целиком. Всегда 100 К? MultiEdit – работал с огромными файлами, но хватало ли ему на все про все 100 К? Word 5.0? Скажу, что на стандартной XT я вообще не сумел его запустить. На 386 пойдет без проблем, но неужели кто-то будет утверждать, что он не влезает в 100 к только потому, что "сделано в Microsoft”? MultiEdit? Сомневаюсь. Он же написан на своем встроенном языке. Значит, исполняющая система запускала собственно редактор, а тот уже начинал всю основную работу. А если кто на нем свою собственную систему обработки текстов напишет – все, нужно снова перетряхивать всю память, выискивая в ней свободные байты.
Я могу продолжать еще долго. Я не упоминал всякие там SuperCalc или Quatro Pro.
И я не говорю о софте типа AutoCAD, он специального назначения. Я старался упоминать то, что было установлено везде.
В общем, попробуй дать хотя бы парочку примеров распространенных продуктов, которые нормально работают в 100 К. Потому что загрузить программу в 100 К – не вопрос. Мой любимый редактор QEdit занимал 48 К, но все тексты держал в памяти. И размер этих текстов был побольше 100 К.
А сможешь ли ты сказать, какая из упомянутых мною программ швыряется памятью, какая хватает ее, а какая, если таковая найдется, использует память правильно?
Использовать память по максимуму – вовсе не означает ею разбрасываться.
Одно время по Сети бегали сообщения о попытках написать Windows-совместимую ОС на чистом ассемблере с целью экономии памяти. И где эта ОС?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>>Железная логика. Если чего-то на свете нет, значит, этого и быть не может. A>>>>мсье теоретик? PD>>>Нет. Мсье автор программ, от которых требовали как можно большую скорость и при этом не расходовать память понапрасну. Windows. A>>эти программы тут не причём, если только они не являются полными аналогами тех, что ты обвинил в непомерном расходе ресурсов PD>Эти программы тут при чем, потому что их можно тоже было написать. руководствуясь этим философскими соображениями
слово "тоже" надо рассматривать как утверждение возможности скостить потребление ресурсов для современных программ без ущерба для них?
A>>>>сможешь доказать, что это может быть? или только обвинять в распиле можешь? PD>>>Железная логика. Если я чего-то не могу доказать, значит, этого быть не может A>>выходит ты просто так, бездоказательно, обвинил немало народу в распиле (считай почти воровстве)? PD>Ты про понятие аналогии слышал ? И вообще, давай все же без таких приемов. Я никого ни в чем не обвиняю, и уж тем более в воровстве.
просто скажите — дали нам миллион, вот мы его и транжирим (с) Pavel Dvorkin
одно из двух — либо мы его транжирим (где получить свою долю? — меня вот это больше всего задевает), либо ты не прав
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>Предположим, у нас есть стандартная конфигурация середины 90-х: комп 80386 DX-40, 4 М оперативки. Комп вполне может быть 386 SX/16 c 2 M, для MS-DOS это не имеет никакого значения.
PD>Я вообще-то говорил о временах 286, но ладно, принимаю.
Это не имеет особого значения, на 286 условия несколько хуже.
PD>Согласен.
PD>Отлично.
P>>PCTools – примерно то же самое.
PD>Тоже хорошо. Впрочем, это не утилита ИМХО, а целый пакет их. Если я не ошибаюсь.
Был приличный пакет PCTools, похожий на Norton Utilities, и еще была программа с тем же названием, возможно, того же производителя.
PD>Тоже принято.
PD>И это принято.
PD>И их примем.
PD>Тоже примем.
P>>В общем, попробуй дать хотя бы парочку примеров распространенных продуктов, которые нормально работают в 100 К.
PD>Опустим его.
И опустил-таки. В твоей реплике ответа на этот вопрос я не увидел. Да, все названия приведены мною в предыдущем сообщении исключительно по памяти.
P>>А сможешь ли ты сказать, какая из упомянутых мною программ швыряется памятью, какая хватает ее, а какая, если таковая найдется, использует память правильно?
PD>А вот теперь ответ.
Скипнут как не имеющий отношения к делу.
Ты ведь сам предложил 286. а теперь внезапно картинки, сайты, 400 Мб, Винда... И ни слова по теме, тобой, к тому же, поднятой.
А в этих своих графических редакторах ты учитываешь только голый размер картинки. А сколько ты отведешь, к примеру, на UNDO/REDO? Ведь любая программа, претендующая на звание редактора графики, обязана его иметь.
А в твоих программах накладных расходов совсем-совсем нет?
Паш, что ты минусы то ставишь? Я тебе описал свое ощущение от твоих заявлений. Не соглашаться с этим глупо. Твое мнение, как и мнение твоих оппонентов заведомо предвзято.
Еще глупее твой минус выглядит на фоне плюсов других "прохожих".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Влад, попробуй все же понять, о чем я. Попробуй, прежде чем критиковать. Дело ведь совсем не в Хроме и не в js.
Да я давно это понял. Большую часть твоих сообщений во всех форумах можно выразить старой до боли фразой — "Небо раньше было зеленее, а трава голубее" .
Все твои рассуждения о производительности и ресурсах просто смешны. Честное слово. А уж когда ты начинаешь откровенно не соглашаться с банальными фактами, то это выглядит уже не смешно, а грустно. Надо все же хоть изредка соглашаться с оппонентами.
Пойми, нет никакого "раньше" и "сейчас". Времена и люди один и те же. Разница только в приоритетах. Никому не нужны более быстрые убогости вроде ВС++ 5.0. Но сделать современную IDE, к примеру, и обеспечить при этом такое же потребление ресурсов как в ВС++ 5.0 практически невозможно. Даже если это было бы возможно, то на это пришлось бы положить силы несоизмеримые с отдачей. А ведь надо еще понимать, что в софтостроении силы нескольких людей нифика не складываются. Иногда увеличение команды только ухудшает результат. Вот и ищут люди компромиссы.
Есть у нас лишние гигабайты оперативки — мы можем пустим их на увеличение быстродействия или упрощение алгоритмов. А на что конкретно определяется конкретными задачами стоящими перед тем кто пишет софт.
Конечно же есть и не производительные затраты. И чем сложнее софт, тем они выше. Но это реалии. И глупо пытаться искать в этом какой-то умысле или небрежное отношение к ресурсам.
Софт такой какой его хотя видеть потребители и могут сделать производители.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Аналогично в свое время VC.NET перетащили на WinForms.
VD>Кончай нести откровенную пургу! Не было в природе никакого VC.NET. Ты его сам только что придумал. И на WinForms никто ничего не переводил. VS NET (2000) использовало WinForms только для пакетов для дотнет-языков. Там на WinForms было написано окно свойств и дизайнер того самого WinForms.
Именно это я и имел в виду, что IDE (devenv.exe) перетащили на дотнет. Может, неточно выразился. О том, чт компилятор с С++ переведут на дотнет,и речи не было.
Пакет C++ как тогда, так и сейчас был написан на С++ и безбожно глючил (и глючит по сей день, могу привести минимум три способа завалить им студию).
PD>>Ну там хоть интерфейс существенно изменили, в общем, он, конечно, стал удобнее, чем в VC6, но его можно было изменить и без того, чтобы все это на WinForms перетаскивать.
VD>Не позорься уж так откровенно. Это же форменный берд.
VD>Если хочешь я тебе немного расскажу об архитектуре VS и отличиях VS 6 (в которой был только С++) от VS следующих поколений.
Меня ее архитектура интересует во вторую очередь, а в первую — то, что она значительно медленее, чем VS6.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>В IDE VC++ до 2010 я не вижу ничего такого, чего не было в BC++ 5.0.
VD> Ты бредишь? Как минимум VS 2010 — это расширяемая IDE для (мягко говоря) более чем одного языка.
Как минимум — VS6 была расширяемой средой с как минимум еще одним вcтраиваемым языком — Compaq Fortran, даже если не брать во внимание о ICC++. Это раз. А во вторых — причем тут это ? Я говорил о возможностях IDE, и только, в плане С++, и только его.
VD>Такое сравнение скорее говорит о степени использования возможностей IDE. Когда пользователю достаточно подсветки синтаксиса и запуска отладчика из редактора, то что ему можно объяснить о современных IDE?
А я вполне согласен. Надо было развивать VS6, а не переписывать на дотнет.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Опустим его.
P>И опустил-таки. В твоей реплике ответа на этот вопрос я не увидел. Да, все названия приведены мною в предыдущем сообщении исключительно по памяти.
Опустим относилось к
P>Мой любимый редактор QEdit занимал 48 К, но все тексты держал в памяти. И размер этих текстов был побольше 100 К.
И ты не мог этого не видеть. Зачем тогда передергиваешь ?
PD>>А вот теперь ответ.
P>Скипнут как не имеющий отношения к делу.
Ах вот оно что... Не имеющий отношения к делу. Вот это не имеет отношения к делу ? (выделил сейчас)
/////////////////
К чему я это ? А вот к чему. Объем данных можно легко увеличить. И это, конечно, требует памяти. Тут никуда не денешься.
DiskEdit. Про размеры FAT говорить не буду. А кластеры ?
NDD — то же самое.
Текстовый редактор. Если текста 10 Кб — незачем. А если 300 — берите, и 500 берите. Глупо не брать в однопрограммной среде. (В Win16 еще поговорим!)
SuperCalc — то же самое.
И т.д.
/////////////////
И все это не имеет отношения к делу ? Текст, в котором я объясняю суть своей точки зрения.
P>Ты ведь сам предложил 286. а теперь внезапно картинки, сайты, 400 Мб, Винда... И ни слова по теме, тобой, к тому же, поднятой.
И то, что я выделил в слешах — ни слова ?
Извини, но ты начинаешь мне Мамута напоминать. Он упорно заявлял, что, дескать, я ничего не хочу о выполнении говорить. Я его тыкал носом — а он мне в ответ : почему ты не говоришь ? Если и ты собираешься таким образом дискутировать — давай лучше сейчас и закончим
PD>Я со всеми твоими примерами согласен. И все их отличает одна особенность. Но начну издалека.
PD>Пусть нам надо отредактировать картинку 10000*10000*32bpp. Тут надо 400 Мб. Можно сразу. Можно по частям. Как угодно. Но без 400 Мб не обойдется. PD>В MS-DOS придется по частям. В Windows сейчас можно и целиком.
PD>И никаких возражений у меня это не вызовет. Потому что здесь самым явным образом огромный массив данных.
PD>А вот если картинка 1000*1000*32bpp — извольте обойтись 4 Мб. Можете тоже сразу или частями.
PD>К чему я это ? А вот к чему. Объем данных можно легко увеличить. И это, конечно, требует памяти. Тут никуда не денешься.
Очень удачный пример. Но дело в том, что под понятием "редактирование картинки" можно понимать как "изменение цвета одного из пикселей"(а что, этим инструментом можно вполне добиться любого результата, но нужно быть изрядным задротом), так и "интеллектуальное выделение, применение сотен фильтров, хитрые алгоритмы при изменении размеров, работа со слоями и еще много-много блекджека и шлюх возможностей, облегчающих жизнь дизайнеру". Так вот для всех этих фич тоже нужна память, и немало.
Та же ситуация и с IDE. Для редактирования кода с подсветкой нужно мало. Для полноценного девелопинга c использованием фантастических для времен BC++ возможностей(про студию пусть другие расскажут, я сейчас немного не в курсе, но там тоже очень много очень нужных вещей) нужно больше. И от количества кода это не зависит.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
PD>После этого я говорю — а знаешь ли, что в 2010 году найдутся люди, которые скажут. что при такой конфигурации невозможно будет решить задачу, которая в конечном счете сводится к созданию картинки размером в несколько экранов и изменении этой картинки в лучшем случае десяток раз в секунду ? И это при том, что большую часть работы по формированию этой картинки возьмет на себя ОС (напомню, что в DOS тебе пришлось бы TTF растеризовать самому и jpg рисовать тоже, через видеоадаптер).
Да-да. Почему современные игры так требовательны к системным ресурсам? Ведь это всего лишь формирование картинки! А это умел Doom на 386 компе.
Так?
PD>Я со всеми твоими примерами согласен. И все их отличает одна особенность. Но начну издалека.
PD>Пусть нам надо отредактировать картинку 10000*10000*32bpp. Тут надо 400 Мб. Можно сразу. Можно по частям. Как угодно. Но без 400 Мб не обойдется. PD>В MS-DOS придется по частям. В Windows сейчас можно и целиком.
PD>И никаких возражений у меня это не вызовет. Потому что здесь самым явным образом огромный массив данных.
PD>А вот если картинка 1000*1000*32bpp — извольте обойтись 4 Мб. Можете тоже сразу или частями.
PD>К чему я это ? А вот к чему. Объем данных можно легко увеличить. И это, конечно, требует памяти. Тут никуда не денешься.
Вот смотри. Есть у тебя база телефонных номеров. И занимает она например все доступные 4Мб. И отлично работает.
Только поиск телефона занимает (к примеру) минуту.
Проходят годы. И выясняется, что пользователи не хотят ждать минуту, а хотят чтобы по мере ввода номера выводилась уже отфильтрованная информация(как подсказки в гугле).
И оказывается что либо ты делаешь различные индексы и выделяешь еще памяти, либо пользователи посылают тебя нафиг с твоей тормозной поделкой.
И что в остатке? Информации на 4Мб. а памяти выделено в два раза больше.
Здравствуйте, hattab, Вы писали:
H>Да? Очень интересно, какие такие фичи получили юзеры атишных карточек с конфигуратором написанным под дотнет?
Он их получил в реальное время и за малые деньги для производителя.
H>Гуй выглядит как говно, тормоза просто дичайшие, потребление ресурсов безумное.
Врешь (мягко говоря).
H>И еще очень интересно, какой такой функциональностью пожертвовала NVidia, которая пишет свой конфигуратор
Почему обязательно функциональность? Жертвы могут быть другими ресурсами — деньгами, временем (что те же деньги).
H>(а там, в отличии от атишного, не только настройками дров рулить можно, но и много чего другого) на сях? Вот смотри, продукты одинаковой направленности, но подход совершенно разный. Хоть кто нибудь может сказать, что дотнет чего то дал атишникам окромя тормозов?
Назвать продуктами мелкие утилиты у меня язык не поворачивается. Продукт там — драйвер. Он несомненно написан на низкоуровневом языке просто из-за требований задачи. Конечно на столь мелких утилитах как ГУЙ-конфигурации выигрышь будет не существенен. Но все же он по любому будет. ATI-шная утилита изобилует визуализацией и прочими излишествами (которые, в прочем, возможно очень привлекают неопытных пользователей). Реализация всех эти финтифлюшек занимает время. Не удивлюсь если узнаю, что на ATI-шную и NVidia-вскоую утилиту ушло примерно одинаковое время. Но за счет упрощения написания и отладки основной части ATI-шники успели (смогли) написать эти финтифлюшки.
Вопрос удобства или нужности всех этих финтифлюшек к делу отношения не имеет. Важно только то, что применение дотнета, по сравнению, с С++ дало выигрыш во времени и позволило сделать то на что не хватило бы времени в ином случае.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
K>>Проблема в том, что потребление ресурсов растет совершенно непропорционально росту фич. Зачастую новых фич вообще ноль, только интерфейс немного перерисовали. А рост отжирания ресурсов — огого.
VD>Ну, это конечно же полная чушь. Конечно же никто не будет вкладывать деньги или время в разработку нового продукта если он ничем не отличается от старого.
Мне конечно не хочется быть грубым, но чушь только что написал ты. Будут, еще как будут. Это называется маркетинг.
Здравствуйте, genre, Вы писали:
G>Да-да. Почему современные игры так требовательны к системным ресурсам? Ведь это всего лишь формирование картинки! А это умел Doom на 386 компе.
Здравствуйте, Antikrot, Вы писали:
PD>>Я так вроде начинал со сравнения BC 5 против VC 6. A>в другой теме — да. а вот тут, чуть выше по ветке: A>
A>Контрвопрос — насколько меньше памяти потреблял компилятор от VC 4.2, 5.0 ? Опять же — от силы раза в 1.5, ну пусть 2. А предположить, что от 4.2 до 6.0 он не развивался, а тут уж прямо в гору пошел — как-то сомнительно
A>никакого BC5 уже нет
Нет, конечно, ну и что ? Сравнивать нельзя ?
PD>>В cl.exe еще и генерация кода под IA-64 засунута, и под другие платформы. Это просто разные куски компилятора(кодогенератора). A>надо полагать, ты его изнутри видел? насколько я понял, это уже другой cl.exe будет
Ну и пусть. Синтанализатор останется без изменений, а кодогенератор можно в виде отдельной DLL сделать, по одной на каждый процессор. И на IL тоже.
A>>>>>- поддержка х64 A>>>>>- оптимизация под процы новее 98ого года A>>>>>- WPO A>>>>>- PGO A>>>>>- SIMD A>>>>>- openmp A>>>>>- всякая мелочёвка PD>>>>Да, все это есть, не спорю. Мог бы сказать, что это скорее к компилятору относится, а не к IDE, но ладно, не буду. A>>>я тебе больше скажу, тут всё что я перечислил, относится к компилятору я до IDE ещё не дошёл PD>>Я вообще-то и начинал именно с IDE, и сравнивал именно IDE. Почитай выше по треду. A>выше по треду: A>
A>Контрвопрос — насколько меньше памяти потреблял компилятор от VC 4.2, 5.0 ?
Так что ? Вопрос-то тебе был, а не мне.
PD>>>>А главное — полная смена target-модели. Вместо сегментированной 16:16 плоская 0:32. Это тебе не переход x86->x64 PD>>>>, где модель осталась без изменений, только размер адреса удвоился. Это гораздо серьезнее. A>>>ты кстати почему-то оставил без ответа моё сообщение о том, что в x64 тоже совсем не одна модель PD>>В x64 не одна модель, но они отличаются друг от друга не столько генерацией кода , сколько требованиями по его размещению в памяти. PD>>Они вводят ограничения на код или данные, и только. Это все намного проще сегментированной модели — ни размеров сегментов, ни прямой работы с LDT/GDT..., ни проблемы 64K PD>>И вообще это все мы с тобой уже обсуждали A>было дело. но не помню, чтоб тогда ты на всё ответил A>кстати, выражаясь твоими же словами, могу сказать что "это просто разные куски компилятора (кодогенератора)"
Да, конечно. Я думаю, что кодогенерация на плоскую модель несколько проще, чем на сегментированную, но если бы надо было соорудить компилятор, который на обе модели компилировал (он, кстати, был, BC 4.5), то, действительно, его стоило бы сделать из двух кусков.
A>>>да и поддержка сегментированной модели — ничто по сравнению с любым вышеперечисленным пунктом PD>>Можно, конечно, утверждать что угодно, тем более здесь, но аргументация, что ограничения в 64-моделях ничто по сравнению с генерацией кода на сегментированную модель — уж очень хлипкая. A>а если бы ещё цитирование не хлипким было, то там вот: A>
A>поддержка сегментированной модели — ничто по сравнению с любым вышеперечисленным пунктом
A>вышеперечисленные пункты повторю: A>— улучшенная поддержка языковых конструкций (типа шаблонов) A>— поддержка managed extensions for c++ A>— поддержка х64 A>— оптимизация под процы новее 98ого года A>— WPO A>— PGO A>— SIMD A>— openmp A>поддержка х64 это намного больше, чем "ограничения в 64-моделях" A>какая аргументация нужна?
Так, как я понял, -mcmodel исключена из списка.
(вопрос в скобках — а она поддерживается вообще в VC++ ? Я что-то опций не нашел) Google в основном про GNU C++ пишет.
Про шаблоны я ответил. Естественно, надо было это написать как следует, исправить ошибки. Но основной код был написан, я думаю, еще как минимум, в VS 4.2, потом его только исправляли и совершенствовали.
/CLR — туда же, куда и IA-64 и прочие MIPS. Отдельный модуль, тут мы вроде бы уже согласились.
x64 — смените некоторые константы 4->8, кое-что поправьте и перекомпилируйте. Я абсолютно не вижу, почему тут хорошо написанный код должен увеличиться в размере. Берем любую программу на С++ и перекомпилируем на x64. Что, ее размер при этом возрастет ? (естественно. я не учитываю, что возрастет размер от перехода к 64 битным командам, 64-битным смещениям в командах и т.д)
Остальное. Да, это серьезно. Кодогенератор с тем же SIMD весьма серьезно отличается от кодогенератора для обычного x86. Тут спорить не приходится.
Но!
Эти все опции включаемые. И включаются они далеко не всегда. И даже когда включены, далеко не всегда реализуются. Можешь поставить SSEi, но это еще не значит, что ты ее получишь.
И роль этих всех улучшений в процентном отношении к общему объему кода невелика. Как правило, компилятор все же генерирует обычный код x86/x64, а не эти улучшения.
Никто не мешает опять же оформить это в виде отдельной DLL. По сути ведь мы опять имеем то же самое — иной выходной язык. Можно x86 чистый, иожно x64 чистый, можно IA-64, а можно x86 + SSE2. Кстати, а в IA-64 часом нет той же векторизации в какой-нибудь упаковке ?
Здравствуйте, Mamut, Вы писали:
M>Распаковывать — фигня. Их еще нарисоаввать надо. С учетом всех прозрачностей и наложений друг на друга. Layout в HTML+CSS — это очень злая штука.
пусть аппаратный ускоритель рисует. хотя... "а вот раньше для просмотра интернета 3d ускоритель не нужен был! и ведь отрисовывали!"
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>...Сказал бы. Я тебя знаю
VD>Я только не понял, что ты хотел услышать в ответ на свои фантазии?
Ну раз не понял — замнем это вопрос.
VD>Что в 88-году даже вывод полноцветной картинки на экран был почти что чудом?
Нет
VD>Или то что считаю, что картинку можно вывести и на куда менее мощном железе нежели ты описываешь?
Тоже нет. Хотя это, может, и верно, но я не об этом спрашивал.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Если поиск в БД на 4 Мб занимает минуту — программиста уволить с волчьим билетом, и все переписать. PD>Я нечто подобное сам писал. Поиск в своем собственном файле (хочешь — назови его БД , хоть и не телефонов. Только поиск этот занимал не минуту, а 5-10 мсек. PD>И память при этм не транжирил. Был там mmf на базу (она была примерно так 300 Мб), маппировались страницы, а больше никакой памяти и не выделялось. Зачем ?
У меня ощущение, что ты над нами издеваешься.
"Третий раз объясняю, уже сам все понял, а они не понимают" (с) анекдот
Ну замени в моем тексте поиск на "сделать некую очень ресурсоемкую операцию" и 4Мб на 4Гб (пусть на винте лежат).
E>> Ну, вообще-то, на современных игровых компах(а нахрена не на игровых АТИ?) оно не тормозит совсем.
H>У меня не игровой комп, это да, всего лишь Phenom II X4 940BE 3.3GHz, 8Gb RAM (ATI Radeon 3300HD, на момент покупки мамки это было самое производительное встроенное видео). Как на таком железе вообще можно тормозить? Однако же факты штука упрямая
Странно это. А комп вполне может стать игровым, если в него втаращить более производительную видяху .
E>> Ну а что до стремности — у АТИ и до времен дотнета Каталист кривой был, с чего бы после перелезания на дотнет это поменялось?
H>У меня давным-давно была атишная карточка All-In-Wonder какая-то-там (с тв-тюнером). Там был прекрасный нативный софт, который отлично работал на моем Celeron 300MHz.
У меня как-то catalyst всегда вызывал легкое недоумение. Впрочем, производители железа частенько тянут страшненькие глючненькие утилитки с собой. Телефонный софт это вообще мрак. А что до АТИ — я вполне готов мириться с ихним софтом — железки мне их как раз наоборот, очень нравятся. На более слабых компах я просто убирал каталист из автозагрузки, сейчас пофигу — памяти дочерта, пусь себе висит.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Но сначала докажите, что она ресурсоемкая.
Так как же тебе докажешь, если ты ничего слушать не хочешь? Читать не хочешь, оппонентов не слушаешь.
ПРо полмиллиона объектов на странице гмейла тебе написали.
Ссылку на новые возможности современных иде давали.
ПРо компилятор с++ рассказывали.
про исполнение js тоже.
А ты байку про "нарисовать картинку на экране" заводишь.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Тогда ответ прост. Пишите эту ресурсоемкую операцию, используя увеличенное количество ресурсов. Но сначала докажите, что она ресурсоемкая.
А ты хотя бы изредка читаешь что тебе пишут ?
Вот суммарно основные составляющие
1 JS V8
2 полмиллиона объектов
3 сотни килобайт скрипта и даже мегабайты не редкость
4 DOM, CSS — сложный рендеринг
5 экран увеличился в 5 раз по самой щадящей оценку, реально 10 раз это нормально
6 куча всяких абревиатур которые браузеры умеют сейчас и не умели раньше
Вопрос — все 6 пунктов вместе взятые могут являться ресурсоёмкой задачей или нет ?
GIF, JPEG и Турбопаскль оставь детям, ответь внятно — браузер которйы умеет перечисленные 6 пунктов, имеели ли он право с твоей точки зрения кушать по 100 и более мб памяти ?
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>GIF, JPEG и Турбопаскль оставь детям, ответь внятно — браузер которйы умеет перечисленные 6 пунктов, имеели ли он право с твоей точки зрения кушать по 100 и более мб памяти ?
PD>Дискуссию закончил, все аргументы изложил, и не раз.
Ты ничего не изложил, хотя написал много текста.
Ни на один заданый вопрос тебе ты вобщем так и не ответил.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А впрочем, все это не самое главное. А самое главное тут вот что. Если GUI поток ожидает мютекса (а хоть бы и еще чего-то) и не принял меры по реагированию во время ожидания на возможный пользовательский ввод — автору нужно идти учить основы. Независимо от приоритетов.
Детский лепет. UI-поток даже теоретически не может принять меры по реагированию на что бы то ни было в ожидании каждого мьютекса. В частности, он может встать на мьютексе в совершенно невинно выглядящем месте, просто потому, что там где-то внутрях сработала LoadLibrary. Странно, что человек с таким загибом пальцев про Win32 этого не знает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В броузер в принципе ничто не мешает засунуть что угодно. Тебе про ActiveX напомнить ?
Чувство юмора — это прекрасно. Но всё же, что делать с твоим мега-ActiveX владельцам, скажем, iPad? Веб-сайты сейчас крутятся в огромном количестве всего, и винда — это не очень значительная доля рынка.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Под "засунуть" в твоей фразе любой веб-девелопер подумает "засунуть со стороны сайта".
Советую впредь внимательнеее читать всю дискуссию. В ней и речи не было о том, что делается на серверной стороне. Речь шла только о том, что делается на клиенте. В броузере то есть.
>Понимаешь? Особенность веба — в том, что мы не контролируем браузер. Мы контролируем только наш сайт. С точки зрения веб-девелопера, браузер — это платформа. Нам не очень хочется иметь дело с несколькими десятками реальных платформ. Лично тебе хорошо — ты пишешь под конкретную версию конкретной операционной системы. Представь, что тебе предложили спортировать твою тщательно вылизанную программу на iOS под A4.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Советую впредь внимательнеее читать всю дискуссию. В ней и речи не было о том, что делается на серверной стороне. Речь шла только о том, что делается на клиенте. В броузере то есть.
I>А ты попробуй перечитать что пишет Синклер — он пишет про клиентскую часть.
Он пишет, но, поскольку там ничего нового нет, а участие в дискуссию я завершил, то и отвечать я не стал, а лишь указал на момент, связанный с сервером.
Здравствуйте, Ikemefula, Вы писали:
I>В старые добрые времена, когда программисты были умными, а программы — быстрыми и компактными, был написан интерпретатор JS.
Во избежание всякого, сделаю при случае прогон под XP 32 в VMWare шоб усё было сильно
Максимум чего можно ожидать — Нетшкап вместо 10 раз упадет 7
Здравствуйте, Mamut, Вы писали:
M>А ты даже не попытался понять или даже прочитать, что тебе написали. В частности, M>
M>IE 8 — это бровзер иногда дает окошко, что дескать скрипт сильно медленно работает и предлагает выключить скрипт.
M>Это то, чем ты попытался «срезать» Икемефулу.
Да все я понял. Просто после того, как я 20 или около того раз нажал "No", чтобы понять, чем все это закончится, мне это просто надоело и я отправил скриншот. Ничего не скажешь, хорош язык и исполняющая среда, в которых выполнение некоего кода может привести к тому, что приложение будет unresponsable. Если бы я написал десктопное приложение на любую тему и в нем выдал бы мессаджбокс "извините, у меня тут длительная операция, так что мое окно может перестать реагировать на ваши нажатия" — могу себе представить, что было бы...
M>При этом Икемефула в пух и прах разнес,в частности, твою теорию о том, что интерпретатор 10-летней давности должен работать быстро на современном железе. Видимо, способностью воспринимать информацию (причем поданую максимально просто — в виде таблички с цифрами) ты тоже не обладаешь.
Да ничего он не разнес. Для того, чтобы что-то серьезное утверждать, надо не брать тесты, специально подобранные этой командой, а самые разные тесты, проверяющие самые разные фичи языка. А в таком виде — это все пустая трата времени. И уж тем более не сравнивать с NN 6.x — это просто была неудачная линия, которая вскоре и прекратила свое существование.
M>Увы. Тебя тоже можно зачислять на полочку к шеридану и хаттабу.
Да отправляй куда хочешь. Можешь даже горшком назвать, только в печь не сажай.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да все я понял. Просто после того, как я 20 или около того раз нажал "No", чтобы понять, чем все это закончится, мне это просто надоело и я отправил скриншот. Ничего не скажешь, хорош язык и исполняющая среда,
Теперь ты понимаешь, почему доля IE падает.
M>>При этом Икемефула в пух и прах разнес,в частности, твою теорию о том, что интерпретатор 10-летней давности должен работать быстро на современном железе. Видимо, способностью воспринимать информацию (причем поданую максимально просто — в виде таблички с цифрами) ты тоже не обладаешь.
PD>Да ничего он не разнес. Для того, чтобы что-то серьезное утверждать, надо не брать тесты, специально подобранные этой командой, а самые разные тесты, проверяющие самые разные фичи языка.
"Эта команда" написала JS V8, а я показал тесты 3 движков кроме этого V8 и именно по этой причине я поставил Хром в конец списка.
Считаешь гугловцы решили тест заточить под Фаерфокс и Интернет Эксплорер ?
> А в таком виде — это все пустая трата времени. И уж тем более не сравнивать с NN 6.x — это просто была неудачная линия, которая вскоре и прекратила свое существование.
Какая была удачная из тех что умела JS ? Ты скажи, мне не сложно прогнать тесты.
PD>>Да все я понял. Просто после того, как я 20 или около того раз нажал "No", чтобы понять, чем все это закончится, мне это просто надоело и я отправил скриншот.
M>Ты мен можешь объяснить смысл этого скринншота в контексте этой ветке?
Посмеяться.
PD>>Ничего не скажешь, хорош язык и исполняющая среда, в которых выполнение некоего кода может привести к тому, что приложение будет unresponsable. Если бы я написал десктопное приложение на любую тему и в нем выдал бы мессаджбокс "извините, у меня тут длительная операция, так что мое окно может перестать реагировать на ваши нажатия" — могу себе представить, что было бы...
M>Все вопросы — к создателям IE8. В Сафари stop script останавливает выполнение скрипта в таких случаях.
И что ? И то и другое — не решение, потому что при этом надо делать так, чтобы исполнение кода не мешало работе интерфейса. Эти вопросы в начальном курсе программирования для десктопоных приложений рассматриваются — хоть на Win API, хоть на дотнете, на чем угодно.
PD>>Да ничего он не разнес. Для того, чтобы что-то серьезное утверждать, надо не брать тесты, специально подобранные этой командой, а самые разные тесты, проверяющие самые разные фичи языка.
M>Ты не поверишь. Именно это, этот тест и проверяет.
Я не намерен ни верить, ни не верить.
PD>>А в таком виде — это все пустая трата времени. И уж тем более не сравнивать с NN 6.x — это просто была неудачная линия, которая вскоре и прекратила свое существование.
M>Ага, то есть тебе уже и браузеры не нравятся. Называй браузер 10-летней давности, который тебе нравятся, проведем сравнение на более обширных SunSpider (http://www2.webkit.org/perf/sunspider/sunspider.html) и Dromaeo (http://dromaeo.com/)
Netscape 3.0 Gold. Ему, правда, не 10 лет, а немного побольше. С NN 4.x началось ухудшение.
M>Более того, помимо твоего утверждения, что интерпретатор 10-летней давности будет быстро работать сегодня, были развенчаны и некоторые другие твои утверждения: M>- Что расход по памяти увеличился в 100 раз
Где именно я говорил про то, что в 100 раз ? То есть если сейчас, скажем, 100 Мб, то был 1 Мб ? А если сейчас 50 — то 0.5 ? Броузер, которому хватало 0.5-1 Мб ? Я такого вроде не говорил. Ссылку можно ?
Вот специально поставил NN 4.7 под XP Mode есть. Virtual Size 6 Мб.
M>- Что программы тормозят (тормозят как раз старые программы на более новом железе)
Угу.Я этот тест от v8 попробовал в ie8 под XP Mode. XP Mode не реагировала на Ctrl-Alt-Del около минуты.
M>- Что интерпретаторы работали достаточно быстро M>- Что каждому юзеру вполне хватило бы 16-32 Мб за глаза (опровергается жрущим 53 мегабайта Нетскейпом)
NN 4.7 таки занимает сейчас 6 Мб и вполне работал таки 10 лет назад на машине, где было 32 Мб всего, и занимал, я полагаю, тогда не больше , чем сейчас (см. выше). И многопользовательский режим у него был, хотя и неважно сделан. Так что грош цена всем этим доказательствам твоим. Я тебе уже сказал — оставь в покое NN 6.x, это неудачное решение. Но ты с упорством пытаешься мне именно его и привести в качестве аргумента. Как это назвать ?
M>ну и т.п.
А что, те тесты с гуглокода написаны на Javascript версии 1.5? Если используемая версия выше — то в топку твои сравнения. Ну или не в топку, однако, NN6 выкинуть из рейтингов.
Здравствуйте, Mamut, Вы писали:
M>Покажи мне эти языки для клиентского скриптинга в браущере с покрытием хотя бы 50% рынка браузеров
C#, VB.NET, F# плюс куча других
Здравствуйте, Wolverrum, Вы писали:
W>А что, те тесты с гуглокода написаны на Javascript версии 1.5? Если используемая версия выше — то в топку твои сравнения. Ну или не в топку, однако, NN6 выкинуть из рейтингов.
Это только часть.
В броузере 10-летней давности не могут использоваться возможности современных процессоров. Кэш, affinity mask, я уж не говорю про всякие SSE (не знаю, используются ли они там).
Здравствуйте, Wolverrum, Вы писали:
W>А что, те тесты с гуглокода написаны на Javascript версии 1.5? Если используемая версия выше — то в топку твои сравнения. Ну или не в топку, однако, NN6 выкинуть из рейтингов.
Он не проходит только один тест, но и так видно, что минимум вдвое медленнее чем IE8
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В броузере 10-летней давности не могут использоваться возможности современных процессоров. Кэш, affinity mask, я уж не говорю про всякие SSE (не знаю, используются ли они там).
Здравствуйте, olegkr, Вы писали:
M>>Покажи мне эти языки для клиентского скриптинга в браущере с покрытием хотя бы 50% рынка браузеров O>C#, VB.NET, F# плюс куча других
Вообще-то я давно решил тебе не отвечать, и далее не буду, но вот одно отметить обязан.
PD>>Где именно я говорил про то, что в 100 раз ?
I>Вот твои слова: I>"Но когда я вижу, что потребности в памяти увеличились в 100 раз, скорость процессора — в 50-100, в все вопят — памяти мало, программы тормозят (и это правда), то объяснение только одно — разучились писать как следует."
Здесь сказано про броузер ? Речь идет о программах вообще. В частности, для компиляторов + IDE это верно : в ДОС они занимали , естественно, 1 Мб (ну иногда больше, за счет expanded памяти, BC++ 3.1), а сейчас VS 2010 без открытого solution — 82 Мб, только сейчас посмотрел.
Но о броузере я такое не говорил, да и не мог сказать , потому что 1 Мб для броузера в принципе не хватит : под картинки может больше понадобиться.
Вот поэтому я и не хочу с тобой дискутировать. Показывать тебе твои передергивания каждый раз — охота мне время на это тратить!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здесь сказано про броузер ? Речь идет о программах вообще. В частности, для компиляторов + IDE это верно : в ДОС они занимали , естественно, 1 Мб (ну иногда больше, за счет expanded памяти, BC++ 3.1), а сейчас VS 2010 без открытого solution — 82 Мб, только сейчас посмотрел.
Ну так они и умеют много больше
PD>Но о броузере я такое не говорил, да и не мог сказать , потому что 1 Мб для броузера в принципе не хватит : под картинки может больше понадобиться.
Вообще то разговор в том контексте был про JS в браузерах а тебя понесло непойми куда.
PD>Вот поэтому я и не хочу с тобой дискутировать. Показывать тебе твои передергивания каждый раз — охота мне время на это тратить!
Очень сложно следить за тем, как ты увиливаешь то на Турбо Паскаль, то на BC 3.1, то на Фокспро, тона BC 5.5 то на NN 4.7
А про браузеры ты много чего говорил:
"Вообще-то интерпретатооры умели писать и раньше, и работали они достаточно быстро. А с тех пор быстродействие процессоров очень — таки возросло, а язык JS вроде как не очень усложнился.."
"Каждому юзеру вполне хватило бы, я так думаю, 16-32 Мб за глаза. Хватало же, когда памяти на машине было именно столько. Что с тех пор радикально нового в JS появилось ?"
"Что за чудная такая задача — интерпретатор с несложного, в общем-то, языка, к тому же большая часть кода в котором есть вызовы браузера (всякие document.open и window.on_не_знаю_что)"
Если бы ты меньше переводил тему на турбо паскаль...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Динамика действительно кажется более удобной, с этим я согласен. Но благими намерениями вымощена дорога известно куда. Можно в конце концов придумать замечательный язык по своим возожностям, но если для работы с ним нужно 500 Мб — в корзину его. Ну а то, что без динамики прямо-таки нельзя решить задачу красивого вывода в окно некоторго количества текста и картинок хоть с применением CSS, хоть с чем-то еще — не выдерживает никакой критики.
Как только оказалось что твой Нетшкап и сам горазд кушать память и ничего не умеет, так ты вместо мантры про 100мб завёл другую — 500 Мб.
Здравствуйте, Ikemefula, Вы писали:
I>Разные версии html, css, браузеров, файлов, отсутствие файлов. С динамикой не возникает никаких проблем. Отсутствие проблем достигается исключительно ручным тестированием под всеми популярными браузерами.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Динамика действительно кажется более удобной, с этим я согласен. WH>Оно тебе кажется исключительно из-за узости твоего крогозора.
Ну конечно. Если я не знаю про некий язык, который мне даром не нужен — это узость кругозора
WH>Надо иногда вылезать за приделы С++.
WH>Сейчас для клиента генерируется жабаскрипт но ни что не мешает засунуть ur прямо в браузер.
В броузер в принципе ничто не мешает засунуть что угодно. Тебе про ActiveX напомнить ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Динамика действительно кажется более удобной, с этим я согласен. WH>>Оно тебе кажется исключительно из-за узости твоего крогозора.
PD>Ну конечно. Если я не знаю про некий язык, который мне даром не нужен — это узость кругозора
Узость кругозора это не тогда, когда ты не знаешь чего то, а тогда, когда ты считаешь что новые знаения тебе даром не нужны.
а собственно что это и кому доказало? заходишь на какой-то пропиаренный сайт свои <свой браузер> и вылетают ошибки — кому какая разница? говносрач из-за скорости, которая особо юзеру не нужна в обычных сайтах — ну реально понтов нет, злит вот лично как обывателя веба: битые скрипты или скрипты, которые заточены или, прямо скажем, работают только под ie — тысячи их!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В броузер в принципе ничто не мешает засунуть что угодно. Тебе про ActiveX напомнить ?
Который работает только в одном браузере в одной системе, и только на дескопе? Спасибо, не надо. Не, ну у меня на работе даже установлен IE7 под вайн(и в нем активиксы работают), но чисто поржать — технология мертва и уже попахивает. Очень попахивает, и не только по причине ее махровой виндозности — безопасники скажут больше. На этом фоне даже жаба апплеты куда перспективнее, хотя сами по себе мертвее мертвых.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Приветствую, olegkr, вы писали:
o> S>windows-only. o> А так же линукс и мак. Маловато будет?
оппа! МС написал дотнет под линупс и мак??? А мужики то не знают!
Здравствуйте, Ikemefula, Вы писали:
PD>>Здесь сказано про броузер ? Речь идет о программах вообще. В частности, для компиляторов + IDE это верно : в ДОС они занимали , естественно, 1 Мб (ну иногда больше, за счет expanded памяти, BC++ 3.1), а сейчас VS 2010 без открытого solution — 82 Мб, только сейчас посмотрел.
I>Ну так они и умеют много больше
Тут бы я сказал на много-много-много-много-много больше. Сравнивать студию+решарпер, или эклипс, или тем более идею с ВС++ — очень странно. Все эти среды сейчас всю черновую работу делают сами, остается только программирование логики.
PD>>Вот поэтому я и не хочу с тобой дискутировать. Показывать тебе твои передергивания каждый раз — охота мне время на это тратить!
I>Очень сложно следить за тем, как ты увиливаешь то на Турбо Паскаль, то на BC 3.1, то на Фокспро, тона BC 5.5 то на NN 4.7
Павел, видимо, просто не видел настоящей мощи современных сред разработки. Вон, у нас человек пришел с идеи(мегамощь), а у нас эклипс(исторически) — среду, саму по себе на порядки превышающую возможности любой "малопамятиресурсовзанимающей", хоть и более слабую, чем идея. Маты слышны ежедневно по поводу убогости. IDE это давно уже не только написание кода, хотя и в этом аспекте продвижение колоссальное.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Sheridan, Вы писали:
o>> А так же линукс и мак. Маловато будет? S>оппа! МС написал дотнет под линупс и мак??? А мужики то не знают!
Ну так как Miguel de Icaza в том же Microsoft опознается как MVP, а так же в связи с тем что под freebsd выпускалось нечто несобирающееся, но очень похожее на то что надо; можно с некоторой погрешностью скзать, что в какой-то мере...
Здравствуйте, Sheridan, Вы писали:
S>оппа! МС написал дотнет под линупс и мак??? А мужики то не знают!
Мужики может и не знают, а остальные в курсе, что такое сильверлайт и мунлайт.
Приветствую, vladimir.vladimirovich, вы писали:
v> Ну так как Miguel de Icaza в том же Microsoft опознается как MVP, а так же в связи с тем что под freebsd выпускалось нечто несобирающееся, но очень похожее на то что надо; можно с некоторой погрешностью скзать, что в какой-то мере...
Здравствуйте, Sheridan, Вы писали:
v>> Ну так как Miguel de Icaza в том же Microsoft опознается как MVP, а так же в связи с тем что под freebsd выпускалось нечто несобирающееся, но очень похожее на то что надо; можно с некоторой погрешностью скзать, что в какой-то мере... S>Только ни МС, ни дотнет тут не при чем.
Читаем внимательно mono-project.com Provides the necessary software to develop and run .NET client and server applications on different platforms..
Про то, что выпускал M$ для freebsd — это вообще чистой водый M$, который "при чем".
Приветствую, vladimir.vladimirovich, вы писали:
v> S>Только ни МС, ни дотнет тут не при чем.
v> Читаем внимательно mono-project.com
моно и дотнет — одно и тоже? пишется в МС?
v>Provides the necessary software to develop and run .NET client and server applications on different platforms..
Посрать что оно provides — не это обсуждается. Кто пишет?
v> Про то, что выпускал M$ для freebsd — это вообще чистой водый M$, который "при чем".
Подробнее пжлст. мс выпустила дотнет для фрибзди?
Здравствуйте, Sheridan, Вы писали:
v>> S>Только ни МС, ни дотнет тут не при чем. v>> Читаем внимательно mono-project.com S>моно и дотнет — одно и тоже? пишется в МС?
о как! а rdp который в virtualbox-е стало быть тоже нифига не rdp и никакого отношения к нему не имеет?
Здравствуйте, Sheridan, Вы писали:
v>> Читаем внимательно mono-project.com S>моно и дотнет — одно и тоже? пишется в МС?
Линукс и дебиан — одно и то же?
v>>Provides the necessary software to develop and run .NET client and server applications on different platforms.. S>Посрать что оно provides — не это обсуждается. Кто пишет?
MVP Майкрософта. И еще. Культурнее говорить: "покакать".
S>Подробнее пжлст. мс выпустила дотнет для фрибзди?
Здравствуйте, Eugeny__, Вы писали:
E__>Тут бы я сказал на много-много-много-много-много больше. Сравнивать студию+решарпер, или эклипс, или тем более идею с ВС++ — очень странно. Все эти среды сейчас всю черновую работу делают сами, остается только программирование логики.
Даже студия без решарпера образца 2005го года умеет больше любого БЦ с булдерами вместе взятыми.
PD>>>Вот поэтому я и не хочу с тобой дискутировать. Показывать тебе твои передергивания каждый раз — охота мне время на это тратить!
E__>Павел, видимо, просто не видел настоящей мощи современных сред разработки. Вон, у нас человек пришел с идеи(мегамощь), а у нас эклипс(исторически) — среду, саму по себе на порядки превышающую возможности любой "малопамятиресурсовзанимающей", хоть и более слабую, чем идея. Маты слышны ежедневно по поводу убогости. IDE это давно уже не только написание кода, хотя и в этом аспекте продвижение колоссальное.
Приветствую, vladimir.vladimirovich, вы писали:
v> v>> Читаем внимательно mono-project.com v> S>моно и дотнет — одно и тоже? пишется в МС? v> Линукс и дебиан — одно и то же?
Не в ту степь ты пошел. Я хочу тебе показать, что говоря о кроссплатформенности дотнета следует говорить о кроссплатформенности моно. И уж никак не о кроссплатформенности МС дотнет фреймворк. Ибо последний "кроссплатформенен" только для "платформ" со словом windows в названии, да и то далеко не для всех.
v> S>Подробнее пжлст. мс выпустила дотнет для фрибзди? v> Неужели пропустил?
Возможно. Покажи-ка.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, vladimir.vladimirovich, вы писали:
v>> S>моно и дотнет — одно и тоже? пишется в МС? v>> Линукс и дебиан — одно и то же? S>Не в ту степь ты пошел. Я хочу тебе показать, что говоря о кроссплатформенности дотнета следует говорить о кроссплатформенности моно. И уж никак не о кроссплатформенности МС дотнет фреймворк. Ибо последний "кроссплатформенен" только для "платформ" со словом windows в названии, да и то далеко не для всех.
В ту степь. В ту. Есть .NET и есть пара фреймворков, его реализующих.
v>> Неужели пропустил? S>Возможно. Покажи-ка.
Здравствуйте, RonWilson, Вы писали:
RW>а собственно что это и кому доказало? заходишь на какой-то пропиаренный сайт свои <свой браузер> и вылетают ошибки — кому какая разница? говносрач из-за скорости, которая особо юзеру не нужна в обычных сайтах — ну реально понтов нет, злит вот лично как обывателя веба: битые скрипты или скрипты, которые заточены или, прямо скажем, работают только под ie — тысячи их!
Уже мало осталось обычных сайтов. IE вот все чаще начинает проц подпаливать при заходе на сайты.
Здравствуйте, vladimir.vladimirovich, Вы писали:
VV>Опять в стиле: "тут играть, тут не играть, тут рыбу заворачивали, не черкайте, это не ваши ноты" (c)
Забавные ассоциации.
VV>Интересно, а что про эти тесты скажут ваши наблюдатели?
Здравствуйте, Privalov, Вы писали:
PD>>Ну конечно. Если я не знаю про некий язык, который мне даром не нужен — это узость кругозора
P>Вот скажи, ты ничего не знаешь про некий язык, но откуда тогда ты знаешь, что он тебе не нужен?
Здравствуйте, vladimir.vladimirovich, Вы писали:
v>>>Provides the necessary software to develop and run .NET client and server applications on different platforms.. S>>Посрать что оно provides — не это обсуждается. Кто пишет?
VV>MVP Майкрософта. И еще. Культурнее говорить: "покакать".
P>Вот скажи, ты ничего не знаешь про некий язык, но откуда тогда ты знаешь, что он тебе не нужен?
Если ты программмируешь, к примеру, для микроконтроллеров, то можно, не изучая некий язык для web-а, сделать вывод о том, что он тебе не нужен ?
Я не имею дело с микроконтроллерами, но то, с чем я имею дело, также говорит о том, что ни один динамический язык мне не нужен — просто в силу быстродействия.
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>В броузер в принципе ничто не мешает засунуть что угодно. Тебе про ActiveX напомнить ?
E__>Который работает только в одном браузере в одной системе, и только на дескопе? Спасибо, не надо. Не, ну у меня на работе даже установлен IE7 под вайн(и в нем активиксы работают), но чисто поржать — технология мертва и уже попахивает. Очень попахивает, и не только по причине ее махровой виндозности — безопасники скажут больше. На этом фоне даже жаба апплеты куда перспективнее, хотя сами по себе мертвее мертвых.
Все верно, но какое это имеет отношение к тому, что я сказал ? См. выделенное.
Здравствуйте, Eugeny__, Вы писали:
E__>Тут бы я сказал на много-много-много-много-много больше. Сравнивать студию+решарпер, или эклипс, или тем более идею с ВС++ — очень странно. Все эти среды сейчас всю черновую работу делают сами, остается только программирование логики.
А сравнивать студию без решарпера (которого, к слову, в С++ никогда не было и нет) с BC++ 5.0 все же можно или нет ? Если нет — что в ней такое новое появилось , чего в ВС 5.0 не было ?
E__>Павел, видимо, просто не видел настоящей мощи современных сред разработки. Вон, у нас человек пришел с идеи(мегамощь), а у нас эклипс(исторически) — среду, саму по себе на порядки превышающую возможности любой "малопамятиресурсовзанимающей", хоть и более слабую, чем идея. Маты слышны ежедневно по поводу убогости. IDE это давно уже не только написание кода, хотя и в этом аспекте продвижение колоссальное.
IDEA действительно только видел, не работал. С эклипсом имел дело несколько лет. Насчет того, что этот самый эклипс чего-то там превышает — не знаю. По сравнению с VC++ только одно серьезное — динамический анализ кода (в VC++ появилось только в 2010). На это память действительно нужна и время тоже. Все остальное не ново. Что касается автоматического преобразования кода , то это фича, которая нужна не так часто , а поэтому постоянно занимать память не должна.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>VS 2010 перевели на WPF. Аллах их знает, чего они хотели этим добиться, внешне интерфейс изменился мало, но в итоге потребности по памяти возросли с 34 Мб (2008) до 80 Мб (при неоткрытом solution). Ну и загружается она секунд 10-15.
продвигают этот самый WPF. не нужен он (особенно такой какой он есть)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Если ты программмируешь, к примеру, для микроконтроллеров, то можно, не изучая некий язык для web-а, сделать вывод о том, что он тебе не нужен ?
Боюсь, придут сейчас пара спецов по микриконтроллерам и скажут точно, что нужно и что не нужно. И JS что, только для web-а, ты уверен?
PD>Я не имею дело с микроконтроллерами, но то, с чем я имею дело, также говорит о том, что ни один динамический язык мне не нужен — просто в силу быстродействия.
Я тоже не программировал микроконтроллеры, но работать в предложенных тобой условиях мне приходилось.
Вот если бы было введено ограничение по количеству переменных в программе (вот тебе 100 на программу и крутись как хочешь
В любом проекте есть часть, выполняющая основную работу и "группа поддержки": всякие утилиты, идущие по расписанию. Например, архивирование логов, закачка данных из внешнего источника. Такие вещи ты тоже предлагаешь писать на C++, экономя байты и выжимая микросекунды? Думаю, ни один заказчик не потянет такое. Бюджет у него, а, стало быть, и у тебя, не резиновый. Даже при полном отсутствии конкурентов ты пролетаешь, а вместе с тобой и твой заказчик. И если ты действительно делаешь такое на C++ и встраиваешь в основной проект, подумай: большую часть времени эти полезняшки просто занимают память.
PD>Хватит такого примера или привести еще ?
PD>>>Да все я понял. Просто после того, как я 20 или около того раз нажал "No", чтобы понять, чем все это закончится, мне это просто надоело и я отправил скриншот.
M>>Ты мен можешь объяснить смысл этого скринншота в контексте этой ветке?
PD>Посмеяться.
Посмеяться с чего? С того, о чем Ikemefulf уже предупредил?
PD>>>Ничего не скажешь, хорош язык и исполняющая среда, в которых выполнение некоего кода может привести к тому, что приложение будет unresponsable. Если бы я написал десктопное приложение на любую тему и в нем выдал бы мессаджбокс "извините, у меня тут длительная операция, так что мое окно может перестать реагировать на ваши нажатия" — могу себе представить, что было бы...
M>>Все вопросы — к создателям IE8. В Сафари stop script останавливает выполнение скрипта в таких случаях.
PD>И что ? И то и другое — не решение, потому что при этом надо делать так, чтобы исполнение кода не мешало работе интерфейса. Эти вопросы в начальном курсе программирования для десктопоных приложений рассматриваются — хоть на Win API, хоть на дотнете, на чем угодно.
Угу. Сейчас ты, анверное, начнешь рассказывать сказки про то, как это выполняется во всех программах, кроме браузеров, ага. Это, на секундочку, тест, выполняющий определенные задачи на пределе возможностей браузера. Ты еще скажи, что ты никогда не видел зависший интерфейс в десктоп-программах, ага.
PD>>>Да ничего он не разнес. Для того, чтобы что-то серьезное утверждать, надо не брать тесты, специально подобранные этой командой, а самые разные тесты, проверяющие самые разные фичи языка. M>>Ты не поверишь. Именно это, этот тест и проверяет. PD>Я не намерен ни верить, ни не верить.
Ну да. У тебя гениальная позиция. «Мне насрать на то, что вы мне тут рассказываете, я верю, что вы все идиоты». По другому эту позицию назвать нельзя.
PD>>>А в таком виде — это все пустая трата времени. И уж тем более не сравнивать с NN 6.x — это просто была неудачная линия, которая вскоре и прекратила свое существование.
M>>Ага, то есть тебе уже и браузеры не нравятся. Называй браузер 10-летней давности, который тебе нравятся, проведем сравнение на более обширных SunSpider (http://www2.webkit.org/perf/sunspider/sunspider.html) и Dromaeo (http://dromaeo.com/)
PD>Netscape 3.0 Gold. Ему, правда, не 10 лет, а немного побольше. С NN 4.x началось ухудшение.
Угу, наверное твое понятие «ухудшение» имеет столько же реальных оснований, как и твои размышления о современных браузерах. Предполагаю, что тесты он не пройдет так же, как и 4.7.9
M>>Более того, помимо твоего утверждения, что интерпретатор 10-летней давности будет быстро работать сегодня, были развенчаны и некоторые другие твои утверждения: M>>- Что расход по памяти увеличился в 100 раз
PD>Где именно я говорил про то, что в 100 раз ? То есть если сейчас, скажем, 100 Мб, то был 1 Мб ? А если сейчас 50 — то 0.5 ? Броузер, которому хватало 0.5-1 Мб ? Я такого вроде не говорил. Ссылку можно ?
Ikemefula тебе привел твои же слова. Ты начал вилять.
PD>Вот специально поставил NN 4.7 под XP Mode есть. Virtual Size 6 Мб. M>>- Что программы тормозят (тормозят как раз старые программы на более новом железе) PD>Угу.Я этот тест от v8 попробовал в ie8 под XP Mode. XP Mode не реагировала на Ctrl-Alt-Del около минуты.
M>>- Что интерпретаторы работали достаточно быстро M>>- Что каждому юзеру вполне хватило бы 16-32 Мб за глаза (опровергается жрущим 53 мегабайта Нетскейпом)
PD>NN 4.7 таки занимает сейчас 6 Мб и вполне работал таки 10 лет назад на машине, где было 32 Мб всего, и занимал, я полагаю, тогда не больше , чем сейчас (см. выше). И многопользовательский режим у него был, хотя и неважно сделан.
Потому что нынешний веб-сайт — это не только 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'ом.
Что из этого умеет 4.7 на 6 мегабайтах? Кусок (и то не полный) HTML'я, кусок (и то неполный) CSS, кусок (и то неполный) Javascript'а... И все.
PD>Так что грош цена всем этим доказательствам твоим. Я тебе уже сказал — оставь в покое NN 6.x, это неудачное решение. Но ты с упорством пытаешься мне именно его и привести в качестве аргумента. Как это назвать ?
Я тебе ничего не привожу, приводил Ikemefula. Ты же не приводишь критерии того, что тебе нужно. Хотя... Тебе же все равно на все наплевать. У тебя — вера и голоса в голове без малейшего желания разобраться в том, что тебе говорят.
RW>а собственно что это и кому доказало? заходишь на какой-то пропиаренный сайт свои <свой браузер> и вылетают ошибки — кому какая разница? говносрач из-за скорости, которая особо юзеру не нужна в обычных сайтах —
Самый популярный сайт в мире — Facebook. Зайди, поинтересйся, сколько там яваскрипта.
Здравствуйте, Mamut, Вы писали:
PD>>Посмеяться.
M>Посмеяться с чего? С того, о чем Ikemefulf уже предупредил?
Нет, с того, что авторы броузера не смогли разрулить ситуацию, которую должны мои студенты разрулить.
PD>>И что ? И то и другое — не решение, потому что при этом надо делать так, чтобы исполнение кода не мешало работе интерфейса. Эти вопросы в начальном курсе программирования для десктопоных приложений рассматриваются — хоть на Win API, хоть на дотнете, на чем угодно.
M>Угу. Сейчас ты, анверное, начнешь рассказывать сказки про то, как это выполняется во всех программах, кроме браузеров, ага. Это, на секундочку, тест, выполняющий определенные задачи на пределе возможностей браузера.
Какие к богу сказки! Это обычное поведение программ. Зайди в форум по Win API, там это сто раз обсуждалось. Это вообще банальность.
>Ты еще скажи, что ты никогда не видел зависший интерфейс в десктоп-программах, ага.
Видел. Это лишь означает, что авторы этой программы тоже не умеют писать как следует. В хороших программах — не видел.
PD>>>>Да ничего он не разнес. Для того, чтобы что-то серьезное утверждать, надо не брать тесты, специально подобранные этой командой, а самые разные тесты, проверяющие самые разные фичи языка. M>>>Ты не поверишь. Именно это, этот тест и проверяет. PD>>Я не намерен ни верить, ни не верить.
M>Ну да. У тебя гениальная позиция. «Мне насрать на то, что вы мне тут рассказываете, я верю, что вы все идиоты». По другому эту позицию назвать нельзя.
У тебя такая аргументация, что спорить с ней просто невозможно ввиду е полной бессмысленности.
PD>>Netscape 3.0 Gold. Ему, правда, не 10 лет, а немного побольше. С NN 4.x началось ухудшение.
M>Угу, наверное твое понятие «ухудшение» имеет столько же реальных оснований, как и твои размышления о современных браузерах. Предполагаю, что тесты он не пройдет так же, как и 4.7.9
Пройдет он тесты или нет — меня мало интересует. Ты просил назвать броузер, который мне нравился лет 10 назад — я и назвал. Что касается ухудшения — это не мое мнение, а мнение очень многих. Закат Netscape начался именно с 4.x.
PD>>Где именно я говорил про то, что в 100 раз ? То есть если сейчас, скажем, 100 Мб, то был 1 Мб ? А если сейчас 50 — то 0.5 ? Броузер, которому хватало 0.5-1 Мб ? Я такого вроде не говорил. Ссылку можно ?
M>Ikemefula тебе привел твои же слова.
Еще раз — где я писал, что в 100 раз для броузеров ? Ты уж пожалуйста, на него не кивай, а ссылочку приведи.
>Ты начал вилять.
О да! Сначала я что-то говорю. Потом ты подвергаешь эти слова расширительному толкованию, распространяя их на ту область, о которой я в этом контексте (именно про 100 раз) не говорил. Когда же я напоминаю, что так делать некрасиво — оказывается, я начинаю вилять. Ну как с тобой разговаривать, если ты к таким приемам прибегаешь ? Если для того, чтобы доказать свое мнение, надо извратить мнение оппонента — значит, дела твои плохи.
PD>>NN 4.7 таки занимает сейчас 6 Мб и вполне работал таки 10 лет назад на машине, где было 32 Мб всего, и занимал, я полагаю, тогда не больше , чем сейчас (см. выше). И многопользовательский режим у него был, хотя и неважно сделан.
M>В десятый, наверное, раз говорю: M>
В десятый раз отвечаю — не думаю. Кстати, о выпадающих менюшках. К твоему сведению, они прекрасно выпадали в Windows 3.0 на 4 Мб памяти. И если бы рост прекратился, то вместо того, чтобы изображать их с помощью неадекватных средств, их бы изобразили теми же средствами, каким их в Windows уже 20 лет изображают. А если бы js этого не смог, то отправили бы его на свалку и заменили чем-то более адекватным.
Да и вообще, что там в этой web-странице есть такое, что "безбожно" может тормозить ? Некоторое количество отформатированного текста + некоторое количество картинок в конечном счете. Я не спорю, вывести надо красиво, с учетом всего, что полагается, но объявить этот вывод 4 Мб в окно чем-то таким, что может безбожно тормозить, можно лишь при условии, что ездить будешь с включенным ручным тормозом.
M>Потому что нынешний веб-сайт — это не только JavaScript. Это и быстрый яваскрипт, сособный манипулировть сотнями тысяч объектов в доли секунды. Как минимум.
M>Потому что нынешний веб-сайт — это не только HTML 3.2/HTML 4. Это и HTML 4 + XHTML 1.0 + XML + XSLT + CSS 2.1 + CSS 3. Как минимум.
M>Потому что нынешний веб-сайт — это не только JPEG + GIF, это и JPEG + GIF + PNG + Canvas + SVG + Flash + Silverlight + CSS3 Transforms (применимо к видео тоже). Как минимум.
M>Потому что нынешний веб-сайт — это не только Flash 5, это Flash 10 (3D Transforms, HD Video, Dynamic Sound Generation и т.п.). Как минимум.
M>И т.д. и т.п.
Да хватит меня аббревиатурами пугать. Ты бы уж хоть подумал прежде чем их список сюда постить. JPEG 10 лет назад не было ? Под JPEG сколько памяти-то надо ? Flash на чем написан-то ?
M>Это все требует скорости и памяти. И в каждый данный момент времени может быть затребовано на любом из открытых сайтов и должно быть готово к манипулированию тем же JavaSscript'ом.
Ну-ну. Манипулируйте.
M>Что из этого умеет 4.7 на 6 мегабайтах? Кусок (и то не полный) HTML'я, кусок (и то неполный) CSS, кусок (и то неполный) Javascript'а... И все.
Конечно, JPEG и GIF не умеет.
M>Я тебе ничего не привожу, приводил Ikemefula. Ты же не приводишь критерии того, что тебе нужно. Хотя... Тебе же все равно на все наплевать. У тебя — вера и голоса в голове без малейшего желания разобраться в том, что тебе говорят.
Давай в очередной раз закончим. Не имеет смысла продолжать.
Здравствуйте, Mamut, Вы писали:
PD>>Только пожалуйста, не занимайтесь теоретическим обоснованием той неэффективности, которую вы делаете.
PD>>(естественно, ничего личного)
PD>>Вот эту последнюю фразу мне мои оппоненты и не простят.
M>Простят. Но только если теоретическое обоснование эффективности с другой стороны не будет пассами руками и рассказами про турбо паскаль.
Ну если ты единственное что углядел в моих сообщениях , это упоминание TP — тогда да.
Здравствуйте, Mamut, Вы писали:
RW>>а собственно что это и кому доказало? заходишь на какой-то пропиаренный сайт свои <свой браузер> и вылетают ошибки — кому какая разница? говносрач из-за скорости, которая особо юзеру не нужна в обычных сайтах —
M>Самый популярный сайт в мире — Facebook. Зайди, поинтересйся, сколько там яваскрипта.
мне наплевать на его кишки, я на сайт захожу как пользователь и мне лично не интересно что и как там. выше написали правильно: если при входе на сайт я слышу завывание системы охлаждения компа, это раздражает и заставляет задуматься
PD>>>Посмеяться. M>>Посмеяться с чего? С того, о чем Ikemefulf уже предупредил? PD>Нет, с того, что авторы броузера не смогли разрулить ситуацию, которую должны мои студенты разрулить.
Ооо. Твои студенты умеют писать браузеры? Покажи хоть один.
>>Ты еще скажи, что ты никогда не видел зависший интерфейс в десктоп-программах, ага.
PD>Видел. Это лишь означает, что авторы этой программы тоже не умеют писать как следует. В хороших программах — не видел.
Photoshop хорошая программа? Не раз видел, как зависал
MS Word хорошая программа? Не раз видел, как зависал
Любой почтовый клиент на выбор. Не раз видел, как зависал
Вообще, практически любую программу, кроме абсолютно простейших утилит, на трех разных системах я хоть раз, но видел зависшей.
Но эти все рассуждения побоку. Мы же говорим о браузерах? Нет. Не так. Мы говорим о браузерах, а ты постоянно заостряешь внимание на браузере. То одном, то другом, не утруждая себя тем, чтобы прчитать и понять, что тебе пишут.
PD>>>>>Да ничего он не разнес. Для того, чтобы что-то серьезное утверждать, надо не брать тесты, специально подобранные этой командой, а самые разные тесты, проверяющие самые разные фичи языка. M>>>>Ты не поверишь. Именно это, этот тест и проверяет. PD>>>Я не намерен ни верить, ни не верить.
M>>Ну да. У тебя гениальная позиция. «Мне насрать на то, что вы мне тут рассказываете, я верю, что вы все идиоты». По другому эту позицию назвать нельзя.
PD>У тебя такая аргументация, что спорить с ней просто невозможно ввиду е полной бессмысленности.
Я кратко выразил тебе то, что я писал длинными выражениями уже много раз. Ты же постоянно игнорируешь то, что тебе пишут.
PD>>>Netscape 3.0 Gold. Ему, правда, не 10 лет, а немного побольше. С NN 4.x началось ухудшение.
M>>Угу, наверное твое понятие «ухудшение» имеет столько же реальных оснований, как и твои размышления о современных браузерах. Предполагаю, что тесты он не пройдет так же, как и 4.7.9
PD>Пройдет он тесты или нет — меня мало интересует. Ты просил назвать броузер, который мне нравился лет 10 назад — я и назвал. Что касается ухудшения — это не мое мнение, а мнение очень многих. Закат Netscape начался именно с 4.x.
Дада, мы поним — тебя вообзе ничего не интересует.
PD>>>NN 4.7 таки занимает сейчас 6 Мб и вполне работал таки 10 лет назад на машине, где было 32 Мб всего, и занимал, я полагаю, тогда не больше , чем сейчас (см. выше). И многопользовательский режим у него был, хотя и неважно сделан.
M>>В десятый, наверное, раз говорю: M>>
PD>В десятый раз отвечаю — не думаю. Кстати, о выпадающих менюшках. К твоему сведению, они прекрасно выпадали в Windows 3.0 на 4 Мб памяти. И если бы рост прекратился, то вместо того, чтобы изображать их с помощью неадекватных средств, их бы изобразили теми же средствами, каким их в Windows уже 20 лет изображают. А если бы js этого не смог, то отправили бы его на свалку и заменили чем-то более адекватным.
PD>Да и вообще, что там в этой web-странице есть такое, что "безбожно" может тормозить ? Некоторое количество отформатированного текста + некоторое количество картинок в конечном счете. Я не спорю, вывести надо красиво, с учетом всего, что полагается, но объявить этот вывод 4 Мб в окно чем-то таким, что может безбожно тормозить, можно лишь при условии, что ездить будешь с включенным ручным тормозом.
M>>Потому что нынешний веб-сайт — это не только JavaScript. Это и быстрый яваскрипт, сособный манипулировть сотнями тысяч объектов в доли секунды. Как минимум.
M>>Потому что нынешний веб-сайт — это не только HTML 3.2/HTML 4. Это и HTML 4 + XHTML 1.0 + XML + XSLT + CSS 2.1 + CSS 3. Как минимум.
M>>Потому что нынешний веб-сайт — это не только JPEG + GIF, это и JPEG + GIF + PNG + Canvas + SVG + Flash + Silverlight + CSS3 Transforms (применимо к видео тоже). Как минимум.
M>>Потому что нынешний веб-сайт — это не только Flash 5, это Flash 10 (3D Transforms, HD Video, Dynamic Sound Generation и т.п.). Как минимум.
M>>И т.д. и т.п.
PD>Да хватит меня аббревиатурами пугать. Ты бы уж хоть подумал прежде чем их список сюда постить. JPEG 10 лет назад не было ? Под JPEG сколько памяти-то надо ? Flash на чем написан-то ?
Блин. Ты из всего списка способен воспринять только графические форматы? В списке выше все, что выделено, 10 лет тому назад не существовало. То, что ты не знаешь эти аббревиатуры, не значит, что их нет, или что браузеры 10-летней давности могли что-либо из перечисленного.
M>>Это все требует скорости и памяти. И в каждый данный момент времени может быть затребовано на любом из открытых сайтов и должно быть готово к манипулированию тем же JavaSscript'ом.
PD>Ну-ну. Манипулируйте.
M>>Что из этого умеет 4.7 на 6 мегабайтах? Кусок (и то не полный) HTML'я, кусок (и то неполный) CSS, кусок (и то неполный) Javascript'а... И все.
PD>Конечно, JPEG и GIF не умеет.
Вау. Какое достижение.
M>>Я тебе ничего не привожу, приводил Ikemefula. Ты же не приводишь критерии того, что тебе нужно. Хотя... Тебе же все равно на все наплевать. У тебя — вера и голоса в голове без малейшего желания разобраться в том, что тебе говорят.
PD>Давай в очередной раз закончим. Не имеет смысла продолжать.
Моя личная к тебе просьба: никогда не появляйся в обсуждения чего-либо, связанного с вебом. Особенно с твоим отношением.
PD>>>Только пожалуйста, не занимайтесь теоретическим обоснованием той неэффективности, которую вы делаете.
PD>>>(естественно, ничего личного)
PD>>>Вот эту последнюю фразу мне мои оппоненты и не простят.
M>>Простят. Но только если теоретическое обоснование эффективности с другой стороны не будет пассами руками и рассказами про турбо паскаль.
PD>Ну если ты единственное что углядел в моих сообщениях , это упоминание TP — тогда да.
Это — практически единственное, о чем ты постоянно говорил. Потому что «мине не интиресна щито ви там гаварите и ссылки я ни читаю».
RW>>>а собственно что это и кому доказало? заходишь на какой-то пропиаренный сайт свои <свой браузер> и вылетают ошибки — кому какая разница? говносрач из-за скорости, которая особо юзеру не нужна в обычных сайтах —
M>>Самый популярный сайт в мире — Facebook. Зайди, поинтересйся, сколько там яваскрипта.
RW>мне наплевать на его кишки, я на сайт захожу как пользователь и мне лично не интересно что и как там. выше написали правильно: если при входе на сайт я слышу завывание системы охлаждения компа, это раздражает и заставляет задуматься
Здравствуйте, Ikemefula, Вы писали:
I>В старые добрые времена, когда программисты были умными, а программы — быстрыми и компактными, был написан интерпретатор JS.
В целом, я согласен с Павлом, но дело вот в чем.
Идет расслоение программистов: самые умные сидят в том же микрософте и гугле и делают суперумные средства разработки и среды выполнения, чтобы тыпорылые массы быдлопрограммеров могли ваять свои говношедевры. Вы тестировали эффективность JS движка, а им как-раз занимались очень умные программеры и делали они это потому что пользуются JS современные "программисты на джаваскрипт".
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>...Обычно чтения первых страницы сайта (книги) по этому языку достаточно, чтобы понять, годится он мне или нет для этой предметной области. Мне не обязательно знать js на уровне профессионалов, чтобы понять, что он для написания драйверов ядра не очень годится
Но, как выясняется, вполне достаточно, чобы рассуждать, как правильно построить для незнакомого языка интерпретатор.
P>>Тут
. Так, на всякий случай.
PD>Было, было. От нечего делать мы в аспирантские времена запрограммировали какой-то простенький расчет для Искра-124. Там было сколько-то регистров, а насчет ОП не помню, была ли вообще. Вот и крутились.
Вот именно. Повторю: те, кто подобное прошел, ресурсы не разбазаривают. Но и ту работу, которую может выполнить машина, не перекладывают на себя.
P>>В любом проекте есть часть, выполняющая основную работу и "группа поддержки": всякие утилиты, идущие по расписанию. Например, архивирование логов, закачка данных из внешнего источника....
PD>Вот тут один любопытный момент возникает. PD>С точки зрения экономии расходов заказчика и своего времени — да. PD>А с точки зрения технологии программирования ? Науки информатики ? Можно ли оправдать экономией денег заказчика то, что эта программа делается вопреки их законам ?
Что значит "вопреки их законам"? Законам информатики? Использовав раз или два в своей практике goto, я их нарушил? Или тем, что сказал: требования к памяти противоречат требованиям ко времени реакции на запрос?
PD>Если ты ответишь да — значит, этой науки уже нет. Потому что можно делать вопреки ее рекомендациям, оправдывая это тем, что иначе денег не хватит.
Так денег действительно не хватит. И потом, нельзя нарушить законы. Рекомендациям можно следовать, а можно и нет, все зависит от конкретных условий.
PD>Я прекрасно понимаю, что ты мне ответишь. Денег-то не хватит! Программа поэтому сделана не будет! И куда ты со своими принципами и наукой ?
PD>Ответ очень прост.
PD>Делаете так — делайте. Ограничен у вас бюджет — делайте неэффективно. Получайте свои деньги и радуйтесь. В общем, на все согласен. Кроме одного
PD>Только пожалуйста, не занимайтесь теоретическим обоснованием той неэффективности, которую вы делаете.
PD>(естественно, ничего личного)
А обосновать выбор C++ в качестве языка для выполнения рутинных работ сможешь? Сколько систем видел, везде используются скрипты. Никто не жалуется. Скрипт разрабатывается значительно быстрее, чем программа, с этим ты тоже будешь спорить?
PD>Вот эту последнюю фразу мне мои оппоненты и не простят. В сущности, они же понимают, что делают неэффективно, что можно бы и получше. Но бюджет... но дедлайн но ... Вот и приходится писать не очень качественно. Сначала это самого раздражает. Надо бы посидеть, подумать, как это лучше сделать, потом время потратить на программирование и отладку. Но времени нет, а есть класс, а у него есть метод, вставил его — и готово.
Техзадание с заказчиком обсудили? Утвердили? В рамки укладываешься? Есть запас прочности по предельным нагрузкам раза в полтора-два? Где здесь, в таком случае, неэффективность?
PD>Черт его знает, что у него там внутри, у этого класса, и как работает этот метод, но работает же!
Инкапсуляция, однако. Или ты, разрабатывая классы, всем все показываешь?
PD>Потом... о, потом происходит хорошо известное психологам событие. Человек постепенно втягивается в эту новую обстановку и начинает принимать ее правила игры.И больше всего его теперь раздражают те, кто эти новые правила не принял и время от времени напоминают ему — а помните, как раньше умели ?
Пример, как человек не принял новые правила игры. Некто, имея очень приличный опыт разработки на ЕС ЭВМ, перешел на PC. Знаешь, как он там ввод-вывод разрабатывал? Как для пакетного режима. Все документы вводятся пачками, пока пачку не ввел, закрыть программу нельзя. А вводятся данные не с перфоленты, а человеком. И хранятся в одном файле, в котором есть поле "тип записи" и некоторые другие служебные. Представляешь, каково было запросы к той базе данных строить? Весь прошлый опыт превратился в балласт. И теперь этот человек ностальгирует, наверно, по старым добрым временам, вместо того, чтобы начать разбираться в новых правилах.
PD>а помните, как раньше Вы умели (это, конечно, не ко всем относится). И ему теперь во что бы то ни стало надо доказать, что те, кто ему это напоминают, решительно неправы, во всем неправы. И доказывая им эту неправоту, они ведь гораздо больше себе доказывают, что они были правы, перейдя в новую веру. Потому что как можно жить в новой вере. если в глубине души шевелится червячок, который то и дело напоминает (пусть даже подсознательно) — а ведь и ты когда-то умел! а может, все же надо признать, что то, что ты сейчас делаешь, не очень...
Какую веру, ты о чем?
А как быть с этим:
Не сотвори себе кумира зи начальника, знай, что ты и сам не дурак.
Все подвергай сомнению.
Здравствуйте, Ikemefula, Вы писали:
E__>>Павел, видимо, просто не видел настоящей мощи современных сред разработки. Вон, у нас человек пришел с идеи(мегамощь), а у нас эклипс(исторически) — среду, саму по себе на порядки превышающую возможности любой "малопамятиресурсовзанимающей", хоть и более слабую, чем идея. Маты слышны ежедневно по поводу убогости. IDE это давно уже не только написание кода, хотя и в этом аспекте продвижение колоссальное.
I>А ты попробуй RIM JDK ...
Может, SDK? А то что-то ни я, ни гугл такой JDK не находит...
Но в любом случае, не хочу.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, vitasR, Вы писали:
R>Идет расслоение программистов: самые умные сидят в том же микрософте и гугле и делают суперумные средства разработки и среды выполнения, чтобы тыпорылые массы быдлопрограммеров могли ваять свои говношедевры. Вы тестировали эффективность JS движка, а им как-раз занимались очень умные программеры и делали они это потому что пользуются JS современные "программисты на джаваскрипт".
Самые умные? Видел я сэмплы к VS SDK, и само VS API немало ковырял. Это полный приплызд, просто полнейший.
Например, функция, которая принимает COM-интерфейс, но на самом деле интерфейс только видимость — функция лезет во внутренности объекта по указателю. Нормально, ага?
Здравствуйте, Klatu, Вы писали:
K>Но проблема тут не в том, что "программисты ленятся", это всё на самом деле большая системная проблема. K>В принципе, выражается одной фразой — "некогда точить пилы, пилить надо!!!". K>Недоделанные программы, недоделанные библиотеки, кривые недоделанные языки. Всё это кое-как скрепляется заплатками, соплями и слезами девелоперов и отправляется в "релиз". И еще проблемы совместимости с предыдущими версиями, такими же кривыми и недоделанными. И с каждой новой версией все эти слои заплаток и соплей растут как снежный ком
Ну, я бы не валил все на девелоперов. Хотя встречал, конечно, разных. Один, помню, запихивая что-то в контейнер, перебирал эти самые контейнеры до тех пор, пока переставал получать исключения на тестах.
Проблема еще в том, что нет хорошего управления проектами. Довольно часто туда отправляют криворуких разработчиков, чтобы не путались под ногами. Многие из них начинают путаться над головами.
Получает, к примеру, девелопер требование сделать какую-нибудь фичу. Берет он и строит модель, посмотреть, будет ли вообще оно работать. Набросал код, запустил пару тестов — работает. Этот самый управленец, вися у него над головой, видит такое дело и рапортует наверх: у нас уже все реализовано и работает. И дает распоряжение внести этот код в очередную сборку. Со всеми вытекающими...
Здравствуйте, Mamut, Вы писали:
RW>>>>а собственно что это и кому доказало? заходишь на какой-то пропиаренный сайт свои <свой браузер> и вылетают ошибки — кому какая разница? говносрач из-за скорости, которая особо юзеру не нужна в обычных сайтах —
M>>>Самый популярный сайт в мире — Facebook. Зайди, поинтересйся, сколько там яваскрипта.
RW>>мне наплевать на его кишки, я на сайт захожу как пользователь и мне лично не интересно что и как там. выше написали правильно: если при входе на сайт я слышу завывание системы охлаждения компа, это раздражает и заставляет задуматься
M>Выделенное выше. Юзеру важна скорость.
Здравствуйте, RonWilson, Вы писали:
M>>Самый популярный сайт в мире — Facebook. Зайди, поинтересйся, сколько там яваскрипта.
RW>мне наплевать на его кишки, я на сайт захожу как пользователь и мне лично не интересно что и как там. выше написали правильно: если при входе на сайт я слышу завывание системы охлаждения компа, это раздражает и заставляет задуматься
RW>>>>>а собственно что это и кому доказало? заходишь на какой-то пропиаренный сайт свои <свой браузер> и вылетают ошибки — кому какая разница? говносрач из-за скорости, которая особо юзеру не нужна в обычных сайтах —
M>>>>Самый популярный сайт в мире — Facebook. Зайди, поинтересйся, сколько там яваскрипта.
RW>>>мне наплевать на его кишки, я на сайт захожу как пользователь и мне лично не интересно что и как там. выше написали правильно: если при входе на сайт я слышу завывание системы охлаждения компа, это раздражает и заставляет задуматься
M>>Выделенное выше. Юзеру важна скорость.
RW>разница в 1-2 секунды — кому и что она дает?
Есть такое понятие — отзывчивость интерфейса. Если на каждое телодвижение в фейсбуке (и так не всегда быстрое) добавить по 1-2 секунды, он будет диким тормозом.
Здравствуйте, Pavel Dvorkin, Вы писали:
>>Ты еще скажи, что ты никогда не видел зависший интерфейс в десктоп-программах, ага.
PD>Видел. Это лишь означает, что авторы этой программы тоже не умеют писать как следует. В хороших программах — не видел.
В Виндовсе в принципе невозможно гарантировать отсутствие замерзаний интерфейса даже если девелоперы будут идеальный код писать.
Все лишь в силу выбраной модели многозадачности. Например процесс с высоким приоритетом может ожидать освобождения объекта ядра который захвачен процессом с низким приоритетом который не может выполняться из за того что выполняется процесс со средним приоритетом
M>>Ikemefula тебе привел твои же слова.
PD>Еще раз — где я писал, что в 100 раз для броузеров ? Ты уж пожалуйста, на него не кивай, а ссылочку приведи.
Смотри первое сообщение, цитаты в конце, у меня было сильное предчувствие что ты, как было раньше, начнешь отказываться от своих слов.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В сущности, вопрос простой, не знаю, зачем ты его поднял. Есть предметная область задачи. Есть некий незнакомый мне язык. Обычно чтения первых страницы сайта (книги) по этому языку достаточно, чтобы понять, годится он мне или нет для этой предметной области. Мне не обязательно знать js на уровне профессионалов, чтобы понять, что он для написания драйверов ядра не очень годится
Вообще говоря ты взялся критиковать реализацию интерпретатора языка созданую профессиональными программистами.
Здравствуйте, Mamut, Вы писали:
RW>>разница в 1-2 секунды — кому и что она дает?
M>Есть такое понятие — отзывчивость интерфейса. Если на каждое телодвижение в фейсбуке (и так не всегда быстрое) добавить по 1-2 секунды, он будет диким тормозом.
это все хорошо для того же фейсбука, но посмотрите на обычные сайты, ну хотя бы на кывт — что толку от этой секунды, если загрузка треда происходит явно не за наносекунды
RW>>>разница в 1-2 секунды — кому и что она дает?
M>>Есть такое понятие — отзывчивость интерфейса. Если на каждое телодвижение в фейсбуке (и так не всегда быстрое) добавить по 1-2 секунды, он будет диким тормозом.
RW>это все хорошо для того же фейсбука, но посмотрите на обычные сайты, ну хотя бы на кывт — что толку от этой секунды, если загрузка треда происходит явно не за наносекунды
Повторю во второй раз
Самый популярный в мире сайт, который самостоятельно генерирует 40% заходов только в Штатах, — это facebook. facebok — это самый, что ни на есть обычный веб сайт
По России аналогичная ситуация, возможно, с одноклассниками. То есть яваскрипта повсюду сейчас много, пусть и не всегда заметного.
Здравствуйте, RonWilson, Вы писали:
M>>Есть такое понятие — отзывчивость интерфейса. Если на каждое телодвижение в фейсбуке (и так не всегда быстрое) добавить по 1-2 секунды, он будет диким тормозом.
RW>это все хорошо для того же фейсбука, но посмотрите на обычные сайты, ну хотя бы на кывт — что толку от этой секунды, если загрузка треда происходит явно не за наносекунды
Найди где нибудь хороший интернет, скажем, 2 мегабита и полазь по инету в тч РСДН разными браузерами, обязательно возьми Хром, Сафари.
Мега-откровений ты вряд ли обнаружишь, зато заметишь, что время отклика даже в пол-секунды имеет значение.
Здравствуйте, Privalov, Вы писали:
P>А обосновать выбор C++ в качестве языка для выполнения рутинных работ сможешь? Сколько систем видел, везде используются скрипты. Никто не жалуется. Скрипт разрабатывается значительно быстрее, чем программа, с этим ты тоже будешь спорить?
А с каких это пор скрипт не программа?
Единственное о чем можно говорить это о скорости разработки и цене проддержки программы на разных языках.
У С++ время разработки большое цена поддержки огромная.
В плюс можно записать то что можно сделать весьма шуструю программу. Но в процессе
У динамически типизированных языков время разрабоки маленькое и цена поддержки не высокая. Но только для маленьких программ. С ростом объема и время разработки и стоимость поддержки начинают катостофически быстро рости.
Также нужно помнить что скорость работы будет низкая, а потребление памяти высоким хоть ты что делай.
У правильно сделанных статически типизированных языков время разрабоки маленькое и цена поддержки не высокая.
С ростом объема катастрофы не происходит.
Скорость работы в районе того что можно сделать на С++.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
P>>Скрипт разрабатывается значительно быстрее, чем программа, с этим ты тоже будешь спорить? WH>А с каких это пор скрипт не программа?
Программа, конечно. В своей реплике мне нужно было написать "чем программа на C++". Виноват, исправлюсь.
WH>Единственное о чем можно говорить это о скорости разработки и цене проддержки программы на разных языках.
Естественно. Одна из составляющих любого проекта — его бюджет. Почему-то в войнах за байты и микросекунды это постоянно игнорируется, по крайней мере, в КСВ.
WH>У С++ время разработки большое цена поддержки огромная. WH>В плюс можно записать то что можно сделать весьма шуструю программу. Но в процессе
Именно поэтому в нашем проекте C++ используется буквально в паре-тройке совсем уж низкоуровневых конструкций.
Здравствуйте, Privalov, Вы писали:
P>Естественно. Одна из составляющих любого проекта — его бюджет. Почему-то в войнах за байты и микросекунды это постоянно игнорируется, по крайней мере, в КСВ.
Здравствуйте, Privalov, Вы писали:
P>Но, как выясняется, вполне достаточно, чобы рассуждать, как правильно построить для незнакомого языка интерпретатор.
Я вроде как ничего о том, как его построить, не писал, нет ? Я лишь высказал некоторые соображения, касающиеся построения компиляторов (трансляторов) в прошлом и сейчас и соотнесения этого с размерами потребной памяти опять же в прошлом и сейчас.
P>>>Тут
. Так, на всякий случай.
PD>>Было, было. От нечего делать мы в аспирантские времена запрограммировали какой-то простенький расчет для Искра-124. Там было сколько-то регистров, а насчет ОП не помню, была ли вообще. Вот и крутились.
P>Вот именно. Повторю: те, кто подобное прошел, ресурсы не разбазаривают. Но и ту работу, которую может выполнить машина, не перекладывают на себя.
А те, кто не прошел — разбазаривают. И те, кто прошел, порой тоже.
P>>>В любом проекте есть часть, выполняющая основную работу и "группа поддержки": всякие утилиты, идущие по расписанию. Например, архивирование логов, закачка данных из внешнего источника....
PD>>Вот тут один любопытный момент возникает. PD>>С точки зрения экономии расходов заказчика и своего времени — да. PD>>А с точки зрения технологии программирования ? Науки информатики ? Можно ли оправдать экономией денег заказчика то, что эта программа делается вопреки их законам ?
P>Что значит "вопреки их законам"? Законам информатики?
Да. Теоретическм основам теории алгоритмов, структур данных и т.д.
>Использовав раз или два в своей практике goto, я их нарушил?
Не имеет отношения к вышесказанному.
>Или тем, что сказал: требования к памяти противоречат требованиям ко времени реакции на запрос?
А это один из законов. Но не все тут так просто.
P>Так денег действительно не хватит.
Я же сказал — этот аргумент серьезный, но к науке информатике отношения не имеет.
>И потом, нельзя нарушить законы.
Законы природы нарушить нельзя. А вот законы, сформированные человечеством для своей деятельности — за милую душу. И не только законы, подпадающие под УК. Построить мост с быками толщиной в спичку нельзя — рухнет. А вот построить его с быками шириной в полреки — можно, угрохать чертову прорву сил и средств, а в итоге получить решение, ничем не лучшее чем то, которое бы получилось на основе положений сопромата и т.д.
>Рекомендациям можно следовать, а можно и нет, все зависит от конкретных условий.
Законам сопромата можно не следовать, да. Древние их не знали, а их мосты до сих пор стоят. Но это лишь потому, что они потратили сил и средств намного больше, чем требовалось.
P>А обосновать выбор C++ в качестве языка для выполнения рутинных работ сможешь?
Смотря каких. Для работы в броузере, если это не ActiveX — не смогу и не буду. Зачем мне доказывать недоказуемое ? И когда это я предлагал тут С++ использовать ?
>Сколько систем видел, везде используются скрипты. Никто не жалуется.
Используются. Насчет не жалуется — а кто бы мог ? Мнение пользователя меня мало интересует, он не компетентен судить.
>Скрипт разрабатывается значительно быстрее, чем программа, с этим ты тоже будешь спорить?
Не буду. Но это плохонький аргумент. Он из той же серии — денег мало, сроки на носу и т.д. Он на побочные факторы жмет, а не на технологию.
PD>>Вот эту последнюю фразу мне мои оппоненты и не простят. В сущности, они же понимают, что делают неэффективно, что можно бы и получше. Но бюджет... но дедлайн но ... Вот и приходится писать не очень качественно. Сначала это самого раздражает. Надо бы посидеть, подумать, как это лучше сделать, потом время потратить на программирование и отладку. Но времени нет, а есть класс, а у него есть метод, вставил его — и готово.
P>Техзадание с заказчиком обсудили? Утвердили? В рамки укладываешься? Есть запас прочности по предельным нагрузкам раза в полтора-два? Где здесь, в таком случае, неэффективность?
Господи, ну уж это не надо. Привлекать тот факт. что заказчик подписал бумагу, в которой пусть даже прописаны характеристики, в качестве аргумента, что они должны быть такими исходя из возможностей техники — это уж слишком. С таким же успехом можно найти индейца племени Ориноко, никогда не видевшего автомобиля и подписать у него техзадание на создание самодвижущейся повозки, едущей со скоростью 40 км/час. Индеец будет в полном восторге, когда вы эту повозку ему представите — его лошадь и 20 км/час не давала
PD>>Черт его знает, что у него там внутри, у этого класса, и как работает этот метод, но работает же!
P>Инкапсуляция, однако. Или ты, разрабатывая классы, всем все показываешь?
Дело не в том, показываю я или нет. Дело в том, что применяя некий метод некоего класса надо не хвататься за этот класс и этот метод на том основании, что он решает задачу, а поинтересоваться — с какими затратами. Если у нас есть метод сортировки, то если он N*logN — это хорошо, если N^2 — может быть иногда приемлемо, а если N^3 — то это безобразие и ничего больше. И даже если сортируется массив на 100 элементов один раз в минуту — это все равно безобразие и ничего больше! И если в той же сортировке заводится дополнительный массив N^2, то это тоже безобразие. И линейный — тоже. А насколько я вижу, в очень многих случаях здесь в профильных форумах вопрос ставится так — а как мне это сделать ? И ответ — а вот так. И хорошо, если найдется специалист, который подскажет — это очень неэффективно. Вот тебе пример, хоть я там и не лучшим образом высказался.
PD>>Потом... о, потом происходит хорошо известное психологам событие. Человек постепенно втягивается в эту новую обстановку и начинает принимать ее правила игры.И больше всего его теперь раздражают те, кто эти новые правила не принял и время от времени напоминают ему — а помните, как раньше умели ?
P>Пример, как человек не принял новые правила игры. Некто, имея очень приличный опыт разработки на ЕС ЭВМ, перешел на PC. Знаешь, как он там ввод-вывод разрабатывал? Как для пакетного режима. Все документы вводятся пачками, пока пачку не ввел, закрыть программу нельзя. А вводятся данные не с перфоленты, а человеком. И хранятся в одном файле, в котором есть поле "тип записи" и некоторые другие служебные. Представляешь, каково было запросы к той базе данных строить? Весь прошлый опыт превратился в балласт. И теперь этот человек ностальгирует, наверно, по старым добрым временам, вместо того, чтобы начать разбираться в новых правилах.
Пример, конечно... Но ИМХО не вполне в тему. Вопрос здесь о построении UI. А это , действительно, при переходе от перфокарт к терминалу (а совсем не обязательно к ПК!) надо ломать на 100%. Тут унаследовать нельзя, разве что речь идет именно о пакетной обработке по характеру задачи. С перфокартами UI, по существу, не было, так что все надо осваивать с нуля.
PD>>а помните, как раньше Вы умели (это, конечно, не ко всем относится). И ему теперь во что бы то ни стало надо доказать, что те, кто ему это напоминают, решительно неправы, во всем неправы. И доказывая им эту неправоту, они ведь гораздо больше себе доказывают, что они были правы, перейдя в новую веру. Потому что как можно жить в новой вере. если в глубине души шевелится червячок, который то и дело напоминает (пусть даже подсознательно) — а ведь и ты когда-то умел! а может, все же надо признать, что то, что ты сейчас делаешь, не очень...
P>Какую веру, ты о чем?
Да обо всем, о чем писал. Не хочешь слова "вера" — изволь, новые принципы, новый подход, как угодно. Я отнюдь не имел в виду веру в религиозном смысле слова. Я просто имел в виду принятие неких принципов работы.
P>А как быть с этим: P>Не сотвори себе кумира зи начальника, знай, что ты и сам не дурак.
А это тут к чему ? Я вроде как начальников не обсуждал. Но впрочем, принимаю, в следующей модификации : "Не сотвори себе кумира из тех, кто задает правила игры в твоей области, помни, что и сам ты не дурак"
P>Все подвергай сомнению.
Так я и подвергаю . Подвергаю более или менее ставшие общепринятыми в определенных кругах концепции.
Уф! И с таким пониманием принципов работы ОС ты еще берешься что-то доказывать!
I>В Виндовсе в принципе невозможно гарантировать отсутствие замерзаний интерфейса даже если девелоперы будут идеальный код писать.
I>Все лишь в силу выбраной модели многозадачности. Например процесс с высоким приоритетом может ожидать освобождения объекта ядра который захвачен процессом с низким приоритетом который не может выполняться из за того что выполняется процесс со средним приоритетом
Процессы, батенька, не могут ожидать освобождения объектов ядра. Ни с каким приоритетом не могут. Потому что они сами не исполняются. Могут только потоки, которые в них исполняются, а этих потоков может быть несколько в процессе, и дело программиста организовать так, чтобы один (одни) потоки чего-то ждали, а другой(другие) обеспечивали работу UI, и организовать между этими потоками правильное взаимодействие.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Уф! И с таким пониманием принципов работы ОС ты еще берешься что-то доказывать!
Оговорка — процесс вместо потока.
I>>В Виндовсе в принципе невозможно гарантировать отсутствие замерзаний интерфейса даже если девелоперы будут идеальный код писать.
I>>Все лишь в силу выбраной модели многозадачности. Например процесс с высоким приоритетом может ожидать освобождения объекта ядра который захвачен процессом с низким приоритетом который не может выполняться из за того что выполняется процесс со средним приоритетом
PD>Процессы, батенька, не могут ожидать освобождения объектов ядра. Ни с каким приоритетом не могут. Потому что они сами не исполняются. Могут только потоки, которые в них исполняются, а этих потоков может быть несколько в процессе, и дело программиста организовать так, чтобы один (одни) потоки чего-то ждали, а другой(другие) обеспечивали работу UI, и организовать между этими потоками правильное взаимодействие.
Организуй не организуй, а инверсию приоритетов ты отменить не в силах.
Здравствуйте, Klatu, Вы писали:
K>Самые умные? Видел я сэмплы к VS SDK, и само VS API немало ковырял. Это полный приплызд, просто полнейший. K>Например, функция, которая принимает COM-интерфейс, но на самом деле интерфейс только видимость — функция лезет во внутренности объекта по указателю. Нормально, ага?
Нормально, потому что VS работает и аддоны для нее пишет много контор. Сравни с конкурентами ты поймешь в чем дело.
Здравствуйте, Ikemefula, Вы писали:
I>Нормально, потому что VS работает и аддоны для нее пишет много контор. Сравни с конкурентами ты поймешь в чем дело.
Ну, потроллим, пивко в крови просит(а Хамон, суко, кончился, и я зол — надо идти в супермаркет, целых 8 минут, а там холодно и мокро).
Ничего, что для Студии самый лучший аддон пишет... Производитель Идеи, ДжетБрэинс — те, кто делает пока что лучшую в мире IDE — но под джаву(а получается комбайн под все что угодно в смешении с любыми языками, в том числе и скриптовыми). Конечно, решарпер неплох, очень неплох, но от Идеи это только тень...
А без Решарпера Студия — УГ, что ни говори. Хотя, это только в сравнении с жабовскими IDE. В сранении с другими — МЕГА УГ все остальное.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Устраняется повышением приоритета всех нитей, захватывающих данный mutex, до одного и того же высокого значения на период удержания mutexa. Некоторые реализации mutex’ов делают это автоматически
M>>Это — практически единственное, о чем ты постоянно говорил. Потому что «мине не интиресна щито ви там гаварите и ссылки я ни читаю».
PD>Кривляться и паясничать — какие убедительные аргументы!
PD>>>...Я лишь высказал некоторые соображения, касающиеся построения компиляторов (трансляторов) в прошлом и сейчас и соотнесения этого с размерами потребной памяти опять же в прошлом и сейчас.
P>>При этом проигнорировав, скажем так, некоторые различия вежду ТурбоПаскалем и js.
PD>Нет, не проигнорировав, а просто не говоря об этом, поскольку это само собой разумееется. Я же не утверждал, что надо интерпретатор JS в 640 Кб запихнуть. Вопрос тоньше — соответствует ли увеличение потребности в ресурсах усложнению языка (если оно есть).
Угу. Только ты постоянно пытался сравнивать только компилятор (TP) и компилятор + выполняющуюся программу (JS в браузере).
А что, давай возбмем и запустим Photoshop, увидим что он жрет 200 метров и на том основании сделаем вывод, что C++ и Фтошоп — гуано, ведь TP умеет компилировать исходники в 2 метразх памяти за 0 секунд.
Вот такой вот у тебя уровень аргументации.
PD>>>А те, кто не прошел — разбазаривают. И те, кто прошел, порой тоже.
P>>Не факт. Во всяком случае, интерпретатор js не подтверждает твой тезис.
PD>Не знаю. Меня тут Мамут тысячекратно обвинял в том, что я не хочу заглянуть в исходники.
Предлагаю сначала показать мне, где я тебе предлагаю заглянуть в исходники, а только потом что-то об этих исходниках говорить
Все остальное скипнуто по вполне понятным причинам.
//////////////
PD>Об XML я говорил, имея в виду его как источник данных. Вот есть у тебя, к примеру. 1 Мб XML файл. Там строки, числа и т.д. Построили из него дерево. Сколько памяти это дерево должно занимать ?
Зависит от функционала модели и оптимизации. Может и в 1000 раз больше быть.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Это почему же ? Приоритеты-то я могу сам назначить
Это хорошо, если ты работаешь только со своими мутексами и только в юзермод.
А в общем случае тебе надо будет всего то подменить диспетчер в вындоусе
Судя по ссылкам на википедию ты вообще не в курсе дел. Ты бы хоть поинтересовался, как винда пытается бороться с инверсией приоритетов и почему в микрософте не сделали нормальную схему разрешения.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А вот контрпример. Показывают мне некую IDE, занимает 80 Мб без открытого солюшена, и говорят — смотри, как хорошо сделано. А я говорю — не очень-то хорошо. Да ты ничего не понимаешь, отвечают мне. Посмотри исходники и убедись.
Это ты просто не хочешь задуматься, а зачем там 80Мб. Это будто тебя прокатили на феррари со скоростью 30кмч и ты задаешься вопросом, а нафига в феррари такие мощные движки ставят.
А ты задумайся. Ну или хотя бы почитай те ссылки, что тут приводят.
Здравствуйте, Mamut, Вы писали:
M>А что, давай возбмем и запустим Photoshop, увидим что он жрет 200 метров и на том основании сделаем вывод, что C++ и Фтошоп — гуано, ведь TP умеет компилировать исходники в 2 метразх памяти за 0 секунд.
M>Пустой фотошоп спокойно отжирает 130 метров памяти. Компилятор С++ — гуано, однозначно.
PD>Слушай, не смеши. При чем тут компилятор ? У меня сейчас фотошоп не установлен, посмотреть не могу. Запусти на него dumpbin, а лучше Process Explorer, и посмотри, что там в этих 130 Мб. Там скорее всего несколько Мб кода (не считая, конечно, кода системных DLL), а остальное — либо массивы данных, либо ресурсы. Вот они там зачем в таком объеме для пустого фотошопа — это действительно вопрос, но уж никак не к С++, а к авторам фотошопа. Я тоже могу сделать приложение мастером VC++, добавить массив на 100 Мб и будет тебе 100 Мб памяти.
///////////////////////////////////////////////
Только вот 11 ноября он брал 130 Мб, а за прошедшие две недели у тебя увеличилось до 200. Подождем еще с месяц, авось и до 500 дойдет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Об XML я говорил, имея в виду его как источник данных. Вот есть у тебя, к примеру. 1 Мб XML файл. Там строки, числа и т.д. Построили из него дерево. Сколько памяти это дерево должно занимать ?
PD>Зависит от функционала модели и оптимизации. Может и в 1000 раз больше быть.
PD>//////////////
PD>
И что тебе не нравится ? Чуть дальше было объяснение подробное, а ты "разобраться невозможно"
Возможно у тебя какие то проблемы возникли с выделеной фразой
M>>А что, давай возбмем и запустим Photoshop, увидим что он жрет 200 метров и на том основании сделаем вывод, что C++ и Фтошоп — гуано, ведь TP умеет компилировать исходники в 2 метразх памяти за 0 секунд.
PD>Повторяешься. Я уже тебе ответил.
PD>/////////////////////////////////////////////// PD>http://rsdn.ru/forum/flame.comp/4034353.1.aspx
M>>Пустой фотошоп спокойно отжирает 130 метров памяти. Компилятор С++ — гуано, однозначно.
PD>>Слушай, не смеши. При чем тут компилятор ? PD>///////////////////////////////////////////////
Тебе подобрать коллекцию из твоих слов, где ты говоил только про компилятор TP, сравнивая его с Яваскриптом или сам найдешь?
На аналогичный вопрос «при чем тут компилятор» ты отмахнулся и продолжил гнуть свое.
Здравствуйте, Ikemefula, Вы писали:
I>Это хорошо, если ты работаешь только со своими мутексами и только в юзермод.
Ну-ну. Теперь уже и kernal-mode понадобился и ожидание неизвестно чьих мютексов
А впрочем, все это не самое главное. А самое главное тут вот что. Если GUI поток ожидает мютекса (а хоть бы и еще чего-то) и не принял меры по реагированию во время ожидания на возможный пользовательский ввод — автору нужно идти учить основы. Независимо от приоритетов.
Так что иди учи основы. Или задай свой вопрос в форуме по Win API.
I>А в общем случае тебе надо будет всего то подменить диспетчер в вындоусе
I>>Это хорошо, если ты работаешь только со своими мутексами и только в юзермод.
PD>Ну-ну. Теперь уже и kernal-mode понадобился и ожидание неизвестно чьих мютексов
PD>А впрочем, все это не самое главное. А самое главное тут вот что. Если GUI поток ожидает мютекса (а хоть бы и еще чего-то) и не принял меры по реагированию во время ожидания на возможный пользовательский ввод — автору нужно идти учить основы. Независимо от приоритетов.
PD>Так что иди учи основы. Или задай свой вопрос в форуме по Win API.
Пойду расскажу это авторам Фотошопа... И Unity3D... И еще Word'а (копи=пейст из Internet Explorer'а, ага). И еще... В общем, я повторяюсь. На всех трех ОСях GUI любого мало-мальски сложного приложения хоть раз до подвисал. Чудес не бывает.
А учить основы можно заставлять студентов на поделках уровня hello world.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Это хорошо, если ты работаешь только со своими мутексами и только в юзермод.
PD>Ну-ну. Теперь уже и kernal-mode понадобился и ожидание неизвестно чьих мютексов
Есть известная проблема — инверсия приоритетов. Ты про нее ни слухом ни духом.
PD>А впрочем, все это не самое главное. А самое главное тут вот что. Если GUI поток ожидает мютекса (а хоть бы и еще чего-то) и не принял меры по реагированию во время ожидания на возможный пользовательский ввод — автору нужно идти учить основы. Независимо от приоритетов.
Самое главное, ты и здесь понять не можешь. Проблема не в ожидании мютекса. Поток, который владеет (а не ожидает) мутексом, может спокойно спать в то время когда должен выполняться.
То есть, отзывчивость интерфейса напрямую зависит от устройства ядра системы.
Виндовс пытается обойти инверсию приоритетов таким способом — спящие потоки периодически пинаются на всякий случай, мало ли, вдруг они владеют объектами ядра которые кроме них используют и высокоприоритетные потоки.
Здравствуйте, Mamut, Вы писали:
M>Пойду расскажу это авторам Фотошопа... И Unity3D... И еще Word'а (копи=пейст из Internet Explorer'а, ага). И еще... В общем, я повторяюсь. На всех трех ОСях GUI любого мало-мальски сложного приложения хоть раз до подвисал. Чудес не бывает.
Не надо идти к авторам Фотошопа. Сходи лучше в форум Win API и задай вопрос, как правильно программировать ожидание в GUI потоках. Там вполне достаточно компетентных специалистов, чтобы объяснить тебе это.
Если же приложение подвисает, (и не из-за того, что ядро ОС отобрало процессор,например, некий поток с приоритетом 20 из System , работающий в режиме ядра ) — это лишь означает ошибку в написании кода.
M>>Пойду расскажу это авторам Фотошопа... И Unity3D... И еще Word'а (копи=пейст из Internet Explorer'а, ага). И еще... В общем, я повторяюсь. На всех трех ОСях GUI любого мало-мальски сложного приложения хоть раз до подвисал. Чудес не бывает.
PD>Не надо идти к авторам Фотошопа. Сходи лучше в форум Win API и задай вопрос, как правильно программировать ожидание в GUI потоках. Там вполне достаточно компетентных специалистов, чтобы объяснить тебе это.
Я прекрасно знаю, как программировать ожидание GUI в потоках. Только, в отличие от некоторых я наблюдаю реальный мир, а не теоретические измышления. Читать выделенное до полного понимания.
PD>Если же приложение подвисает, (и не из-за того, что ядро ОС отобрало процессор,например, некий поток с приоритетом 20 из System , работающий в режиме ядра ) — это лишь означает ошибку в написании кода.
Это может означать что угодно и не всегда — ошибку в написании кода.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>А в общем случае тебе надо будет всего то подменить диспетчер в вындоусе
PD>О господи!
Именно так. Представь себе простейшее приложение, которое ничего не ожидает — диаложек с одной лишь кнопкой.
Так вот, особенность системы виндовс состоит в том, что в определенных случаях ты эту кнопку ты нажать не сможешь при всем желании, потому что UI замерзает.
И никакое API здесь не поможет в т.ч. благодаря инверсии приоритетов.
Когда то в MSDN было демо приложение, которое запускало около 10 потоков самого низкого приоритета которые всего лишь копировали длинные файлы с места на место.
На старых компьютерах эта вещь приводила к тому, что винда практически морозилась. Сейчас ситуация немногим лучше, но решения проблемы нет и по сей день.
Здравствуйте, Ikemefula, Вы писали:
I>Есть известная проблема — инверсия приоритетов. Ты про нее ни слухом ни духом.
О господи!
PD>>А впрочем, все это не самое главное. А самое главное тут вот что. Если GUI поток ожидает мютекса (а хоть бы и еще чего-то) и не принял меры по реагированию во время ожидания на возможный пользовательский ввод — автору нужно идти учить основы. Независимо от приоритетов.
I>Самое главное, ты и здесь понять не можешь. Проблема не в ожидании мютекса. Поток, который владеет (а не ожидает) мутексом, может спокойно спать в то время когда должен выполняться.
Проблема в том, что поток GUI вообще не имеет права ожидать никакие синхрообъекты, не приняв меры к тому, чтобы обработать пользовательский ввод во время ожидания. Поэтому совершенно не важно, кто там какие объекты создал, владеет (мютекс) и т.д. Поток GUI может их ожидать, но только при условии. что если появится пользовательский ввод , то это ожидание должно быть прервано. Не дождавшись. Для этого специальная функция есть
И причина этого отнюдь не в инверсии приоритетов. И без нее , если не следовать этому правилу, проблем хватит. Что мне за дело, спит поток, захвативший мютекс или захватил его, не отпускает и работает при этом ? В любом случае поток GUI, тупо ожидающий этот мютекс, будет блокирован, а это никуда не годится, потому что он сможет выбирать сообщения и тем самым будет заморожен интерфейс..
Кстати, не только ожидание ему запрещено. Ему, к примеру, нельзя запустить свою собственную операцию на более или менее длительное время, без всякого ожидания. По той же причине. Запусти CopyFile на файл в 100 Мб — подвесишь интерфейс без каких бы то ни было мютексов. Или займись перемножением матриц. Вот эту ошибку чаще всего и делают. CopyFile на 1Мб — сойдет, а потом оказывается, что файл-то стомегабайтный.
И вообще в любом учебнике сказано — обработчик сообщения должен его обрабатывать как можно быстрее. Понятно, что ожидание с INFINITE этому противоречит.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Самое главное, ты и здесь понять не можешь. Проблема не в ожидании мютекса. Поток, который владеет (а не ожидает) мутексом, может спокойно спать в то время когда должен выполняться.
PD>Проблема в том, что поток GUI вообще не имеет права ожидать никакие синхрообъекты, не приняв меры к тому, чтобы
Еще раз — GUI из одной кнопки безо всякого ожидания да и кода вообще может замёрзнуть.
Так понятно ?
Соответсвенно рассуждения про ожидания всякие я скипнул.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не надо идти к авторам Фотошопа. Сходи лучше в форум Win API и задай вопрос, как правильно программировать ожидание в GUI потоках. Там вполне достаточно компетентных специалистов, чтобы объяснить тебе это.
Представь себе правильный, идеальный UI написаный тобой, из одного диаложка с одной кнопки в обработчике которой мега-фича — выход из приложения.
Т.е. никаких ожиданий ни от чего кроме цикла выборки сообщений.
Особенность Виндовса состоит в том, что это приложение может замёрзнуть В том числе из за того, что ктото где то чего то делает или не делает, ожидает или захватывает.
Здравствуйте, Mamut, Вы писали:
M>>>Пойду расскажу это авторам Фотошопа... И Unity3D... И еще Word'а (копи=пейст из Internet Explorer'а, ага). И еще... В общем, я повторяюсь. На всех трех ОСях GUI любого мало-мальски сложного приложения хоть раз до подвисал. Чудес не бывает.
PD>>Не надо идти к авторам Фотошопа. Сходи лучше в форум Win API и задай вопрос, как правильно программировать ожидание в GUI потоках. Там вполне достаточно компетентных специалистов, чтобы объяснить тебе это.
M>Я прекрасно знаю, как программировать ожидание GUI в потоках.
Не похоже. Одно дело — обсуждать ошибки, которые при этом сделаны, другое — заявлять, что это невозможно сделать как требуется в принципе.
К примеру, тот же Paste в Word или где-то еще. Исходников Word я не видел, поэтому все, что ниже в этом абзаце — мои предположения. Word должен взять с clipboard, а потом распарсить формат и построить свои структуры. Полагаю, что на clipboard не CF_TEXT, а что-то посложнее, может быть, даже собственный формат. Да еще OLE вмешался почти наверняка. Если там CF_TEXT да на 10 Кб — пройдет со свистом мгновенно, а если посложнее, да на приличный объем, да с внедрением по OLE — быстро не получается. Надо было это в отдельном потоке делать (а в основном вывести что-то вроде "Загружаю" или как-то комбинировать работу основного потока и вспомогательного(ых). Может, там что-то такое и делается, только написано это, видимо, не лучшим образом, поэтому основной поток иногда все же выполняет длительную операцию, в течение которой, естественно, интерфейс заморожен. Вот и все. Почему так — спроси MS. Может, потому. что начинался Word во времена Windows 3.1, когда и потоков не было, и OLE был в зародыше, и файлы были явно поменьше, может, они не переделали как следует, а положили заплату, которая вообще-то работает,но не всегда как надо.
>Только, в отличие от некоторых я наблюдаю реальный мир, а не теоретические измышления.
Если ты видишь ошибки в программах реального мира, то это и значит, что в них есть ощибки. Более ничего.
>Читать выделенное до полного понимания.
Ты все же не находишь, что такой тон выглядит довольно глупо ? Звучит так, как будто ты владеешь истиной в последней инстанции, а все, кто с тобой не согласен, должны над этим евангелием от Мамута медитировать с утра до ночи , пока не озарит их божественная благодать сей мудрости.
PD>>Если же приложение подвисает, (и не из-за того, что ядро ОС отобрало процессор,например, некий поток с приоритетом 20 из System , работающий в режиме ядра ) — это лишь означает ошибку в написании кода.
M>Это может означать что угодно и не всегда — ошибку в написании кода.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Проблема в том, что поток GUI вообще не имеет права ожидать никакие синхрообъекты, не приняв меры к тому, чтобы обработать пользовательский ввод во время ожидания. Поэтому совершенно не важно, кто там какие объекты создал, владеет (мютекс) и т.д. Поток GUI может их ожидать, но только при условии. что если появится пользовательский ввод , то это ожидание должно быть прервано. Не дождавшись. Для этого специальная функция есть
PD>http://img.meta.ua/rsdnsearch/?q=MsgWaitForMultipleObjects&mode=rank&group=N
Если бы ты попробовал писать под ОС РВ какую, то давно знал бы, почему популярны такие функции.
Это как раз следствие нерешенных проблем, в т.ч. инверсии приоритетов.
Здравствуйте, Ikemefula, Вы писали:
I>Именно так. Представь себе простейшее приложение, которое ничего не ожидает — диаложек с одной лишь кнопкой.
I>Так вот, особенность системы виндовс состоит в том, что в определенных случаях ты эту кнопку ты нажать не сможешь при всем желании, потому что UI замерзает.
Фууу... Мы о чем говорим-то ? О действиях, которые определены программой, или о том, что Windows при определенных условиях может поднять IRQL до заоблачных высот и не отпускать его (ну это вряд ли) или дать поработать потоку в процессе System с приоритетом 20 (а вот это вполне, я не раз видел ситуацию, когда System загружает процессор на 20-40%)?
I>И никакое API здесь не поможет в т.ч. благодаря инверсии приоритетов.
I>Когда то в MSDN было демо приложение, которое запускало около 10 потоков самого низкого приоритета которые всего лишь копировали длинные файлы с места на место.
I>На старых компьютерах эта вещь приводила к тому, что винда практически морозилась. Сейчас ситуация немногим лучше, но решения проблемы нет и по сей день.
Да, такое возможно. Но это опять лишь говорит о твоем непонимании основ.
Файлы копирует не поток. Поток лишь запускает операцию, и (если это синхронный ввод-вывод) ждет ее окончания. Операция же идет в ядре. Она спокойно может идти, когда процессор (предполагаю одно ядро для простоты) переключен на совсем иной поток из совсем иного процесса. Ядро асинхронно внутри себя и о потоке инициаторе вспомнит лишь тогда, когда надо будет ему вернуть результат, тогда ему APC поставят, чтобы контекст процессора переключить. А эти потоки, запустившие ввод-вывод, вообще ни кванта не получат, пока он не закончится, а поэтому ничего не могут сделать тут вообще. А то, что при этом в ядре не все хорошо сделано при таких нагрузках — да, такая проблема есть, но потоки-инициаторы тут решительно ни при чем.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Так вот, особенность системы виндовс состоит в том, что в определенных случаях ты эту кнопку ты нажать не сможешь при всем желании, потому что UI замерзает.
PD>Фууу... Мы о чем говорим-то ?
Мы говорим о времени отклика UI. Винда очень часто не может обеспечить этот отклик.
I>>На старых компьютерах эта вещь приводила к тому, что винда практически морозилась. Сейчас ситуация немногим лучше, но решения проблемы нет и по сей день.
PD>Да, такое возможно. Но это опять лишь говорит о твоем непонимании основ.
То есть Винда морозится потому что я чего то не понимаю ? Ну и ну.
PD>Файлы копирует не поток. Поток лишь запускает операцию, и (если это синхронный ввод-вывод) ждет ее окончания. Операция же идет в ядре.
Это и ежу понятно, такие банальности ты мог бы и опускать. Проблема в том, что вот такие операции морозят UI самых разных процессов и не только UI.
>А то, что при этом в ядре не все хорошо сделано при таких нагрузках — да, такая проблема есть
"не все хорошо сделано " — это, например, инверсия приоритетов.
Пользуйся нормальными терминами, лично мне не ясно, какой смысл ты вкладываешь в "не все хорошо сделано".
I>Если бы ты попробовал писать под ОС РВ какую, то давно знал бы, почему популярны такие функции.
I>Это как раз следствие нерешенных проблем, в т.ч. инверсии приоритетов.
Нет, это следствие того, что, во-первых, windows не есть ОС реального времени (это к ядру относится), а во-вторых, в ОС РВ (я с ней знаком и работал) не было программирования, управляемого сообщениями (это к GUI относится). Модель не та, банально. Нельзя же заморозить интерфейс консольного приложения командной строки даже в Windows — приложение банально выведет сообщение "Работаю" хоть на полчаса — и никаких проблем, не должно оно на действия пользователя (ну разве Ctrl-C) реагировать.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Это как раз следствие нерешенных проблем, в т.ч. инверсии приоритетов.
PD>Нет, это следствие того, что, во-первых, windows не есть ОС реального времени (это к ядру относится),
"не есть ОС реального времени" включает в себя например проблему с инверсией приоритетов.
>Нельзя же заморозить интерфейс консольного приложения командной строки даже в Windows — приложение банально выведет сообщение "Работаю" хоть на полчаса — и никаких проблем, не должно оно на действия пользователя (ну разве Ctrl-C) реагировать.
Здравствуйте, Ikemefula, Вы писали:
PD>>Фууу... Мы о чем говорим-то ?
I>Мы говорим о времени отклика UI. Винда очень часто не может обеспечить этот отклик.
Мы говорим о времени отклика UI приложения по причине, определяемой этим приложением, по причине, связанной с тем, как это приложение устроено. У меня не было и нет никакого желания обсуждать внутренности Windows.
PD>>Да, такое возможно. Но это опять лишь говорит о твоем непонимании основ.
I>То есть Винда морозится потому что я чего то не понимаю ? Ну и ну.
Нет, это ты не понимаешь, почему она морозится.
PD>>Файлы копирует не поток. Поток лишь запускает операцию, и (если это синхронный ввод-вывод) ждет ее окончания. Операция же идет в ядре.
I>Это и ежу понятно, такие банальности ты мог бы и опускать. Проблема в том, что вот такие операции морозят UI самых разных процессов и не только UI.
Еще бы. Напиши драйвер, который крутит while(1); и все заморозишь.
>>А то, что при этом в ядре не все хорошо сделано при таких нагрузках — да, такая проблема есть
I>"не все хорошо сделано " — это, например, инверсия приоритетов.
I>Пользуйся нормальными терминами, лично мне не ясно, какой смысл ты вкладываешь в "не все хорошо сделано".
Я не собирался обсуждать, как внутри устроена Windows, ты меня втравил в это обсуждение со своим приоритетами и инверсиями. Еще менее я намерен обсуждать, что там в ядре хорошо и что нет. Но все это не имеет отношения к тому. что есть в приложении 3 кольца. А там есть правила по программированию интерфейса и ожиданию в GUI потоках, которые обеспечивают создание корректно работающих приложений, разумеется, при условии, что во время их работы Windows или драйвер не сбрендит и не начнет крутить вышеуказанный цикл. Я могу в 3 кольце играть с приоритетами и корректно программировать ожидание, но я совершенно не в состоянии изменить IRQL даже до 1, а при IRQL>0 все приоритеты 3 кольца — позабыть и забросить. Вот и все.
На этом и закончим. Я в конце концов не специалист по ядру и драйверам, есть форум, иди туда и спрашивай. А по 3 кольцу — в Win API форум, там я могу и поучаствовать, но учти, что "элегантный" переход от работы с сообщениями к прблемам ядра там не пройдет — там не любять всего, что к тематике не относится.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я не собирался обсуждать, как внутри устроена Windows, ты меня втравил в это обсуждение со своим приоритетами и инверсиями.
Втравил, да, что бы получить от тебя информацию о тебе самом
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>К примеру, тот же Paste в Word или где-то еще. Исходников Word я не видел, поэтому все, что ниже в этом абзаце — мои предположения. Word должен взять с clipboard, а потом распарсить формат и построить свои структуры. Полагаю, что на clipboard не CF_TEXT, а что-то посложнее, может быть, даже собственный формат. Да еще OLE вмешался почти наверняка. Если там CF_TEXT да на 10 Кб — пройдет со свистом мгновенно, а если посложнее, да на приличный объем, да с внедрением по OLE — быстро не получается. Надо было это в отдельном потоке делать (а в основном вывести что-то вроде "Загружаю" или как-то комбинировать работу основного потока и вспомогательного(ых).
Это не всегда поможет. Если сильно нагрузить IPC, то UI замерзает хоть ты что хошь делай.
Тяжелое наследство от предыдущих версий.
PD>Ты все же не находишь, что такой тон выглядит довольно глупо ? Звучит так, как будто ты владеешь истиной в последней инстанции, а все, кто с тобой не согласен, должны над этим евангелием от Мамута медитировать с утра до ночи , пока не озарит их божественная благодать сей мудрости.
Ты же в КСВ Это форум для тех кто не прочь посражаться и выпусть пар.
M>Нет. Не нахожу. В качестве носителя истинной истины выступаешь тут только ты.
M>
M> Если GUI поток ожидает мютекса (а хоть бы и еще чего-то) и не принял меры по реагированию во время ожидания на возможный пользовательский ввод — автору нужно идти учить основы. Независимо от приоритетов.
M>Так что иди учи основы. Или задай свой вопрос в форуме по Win API.
Ну и что ? Или ты считаешь, что здесь что-то неверно? То есть можно ожидать в GUI потоке и не принять эти меры ? Если считаешь — то это в некотором противоречии с тем, что ты писал, будто знаешь, как писать ожидание в GUI потоке. А если это верно, а некий автор этого не знает, то ему надо учить основы. Что я ему еще могу посоветовать-то ?
M>Твоя общая позиция в этих спорах: «все, кто пишут программы, что мы тут обсуждаем, тупые идиоты, один я знаю, как надо и студенты у меня легко это показывают»
Опять передергивания пошли. Надоело. Какие все ? Я всего лишь Ikemefula объяснял, что он не знает. Я кого-то идиотом хоть раз назвал ? Я хоть где-то написал, что я один знаю, а больше никто ? Где ?
Врать-то зачем ? Неужели, чтобы доказать свою точку зрения, надо обязательно прибегать к столь примитивному вранью ?
Оно ведь, само по себе (вранье это) заставляет сильно засомненваться в справедливости твоих утверждений, даже ничего не зная об их сути. Потому что если для их отстаивания нужно лгать, то это само по себе ставит их под сомнение.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>К примеру, тот же Paste в Word или где-то еще. Исходников Word я не видел, поэтому все, что ниже в этом абзаце — мои предположения. Word должен взять с clipboard, а потом распарсить формат и построить свои структуры. Полагаю, что на clipboard не CF_TEXT, а что-то посложнее, может быть, даже собственный формат. Да еще OLE вмешался почти наверняка. Если там CF_TEXT да на 10 Кб — пройдет со свистом мгновенно, а если посложнее, да на приличный объем, да с внедрением по OLE — быстро не получается. Надо было это в отдельном потоке делать (а в основном вывести что-то вроде "Загружаю" или как-то комбинировать работу основного потока и вспомогательного(ых).
I>Это не всегда поможет. Если сильно нагрузить IPC, то UI замерзает хоть ты что хошь делай.
I>Тяжелое наследство от предыдущих версий.
PD>>Ты все же не находишь, что такой тон выглядит довольно глупо ? Звучит так, как будто ты владеешь истиной в последней инстанции, а все, кто с тобой не согласен, должны над этим евангелием от Мамута медитировать с утра до ночи , пока не озарит их божественная благодать сей мудрости.
I>Ты же в КСВ Это форум для тех кто не прочь посражаться и выпусть пар.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Опять передергивания пошли. Надоело. Какие все ? Я всего лишь Ikemefula объяснял, что он не знает. Я кого-то идиотом хоть раз назвал ? Я хоть где-то написал, что я один знаю, а больше никто ? Где ?
Представь себе, ты на форуме преподавателей основ программирования.
Тут приходит некто и говорит "Преподавание основ программирования нынче безалаберное, никто толком не может ничего объяснить студентами."
I>>Тут приходит некто и говорит "Преподавание основ программирования нынче безалаберное, никто толком не может ничего объяснить студентами."
I>>Какая будет реакция посетителей ?
PD>От посетителей зависит. Лично я — попрошу аргументы, с которыми, возможно, соглашусь, а может и нет. А почему бы не послушать мнение человека , даже если я о нем ничего не знаю ? Есть такое понятие — профессиональный кретинизм, слышал, наверное ? Так вот у этого некто как минимум его нет, потому что он не преподаватель, а со стороны. Пусть скажет, что он думает. Если явная чепуха — спорить не буду, пропущу мимо ушей. А вдруг совсем не чепуха ?
Тогда почему ты не слушаешь нас, а несешь всякую чушь про компиляторы и GIf/JPEG, не пытаясь даже предпринять даже малейшие попытки понять, о чем тебе говорят?
Здравствуйте, Mamut, Вы писали:
M>>>Так что иди учи основы. Или задай свой вопрос в форуме по Win API. M>>>[/q]
PD>>Ну и что ? Или ты считаешь, что здесь что-то неверно? То есть можно ожидать в GUI потоке и не принять эти меры ? Если считаешь — то это в некотором противоречии с тем, что ты писал, будто знаешь, как писать ожидание в GUI потоке. А если это верно, а некий автор этого не знает, то ему надо учить основы. Что я ему еще могу посоветовать-то ?
M>Твоя точка зрения — сугубо академическая, к реальному миру имеющая мало отношения.
А можно все же указать, что в той фразе неверно ? Вместо голословных утверждений — твоя мол, точка зрения академическая ? И потом — я же тебе предлагал пойти в форум по Win API и там задать вопрос (или не тебе, а Икемефула, забыл уже, если ему, то предлагаю тебе сейчас). Там все же специалисты есть, или тоже одна академическая точка зрения ? Только там демагогии не любят, имей в виду. Может все же пойдешь, а ?
Ну а насчет академичности моей точки зрения — ты слишком мало знаешь о том, что я писал, чтобы судить.
M>«Я не собираюсь читать, что вы мне пишите,
Читал.
>я не собираюсь открывать ни одной ссылки что вы мне присылаете
Не собираюсь, верно. Объяснил вот здесь сегодня почему
>я не собираюсь понимать ни одной цифры, что вы мне пишите.
Передергивание.
>НО! У меня есть мнение по преметам,в которых я абсолютно не разбираюсь, поэтому я буду выборочно брать из ваших сообщений то, что мне захочется, создавать собственные ветряные мельницы и успешно с ними бороться. А на ваши доводы мне глубоко наплевать с высокой колокольни».
Ну а это никаким комментариям не подлежит, разве что вот этому
PD>>Оно ведь, само по себе (вранье это) заставляет сильно засомненваться в справедливости твоих утверждений, даже ничего не зная об их сути. Потому что если для их отстаивания нужно лгать, то это само по себе ставит их под сомнение.
M>Если бы ты читал хоть одно мое утвержедение M>Если бы ты читал хоть чьи-либо утвержддения M>Если бы ты перешел хоть по одной ссылке, что тебе показали M>Если бы ты попытался разобраться хоть в чем-то, о чем тебе говорили
M>То тогда я бы согласился, что я вру.
Если бы ты не повторял десять раз одно и то же, а попробовал понять, какие аргументы я принимаю, а какие нет, какие аргументы я выдвигаю, то тебе не пришлось бы десять раз писать одно и то же.
M>Но ты же веришь только голосам в своей голове
Здравствуйте, Mamut, Вы писали:
M>Тогда почему ты не слушаешь нас, а несешь всякую чушь про компиляторы и GIf/JPEG, не пытаясь даже предпринять даже малейшие попытки понять, о чем тебе говорят?
PD>Да хватит меня аббревиатурами пугать. Ты бы уж хоть подумал прежде чем их список сюда постить. JPEG 10 лет назад не было ? Под JPEG сколько памяти-то надо ? Flash на чем написан-то ?
M>Что из этого умеет 4.7 на 6 мегабайтах? Кусок (и то не полный) HTML'я, кусок (и то неполный) CSS, кусок (и то неполный) Javascript'а... И все. PD>Конечно, JPEG и GIF не умеет. (тут я забыл смайлик поставить, зря)
Здравствуйте, Mamut, Вы писали:
M>>>Тогда почему ты не слушаешь нас, а несешь всякую чушь про компиляторы и GIf/JPEG, не пытаясь даже предпринять даже малейшие попытки понять, о чем тебе говорят?
PD>>Я несу чушь про GIF/JPEG ?
PD>>Вот все, что я о них сказал
PD>>http://rsdn.ru/forum/flame.comp/4051285.aspx
PD>>>Да хватит меня аббревиатурами пугать. Ты бы уж хоть подумал прежде чем их список сюда постить. JPEG 10 лет назад не было ? Под JPEG сколько памяти-то надо ? Flash на чем написан-то ?
M>>>Что из этого умеет 4.7 на 6 мегабайтах? Кусок (и то не полный) HTML'я, кусок (и то неполный) CSS, кусок (и то неполный) Javascript'а... И все. PD>>>Конечно, JPEG и GIF не умеет. (тут я забыл смайлик поставить, зря)
PD>>Ну и Privalov'у кое что мимоходом
PD>>http://rsdn.ru/forum/flame.comp/4046330.aspx
PD>>Вот и все.
PD>>Так что поздравляю вас, гражданин, соврамши. В очередной раз.
M>А тебе не кажется странным, что в том списке в четыре раза больше технологий, которых не было в 2000-м году, чем только GIF и JPEG.
Нет. Мне это не кажется странным. Мне кажется странным другое. Ты мне четко заявил — я несу чушь про компиляторы (о них не буду, ладно), и GIF/JPEG. От этих слов не отопрешься — они выше прямо тут. Я тебя уличаю в явной лжи. Ты ничего возразить не можешь, но вместо того, чтобы извиниться, переводишь разговор на 4x кратное количество технологий.
Вот это мне и кажется странным. Неприличным. И недопустимым.
Извини, но больше ни дискутировать, ни читать твои сообщения в этом треде не буду. Расценивай как хочешь.
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>Но все же существует разница между ТурбоПаскалем и js.
PD>Я одно не пойму — с чего вы все решили, что я этой разницы не вижу и требую уложить нынешний интерпретатор js в 640 Кб ? Я привожу TP в качестве некоей реперной точки для рассуждений, вот и все.
Не ясно, как увязать TP c JS.
Ты до сих пор никак не обосновал этот переход, не подкрепил буквально ничем, кроме многократных повторений.
Были выпросы — ты везде увильнул то на BC, то на фокспро, то на Ямаху, то еще куда.
M>>А тебе не кажется странным, что в том списке в четыре раза больше технологий, которых не было в 2000-м году, чем только GIF и JPEG.
PD>Нет. Мне это не кажется странным. Мне кажется странным другое. Ты мне четко заявил — я несу чушь про компиляторы (о них не буду, ладно), и GIF/JPEG. От этих слов не отопрешься — они выше прямо тут. Я тебя уличаю в явной лжи. Ты ничего возразить не можешь, но вместо того, чтобы извиниться, переводишь разговор на 4x кратное количество технологий.
К буквоедству прибегают, когда аргументы заканчиваются полностью. Почему твои слова — чушь, я уже описал.
PD>Вот это мне и кажется странным. Неприличным. И недопустимым.
Странным, неприличным и недопустимым является придирание к словам, выдирание из списка фаткот только того, что тебе нужно и т.п.
PD>Извини, но больше ни дискутировать, ни читать твои сообщения в этом треде не буду. Расценивай как хочешь.
Угу. Ты и до этого их не читал, так что невелика потеря.
Здравствуйте, Mamut, Вы писали:
I>>>P.S. Пока не залез в твой профайл мне все все время казалось что имею дело с подростком — вчерашним студентом.
PD>>который каким-то образом ухитрился работать в 80-е годы на ТурбоПаскале.
PD>>
M>Обрати внимание на поведение. Ему пдевать, что ему указывают на гигантские дыры в его рассуждениях (и не мение гигантские лакуны в его знаниях). Он предпочитает из всего сообщения выбрать одно предложение и ответить на него.
Он просто уже сыт по горло всей этой дискуссией, а потому очень хочет участие в ней закончить. Но он не любит передергиваний и не удержался, чтобы не показать автору предыдущегго сообщения на очередное...
I>>>>P.S. Пока не залез в твой профайл мне все все время казалось что имею дело с подростком — вчерашним студентом.
PD>>>который каким-то образом ухитрился работать в 80-е годы на ТурбоПаскале.
PD>>>
M>>Обрати внимание на поведение. Ему пдевать, что ему указывают на гигантские дыры в его рассуждениях (и не мение гигантские лакуны в его знаниях). Он предпочитает из всего сообщения выбрать одно предложение и ответить на него.
PD>Он просто уже сыт по горло всей этой дискуссией, а потому очень хочет участие в ней закончить. Но он не любит передергиваний и не удержался, чтобы не показать автору предыдущегго сообщения на очередное...
Где здесь передергивания?
Тебе был даден огромый список того, что нынешний бровзер должен уметь в обязательном порядке(это кстати говоря и есть реперные точки).
Что делаешь ты ?
Ты пишешь "Да хватит меня аббревиатурами пугать" и соскакиваешь на Jpeg/Gif
Ты мог пройтись по всему списку, но вместо этого придумал отписку — Jpeg/Gif.
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>При этом проигнорировав, скажем так, некоторые различия вежду ТурбоПаскалем и js.
PD>Нет, не проигнорировав, а просто не говоря об этом, поскольку это само собой разумееется. Я же не утверждал, что надо интерпретатор JS в 640 Кб запихнуть.
А если само собой разумеется, то почему в качестве аргумента ущербности js ты приводишь ТурвоПаскаль? Ссылки даже искать не надо, их полно. Вон у Mamut-а целое собрание
ссылок.
PD>Вопрос тоньше — соответствует ли увеличение потребности в ресурсах усложнению языка (если оно есть).
PD>Не знаю. Меня тут Мамут тысячекратно обвинял в том, что я не хочу заглянуть в исходники. А я действительно не хочу. Зачем ?
Наверное, чтобы у тебя появились какие-то аргументы в пользу прожорливости js в Chrome.
PD>2. Я их анализирую и, потрясенный их мощью, изяществом и оптимальностью, признаю себя неправым. Тоже не реально и по той же причине.
Нереально, что признаешь себя неправым? Извини, не удержался.
PD>Речь идет, как наверное понял, о VS2010 vs. VS 2008. Правда, сомневаюсь, что мне MS покажет исходники
Не поверишь, не понял. Студия не является моим основным инструментом. У меня 2005. Тяжелее шестерки. IDEA с небольшим проектиком из пары десятков классов сразу 200 метров отбирает, и что? Нормально работает, без тормозов, и никому не мешая, в т. ч. Chrome, с которого я читаю сейчас этот форум.
Во времена MS-DOS, работая с продуктами MS, я использовал make-файлы и текстовый редактор QEdit. PWB запускал крайне редко, в основном, чтобы построить новый проект. Остальное все руками. Ну очень он не нравился мне.
PD>Применение неподходящего контейнера есть нарушение закона. Разумееется, не законов поведения этого контейнера, а законов теории алгоритмов, которая определяет, какой алгоритм (и соответствующий контейнер, но это частности) должен применяться для решения той или иной задачи.
Для решения одной и той же задачи могут применяться различные алгоритмы и различные контейнеры. Причем оптимальность зависит от множества условий. Ваш К. О.
PD>Зачем, спрашивается, тысячи и тысячи математиков и программистов эти алгоритмы и структуры данных анализировали и искали наилучшее решение, если можно наивным программированием запустить нечто, на порядок по времени/памяти хуже, лишь бы работало.
Алгоритмы не прибиты гвоздями к задачам. Первая, пилотная, версия проекта, именно так и реализуется, наивным программированием. Главное преимущество такого подхода — скорость разработки. И вот если станет ясно, что данный подход не решает поставленную задачу, то с помощью наивного подхода получается значительная экономия средств.
PD>Зачем Кнут quicksort придумал и зачем ее потом годами анализировали — пузырек прекрасно работает и всегда дает правильный результат. Вот это и есть нарушение законов. Это и есть постройка моста с быками в полреки.
Самая популярная тема в КСВ — quicksort vs bubblesort. Win vs Lin курят.
Quicksort разработан не Кнутом, а Хоаром, о чем можно прочесть у самого Кнута, а также у Вирта и других авторов. И оптимизирует выполнение он не всегда. Помнишь, что у того же Кнута (или все же Вирта?) про особые случаи сказано? А, например, при обработке экспериментальных данных такое может вылезти когда угодно и сколь угодно часто. И что ты будешь делать? статистику собирать и на основании результата запускать quick или что-то другое? Но весь выигрыш от quick расходуется на статистику, а если еще окажется, что quick неприменим для данного набора, то будет еще хуже. Тупое применение quicksort — это и есть пренебрежение результатами, полученными Хоаром, Кнутом и другими.
PD>Допустим, что в этом случае это именно так. Но я вижу множество случаев, когда это далеко не так. А просто транжирят память без зазрения совести. PD>А если это так — почему я должен верить, что для v8 это так ? Потому что меня Мамут пытается в этом убедить ?
Но ты же твердо веришь в то, что это не так. Выше мы видели, что анализ ты проводить не хочешь, но продолжаешь стоять на своем.
P>>Поинтересуйся как-нибудь, почему прорывает водопровод, причем в одно и то же время.
PD>У кого ?
Во дворах, на улице. Как правило, весной и осенью.
>>Так что к его мнению ты будешь внимательно прислушиваться, и совершенно никого не интересует твое к этому мнению отношение.
PD>Буду. Если он мне скажет, что программа делает не то, что надо или не так — непременно буду. Но о том, какие средства употреблять и какие затраты памяти и т.д. должны быть — не ему говорить и не мне слушать.
Хороший, умный заказчик о таких вещах говорить не станет. Выше мы уже это обсудили.
P>>Еще раз: заказчик знает, что он хочет. Умный заказчик попросит техзадание от нескольких исполнителей, а потом еще и экспертам покажет.
PD>Это годится, когда есть разные разработчики, если одна команда может предложить решение, намного лучшее, чем другая. Если все предлагают решение одного качества, сообразуясь в основном не с тем, как это можно хорошо сделать, а в основном с тем, сколько заказчик на это готов потратить — мы получим отот всех одно и то же.
Нет. У команд отличаются взгляды на жизнь, на разработку. Точки зрения на продукт разные. Одно и то же никак не получится. Вспомни, сколько народу писало бухгалтерии в 90-е. Они что, все одинаковые? И так везде.
PD>>>Дело в том, что применяя некий метод некоего класса надо не хвататься за этот класс и этот метод на том основании, что он решает задачу, а поинтересоваться — с какими затратами.
P>>Такие вещи везде и всегда зависят от конкретных условий. Ты, наверное, знаешь, что 100 элементов пузырьком сортируются столь же эффективно, как и быстрым алгоритмом.
PD>Я же и сказал — иногда приемлемо.
>>А иногда выделение массива дает выигрыш в скорости. пример — быстрая сортировка на Фортране IV.
PD>Ты о том, что quicksort требует стека и его на Ф4 динамически не выделить ? Согласен, но это лишь следствие ограничений Ф4.
То есть это не считается аргументом? Но ведь память — реальная — выделяется! Причем в расчете на худший случай. Во избежание. И неважно, статически или динамически.
Я думал, ты мне здесь расскажешь, как организовать рекурсию на Ф4. я пробовал, работает, но жутко тормозно. в качестве решения для quicksort не подходит. Лучше массив.
P>>Но все же существует разница между ТурбоПаскалем и js.
PD>Я одно не пойму — с чего вы все решили, что я этой разницы не вижу и требую уложить нынешний интерпретатор js в 640 Кб ? Я привожу TP в качестве некоей реперной точки для рассуждений, вот и все.
Дак для js он в этом качестве, как я понимаю, не подходит.
P. S. Букв становится все больше, если где контекст нарушил — не со зла. впрочем, он легко восстанавливается.
Здравствуйте, Mamut, Вы писали:
I>>>>>P.S. Пока не залез в твой профайл мне все все время казалось что имею дело с подростком — вчерашним студентом.
PD>>>>который каким-то образом ухитрился работать в 80-е годы на ТурбоПаскале.
PD>>>>
M>>>Обрати внимание на поведение. Ему пдевать, что ему указывают на гигантские дыры в его рассуждениях (и не мение гигантские лакуны в его знаниях). Он предпочитает из всего сообщения выбрать одно предложение и ответить на него.
PD>>Он просто уже сыт по горло всей этой дискуссией, а потому очень хочет участие в ней закончить. Но он не любит передергиваний и не удержался, чтобы не показать автору предыдущегго сообщения на очередное...
M>Где здесь передергивания?
Да просто не мог Икемефула, прочитав мои первые сообщения, где я говорил о ТурбоПаскале Ямахи с 64 Кб памяти, предположить, что я вчерашний студент.
M>
M>Тебе был даден огромый список того, что нынешний бровзер должен уметь в обязательном порядке(это кстати говоря и есть реперные точки).
M>Что делаешь ты ?
M>Ты пишешь "Да хватит меня аббревиатурами пугать" и соскакиваешь на Jpeg/Gif
M>Ты мог пройтись по всему списку, но вместо этого придумал отписку — Jpeg/Gif.
Извини, но про то, что я несу чушь про GIF/JPEG, сказал ты, а не я. Я бы о них и говорить не стал — было бы о чем, подумаешь — вывод картинки на экран.
А вообще все наша дискуссия выглядит так.
Ребятки, чего это ваш агрегат со скоростью 60 км/час движется ?
Ничего ты не понимаешь! Там кардан, подвеска, двигатель, коробка, датчики , колеса , шатун и кривошип.
Ребятки, чего это ваш агрегат со скоростью 60 км/час движется ?
Да ты только посмотри, как кривошип устроен (дальше подробное описание работы кривошипа со ссылками на уважаемые источники))
Ребятки, чего это ваш агрегат со скоростью 60 км/час движется ?
Да ты пойми. что двигатель использует энергию сгорания бензина, а это сгорание регулируется такими-то и такими-то законами термодинамики (дальше описание всех этих законов, со ссылками на уважаемые источники)
Ребятки, чего это ваш агрегат со скоростью 60 км/час движется ?
Да ты пойми, что для правильной работы датчиков нужно, чтобы сигналы передавались (не знаю, что уж там должно куда передаваться, но опять же со ссылками на уважаемые источники)
Ребятки, чего это ваш агрегат со скоростью 60 км/час движется ?
Да ты вообще ничего не понимаешь. Ты хоть представляешь себе, как коробка передач устроена ? Не представляешь ? У тебя гигантские лакуны в твоих познаниях. И дыры в рассуждениях.
Ребятки, чего это ваш агрегат со скоростью 60 км/час движется ?
С тобой вообще невозможно разговаривать. Что тебе ни скажи — как об стенку горох! Я тебе десятки аргументов привел, а от тебя все отскакивает.
Ребятки, кончайте мне морочить голову коробками передач, датчиками и кривошипами, колесами, термодинамикой и прочим и прочим и прочим. Я о них не знаю и знать не хочу. Чкалов в 1937 году перелетел через Северный Полюс в Америку, самолет АНТ-25, скорость 165 км/час. Вот когда ваша конструкция будет хотя бы с такой скоростью двигаться, причем не ездить, а летать, тогда и обсудим, какие там должны быть конструкторские решения. А до тех пор идите-ка вы со своей нелетающей повозкой куда хотите...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ребятки, кончайте мне морочить голову коробками передач, датчиками и кривошипами, колесами, термодинамикой и прочим и прочим и прочим. Я о них не знаю и знать не хочу. Чкалов в 1937 году перелетел через Северный Полюс в Америку, самолет АНТ-25, скорость 165 км/час. Вот когда ваша конструкция будет хотя бы с такой скоростью двигаться, причем не ездить, а летать, тогда и обсудим, какие там должны быть конструкторские решения. А до тех пор идите-ка вы со своей нелетающей повозкой куда хотите...
PD>А вообще все наша дискуссия выглядит так.
PD>Ребятки, чего это ваш агрегат со скоростью 60 км/час движется ? PD>Ничего ты не понимаешь! Там кардан, подвеска, двигатель, коробка, датчики , колеса , шатун и кривошип.
Ваша дискуссия выглядит так:
Ребятки, чего это ваш агрегат со скоростью 60 км/час движется ?
Так это, траффик, машин много стало в 21 веке, быстрее сложно в городе ездить, даже на феррари.
Неее. Ничего не знаю, я еще 20 лет назад из жигулей 70кмч под горку выжимал, говно ваша феррари.
Здравствуйте, genre, Вы писали:
G>Ваша дискуссия выглядит так: G>Ребятки, чего это ваш агрегат со скоростью 60 км/час движется ? G>Так это, траффик, машин много стало в 21 веке, быстрее сложно в городе ездить, даже на феррари. G>Неее. Ничего не знаю, я еще 20 лет назад из жигулей 70кмч под горку выжимал, говно ваша феррари.
А чего это ваша "феррари" все же под горку со скоростью 60 км/час движется ? Там, где нет трафика, нет машин, да и дорога стала намного шире ?
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>Где здесь передергивания?
PD>Да просто не мог Икемефула, прочитав мои первые сообщения, где я говорил о ТурбоПаскале Ямахи с 64 Кб памяти, предположить, что я вчерашний студент.
Если совсем точно, я полез смотреть профайл когда увидел что ты про турбо паскаль пишешь, а до того считал тебя вчерашним студентом. По одной простой причине — сам писал на TP(+ BP,TC,BC) где то 15 лет назад.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не совсем так. TP приведен не для доказательства ущербности js (точнее, интерпретатора с него), а для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае. Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб, причем с самых разных языков, и при на порядки более медленных машинах, и вдруг оказалось, что для языка, который, в общем-то, не сложнее намного предыдущих, потребовалось памяти намного больше — что-то здесь подозрительно.
Уже в который раз — не для языка, а для задач которые решаются этим языком.
На Турпбопаскале, даже для ямахи, можно написать интерпретатор джаваскрипта.
Здравствуйте, Pavel Dvorkin, Вы писали:
G>>Ваша дискуссия выглядит так: G>>Ребятки, чего это ваш агрегат со скоростью 60 км/час движется ? G>>Так это, траффик, машин много стало в 21 веке, быстрее сложно в городе ездить, даже на феррари. G>>Неее. Ничего не знаю, я еще 20 лет назад из жигулей 70кмч под горку выжимал, говно ваша феррари.
PD>А чего это ваша "феррари" все же под горку со скоростью 60 км/час движется ? Там, где нет трафика, нет машин, да и дорога стала намного шире ?
Тесты видел ?
"Феррари", ака JS V8 рвет в клочья _всех_ нынешних конкурентов, не говоря о прошлых версиях.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Задача — совеременным программистам написать компилятор с языка в точности того, каким был ТурбоПаскаль в 198x году! И IDE в точности такую же. Ни на йоту больше. Средства для написания использовать какие угодно.
PD>Сколько памяти потребуют ?
PD>
Не поверишь — еще меньше, чем это было нужно раньше.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет, не буду. Я уже все аргументы изложил. Коротко — непропорциональность роста потребления ресурсов и роста возможностей.
Ответь хотя бы вот на это: G>Почему когда тебе дают ответ, что современный популярный веб сайт это огромное количество кода оперирующего огромным количеством данных, ты это игнорируешь? G>Почему когда тебе дают ответ, что современная ИДЕ это не просто текстовый редактор, а, например, она держит в памяти AST всего(зачастую огромного) проекта в любой момент времени (да и апдейтит его на каждый чих и весьма хитро меняет его), ты это игнорируешь? G>итд.
Вопрос, почему ты игнорируешь, то что тебе говорят люди которые более компетентны в этом вопросе чем ты?
PD>>Задача — совеременным программистам написать компилятор с языка в точности того, каким был ТурбоПаскаль в 198x году! И IDE в точности такую же. Ни на йоту больше. Средства для написания использовать какие угодно.
PD>>Сколько памяти потребуют ?
PD>>
I>Не поверишь — еще меньше, чем это было нужно раньше.
Не поверю. Раньше — было 64 Кб (TP 1.0), потому что больше на машине и не было. Во сколько берешься уложить ? Не забудь — исходный текст программы, редактор этого текста и исполняемый код должны разместиться в этих же 64 Кбайтах. Никаких дисковых операций.
Здравствуйте, Pavel Dvorkin, Вы писали:
G>>Так рост потребления возможностей ты померять не можешь! Во-первых потому что ты просто не знаешь эти новые возможности (и слышать об этом не хочешь)
PD>Я (как пользователь) их на экране вижу. И роста их на порядок — не вижу.
Так тебе объясняют, что видишь ты лишь вершину айсберга. Ну прислушайся же к людям.
Здравствуйте, genre, Вы писали:
G>Вопрос, почему ты игнорируешь, то что тебе говорят люди которые более компетентны в этом вопросе чем ты?
Потому что люди, которые считают себя более кометентными, вместе с этой компетентностью приняли правила игры в этой отрасли, а поэтому взглянуть на эту проблему, отринув эти правила игры, не могут. Люди, которые очень компетентны в разработке автомобиля, не поверят, что с двигателем внутреннего сгорания можно сделать что-то такое, что будет летать — их компетентность давно их научила тому, что рожденный ездить летать не может
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mamut, Вы писали:
I>>>>>>P.S. Пока не залез в твой профайл мне все все время казалось что имею дело с подростком — вчерашним студентом.
PD>>>>>который каким-то образом ухитрился работать в 80-е годы на ТурбоПаскале.
PD>>>>>
M>>>>Обрати внимание на поведение. Ему пдевать, что ему указывают на гигантские дыры в его рассуждениях (и не мение гигантские лакуны в его знаниях). Он предпочитает из всего сообщения выбрать одно предложение и ответить на него.
PD>>>Он просто уже сыт по горло всей этой дискуссией, а потому очень хочет участие в ней закончить. Но он не любит передергиваний и не удержался, чтобы не показать автору предыдущегго сообщения на очередное...
M>>Где здесь передергивания?
PD>Да просто не мог Икемефула, прочитав мои первые сообщения, где я говорил о ТурбоПаскале Ямахи с 64 Кб памяти, предположить, что я вчерашний студент.
M>>
M>>Тебе был даден огромый список того, что нынешний бровзер должен уметь в обязательном порядке(это кстати говоря и есть реперные точки).
M>>Что делаешь ты ?
M>>Ты пишешь "Да хватит меня аббревиатурами пугать" и соскакиваешь на Jpeg/Gif
M>>Ты мог пройтись по всему списку, но вместо этого придумал отписку — Jpeg/Gif.
PD>Извини, но про то, что я несу чушь про GIF/JPEG, сказал ты, а не я. Я бы о них и говорить не стал — было бы о чем, подумаешь — вывод картинки на экран.
Опять тебя зациклило на JPEG/GIF!!!!
Ты вообще выделенное способен понять?
Все остальное поскипано, как не имеющее ничего общего с реальностью, так как наблюдаемые мной браузеры летают всяко больше 60 км/ч.
Выделенные ниже технологии на 2000-й год не существовали. Какую букву из «не существовали» ты не понимаешь? А если понимаешь, с какого перепугу ты цепляешься именно и только к графическим форматам?
M>>Потому что нынешний веб-сайт — это не только JavaScript. Это и быстрый яваскрипт, сособный манипулировть сотнями тысяч объектов в доли секунды. Как минимум.
M>>Потому что нынешний веб-сайт — это не только HTML 3.2/HTML 4. Это и HTML 4 + XHTML 1.0 + XML + XSLT + CSS 2.1 + CSS 3. Как минимум.
M>>Потому что нынешний веб-сайт — это не только JPEG + GIF, это и JPEG + GIF + PNG + Canvas + SVG + Flash + Silverlight + CSS3 Transforms (применимо к видео тоже). Как минимум.
M>>Потому что нынешний веб-сайт — это не только Flash 5, это Flash 10 (3D Transforms, HD Video, Dynamic Sound Generation и т.п.). Как минимум.
Почему твоим вопросм ко всему этому было « JPEG 10 лет назад не было ? Под JPEG сколько памяти-то надо ?»???????????????? При чем тут JPEG????
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Не поверишь — еще меньше, чем это было нужно раньше.
PD>Не поверю. Раньше — было 64 Кб (TP 1.0), потому что больше на машине и не было.
Тут не надо верить, уже в то время были реализации других производителей, а продукты борланда никогда не были компактными.
PD>>Я (как пользователь) их на экране вижу. И роста их на порядок — не вижу.
G>Так тебе объясняют, что видишь ты лишь вершину айсберга. Ну прислушайся же к людям.
А мне-то, (как пользователю) — не все ли равно, какие там айсберги ? Я раньше видел картинки на экране и сейчас вижу их. Покрасивее все стало, да, кое-что добавилось. И я никак не могу принять, что эти добавления и красивости так уж требуют роста потребляемых ресурсов в 10 и более раз.
Вот когда я вижу программу, перегоняющую 1.5 часовой фильм из mpeg в avi, то я понимаю, какой там объем действий и не возражаю, что это занимает приличное время. Или когда программа для расчета прогноза погоды в Евразии требуте сколько ей там надо, я тоже понимаю, что ей это аремя нужно. Или когда речь идет о БД размером в 100 Гб, то тоже понятно, что там возможны операции, требующие минуты, а то и часы.
А вывести картинку размером 1500*1000 и принять ввод пользователя...
PD>>Не совсем так. TP приведен не для доказательства ущербности js (точнее, интерпретатора с него), а для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае. Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб, причем с самых разных языков, и при на порядки более медленных машинах, и вдруг оказалось, что для языка, который, в общем-то, не сложнее намного предыдущих, потребовалось памяти намного больше — что-то здесь подозрительно. A>а самое подозрительное то, что ты отказываешься обсуждать, *зачем* потребовалось много памяти. и сравнивать самую ресурсоёмкую часть — оптимизатор — ты отказался.
Ладно, сделай мне, чтобы VC++ 2010 в режиме Debug занимал 5-10 Мб. Оптимизатору в режиме Debug делать нечего, пусть сидит на диске и ждет, когда я в Release переключусь.
Здравствуйте, Ikemefula, Вы писали:
I>>>Не поверишь — еще меньше, чем это было нужно раньше.
PD>>Не поверю. Раньше — было 64 Кб (TP 1.0), потому что больше на машине и не было.
I>Тут не надо верить, уже в то время были реализации других производителей, а продукты борланда никогда не были компактными.
Конечно не были. Никогда. ТурбоПаскаль же не Борланд, а инопланетяне сделали.
Здравствуйте, Mamut, Вы писали:
M>Не говоря уже о том, что эта программа во время выполнения не занимается JIT'ом, оптимизацией и т.д. и т.п. (опять повторяюсь).
не провоцируй, а то ведь вспомнит про p-code
Здравствуйте, genre, Вы писали:
PD>>Потому что люди, которые считают себя более кометентными, вместе с этой компетентностью приняли правила игры в этой отрасли, а поэтому взглянуть на эту проблему, отринув эти правила игры, не могут. Люди, которые очень компетентны в разработке автомобиля, не поверят, что с двигателем внутреннего сгорания можно сделать что-то такое, что будет летать — их компетентность давно их научила тому, что рожденный ездить летать не может
G>Все, я сдаюсь. Это религия, а религия как известно не подчиняется здравому смыслу.
Есть у психологов такое понятие — "профессиональный кретинизм" — которое означает, что работа человека формирует у него стереотипы, через которые он воспринимает весь окружающий мир, по крайней мере это стереотипы его действий, попыток решения возникающих задач.
P>>Не поверишь, не понял. Студия не является моим основным инструментом. У меня 2005. Тяжелее шестерки. IDEA с небольшим проектиком из пары десятков классов сразу 200 метров отбирает, и что? Нормально работает, без тормозов, и никому не мешая, в т. ч. Chrome, с которого я читаю сейчас этот форум.
PD>Я с IDEA не работал, судить не буду. Кто-то тут сказал, что она намного мощнее и студии, и эклипса. Допускаю. Может быть, для тех ее возможностей, которые я даже и не видел, надо намного больше. Кстати, я ничего не имею против того, что VC2010 требует больше, чем VC2008 из-за того, что в VC2010 есть компиляция на лету (по ходу набора подсвечивает ошибки). За это я готов платить. Но в предыдущем сообщении речь шла о студии без открытого солюшена.
У нас все ходы записаны. В частности о том, как ты предпочитаешь игнорировать неудобные для тебя факты. Понеслася:
Ну-ка, расскажи, что имеет компилятор VC++ 2008 С++ сверх того, что было в BC 5.5. Кроме оптимизации. Впрочем, она и там была, вот только сравнивать не берусь.
эка ты взял и выкинул большую часть функционала из рассмотрения. там ещё кодогенератор есть — берёшься сравнивать? или с твоей колокольни всё что за пределами языковых конструкций — непонятная неважная фигня?
Все, что тебе непонятно или ты не знаешь, ты считаешь несущественным, сводя все к тому единственному набору фич, которые ты знаешь/понимаешь. И так — и с BC++ и с браузерами и т.п. Пруфлинк: http://rsdn.ru/forum/flame.comp/4042164.1.aspx
Я имел в виду, что спрашивать, была ли в компиляторе 1996 года поддержка openmp не выглядит особенно умной. Естественно, сравнивая эти два компилятора, можно говорить только об их общем подмножестве, то есть о компиляции на базовый набор команд x86.
M>>Не говоря уже о том, что эта программа во время выполнения не занимается JIT'ом, оптимизацией и т.д. и т.п. (опять повторяюсь). A>не провоцируй, а то ведь вспомнит про p-code
PD>>>Я (как пользователь) их на экране вижу. И роста их на порядок — не вижу.
G>>Так тебе объясняют, что видишь ты лишь вершину айсберга. Ну прислушайся же к людям.
PD>А мне-то, (как пользователю) — не все ли равно, какие там айсберги ? Я раньше видел картинки на экране и сейчас вижу их. Покрасивее все стало, да, кое-что добавилось. И я никак не могу принять, что эти добавления и красивости так уж требуют роста потребляемых ресурсов в 10 и более раз.
Тебе наглядно показали, что это неправда.
PD>Вот когда я вижу программу, перегоняющую 1.5 часовой фильм из mpeg в avi, то я понимаю, какой там объем действий и не возражаю, что это занимает приличное время. Или когда программа для расчета прогноза погоды в Евразии требуте сколько ей там надо, я тоже понимаю, что ей это аремя нужно. Или когда речь идет о БД размером в 100 Гб, то тоже понятно, что там возможны операции, требующие минуты, а то и часы.
PD>А вывести картинку размером 1500*1000 и принять ввод пользователя...
Еще раз иди читай про список технологий.
Ах да. На досуге можешь попытаться произвести вывод этой самой «картинки».
Здравствуйте, Mamut, Вы писали:
PD>>Не совсем так. TP приведен не для доказательства ущербности js (точнее, интерпретатора с него), а для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае. Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб, причем с самых разных языков, и при на порядки более медленных машинах, и вдруг оказалось, что для языка, который, в общем-то, не сложнее намного предыдущих, потребовалось памяти намного больше — что-то здесь подозрительно.
M>Внезапно потерялось выполнение. Скомпилированная TP программа при выполнении спокойно может занять намного больше памяти, чем до, во время или после компиляции.
Ну и что ? Пусть берет. На это куча есть. Стек есть. Что за проблемы ? И куда это управление пропало ? jmp неизвестно куда ? Зависнем. Может, тебе ОС защищенного режима еще сделать в 64 Кбайтах ?
>Не говоря уже о том, что эта программа во время выполнения не занимается JIT'ом, оптимизацией и т.д. и т.п. (опять повторяюсь).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Ikemefula, Вы писали:
I>>>>Не поверишь — еще меньше, чем это было нужно раньше.
PD>>>Не поверю. Раньше — было 64 Кб (TP 1.0), потому что больше на машине и не было.
I>>Тут не надо верить, уже в то время были реализации других производителей, а продукты борланда никогда не были компактными.
PD>Конечно не были. Никогда. ТурбоПаскаль же не Борланд, а инопланетяне сделали.
Во первых, первая версия турбопаскаля была ажно 83м году и требовала 32кб памяти а не 64.
Во вторых никаких особых фич в языке не было, это был обычный паскаль.
Кроме компилятора, был еще редактор.
Всё. Потому можно написать обычный паскаль + обычный редактор того времени , но оптимизировать с учетом новых возможностей как по памяти так и по быстродейсвию так и по качеству кода.
Например у разработчиков тогда практически не было профайлеров, а их понятия о x86 были поверхностными, потому как машинный код получался откровенно гнусным.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mamut, Вы писали:
PD>>>Не совсем так. TP приведен не для доказательства ущербности js (точнее, интерпретатора с него), а для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае. Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб, причем с самых разных языков, и при на порядки более медленных машинах, и вдруг оказалось, что для языка, который, в общем-то, не сложнее намного предыдущих, потребовалось памяти намного больше — что-то здесь подозрительно.
M>>Внезапно потерялось выполнение. Скомпилированная TP программа при выполнении спокойно может занять намного больше памяти, чем до, во время или после компиляции.
PD>Ну и что ? Пусть берет. На это куча есть. Стек есть. Что за проблемы ? И куда это управление пропало ? jmp неизвестно куда ? Зависнем. Может, тебе ОС защищенного режима еще сделать в 64 Кбайтах ?
Это звиздец, господа. Павел, специально для тебя упрощаю весь текст до уровня 6-летнего ребенка:
1. для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае.
2. Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб
Вопрос. Почему ты сначала говоришь об исполнении, а потом благополучно о нем забываешь и говоришь только о компиляции?
Здравствуйте, Mamut, Вы писали:
M>>>Не говоря уже о том, что эта программа во время выполнения не занимается JIT'ом, оптимизацией и т.д. и т.п. (опять повторяюсь). A>>не провоцируй, а то ведь вспомнит про p-code M>ээээ. чо?
да вики же я в том смысле, что "ещё когда умели правильно писать и руки не кривые были", уже были "виртмашины", и таки частенько это было подложено именно под паскаль
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Вот когда я вижу программу, перегоняющую 1.5 часовой фильм из mpeg в avi, то я понимаю, какой там объем действий A>а я вот в выделенном не уверен, ибо зависит. в принципе, оно вообще может единственно выполнять копирование из файла в файл кусками
Я не знаток форматов, поэтому предположим. что это не так. Есть же хоть парочка таких форматов.
PD>>А вывести картинку размером 1500*1000 A>векторную многослойную с хитровывернутым сжатием, ага
PD>>Вот когда я вижу программу, перегоняющую 1.5 часовой фильм из mpeg в avi, то я понимаю, какой там объем действий A>а я вот в выделенном не уверен, ибо зависит. в принципе, оно вообще может единственно выполнять копирование из файла в файл кусками
PD>>А вывести картинку размером 1500*1000 A>векторную многослойную с хитровывернутым сжатием, ага
Ну и фигня, что алгоритм создания и перерисовки такой картинки Павлу не известен даже близко.
M>>>>Не говоря уже о том, что эта программа во время выполнения не занимается JIT'ом, оптимизацией и т.д. и т.п. (опять повторяюсь). A>>>не провоцируй, а то ведь вспомнит про p-code M>>ээээ. чо? A>да вики же я в том смысле, что "ещё когда умели правильно писать и руки не кривые были", уже были "виртмашины", и таки частенько это было подложено именно под паскаль
Ааааа. Я думал, он просто уже говорил об этом, и удивился
В википеии есть хорошая фраза «One of the significant disadvantages of p-code is execution speed, which can sometimes be remedied through the use of a JIT compiler»
I>Во первых, первая версия турбопаскаля была ажно 83м году и требовала 32кб памяти а не 64.
Возможно.
I>Во вторых никаких особых фич в языке не было, это был обычный паскаль.
А кто говорил, что было ? Впрочем, это все же не Паскаль Вирта. blockread и т.д.
I>Кроме компилятора, был еще редактор.
I>Всё. Потому можно написать обычный паскаль + обычный редактор того времени , но оптимизировать с учетом новых возможностей как по памяти так и по быстродейсвию так и по качеству кода.
И уложи в 64 Кб
I>Например у разработчиков тогда практически не было профайлеров, а их понятия о x86 были поверхностными, потому как машинный код получался откровенно гнусным.
Еще бы. Тем более, что там был и не x86, а 8080 и CP/M. 8086 будет позже.
I>>Открой Google документс. Эта штукенция позволяет одновременное редактирование одного документа разными пользователями.
I>>15 лет, даже 10 лет назад на тогдашних технологиях даже и мечтали про такое.
PD>Фантастика! Все, сдаюсь. Раз уж при 3.2 GHz, 4 ядрах, 4 GB памяти, черт знает каком количестве каких компьютеров у самой Google и скоростью Интернета в несколько Мбит/сек научились редактировать один документ несколькими пользователями — все, я сдаюсь.
В браузере 10-летней давности такое не было возможно. И, кстати, одновременное — это значит, что каждый пользователь, открывший документ, видит все действия, производимые всеми другими пользователями, в почти реальном времени.
PD>
Увы, кром улыбочек нормальных аргументов от тебя не дождешься. А так — да, в 2000-м были и JPEG и GIF, если это тебе интересно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Вот когда я вижу программу, перегоняющую 1.5 часовой фильм из mpeg в avi, то я понимаю, какой там объем действий A>>а я вот в выделенном не уверен, ибо зависит. в принципе, оно вообще может единственно выполнять копирование из файла в файл кусками PD>Я не знаток форматов, поэтому предположим. что это не так. Есть же хоть парочка таких форматов.
форматов-то дофига, вот только avi ни разу не формат вообще
PD>>>А вывести картинку размером 1500*1000 A>>векторную многослойную с хитровывернутым сжатием, ага PD>Да. Только если это делать нативным кодом.
ну, несерьёзно. ты же и на VC наезжал, в котором таки есть генерация нативного кода.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не совсем так. TP приведен не для доказательства ущербности js (точнее, интерпретатора с него), а для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае.
А почему тогда не FoxPro? Он чуть ближе к js, чем TP. Там и компилятор, и runtime, и память под свои нужды он подбирал абсолютно всю, какую только мог.
PD>Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб, причем с самых разных языков, и при на порядки более медленных машинах, и вдруг оказалось, что для языка, который, в общем-то, не сложнее намного предыдущих, потребовалось памяти намного больше — что-то здесь подозрительно.
Учитывая, что языка этого ты не знаешь, твое заявление выглядит весьма смелым. Я тут почитал пару статей про js для начинающих и пришел к выводу, что не так с ним все просто.
Может быть, сам js ущербный. Но вот интерпретатор, сдается мне, вполне нормальный.
То, что компилятор с PL/1 работал в 96 К, позволяет считать его шедевром в этой области. Но PL/1 не стал от этого менее ущербным.
PD>>>2. Я их анализирую и, потрясенный их мощью, изяществом и оптимальностью, признаю себя неправым. Тоже не реально и по той же причине.
P>>Нереально, что признаешь себя неправым? Извини, не удержался.
PD>Нереально, что я за разумное время смогу проанализировать их до мельчайших подробностей и сделаю вывод, что лучше сделать нельзя
А вообще без анализа, на основании верований, значит, можно?
PD>Я с IDEA не работал, судить не буду. Кто-то тут сказал, что она намного мощнее и студии, и эклипса. Допускаю. Может быть, для тех ее возможностей, которые я даже и не видел, надо намного больше. Кстати, я ничего не имею против того, что VC2010 требует больше, чем VC2008 из-за того, что в VC2010 есть компиляция на лету (по ходу набора подсвечивает ошибки). За это я готов платить. Но в предыдущем сообщении речь шла о студии без открытого солюшена.
Так там 80 было. А у меня — 200 с открытым проектом.
PD>Я только с борландовскими продуктами работал. Впечатления были хорошие.
Выбросил, когда не сумел нормально прилинковать фортрановский модуль к BC-шному. Точнее, прошел только тривиальный пример, я даже Fortran в Turbo Debugger-е увидел.
PD>Да, конечно. Те же конкуренция память — время. И если бы ыбть уверенным, что тут принято именно наилучшее решение, то можно многое допустить. Но уверенности нет. Слишком уж как-то все это больше напоминает принцип "памяти много, чего ее жалеть", нежеди принцип "найдем оптимальное решение".
Именно поэтому проверяются несколько вариантов решения, если условия (бюджет и пр. ) позволяют. Иначе, если не знаешь, что выбрать — выбирай грубую силу (с) Маккилрой (?).
PD>>>Зачем, спрашивается, тысячи и тысячи математиков и программистов эти алгоритмы и структуры данных анализировали и искали наилучшее решение, если можно наивным программированием запустить нечто, на порядок по времени/памяти хуже, лишь бы работало.
P>>Алгоритмы не прибиты гвоздями к задачам. Первая, пилотная, версия проекта, именно так и реализуется, наивным программированием. Главное преимущество такого подхода — скорость разработки. И вот если станет ясно, что данный подход не решает поставленную задачу, то с помощью наивного подхода получается значительная экономия средств.
PD>Тут я категорически не согласен. Если бы я так делал то, что я сделал, я бы не сделал ничего, просто потому, что не получив нужной скорости работы (а ее при таком подходе получить нельзя), мне пришлось бы либо выбросить все на помойку и расписаться в своем бессилии, либо начать все с начала.
Это ж сколько времени тебе приходится ждать результата в текущем состоянии проекта, если ты не можешь себе позволить модели строить?
PD>Мне именно надо было продумать структуры данных, чтобы они хорошо подходили под мои алгоритмы работы с ними, и алгоритмы. чтобы они хорошо с этим данными работали, быстро. И пока я все это не продумал, я вообще ничего не писал.
Я почему-то думал, что это итеративный процесс. Если движешься в верном направлении, каждая следующая итерация будет лучше предыдущей, а если нет, надо прекращать работу. А чисто теоретически, без профайлера, в этом убедиться невозможно.
P>>Quicksort разработан не Кнутом, а Хоаром,
PD>О черт!!!!!!!! Дико извиняюсь. Конечно, Хоаром. Какой дъявол меня подтолкнул написать про Кнута
Так отож!
PD>>>Допустим, что в этом случае это именно так. Но я вижу множество случаев, когда это далеко не так. А просто транжирят память без зазрения совести.
Ну так подскажи им, как правильно должно быть.
PD>Мне повторить аргументы ? Я их вроде как озвучил. Да, это моя позиция.
Все же вопросы веры — в другом форуме.
P>>>>Поинтересуйся как-нибудь, почему прорывает водопровод, причем в одно и то же время.
PD>Что-то я так и не пойму, при чем тут водопровод.
Инженеры-строители, специалисты в области водоснабжения и канализации, неверно рассчитывают коленца водопровода, хотя сопромат и прочие науки знают. Говорят, есть какие-то хитрости в тех расчетах.
PD>>>Буду. Если он мне скажет, что программа делает не то, что надо или не так — непременно буду. Но о том, какие средства употреблять и какие затраты памяти и т.д. должны быть — не ему говорить и не мне слушать.
P>>Хороший, умный заказчик о таких вещах говорить не станет. Выше мы уже это обсудили.
PD>Конечно, не будет. Я просто сказал, о чем я его мнение готов слушать, а о чем нет.
PD>Отличаются, да. Только вот если принято, что под эту бухгалтерию надо минимум 20 Мб, то одна команда скажет про 15, а другая про 25. А вот 20 лет назад, когда один "программист" заявил, что ему для расчета зарплаты для организации в несколько сот человек нужно 512 Килобайт и монопольный доступ к машине, над ним вся эта организация смеялась (там в основном программисты работали). И дали 64 Кбайта — зачем больше-то ? В начале 1990-х я сам писал расчет заработной платы для одной птицефабрики с персоналом в несколько сот че человек. Машина СМ-1420, ОП 256 Кб.
Ну это он, безусловно, загнул. Но тогда все велось в пакетном режиме, ввод/вывод совершенно другие, интерфейс отсутствует. Я тоже работал над учетом зарплаты. Я писал об этом. "Искра-226" и т. д. Те же 64 К. А на PC — уже 640 К, но появился нормальный оконный интерфейс у программы и нормальная файловая система у ОС (у "Искры" это было еще то УГ).
P>>То есть это не считается аргументом? Но ведь память — реальная — выделяется! Причем в расчете на худший случай. Во избежание. И неважно, статически или динамически.
PD>Нет, не считается. Если бы там было динамическое выделение памяти, а автор им бы не воспользовался — тогда да. Но если просто-напросто его нет — что делать-то ? Одно из двух : либо выделять статически, либо отказаться от Фортрана. Нельзя же упрекнуть меня в том. что я не воспользовался возможностями, которых нет.
А какая разница, если память выделяется один раз? От того, статически она выделяется или динамически она что, работать иначе будет? Есть системы, в которых вообще отказываются от динамического выделения памяти. И это решение вполне обосновано.
Если ты будешь писать на C нерекурсивную версию быстрой сортировки, зная, что вызываться она будет постоянно, неужели на каждом шаге будешь память выделять/освобождать?
PD>Вообще-то очень многие компиляторы с Ф4 разрешали рекурсию. Насчет тормозно — вопрос скорее по реализации ее на той или иной машине. Я, честно говоря, на Фортране ее, кажется, ни разу не употреблял.
Прямую — нет. А косвенную можно было организовать, пользуясь тем, что компилятор не может проверить, что передалось в подпрограмму, где оно объявлено EXTERNAL. Но я это сделал только однажды в познавательных целях. Очень тормозило.
PD>>>Я привожу TP в качестве некоей реперной точки для рассуждений, вот и все.
P>>Дак для js он в этом качестве, как я понимаю, не подходит.
PD>Так он для много чего не подходит . Он просто был и вечным укором останется.
PD>О! Идея! А дай-ка я переверну ситуацию.
PD>Задача — совеременным программистам написать компилятор с языка в точности того, каким был ТурбоПаскаль в 198x году! И IDE в точности такую же. Ни на йоту больше. Средства для написания использовать какие угодно.
PD>Сколько памяти потребуют ?
TP 1.0 работал в 64 К. У его IDE было примитивное меню, не было раздельной компиляции и еще много чего. Т. е. он был ближе к Паскалю Вирта. В версии 4.0 они впервые сумели сделать размер полученного exe-файла больше 64 К. В 5.0 добавили отладчик. И т. д. Версия 7 отличалась от 1-й, как мерс от запорожца.
Все же думаю, разница не будет большой. Может, что-то увеличится за счет поддержки 32- и 64-битовых приложений.
PD>
Здравствуйте, rusted, Вы писали:
PD>>Нет, не буду. Я уже все аргументы изложил. Коротко — непропорциональность роста потребления ресурсов и роста возможностей.
R>А откуда вообще взялось, что должна быть пропорциональность? Время той же сортировки например тоже не пропорционально растет с ростом количества элементов.
Если вспомнить комбинаторику то с ростом числа элементов сложность увеличивается пропорционально факториалу.
Так что все-таки модульность и декомпозиция как-никак но работают и мы еще легко отделались
Здравствуйте, Mamut, Вы писали:
M>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Здравствуйте, Mamut, Вы писали:
PD>>>>Не совсем так. TP приведен не для доказательства ущербности js (точнее, интерпретатора с него), а для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае. Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб, причем с самых разных языков, и при на порядки более медленных машинах, и вдруг оказалось, что для языка, который, в общем-то, не сложнее намного предыдущих, потребовалось памяти намного больше — что-то здесь подозрительно.
M>>>Внезапно потерялось выполнение. Скомпилированная TP программа при выполнении спокойно может занять намного больше памяти, чем до, во время или после компиляции.
PD>>Ну и что ? Пусть берет. На это куча есть. Стек есть. Что за проблемы ? И куда это управление пропало ? jmp неизвестно куда ? Зависнем. Может, тебе ОС защищенного режима еще сделать в 64 Кбайтах ?
M>Это звиздец, господа. Павел, специально для тебя упрощаю весь текст до уровня 6-летнего ребенка: M>
M>1. для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае.
M>2. Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб
M>Вопрос. Почему ты сначала говоришь об исполнении, а потом благополучно о нем забываешь и говоришь только о компиляции?
M>Я требую ответа только на этот вопрос
Хоть убей, если я тебя понимаю.
Ты : Внезапно потерялось выполнение. Скомпилированная TP программа при выполнении спокойно может занять намного больше памяти, чем до, во время или после компиляции.
Я : Ну и что ? Пусть берет. На это куча есть. Стек есть. Что за проблемы ? И куда это управление пропало ? jmp неизвестно куда ? Зависнем. Может, тебе ОС защищенного режима еще сделать в 64 Кбайтах ?
Ты : Сначала что-то совсем непонятное на уровне 6-летнего ребенка. "Для сравнения потребностей... и т.д что именно для сравнения ?" "Если на протяжении десятилетий ... " То что ?
А потом
>Почему ты сначала говоришь об исполнении, а потом благополучно о нем забываешь и говоришь только о компиляции?
Ты меня спросил — что будет если потерялось управление и что если там потребуется доп. память. Я тебе именно на этот вопрос и ответил.
Какое отношение имеет потеря управления и рост памяти во время выполнения к этому детскому лепету — решительно не могу понять.
Здравствуйте, rusted, Вы писали:
PD>>Нет, не буду. Я уже все аргументы изложил. Коротко — непропорциональность роста потребления ресурсов и роста возможностей.
R>А откуда вообще взялось, что должна быть пропорциональность? Время той же сортировки например тоже не пропорционально растет с ростом количества элементов.
Ну если уж о сортировке речь зашла, то хоть и не строго пропорционально, но "курица не птица, логарифм не бесконечность"
А во-вторых (и это намного важнее) — ты взял случай с ростом объема данных. Тут пропорциональности никто и не ждет : например, перемножение матриц 100*100 и 1000*1000 будет оличаться по времени не в 2 раза, это и так понятно.
Вот если бы размер экрана увеличился с тех пор раз так в 10 — другое дело. Или страница имела бы размер так примерно Мб 50 против 5
PD>>>>>Не совсем так. TP приведен не для доказательства ущербности js (точнее, интерпретатора с него), а для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае. Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб, причем с самых разных языков, и при на порядки более медленных машинах, и вдруг оказалось, что для языка, который, в общем-то, не сложнее намного предыдущих, потребовалось памяти намного больше — что-то здесь подозрительно.
M>>>>Внезапно потерялось выполнение. Скомпилированная TP программа при выполнении спокойно может занять намного больше памяти, чем до, во время или после компиляции.
PD>>>Ну и что ? Пусть берет. На это куча есть. Стек есть. Что за проблемы ? И куда это управление пропало ? jmp неизвестно куда ? Зависнем. Может, тебе ОС защищенного режима еще сделать в 64 Кбайтах ?
M>>Это звиздец, господа. Павел, специально для тебя упрощаю весь текст до уровня 6-летнего ребенка: M>>
M>>1. для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае.
M>>2. Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб
M>>Вопрос. Почему ты сначала говоришь об исполнении, а потом благополучно о нем забываешь и говоришь только о компиляции?
M>>Я требую ответа только на этот вопрос
PD>Хоть убей, если я тебя понимаю.
PD>Ты : Внезапно потерялось выполнение. Скомпилированная TP программа при выполнении спокойно может занять намного больше памяти, чем до, во время или после компиляции. PD>Я : Ну и что ? Пусть берет. На это куча есть. Стек есть. Что за проблемы ? И куда это управление пропало ? jmp неизвестно куда ? Зависнем. Может, тебе ОС защищенного режима еще сделать в 64 Кбайтах ?
PD>Ты : Сначала что-то совсем непонятное на уровне 6-летнего ребенка. "Для сравнения потребностей... и т.д что именно для сравнения ?" "Если на протяжении десятилетий ... " То что ?
PD>А потом
>>Почему ты сначала говоришь об исполнении, а потом благополучно о нем забываешь и говоришь только о компиляции?
PD>Ты меня спросил — что будет если потерялось управление и что если там потребуется доп. память. Я тебе именно на этот вопрос и ответил.
Теперь внимательно перечитай мой текст. И найди там хоть слово про управление. Хоть одно слово управление во всем моем тексте. Это к вопросу о том, как ты хорошо «читаешь» сообщения.
PD>Какое отношение имеет потеря управления и рост памяти во время выполнения к этому детскому лепету — решительно не могу понять.
Повторяю еще раз.
Ты говоришь: использую TP для сравнения компиляции и выполнения в случае TP и JS.
После чего ты говоришь толкьо про компиляцию. Куда делось выполнение?
Я уже упростил текст до уровня ясельно группы. Интересно, поймешь ли ты его сейчас.
Здравствуйте, Mamut, Вы писали:
PD>>Фантастика! Все, сдаюсь. Раз уж при 3.2 GHz, 4 ядрах, 4 GB памяти, черт знает каком количестве каких компьютеров у самой Google и скоростью Интернета в несколько Мбит/сек научились редактировать один документ несколькими пользователями — все, я сдаюсь.
M>В браузере 10-летней давности такое не было возможно.
Не сомневаюсь.
>И, кстати, одновременное — это значит, что каждый пользователь, открывший документ, видит все действия, производимые всеми другими пользователями, в почти реальном времени.
И это тоже понятно. Но сдается мне, что для этого в первую очередь нужна соответсвующая скорость интернета. Сама же задача , если не в Интернете, заключается во внесении изменений в документ , больше ничего. А изменения в этом документе можно делать по WM_KEYDOWN, WM_MOUSE всякие, а можно — из данных внешнего источника. Ну а если несколько пользователей — это значит, что изменения нужно делать в обоих направлениях.
Кстати, сетевые игры — это не то же самое ?
PD>>
M>Увы, кром улыбочек нормальных аргументов от тебя не дождешься.
Ну-ну.
>А так — да, в 2000-м были и JPEG и GIF, если это тебе интересно.
PD>>>Нет, не буду. Я уже все аргументы изложил. Коротко — непропорциональность роста потребления ресурсов и роста возможностей.
R>>А откуда вообще взялось, что должна быть пропорциональность? Время той же сортировки например тоже не пропорционально растет с ростом количества элементов.
PD>Ну если уж о сортировке речь зашла, то хоть и не строго пропорционально, но "курица не птица, логарифм не бесконечность"
PD>А во-вторых (и это намного важнее) — ты взял случай с ростом объема данных. Тут пропорциональности никто и не ждет : например, перемножение матриц 100*100 и 1000*1000 будет оличаться по времени не в 2 раза, это и так понятно.
PD>Вот если бы размер экрана увеличился с тех пор раз так в 10 — другое дело.
не на десять, но в 4-5 раз.
PD>Или страница имела бы размер так примерно Мб 50 против 5
весила 5-10 килобайт, сейчас суммарно может весит несколько мегабайт (странно, где-то я это уже писал).
не говоря уже о толпе новых технологий и возможностей, о которых ты стабильно забываешь/игнорируешь
Здравствуйте, Antikrot, Вы писали:
PD>>>>А вывести картинку размером 1500*1000 A>>>векторную многослойную с хитровывернутым сжатием, ага PD>>Да. Только если это делать нативным кодом. A>ну, несерьёзно. ты же и на VC наезжал, в котором таки есть генерация нативного кода.
Я про затраты памяти в IDE и компиляторе VC говорил, а картинки не компилятор обрабатывает и не IDE.
PD>>>Фантастика! Все, сдаюсь. Раз уж при 3.2 GHz, 4 ядрах, 4 GB памяти, черт знает каком количестве каких компьютеров у самой Google и скоростью Интернета в несколько Мбит/сек научились редактировать один документ несколькими пользователями — все, я сдаюсь.
M>>В браузере 10-летней давности такое не было возможно.
PD>Не сомневаюсь.
Почему? Вопрос о скорости интернета оставим в стороне.
>>И, кстати, одновременное — это значит, что каждый пользователь, открывший документ, видит все действия, производимые всеми другими пользователями, в почти реальном времени.
PD>И это тоже понятно. Но сдается мне, что для этого в первую очередь нужна соответсвующая скорость интернета. Сама же задача , если не в Интернете, заключается во внесении изменений в документ , больше ничего. А изменения в этом документе можно делать по WM_KEYDOWN, WM_MOUSE всякие, а можно — из данных внешнего источника. Ну а если несколько пользователей — это значит, что изменения нужно делать в обоих направлениях.
Вау. Ты открыл мне глаза. WM_KEYDOWN ага.
Синхронизацию данных мы, естественно, забудем.
О том, что все эти изменения нужно отображать сразу в документе, мы забудем
О том, что это не текстовый документ — а Rich Text или подобие EXcel'я мы тоже забудем
Ведь все так просто — отослать туда-сюда пару WM_KEYDOWN.
Я так думаю, ты уверен, что NN 3.0 Gold с этим, безусловно бы справился
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот если бы размер экрана увеличился с тех пор раз так в 10 — другое дело. Или страница имела бы размер так примерно Мб 50 против 5
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И это тоже понятно. Но сдается мне, что для этого в первую очередь нужна соответсвующая скорость интернета.
Нужна толковая инфраструктура и клиентский софт.
PD>Кстати, сетевые игры — это не то же самое ?
Сетевые игры немного другой расклад. Там конкретные версии сервера, клиентов и более удобные протоколы, что снимает огромную часть вопросов например с безопасностью, временем отклика и тд.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Нет, не буду. Я уже все аргументы изложил. Коротко — непропорциональность роста потребления ресурсов и роста возможностей. R>>А откуда вообще взялось, что должна быть пропорциональность? Время той же сортировки например тоже не пропорционально растет с ростом количества элементов. PD>Ну если уж о сортировке речь зашла, то хоть и не строго пропорционально, но "курица не птица, логарифм не бесконечность" PD>А во-вторых (и это намного важнее) — ты взял случай с ростом объема данных.
а теперь представь ситуацию, что сортировку делает оптимизатор в компиляторе. и при неизменном *внешнем* объёме исходных данных (те же исходники), добавление межпроцедурных оптимизаций увеличит *внутренний* объём данных. то есть внешне вообще ничего не поменялось, но сложность при этом запросто нелинейно увеличилась, а тебе подавай "пропорционально"
Здравствуйте, FR, Вы писали:
PD>>Вот если бы размер экрана увеличился с тех пор раз так в 10 — другое дело. Или страница имела бы размер так примерно Мб 50 против 5
FR>
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Не совсем так. TP приведен не для доказательства ущербности js (точнее, интерпретатора с него), а для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае.
P>А почему тогда не FoxPro? Он чуть ближе к js, чем TP. Там и компилятор, и runtime, и память под свои нужды он подбирал абсолютно всю, какую только мог.
А и FoxPro тоже. ИМХО я где-то его упоминал. Но это все же интерпретатор, а TP — компилятор. Присутствие самого TP при рабьте не требовалось, если, конечно, рабочую программу не в ОП делать, а com-файл создать.
PD>>Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб, причем с самых разных языков, и при на порядки более медленных машинах, и вдруг оказалось, что для языка, который, в общем-то, не сложнее намного предыдущих, потребовалось памяти намного больше — что-то здесь подозрительно.
P>Учитывая, что языка этого ты не знаешь, твое заявление выглядит весьма смелым. Я тут почитал пару статей про js для начинающих и пришел к выводу, что не так с ним все просто.
Может быть. Я его не то что совсем не знаю, а ... так себе. Но ты и впрямь заявишь, что он сложнее того же С++ в N раз ? Чему N равно ?
P>Может быть, сам js ущербный. Но вот интерпретатор, сдается мне, вполне нормальный.
Может быть. Первое.
P>То, что компилятор с PL/1 работал в 96 К, позволяет считать его шедевром в этой области. Но PL/1 не стал от этого менее ущербным.
Он был очень сильно оверлейный. Так что 96 К — это потребность в ОП, но далеко не объем компилятора. А вот TP действительно целиком размещался в 64 К, да еще оставлял место для редактора, исходника и рабочей программы.
PD>>Нереально, что я за разумное время смогу проанализировать их до мельчайших подробностей и сделаю вывод, что лучше сделать нельзя
P>А вообще без анализа, на основании верований, значит, можно?
Нет, не верований. А просто на основе интерполяции имеющихся данных. Вот смотри. PL/1 (жуткий монстр) — 96 К. Фортран OE (с оптимизацией) — 256 К. Досовские компиляторы — 640 К. Первые Windows компиляторы — 1-2 М. BC++ 3.1 — до 4 М.
Растем потихонечку. Язык усложняется, память растет. Все логично. Можно и 8 ждать.
И вдруг на тебе. Десятки Мб. А что, язык(и) сильно усложнились ? Да вроде нет.
А вот памяти стало больше, это верно.
Вывод ?
PD>>Я только с борландовскими продуктами работал. Впечатления были хорошие.
P>Выбросил, когда не сумел нормально прилинковать фортрановский модуль к BC-шному. Точнее, прошел только тривиальный пример, я даже Fortran в Turbo Debugger-е увидел.
Ну это обобая песня. Я Fortran — 77 к VC++ прилинковал, без особых проблем.
PD>>Да, конечно. Те же конкуренция память — время. И если бы ыбть уверенным, что тут принято именно наилучшее решение, то можно многое допустить. Но уверенности нет. Слишком уж как-то все это больше напоминает принцип "памяти много, чего ее жалеть", нежеди принцип "найдем оптимальное решение".
P>Именно поэтому проверяются несколько вариантов решения, если условия (бюджет и пр. ) позволяют. Иначе, если не знаешь, что выбрать — выбирай грубую силу (с) Маккилрой (?).
Вот именно. Бери больше, кидай дальше.
PD>>Тут я категорически не согласен. Если бы я так делал то, что я сделал, я бы не сделал ничего, просто потому, что не получив нужной скорости работы (а ее при таком подходе получить нельзя), мне пришлось бы либо выбросить все на помойку и расписаться в своем бессилии, либо начать все с начала.
P>Это ж сколько времени тебе приходится ждать результата в текущем состоянии проекта, если ты не можешь себе позволить модели строить?
Я могу себе позволить, но модели я предпочитаю в уме строить. А ждать... Однажды 2 недели их в уме строил, пока не придумал то, что мне показалось приемлемым.
PD>>Мне именно надо было продумать структуры данных, чтобы они хорошо подходили под мои алгоритмы работы с ними, и алгоритмы. чтобы они хорошо с этим данными работали, быстро. И пока я все это не продумал, я вообще ничего не писал.
P>Я почему-то думал, что это итеративный процесс. Если движешься в верном направлении, каждая следующая итерация будет лучше предыдущей, а если нет, надо прекращать работу. А чисто теоретически, без профайлера, в этом убедиться невозможно.
У меня на этот счет иные сображения. Если изнавчально была выбрана неподходящая в своей основе модель, то ее не улучишь, а пытаясь улучшать — получишь только субоптимизацию. Узкое место ты на 10% улучшишь, верно, потом еще одно узкое на 20%, а то, что можно было бы в 10 раз — никогда и не узнаешь.
PD>>>>Допустим, что в этом случае это именно так. Но я вижу множество случаев, когда это далеко не так. А просто транжирят память без зазрения совести.
P>Ну так подскажи им, как правильно должно быть.
А ты не видишь, что получается, когда я им пытаюсь это объяснить ? Проще выйти без бандерильи на бешеного быка
P>Инженеры-строители, специалисты в области водоснабжения и канализации, неверно рассчитывают коленца водопровода, хотя сопромат и прочие науки знают. Говорят, есть какие-то хитрости в тех расчетах.
Может быть
PD>>Отличаются, да. Только вот если принято, что под эту бухгалтерию надо минимум 20 Мб, то одна команда скажет про 15, а другая про 25. А вот 20 лет назад, когда один "программист" заявил, что ему для расчета зарплаты для организации в несколько сот человек нужно 512 Килобайт и монопольный доступ к машине, над ним вся эта организация смеялась (там в основном программисты работали). И дали 64 Кбайта — зачем больше-то ? В начале 1990-х я сам писал расчет заработной платы для одной птицефабрики с персоналом в несколько сот че человек. Машина СМ-1420, ОП 256 Кб.
P>Ну это он, безусловно, загнул. Но тогда все велось в пакетном режиме, ввод/вывод совершенно другие, интерфейс отсутствует. Я тоже работал над учетом зарплаты. Я писал об этом. "Искра-226" и т. д. Те же 64 К. А на PC — уже 640 К, но появился нормальный оконный интерфейс у программы и нормальная файловая система у ОС (у "Искры" это было еще то УГ).
Так можно зарплату хоть в 640 К уложить ? Кстати, ее расчет не сильно усложнился с тех времен. Сказать проще — никак не усложнился
PD>>Нет, не считается. Если бы там было динамическое выделение памяти, а автор им бы не воспользовался — тогда да. Но если просто-напросто его нет — что делать-то ? Одно из двух : либо выделять статически, либо отказаться от Фортрана. Нельзя же упрекнуть меня в том. что я не воспользовался возможностями, которых нет.
P>А какая разница, если память выделяется один раз? От того, статически она выделяется или динамически она что, работать иначе будет? Есть системы, в которых вообще отказываются от динамического выделения памяти. И это решение вполне обосновано.
Разница в том, что другим не хватит, если лишнее брать
P>Если ты будешь писать на C нерекурсивную версию быстрой сортировки, зная, что вызываться она будет постоянно, неужели на каждом шаге будешь память выделять/освобождать?
Черт знает. От задачи зависит.
PD>>Вообще-то очень многие компиляторы с Ф4 разрешали рекурсию. Насчет тормозно — вопрос скорее по реализации ее на той или иной машине. Я, честно говоря, на Фортране ее, кажется, ни разу не употреблял.
P>Прямую — нет. А косвенную можно было организовать, пользуясь тем, что компилятор не может проверить, что передалось в подпрограмму, где оно объявлено EXTERNAL. Но я это сделал только однажды в познавательных целях. Очень тормозило.
И прямую можно было. Фортран ОС РВ, например.
PD>>Задача — совеременным программистам написать компилятор с языка в точности того, каким был ТурбоПаскаль в 198x году! И IDE в точности такую же. Ни на йоту больше. Средства для написания использовать какие угодно.
PD>>Сколько памяти потребуют ?
P>TP 1.0 работал в 64 К. У его IDE было примитивное меню, не было раздельной компиляции и еще много чего. Т. е. он был ближе к Паскалю Вирта. В версии 4.0 они впервые сумели сделать размер полученного exe-файла больше 64 К. В 5.0 добавили отладчик. И т. д. Версия 7 отличалась от 1-й, как мерс от запорожца.
P>Все же думаю, разница не будет большой. Может, что-то увеличится за счет поддержки 32- и 64-битовых приложений.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Вот если бы размер экрана увеличился с тех пор раз так в 10 — другое дело. Или страница имела бы размер так примерно Мб 50 против 5
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Privalov, Вы писали:
P>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Не совсем так. TP приведен не для доказательства ущербности js (точнее, интерпретатора с него), а для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае.
P>>А почему тогда не FoxPro? Он чуть ближе к js, чем TP. Там и компилятор, и runtime, и память под свои нужды он подбирал абсолютно всю, какую только мог.
PD>А и FoxPro тоже. ИМХО я где-то его упоминал. Но это все же интерпретатор, а TP — компилятор. Присутствие самого TP при рабьте не требовалось, если, конечно, рабочую программу не в ОП делать, а com-файл создать.
PD>>>Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб, причем с самых разных языков, и при на порядки более медленных машинах, и вдруг оказалось, что для языка, который, в общем-то, не сложнее намного предыдущих, потребовалось памяти намного больше — что-то здесь подозрительно.
P>>Учитывая, что языка этого ты не знаешь, твое заявление выглядит весьма смелым. Я тут почитал пару статей про js для начинающих и пришел к выводу, что не так с ним все просто.
PD>Может быть. Я его не то что совсем не знаю, а ... так себе. Но ты и впрямь заявишь, что он сложнее того же С++ в N раз ? Чему N равно ?
P>>Может быть, сам js ущербный. Но вот интерпретатор, сдается мне, вполне нормальный.
PD>Может быть. Первое.
P>>То, что компилятор с PL/1 работал в 96 К, позволяет считать его шедевром в этой области. Но PL/1 не стал от этого менее ущербным.
PD>Он был очень сильно оверлейный. Так что 96 К — это потребность в ОП, но далеко не объем компилятора. А вот TP действительно целиком размещался в 64 К, да еще оставлял место для редактора, исходника и рабочей программы.
PD>>>Нереально, что я за разумное время смогу проанализировать их до мельчайших подробностей и сделаю вывод, что лучше сделать нельзя
P>>А вообще без анализа, на основании верований, значит, можно?
PD>Нет, не верований. А просто на основе интерполяции имеющихся данных. Вот смотри. PL/1 (жуткий монстр) — 96 К. Фортран OE (с оптимизацией) — 256 К. Досовские компиляторы — 640 К. Первые Windows компиляторы — 1-2 М. BC++ 3.1 — до 4 М.
PD>Растем потихонечку. Язык усложняется, память растет. Все логично. Можно и 8 ждать.
PD>И вдруг на тебе. Десятки Мб. А что, язык(и) сильно усложнились ? Да вроде нет.
PD>А вот памяти стало больше, это верно.
PD>Вывод ?
В пятидесятый раз: он не только компилируется. Он еще и вы.пол.ня.ет.ся. Специально по слогам тебе написал. Могу повторить: выполняется. Написать курсивом: выполняется, полужирным: выполняется. О! Заглавными буквами: ВЫПОЛНЯЕТСЯ.
То, что ТР что-то там компилировал в пределах одного мегабайта разве означало, что конечная программа будет выполняться в пределах 1 мегабайта? Нет.
С какого перепугу ты продолжаешь сравнивать (компиляцию + выполнение) только с компиляцией?
PD>>>>>Допустим, что в этом случае это именно так. Но я вижу множество случаев, когда это далеко не так. А просто транжирят память без зазрения совести.
P>>Ну так подскажи им, как правильно должно быть.
PD>А ты не видишь, что получается, когда я им пытаюсь это объяснить ? Проще выйти без бандерильи на бешеного быка
Ты не объясняешь. Ты берешь только те факты, что тебе известны, и игнорируешь ввсе, что тебе не нравится. Пример про компиляцию выше. ример про BC++ рядом я привел
I>Разница то какая ?
I>Если например найти тот самый код, то я просто уверен что его можно соптимизировать нынешниеми инструментами и по памяти и по быстродействи и заставить генерировать более быстрый код.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так можно зарплату хоть в 640 К уложить ? Кстати, ее расчет не сильно усложнился с тех времен. Сказать проще — никак не усложнился
Можно, некотрые предприятия до сих пор так считают. Только сейачас кроме ЗП нужно много чего другого считать чего раньше и в принципе посчитать не могли.
PD>>Так можно зарплату хоть в 640 К уложить ? Кстати, ее расчет не сильно усложнился с тех времен. Сказать проще — никак не усложнился
I>Можно, некотрые предприятия до сих пор так считают. Только сейачас кроме ЗП нужно много чего другого считать чего раньше и в принципе посчитать не могли.
Более того. Сейчас вынь да положь отчеты в Уxcel'е с дбликатом отчета в Excel'е и/или PDF'е еженедельно и ежемесячно на мыло, графики, доступ о всему этому через Web или, на худой конец, с синхронизацией с такой же софтиной где-нить в центральном офисе.
PD>>Хоть убей, если я тебя понимаю.
PD>>Ты : Внезапно потерялось выполнение. Скомпилированная TP программа при выполнении спокойно может занять намного больше памяти, чем до, во время или после компиляции. PD>>Я : Ну и что ? Пусть берет. На это куча есть. Стек есть. Что за проблемы ? И куда это управление пропало ? jmp неизвестно куда ? Зависнем. Может, тебе ОС защищенного режима еще сделать в 64 Кбайтах ?
PD>>Ты : Сначала что-то совсем непонятное на уровне 6-летнего ребенка. "Для сравнения потребностей... и т.д что именно для сравнения ?" "Если на протяжении десятилетий ... " То что ?
PD>>А потом
>>>Почему ты сначала говоришь об исполнении, а потом благополучно о нем забываешь и говоришь только о компиляции?
Уфффф... Ты бы хоть объяснялся нормально. Потерялось выполнение и программа может занять больше памяти... Я и понял, что речь идет о проблемах времени работы программы — потеря выполнения(управления) в программе или нехватка памяти.
Возращаюсь назад.
PD>>Не совсем так. TP приведен не для доказательства ущербности js (точнее, интерпретатора с него), а для сравнения потребностей для обработки исходной программы и исполнения результирующей программы в том и в другом случае. Если на протяжении десятилетй как-то ухитрялись укладывать задачу компиляции в Мб, причем с самых разных языков, и при на порядки более медленных машинах, и вдруг оказалось, что для языка, который, в общем-то, не сложнее намного предыдущих, потребовалось памяти намного больше — что-то здесь подозрительно.
M>Внезапно потерялось выполнение. Скомпилированная TP программа при выполнении спокойно может занять намного больше памяти, чем до, во время или после компиляции
Ну а уж если тебя интересует именно то, что программа, скомпилированная с TP, не уложится в Мб — ответ настолько прост, что дальше и некуда. Не было больше в MS-DOS. При наличии отсутствия . Так что "занять намного больше памяти, чем до, во время или после компиляции" можно, только не более 1 Мб.
А вот какое это имеет отношение к делу — непонятно. Одной программе нужно больше, другой меньше... Укладывались в 640, как правило.
Кстати, если не секрет, не мог бы ты объяснить, что означает количество памяти, занимаемое рабочей программой до выполнения ?
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Есть у психологов такое понятие — "профессиональный кретинизм" — которое означает, что работа человека формирует у него стереотипы, через которые он воспринимает весь окружающий мир, по крайней мере это стереотипы его действий, попыток решения возникающих задач.
G>То есть ты хочешь сказать, что работа в IT вынуждает всех присутствующих в данном форуме быть дурачками неспособными оперировать фактами?
Я тут вообще ничего не сказал. Это цитата. А чуть выше — твоя интерпретация.
Здравствуйте, Mamut, Вы писали:
M>Вау. Ты открыл мне глаза. WM_KEYDOWN ага.
M>Синхронизацию данных мы, естественно, забудем.
Я тебе что, инструкцию пишу со всеми подробностями ?
M>О том, что все эти изменения нужно отображать сразу в документе, мы забудем
Читай внимательно. Я же сказал — документ изменяется под влиянием WM_KEYDOWN и внешних источников. Изменения от WM_KEYDOWN отображаются, как ни странно, сразу. От внешних тоже.
M>О том, что это не текстовый документ — а Rich Text или подобие EXcel'я мы тоже забудем
Ну насчет подобия Excel промолчим. Ваши таблицы в броузере с ним и близко не лежали. А насчет RTF — ну и что ?
M>Я так думаю, ты уверен, что NN 3.0 Gold с этим, безусловно бы справился
Я так думаю, что NN этим заниматься бы не стал, поскольку не его это дело было при тех скоростях, а вот написать программу, которая делала бы это в локальной сети , вполне можно было и 15 лет назад. Во всяком случае, тут нет ничего невозможного.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Вот если бы размер экрана увеличился с тех пор раз так в 10 — другое дело. Или страница имела бы размер так примерно Мб 50 против 5
Не жульничай, батенька, не пройдет, нечего тут про CGA режимы писать. Windows может работать минимум с VGA 640*480 режимом. И в нем и 10 лет назад никто не работал, по крайней мере стоял 800*600
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Если например найти тот самый код, то я просто уверен что его можно соптимизировать нынешниеми инструментами и по памяти и по быстродействи и заставить генерировать более быстрый код.
PD>
У меня, к слову, есть компилятор модула, не мной правда написаный. Язык от паскаля не шибко отличается, можно оценить что где подкрутить можно.
Здравствуйте, Ikemefula, Вы писали:
PD>>Кстати, сетевые игры — это не то же самое ?
I>Сетевые игры немного другой расклад. Там конкретные версии сервера, клиентов и более удобные протоколы, что снимает огромную часть вопросов например с безопасностью, временем отклика и тд.
Так поставьте эти самые версии и протоколы А точнее — используйте соответствующие средства и не создавайте из мух слонов.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>Нет, не буду. Я уже все аргументы изложил. Коротко — непропорциональность роста потребления ресурсов и роста возможностей. R>>>А откуда вообще взялось, что должна быть пропорциональность? Время той же сортировки например тоже не пропорционально растет с ростом количества элементов. PD>>Ну если уж о сортировке речь зашла, то хоть и не строго пропорционально, но "курица не птица, логарифм не бесконечность" PD>>А во-вторых (и это намного важнее) — ты взял случай с ростом объема данных. A>а теперь представь ситуацию, что сортировку делает оптимизатор в компиляторе. и при неизменном *внешнем* объёме исходных данных (те же исходники), добавление межпроцедурных оптимизаций увеличит *внутренний* объём данных. то есть внешне вообще ничего не поменялось, но сложность при этом запросто нелинейно увеличилась, а тебе подавай "пропорционально"
Хорошее замечание. Только вот файлы в VC++ компилируются независимо. Поэтому компилятор может оптимизировать только в пределах файла, а там сотни тысяч классов и методов не будет.
Отптимизацию между файлами делает вторая фаза, вызываемая из линкера. Она доступа к исходникам не имеет. Вот в ней я готов допустить этот рост, и то вряд ли как N^2, так как едва ли в этой оптимизации задействованы все пары методы всех классов — времени на такое не хватит.
Так что рост затрат по памяти возможен (впрочем, он возможен и без всякой сортировки), но отнюдь не квадратично.
Ну а если N*logN — от линейного это мало отличается, пока у тебя не сотни тысяч классов и методов (библиотечные, естественно, опустим).
M>В пятидесятый раз: он не только компилируется. Он еще и вы.пол.ня.ет.ся. Специально по слогам тебе написал. Могу повторить: выполняется. Написать курсивом: выполняется, полужирным: выполняется. О! Заглавными буквами: ВЫПОЛНЯЕТСЯ.
M>То, что ТР что-то там компилировал в пределах одного мегабайта разве означало, что конечная программа будет выполняться в пределах 1 мегабайта? Нет.
Ну ты даешь! Повторяю во второй раз — будет, потому что в PC XT на машине всего 1 Мб. Более того, доступно 640 Кб.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Так можно зарплату хоть в 640 К уложить ? Кстати, ее расчет не сильно усложнился с тех времен. Сказать проще — никак не усложнился
I>Можно, некотрые предприятия до сих пор так считают. Только сейачас кроме ЗП нужно много чего другого считать чего раньше и в принципе посчитать не могли.
А если не секрет, что именно ? И как же они без этого жили, если на тех компьютерах и посчитать не могли ? А на счетах могли ? . Деньги — это ведь не шутка, если сказать, что их посчитать не могли, да еще при советской власти, то сам понимаешь, что было бы. И не только деньги, а и все материальные ценности и т.д.
PD>Хорошее замечание. Только вот файлы в VC++ компилируются независимо. Поэтому компилятор может оптимизировать только в пределах файла, а там сотни тысяч классов и методов не будет.
I>>>Если например найти тот самый код, то я просто уверен что его можно соптимизировать нынешниеми инструментами и по памяти и по быстродействи и заставить генерировать более быстрый код.
PD>>
I>У меня, к слову, есть компилятор модула, не мной правда написаный. Язык от паскаля не шибко отличается, можно оценить что где подкрутить можно.
Ты это брось. То ему "найти тот самый код", то "не мной правда написаный". Ты садись и пиши свой компилятор и т.д., и чтобы в 64 Кбайтах работал.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>>Нет, не буду. Я уже все аргументы изложил. Коротко — непропорциональность роста потребления ресурсов и роста возможностей. R>>>>А откуда вообще взялось, что должна быть пропорциональность? Время той же сортировки например тоже не пропорционально растет с ростом количества элементов. PD>>>Ну если уж о сортировке речь зашла, то хоть и не строго пропорционально, но "курица не птица, логарифм не бесконечность" PD>>>А во-вторых (и это намного важнее) — ты взял случай с ростом объема данных. A>>а теперь представь ситуацию, что сортировку делает оптимизатор в компиляторе. и при неизменном *внешнем* объёме исходных данных (те же исходники), добавление межпроцедурных оптимизаций увеличит *внутренний* объём данных. то есть внешне вообще ничего не поменялось, но сложность при этом запросто нелинейно увеличилась, а тебе подавай "пропорционально" PD>Хорошее замечание. Только вот файлы в VC++ компилируются независимо. Поэтому компилятор может оптимизировать только в пределах файла, а там сотни тысяч классов и методов не будет.
оно таки да, но я не про межфайловую, а про межпроцедурную оптимизацию
PD>Отптимизацию между файлами делает вторая фаза, вызываемая из линкера. Она доступа к исходникам не имеет.
???
а зачем ей доступ к исходникам?
PD>Вот в ней я готов допустить этот рост, и то вряд ли как N^2, так как едва ли в этой оптимизации задействованы все пары методы всех классов — времени на такое не хватит.
не понял про "пары методов", но не суть. кстати, а кто ограничивает по времени?
PD>(библиотечные, естественно, опустим).
я бы не был так категоричен
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Можно, некотрые предприятия до сих пор так считают. Только сейачас кроме ЗП нужно много чего другого считать чего раньше и в принципе посчитать не могли.
PD>А если не секрет, что именно ? И как же они без этого жили, если на тех компьютерах и посчитать не могли ? А на счетах могли ? .
Тратили больше денег, не владели полной информацией, принимали ошибочные решения.
Например раньше практически невозможно было рассчитать более-менее оптимальную оптическую сеть.
Нельзя было рассчитать более-менее оптимальный транспортный путь.
С внедрением компьютеров эти проблемы стали решаться.
>Деньги — это ведь не шутка, если сказать, что их посчитать не могли, да еще при советской власти, то сам понимаешь, что было бы. И не только деньги, а и все материальные ценности и т.д.
Вот представь — раньше люди не знали сопромата и строили мосты. За счет чего ?
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>У меня, к слову, есть компилятор модула, не мной правда написаный. Язык от паскаля не шибко отличается, можно оценить что где подкрутить можно.
PD>Ты это брось. То ему "найти тот самый код", то "не мной правда написаный". Ты садись и пиши свой компилятор и т.д., и чтобы в 64 Кбайтах работал.
Зачем писать свой если есть уже готовй ? Его доточить под конкретную задачу — уменьшить потребление памяти при увеличении быстродействия и повышении качества выходного кода.
PD>Ну а уж если тебя интересует именно то, что программа, скомпилированная с TP, не уложится в Мб — ответ настолько прост, что дальше и некуда. Не было больше в MS-DOS. При наличии отсутствия . Так что "занять намного больше памяти, чем до, во время или после компиляции" можно, только не более 1 Мб. PD>А вот какое это имеет отношение к делу — непонятно. Одной программе нужно больше, другой меньше... Укладывались в 640, как правило.
PD>Кстати, если не секрет, не мог бы ты объяснить, что означает количество памяти, занимаемое рабочей программой до выполнения ?
Тьфу блин, я сейчас начну материться.
Почему ты сначала говоришь об исполнении, а потом благополучно о нем забываешь и говоришь только о компиляции?
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>В пятидесятый раз: он не только компилируется. Он еще и вы.пол.ня.ет.ся. Специально по слогам тебе написал. Могу повторить: выполняется. Написать курсивом: выполняется, полужирным: выполняется. О! Заглавными буквами: ВЫПОЛНЯЕТСЯ.
M>>То, что ТР что-то там компилировал в пределах одного мегабайта разве означало, что конечная программа будет выполняться в пределах 1 мегабайта? Нет.
PD>Ну ты даешь! Повторяю во второй раз — будет, потому что в PC XT на машине всего 1 Мб. Более того, доступно 640 Кб.
Попробуй рассказать, как ты понял его фразу. Ты почему то упорно отказываешься прочесть простую вещь.
FR>>
PD>Не жульничай, батенька, не пройдет, нечего тут про CGA режимы писать. Windows может работать минимум с VGA 640*480 режимом. И в нем и 10 лет назад никто не работал, по крайней мере стоял 800*600
PD>1930 * 1080 / (800 * 600) = 4.32
Здравствуйте, Antikrot, Вы писали:
A>оно таки да, но я не про межфайловую, а про межпроцедурную оптимизацию
Так я и сказал — при первой фазе это возможно только в пределах данного .cpp (со всми его #include), а там сотен классов не будет.
PD>>Отптимизацию между файлами делает вторая фаза, вызываемая из линкера. Она доступа к исходникам не имеет. A>??? A>а зачем ей доступ к исходникам?
Просто так сказал
PD>>Вот в ней я готов допустить этот рост, и то вряд ли как N^2, так как едва ли в этой оптимизации задействованы все пары методы всех классов — времени на такое не хватит. A>не понял про "пары методов", но не суть. кстати, а кто ограничивает по времени?
Пусть методов N всех классов. Если предположить, что создается некий массив (который надо сортировать), то допустим, там при межпроцедурной оптимизации нужны пары всех процедур.
PD>>(библиотечные, естественно, опустим). A>я бы не был так категоричен
А я буду. Если речь идет именно о lib. Никто код strcpy не оптимизирует.
PD>>>Кстати, сетевые игры — это не то же самое ?
I>>Сетевые игры немного другой расклад. Там конкретные версии сервера, клиентов и более удобные протоколы, что снимает огромную часть вопросов например с безопасностью, временем отклика и тд.
PD>Так поставьте эти самые версии и протоколы
нашелся теоретик на нашу голову.
PD>А точнее — используйте соответствующие средства и не создавайте из мух слонов.
никто и н создает по этой части ты тут у нас спец. Тут народ работает в браузерах, во много раз более быстрых и функциональных, чем браузеры 10-летней давности, а ты тут что-то суетишься и всем в лицо тычешь то NN 3.0, то TP, то BC++.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
I>Тратили больше денег, не владели полной информацией, принимали ошибочные решения.
I>Например раньше практически невозможно было рассчитать более-менее оптимальную оптическую сеть.
Абсолютно верно! Не могли ее никак рассчитать, потому что их и не было. Никаких
Но я тебя о деловой сфере спрашивал (бухгалтерия, склад и т.п.). А там оптические сети не рассчитывали и даже расчет силы тока в светильниках тоже.
I>Нельзя было рассчитать более-менее оптимальный транспортный путь.
Очень актуально для птицефабрики, к которой идет одна дорога на ж-д станцию
I>С внедрением компьютеров эти проблемы стали решаться.
Это точно.
В одном леспромхоже провели полную автоматизацию. Тепер стоит лишь нажать кнопку — и бревно уже на плече.
>>Деньги — это ведь не шутка, если сказать, что их посчитать не могли, да еще при советской власти, то сам понимаешь, что было бы. И не только деньги, а и все материальные ценности и т.д.
I>Вот представь — раньше люди не знали сопромата и строили мосты. За счет чего ?
Не уходи в сторону. Сопромата они не знали, а вот насчет того, что деньги считать не умели даже во времена фараонов — не слышал.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Может быть. Я его не то что совсем не знаю, а ... так себе. Но ты и впрямь заявишь, что он сложнее того же С++ в N раз ? Чему N равно ?
Ты и впрямь считаешь, что я такое заявлю? А вот, судя по твоему вопросу, ты уже знаешь, чему равен N. Озвучишь?
P>>То, что компилятор с PL/1 работал в 96 К, позволяет считать его шедевром в этой области. Но PL/1 не стал от этого менее ущербным.
PD>Он был очень сильно оверлейный. Так что 96 К — это потребность в ОП, но далеко не объем компилятора.
И компилятор PL/1 был шестипроходным. И что? По-моему, изначально обсуждалась именно потребность в ОП, а не объем компилятора.
PD>А вот TP действительно целиком размещался в 64 К, да еще оставлял место для редактора, исходника и рабочей программы.
Это TP 1.0 образца 1983 года. Тогда еще было до фига компьютеров с 64 К памяти. А что с TP 7.0, не подскажешь?
PD>>>Нереально, что я за разумное время смогу проанализировать их до мельчайших подробностей и сделаю вывод, что лучше сделать нельзя
P>>А вообще без анализа, на основании верований, значит, можно?
PD>Нет, не верований. А просто на основе интерполяции имеющихся данных. Вот смотри. PL/1 (жуткий монстр) — 96 К. Фортран OE (с оптимизацией) — 256 К. Досовские компиляторы — 640 К. Первые Windows компиляторы — 1-2 М. BC++ 3.1 — до 4 М.
И как сюда вписывается JS? Он появился позже названных тобой продуктов. Тогда это не интерполяция, а экстраполяция. А там все сложнее. Ну и опять про выполнение забыл.
P>>Выбросил, когда не сумел нормально прилинковать фортрановский модуль к BC-шному. Точнее, прошел только тривиальный пример, я даже Fortran в Turbo Debugger-е увидел.
PD>Ну это обобая песня. Я Fortran — 77 к VC++ прилинковал, без особых проблем.
Тоже мне бином Ньютона. После того, как у меня в MS-DOS нормально стал собираться проект, в котором вперемешку шли файлы и библиотеки С и Fortran 77 (MSC 6.0 и MSF 5.1), я ничего не боюсь. Я там еще пару неточностей в документации нашел.
P>>Иначе, если не знаешь, что выбрать — выбирай грубую силу (с) Маккилрой (?).
PD>Вот именно. Бери больше, кидай дальше.
А что не так? Ты всегда сразу знаешь, что будет, а что не будет работать? А если не знаешь — то бери больше и кидай дальше. И пока летит — отдыхай.
PD>Я могу себе позволить, но модели я предпочитаю в уме строить. А ждать... Однажды 2 недели их в уме строил, пока не придумал то, что мне показалось приемлемым.
Я тоже 2 недели могу ходить с отрешенным видом. Но совсем без прикидок? Ты сам сказал: тебе показалось приемлемым? Но так ли это на самом деле?
PD>>>Мне именно надо было продумать структуры данных, чтобы они хорошо подходили под мои алгоритмы работы с ними, и алгоритмы. чтобы они хорошо с этим данными работали, быстро. И пока я все это не продумал, я вообще ничего не писал.
P>>Я почему-то думал, что это итеративный процесс. Если движешься в верном направлении, каждая следующая итерация будет лучше предыдущей, а если нет, надо прекращать работу. А чисто теоретически, без профайлера, в этом убедиться невозможно.
PD>У меня на этот счет иные сображения. Если изнавчально была выбрана неподходящая в своей основе модель, то ее не улучишь, а пытаясь улучшать — получишь только субоптимизацию. Узкое место ты на 10% улучшишь, верно, потом еще одно узкое на 20%, а то, что можно было бы в 10 раз — никогда и не узнаешь.
Дак сначала выяснить нужно, подходящая она или нет. Если есть несколько вариантов (а в большинстве случаев это так), понять, что верно, а что нет, путем только медитации, по-моему, несколько затруднительно.
PD>>>>>Допустим, что в этом случае это именно так. Но я вижу множество случаев, когда это далеко не так. А просто транжирят память без зазрения совести.
P>>Ну так подскажи им, как правильно должно быть.
PD>А ты не видишь, что получается, когда я им пытаюсь это объяснить ? Проще выйти без бандерильи на бешеного быка
Я было подумал, что ты говоришь о каком-то конкретном проекте, в котором тебе разбираться пришлось, а ты, оказывается, опять за свое. Объяснения всех твоих оппонентов кажутся мне более убедительными.
PD>Так можно зарплату хоть в 640 К уложить ? Кстати, ее расчет не сильно усложнился с тех времен. Сказать проще — никак не усложнился
Можно. Беда в том, что не нужно. Еще в конце прошлого века стали появляться интегрированные системы управления предприятием. Они включали все: от учета основных средств до картотеки посетителей медпункта. Нормальный клиент-сервер, удаленный доступ, разграничение прав. А это все запихать в 640 К несколько затруднительно.
P>>А какая разница, если память выделяется один раз?
PD>Разница в том, что другим не хватит, если лишнее брать
Почему лишняя? В случае отказа от рекурсии ты обязан ее выделить. Или я что-то забыл? Тогда покажи нерекурсивный quicksort без "лишней" памяти.
P>>Если ты будешь писать на C нерекурсивную версию быстрой сортировки, зная, что вызываться она будет постоянно, неужели на каждом шаге будешь память выделять/освобождать?
PD>Черт знает. От задачи зависит.
Именно! И таких "черт знает" слышно все время на протяжении всего процесса разработки и, я не побоюсь этого слова, сопровождения.
PD>>>Я, честно говоря, на Фортране ее, кажется, ни разу не употреблял.
P>>Прямую — нет. А косвенную можно было организовать, пользуясь тем, что компилятор не может проверить, что передалось в подпрограмму, где оно объявлено EXTERNAL.
PD>И прямую можно было. Фортран ОС РВ, например.
Вот опять. Не употреблял, а рассуждаешь. Я говорю здесь о том, что сам сделал. MSF 5.1 рекурсию не поддерживал.
Здравствуйте, Ikemefula, Вы писали:
I>>>У меня, к слову, есть компилятор модула, не мной правда написаный. Язык от паскаля не шибко отличается, можно оценить что где подкрутить можно.
PD>>Ты это брось. То ему "найти тот самый код", то "не мной правда написаный". Ты садись и пиши свой компилятор и т.д., и чтобы в 64 Кбайтах работал.
I>Зачем писать свой если есть уже готовй ? Его доточить под конкретную задачу — уменьшить потребление памяти при увеличении быстродействия и повышении качества выходного кода.
То. что они умели писать хороший код — я не спорю, а оптимизировать незачем, потому что этот компилятор никому не нужен. Ты обещал написать свой компилятор + остальное в 64 Кбайтах. Вот и пиши. Можешь на js, можешь на чем-то ином
Здравствуйте, Mamut, Вы писали:
PD>>Ну а уж если тебя интересует именно то, что программа, скомпилированная с TP, не уложится в Мб — ответ настолько прост, что дальше и некуда. Не было больше в MS-DOS. При наличии отсутствия . Так что "занять намного больше памяти, чем до, во время или после компиляции" можно, только не более 1 Мб. PD>>А вот какое это имеет отношение к делу — непонятно. Одной программе нужно больше, другой меньше... Укладывались в 640, как правило.
PD>>Кстати, если не секрет, не мог бы ты объяснить, что означает количество памяти, занимаемое рабочей программой до выполнения ?
M>Тьфу блин, я сейчас начну материться.
Не стоит. Модераторы, то да се...
M>Почему ты сначала говоришь об исполнении, а потом благополучно о нем забываешь и говоришь только о компиляции?
Потому что мне и в голову не пришло, что ты не знаешь, что на машине в те времена был всего 1 Мб, поэтому рабочая программа никак больше занимать не могла. Но вот компилятору (TP 7.0) хватало 1 Мб, и на этом я акцентировал внимание твое. А рабочей программе сколько хватало — я не знаю, может , 100 Кб, может, 200, а может, тоже 640, но не больше, потому что больше на машине не было.
M>Ты можешь внятно ответить на этот вопрос?
I>>>>У меня, к слову, есть компилятор модула, не мной правда написаный. Язык от паскаля не шибко отличается, можно оценить что где подкрутить можно.
PD>>>Ты это брось. То ему "найти тот самый код", то "не мной правда написаный". Ты садись и пиши свой компилятор и т.д., и чтобы в 64 Кбайтах работал.
I>>Зачем писать свой если есть уже готовй ? Его доточить под конкретную задачу — уменьшить потребление памяти при увеличении быстродействия и повышении качества выходного кода.
PD>То. что они умели писать хороший код — я не спорю, а оптимизировать незачем, потому что этот компилятор никому не нужен. Ты обещал написать свой компилятор + остальное в 64 Кбайтах.
M>>Почему ты сначала говоришь об исполнении, а потом благополучно о нем забываешь и говоришь только о компиляции?
PD>Потому что мне и в голову не пришло, что ты не знаешь, что на машине в те времена был всего 1 Мб, поэтому рабочая программа никак больше занимать не могла. Но вот компилятору (TP 7.0) хватало 1 Мб, и на этом я акцентировал внимание твое. А рабочей программе сколько хватало — я не знаю, может , 100 Кб, может, 200, а может, тоже 640, но не больше, потому что больше на машине не было.
M>Повторяю задачу. Чем теоретизировать, открыл бы Google Docs, и посмотрел бы. NN этим заниматься не стал бы, потому что у него бы лопнул (образно выражаясь) интерпретатор JS'а, среди прочих.
Попробовал.Работает. Ну и что ?
M>И да, 15 лет тому назад это было невозможно. Даже в локальных сетях.
Обоснуй. Скорость передачи пусть даже 10 Мбит/сек вполне достаточная для передачи этих изменений, у меня и сейчас 10 Мбит, так что здесь ничего нового. Игры в локальной сети и тогда были, вполне работали.
Что такое имеется в редактировании текста, что невозможно было бы сделать в совместной работе при 256 Мб и 667 MHZ ?
Я никогда такими редакторами не интересовался, но вот поискал в Интернете, и вот такая ссылка, например. Естественно. за качество программы не ручаюсь.
И кстати, как же, черт возьми, Terminal Service работал-то ? Там ведь именно это и происходит — действия пользователя отсылались на сервер, картинка с сервера — на экран пользователя. И совместные объекты там были (про Global namespace в ядре Windows знаешь, надеюсь). И ядро сервера со всем этим как-то управлялось. Тексты там совместно не редактировали, верно, но неужели задача совместного редактирования текстов на одной машине (сервере Terminal Server) такая уж неизмеримо сложная ? Ну несколько источников WM_KEYDOWN , а картинку все равно отправлять клиенту надо.
Поискать как следует — наверное, найдутся и другие.
Вот и все. Просто вы и впрямь решили, что с web-программированием открылась новая эра, а раньше ничего подобного не было. Многое было, и требовало намного меньше ресурсов. А вы их берете немеряно, используете не слишком пододящие инструменты, а потом удивляетесь, когда вам об этом говорять и заявляете — это же неизмеримо сложно, такого и в мире ничего нет.
Помню, мне как-то Синклер доказывал про неизмеримую сложность изображения карт Google maps в броузере и создания там подписей. А я ему объяснял, что изображение битовых карт было известно еще во времена Win 3.0 и вполне быстро работало на тех компьютерах, и диалоги тоже. Вот передавать такие карты с хорошей скоростью тогда не могли, верно, да и карт не было. А нарисовать — что за проблема-то ?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
M>>>В пятидесятый раз: он не только компилируется. Он еще и вы.пол.ня.ет.ся. Специально по слогам тебе написал. Могу повторить: выполняется. Написать курсивом: выполняется, полужирным: выполняется. О! Заглавными буквами: ВЫПОЛНЯЕТСЯ.
M>>>То, что ТР что-то там компилировал в пределах одного мегабайта разве означало, что конечная программа будет выполняться в пределах 1 мегабайта? Нет.
PD>>Ну ты даешь! Повторяю во второй раз — будет, потому что в PC XT на машине всего 1 Мб. Более того, доступно 640 Кб.
I>Попробуй рассказать, как ты понял его фразу. Ты почему то упорно отказываешься прочесть простую вещь.
Прочти выше то, что я выделил. Понять эту фразу иначе нельзя. Более того, независимо от того, что там TP делал и был ли он там вообще, конечная программа всегда выполнялась в пределах 1 мегабайта. Любая конечная программа на PC/XT. Потому что больше там памяти не было. Физически.
PD>>Ну ты даешь! Повторяю во второй раз — будет, потому что в PC XT на машине всего 1 Мб. Более того, доступно 640 Кб.
M>Ах, да, старый добрый ДОС. забывать уже стал, старею.
Не стареешь, а в детство впадаешь. Сначала в шестилетний возраст, а потом в ясельный.
M>Толкьо что-то мне подсказывает, что ни JIT'а там не было
Не было. Нужен он там как зайцу стоп-сигнал или как тот же JIT современному коду, оттранслированнному с неуправляемого C++. По той же причине.
>ни run-time optimizations
Ее и сейчас в С++ нет — некому ей заниматься и незачем. И без нее код с ++ быстрее.
>ни динамики какой-либо. И Икемефула тут уже говорил, что JS управляет количеством объектов бОльшим, чем памяти было у TP.
В байтах ? То есть у js объектов 640 тысяч ? для любой страницы ? для Hello,world тоже ?
M>Да-да. Только вот ты это старательно и сознатльно игнорируешь.
M>>Повторяю задачу. Чем теоретизировать, открыл бы Google Docs, и посмотрел бы. NN этим заниматься не стал бы, потому что у него бы лопнул (образно выражаясь) интерпретатор JS'а, среди прочих.
PD>Попробовал.Работает. Ну и что ?
Версия NN? работа со сколь-нибудь сложным документом? Работа нескольких пользователей?
M>>И да, 15 лет тому назад это было невозможно. Даже в локальных сетях.
PD>Обоснуй. Скорость передачи пусть даже 10 Мбит/сек вполне достаточная для передачи этих изменений, у меня и сейчас 10 Мбит, так что здесь ничего нового. Игры в локальной сети и тогда были, вполне работали.
Зря я про сети упомянул. 15 лет тому назад этого не умел ни JS ни HTML ни CSS.
PD>Что такое имеется в редактировании текста, что невозможно было бы сделать в совместной работе при 256 Мб и 667 MHZ ?
PD>Я никогда такими редакторами не интересовался, но вот поискал в Интернете, и вот такая ссылка, например. Естественно. за качество программы не ручаюсь.
PD>Gobby: совместное редактирование текста PD>http://beshenov.ru/debaday/200704.html
Действительно. Давайте заменим rich text на, по сути, plain text и назовем их одинаковыми. Возвращаясь ближе к изначальному контексту разговора: 10-15 лет тому назад brwser не умел rich text.
PD>И кстати, как же, черт возьми, Terminal Service работал-то ? Там ведь именно это и происходит — действия пользователя отсылались на сервер, картинка с сервера — на экран пользователя. И совместные объекты там были (про Global namespace в ядре Windows знаешь, надеюсь). И ядро сервера со всем этим как-то управлялось. Тексты там совместно не редактировали, верно, но неужели задача совместного редактирования текстов на одной машине (сервере Terminal Server) такая уж неизмеримо сложная ? Ну несколько источников WM_KEYDOWN , а картинку все равно отправлять клиенту надо.
Есть огромная разница между отправкой картинки и отображением веб-страницы.
PD>Поискать как следует — наверное, найдутся и другие.
PD>Вот и все. Просто вы и впрямь решили, что с web-программированием открылась новая эра, а раньше ничего подобного не было. Многое было, и требовало намного меньше ресурсов. А вы их берете немеряно, используете не слишком пододящие инструменты, а потом удивляетесь, когда вам об этом говорять и заявляете — это же неизмеримо сложно, такого и в мире ничего нет.
О, мне это нравится. Какая шикарная подмена понятий. Давай вернемся ближе к контексту обсуждения и задаим более близкий к нему вопрос: «Возможно ли было такое в браузере 10-15 лет тому назад»? Ответ: «нет». Измышлизмы на тему эр и того что мы считаем, оставлю на твоей совести.
Здравствуйте, Mamut, Вы писали:
PD>>>>Вот если бы размер экрана увеличился с тех пор раз так в 10 — другое дело. Или страница имела бы размер так примерно Мб 50 против 5
FR>>>
PD>>Не жульничай, батенька, не пройдет, нечего тут про CGA режимы писать. Windows может работать минимум с VGA 640*480 режимом. И в нем и 10 лет назад никто не работал, по крайней мере стоял 800*600
PD>>1930 * 1080 / (800 * 600) = 4.32
M>Фигня, что я про это уже написал: http://rsdn.ru/forum/flame.comp/4054699.1.aspx
А я не тебе отвечал. Мне написали. я ответил, заодно и на некоторое передергивание указал. Но впрочем, если ты хочешь закрепить за собой права первооткрывателя в области сравнения размеров экрана тогда и сейчас, готов ходатайствовать , чтобы тебе эти права присвоили
PD>А я не тебе отвечал. Мне написали. я ответил, заодно и на некоторое передергивание указал. Но впрочем, если ты хочешь закрепить за собой права первооткрывателя в области сравнения размеров экрана тогда и сейчас, готов ходатайствовать , чтобы тебе эти права присвоили
Теперь пройди по этой ссылке и почитай еще раз, что там написано, включая свои слова и слова rusted.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Зачем писать свой если есть уже готовй ? Его доточить под конкретную задачу — уменьшить потребление памяти при увеличении быстродействия и повышении качества выходного кода.
PD>То. что они умели писать хороший код — я не спорю, а оптимизировать незачем, потому что этот компилятор никому не нужен. Ты обещал написать свой компилятор + остальное в 64 Кбайтах. Вот и пиши. Можешь на js, можешь на чем-то ином
Ты спросил, сколко понадобится памяти — я тебе ответил. Компилятор почти такого же языка у меня есть с исходным кодом
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>И да, 15 лет тому назад это было невозможно. Даже в локальных сетях.
PD>Обоснуй. Скорость передачи пусть даже 10 Мбит/сек вполне достаточная для передачи этих изменений, у меня и сейчас 10 Мбит, так что здесь ничего нового. Игры в локальной сети и тогда были, вполне работали.
Игры того времени это детский лепет.
Игры умели PDF рендерить ?
PD>Что такое имеется в редактировании текста, что невозможно было бы сделать в совместной работе при 256 Мб и 667 MHZ ?
Ты опять хочеш свети задачу к маленькой подзадаче.
PD>Я никогда такими редакторами не интересовался, но вот поискал в Интернете, и вот такая ссылка, например. Естественно. за качество программы не ручаюсь.
Нужен не редактор, а весь набор приложений.
PD>И кстати, как же, черт возьми, Terminal Service работал-то ? Там ведь именно это и происходит — действия пользователя отсылались на сервер, картинка с сервера — на экран пользователя.
Это офисное приложение, да ? Или может он PDF умел рендерить ?
PD>Вот и все. Просто вы и впрямь решили, что с web-программированием открылась новая эра, а раньше ничего подобного не было.
Раньше для этого надо было десятки программ устанавливать, конфигурировать, сопровождать и тд.
А сейчас это все в одной — в браузере.
PD>Помню, мне как-то Синклер доказывал про неизмеримую сложность изображения карт Google maps в броузере
Он доказывал тебе не сложность отрисовки, а сложность создания приложения Google Maps.
>А я ему объяснял, что изображение битовых карт было известно еще во времена Win 3.0 и вполне быстро работало на тех компьютерах, и диалоги тоже. Вот передавать такие карты с хорошей скоростью тогда не могли, верно, да и карт не было. А нарисовать — что за проблема-то ?
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Может быть. Я его не то что совсем не знаю, а ... так себе. Но ты и впрямь заявишь, что он сложнее того же С++ в N раз ? Чему N равно ?
P>Ты и впрямь считаешь, что я такое заявлю? А вот, судя по твоему вопросу, ты уже знаешь, чему равен N. Озвучишь?
Не, не. Такое заявить должен любой. js сложнее С++ в N раз — тут ничего ещещ не сказано. Гора больше мыши в N раз — что, неверно ?
Вопрос, чему N равно.
Я — не знаю, но полагаю, от 0.5 до 2.
А впрочем, тут где-то Икемефула приводил ссылку на сравнение по числу фич. Хотя это не очень точный критерий.
PD>>Он был очень сильно оверлейный. Так что 96 К — это потребность в ОП, но далеко не объем компилятора.
P>И компилятор PL/1 был шестипроходным. И что? По-моему, изначально обсуждалась именно потребность в ОП, а не объем компилятора.
+
P>Это TP 1.0 образца 1983 года. Тогда еще было до фига компьютеров с 64 К памяти. А что с TP 7.0, не подскажешь?
640. Работал у меня на машинах с 1 Мб без винчестера — школьный класс PS/2, где я вел кружок. На оставшиеся 384 К я его хелп засунул и библиотеки (tpu)
PD>>Нет, не верований. А просто на основе интерполяции имеющихся данных. Вот смотри. PL/1 (жуткий монстр) — 96 К. Фортран OE (с оптимизацией) — 256 К. Досовские компиляторы — 640 К. Первые Windows компиляторы — 1-2 М. BC++ 3.1 — до 4 М.
P>И как сюда вписывается JS? Он появился позже названных тобой продуктов. Тогда это не интерполяция, а экстраполяция. А там все сложнее. Ну и опять про выполнение забыл.
Конечно, экстраполяция. Всегда экстраполяция. На кой мне интерполяция — обсудить, сколько должен бы занимать несозданный компилятор ?
P>А что не так? Ты всегда сразу знаешь, что будет, а что не будет работать?
Стараюсь
>А если не знаешь — то бери больше и кидай дальше. И пока летит — отдыхай.
Не-а, не выйдет. Лететь слишком долго будет, а меня уволят за слишком частый отдых
P>Я тоже 2 недели могу ходить с отрешенным видом. Но совсем без прикидок? Ты сам сказал: тебе показалось приемлемым? Но так ли это на самом деле?
Да, было так. Прикидки были только в уме. Я не делал тестовых примеров, потому что и так понимал, во что мне что обойдется.
PD>>У меня на этот счет иные сображения. Если изнавчально была выбрана неподходящая в своей основе модель, то ее не улучишь, а пытаясь улучшать — получишь только субоптимизацию. Узкое место ты на 10% улучшишь, верно, потом еще одно узкое на 20%, а то, что можно было бы в 10 раз — никогда и не узнаешь.
P>Дак сначала выяснить нужно, подходящая она или нет. Если есть несколько вариантов (а в большинстве случаев это так), понять, что верно, а что нет, путем только медитации, по-моему, несколько затруднительно.
Почему ? Есть же в конце концов простые соображения. O(N), O(NLogN), O(N^2), однопроходный, двухпроходный, время чтения с диска...
PD>>>>>>Допустим, что в этом случае это именно так. Но я вижу множество случаев, когда это далеко не так. А просто транжирят память без зазрения совести.
P>>>Ну так подскажи им, как правильно должно быть.
PD>>А ты не видишь, что получается, когда я им пытаюсь это объяснить ? Проще выйти без бандерильи на бешеного быка
P>Я было подумал, что ты говоришь о каком-то конкретном проекте, в котором тебе разбираться пришлось, а ты, оказывается, опять за свое. Объяснения всех твоих оппонентов кажутся мне более убедительными.
Дело твое.
PD>>Так можно зарплату хоть в 640 К уложить ? Кстати, ее расчет не сильно усложнился с тех времен. Сказать проще — никак не усложнился
P>Можно. Беда в том, что не нужно. Еще в конце прошлого века стали появляться интегрированные системы управления предприятием. Они включали все: от учета основных средств до картотеки посетителей медпункта. Нормальный клиент-сервер, удаленный доступ, разграничение прав. А это все запихать в 640 К несколько затруднительно.
Да я и не спорю, что это удобнее. И сколько им памяти нужно, не знаю. Но не уверен, что именно столько, сколько действительно необходимо для такой задачи.
P>>>А какая разница, если память выделяется один раз?
PD>>Разница в том, что другим не хватит, если лишнее брать
P>Почему лишняя? В случае отказа от рекурсии ты обязан ее выделить.
Что-то я не пойму, о чем мы. О Фортране ? Я уже сказал, что я тут думаю — инструмент неудачный. О выделении памяти вообще ? Выделить надо, но потом можно освободить.
>Или я что-то забыл? Тогда покажи нерекурсивный quicksort без "лишней" памяти.
Не знаю такого
P>>>Если ты будешь писать на C нерекурсивную версию быстрой сортировки, зная, что вызываться она будет постоянно, неужели на каждом шаге будешь память выделять/освобождать?
PD>>Черт знает. От задачи зависит.
P>Именно! И таких "черт знает" слышно все время на протяжении всего процесса разработки и, я не побоюсь этого слова, сопровождения.
PD>>>>Я, честно говоря, на Фортране ее, кажется, ни разу не употреблял.
P>>>Прямую — нет. А косвенную можно было организовать, пользуясь тем, что компилятор не может проверить, что передалось в подпрограмму, где оно объявлено EXTERNAL.
PD>>И прямую можно было. Фортран ОС РВ, например.
P>Вот опять. Не употреблял, а рассуждаешь. Я говорю здесь о том, что сам сделал. MSF 5.1 рекурсию не поддерживал.
А Ф4 ОС РВ — да. В документации было написано. А я документации верю
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>Вот опять. Не употреблял, а рассуждаешь. Я говорю здесь о том, что сам сделал. MSF 5.1 рекурсию не поддерживал.
PD>А Ф4 ОС РВ — да. В документации было написано. А я документации верю
Наверное в том случае, если тебя таки заставят прочесть эту документацию
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Чему N равно ?
P>>Ты и впрямь считаешь, что я такое заявлю? А вот, судя по твоему вопросу, ты уже знаешь, чему равен N. Озвучишь?
PD>Не, не. Такое заявить должен любой. js сложнее С++ в N раз — тут ничего ещещ не сказано. Гора больше мыши в N раз — что, неверно ?
Я ведь заявил на весь форум, что не знаю js. По-твоему логично, если я сейчас начну сравнивать его с C++, который, кстати, тоже видел последний раз пару лет назад, а может больше? Да за такое сравнение меня сразу в дурдом отправят, потому что рассуждать о том, чего не знаешь — это симптом. А я, по мнению окружающих, пока в порядке.
P>>Это TP 1.0 образца 1983 года. Тогда еще было до фига компьютеров с 64 К памяти. А что с TP 7.0, не подскажешь?
PD>640. Работал у меня на машинах с 1 Мб без винчестера — школьный класс PS/2, где я вел кружок. На оставшиеся 384 К я его хелп засунул и библиотеки (tpu)
Надеюсь, здесь ты не будешь утверждать, что TP 7 слишком прожорлив? Или отладчик, подсветка синтаксиса, многооконность не нужны?
P>>И как сюда вписывается JS? Он появился позже названных тобой продуктов. Тогда это не интерполяция, а экстраполяция. А там все сложнее. Ну и опять про выполнение забыл.
PD>Конечно, экстраполяция. Всегда экстраполяция. На кой мне интерполяция — обсудить, сколько должен бы занимать несозданный компилятор ?
А про выполнение опять не вспомнил.
P>>А что не так? Ты всегда сразу знаешь, что будет, а что не будет работать?
PD>Стараюсь
Значит, не всегда, все-таки. Ясно, чудес не бывает. И как тогда?
>>А если не знаешь — то бери больше и кидай дальше. И пока летит — отдыхай.
PD>Не-а, не выйдет. Лететь слишком долго будет, а меня уволят за слишком частый отдых
Тогда подумай над оптимизацией процесса разработки.
PD>Да, было так. Прикидки были только в уме. Я не делал тестовых примеров, потому что и так понимал, во что мне что обойдется.
Так бывает, если точно знаешь, в каких пределах ты находишься и никогда из них не выскочишь.
P>>Дак сначала выяснить нужно, подходящая она или нет. Если есть несколько вариантов (а в большинстве случаев это так), понять, что верно, а что нет, путем только медитации, по-моему, несколько затруднительно.
PD>Почему ? Есть же в конце концов простые соображения. O(N), O(NLogN), O(N^2), однопроходный, двухпроходный, время чтения с диска...
Только строгий анализ и тесты. Всегда можно нарваться на особый случай. Например, диск находится в сети. И все эти O меняются в зависимости от условий.
PD>Да я и не спорю, что это удобнее. И сколько им памяти нужно, не знаю. Но не уверен, что именно столько, сколько действительно необходимо для такой задачи.
Но, похоже, уже веришь, что больше, чем нужно. Без всяких на то оснований. А основание простое. Сравни TP 1 и TP 7.
P>>>>А какая разница, если память выделяется один раз?
PD>>>Разница в том, что другим не хватит, если лишнее брать
P>>Почему лишняя? В случае отказа от рекурсии ты обязан ее выделить.
PD>Что-то я не пойму, о чем мы. О Фортране ? Я уже сказал, что я тут думаю — инструмент неудачный. О выделении памяти вообще ? Выделить надо, но потом можно освободить.
Я тебе привел пример, где выделение лишней памяти существенно сокращает время выполнения функции. Реализация Quicksort на Ф4 из-за отсутствия в последнем рекурсии требует дополнительного массива. Может, тебе это покажется надуманным, но это реальный пример из реального проекта. А потом я что-то увлекся. Так все-таки, почему этот дополнительный массив — не аргумент? Классика ведь: время экономится за счет увеличения требуемой памяти. Все строго в рамках закона.
>>Или я что-то забыл? Тогда покажи нерекурсивный quicksort без "лишней" памяти.
PD>Не знаю такого
Вот именно. И что, повторю, с дополнительным массивом? Получается, что нужен он? все-таки аргумент?
P>>>>Если ты будешь писать на C нерекурсивную версию быстрой сортировки, зная, что вызываться она будет постоянно, неужели на каждом шаге будешь память выделять/освобождать?
P>>Вот опять. Не употреблял, а рассуждаешь. Я говорю здесь о том, что сам сделал. MSF 5.1 рекурсию не поддерживал.
PD>А Ф4 ОС РВ — да. В документации было написано. А я документации верю
Я, в общем, тоже. Хотя иногда нахожу в ней неточности. Тогда, может, почитаешь про js? Многие вопросы уйдут за пару часов, а на остальные тебе, думаю, в форуме ответят.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Eugeny__, Вы писали:
E__>>В том-то и дело.
E__>>Например, вот тут краткое описание возможностей современной IDE. Причем практически каждая из приведенного списка фич сама по себе сильно(некоторые — в разы) сложнее всей IDE для паскаля. Очень рекомендую Павлу для ознакомления. Там не сухие доки, а нормальное описание человеческим языком с картинками — читается легко. Просто для ознакомления.
I>Смотри, как на это может ответить Дворкин:
I>"Ну что там такого в этом списке ? Navigation and Search ? Да Search был в турбопаскале а это 20 лет назад ! I>Code Duplicates Detection ? Так пишите нормально и учитесь код читать и не нужны будут такие фичи."
Хоть так — и то хорошо бутет. Я влегкую найду там весьма сложные и нужные штуки.
Кстати, в этом списке далеко не все. Нет вообще описания мастеров, которых очень много, и они выполняют колоссальную работу.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Mamut, Вы писали:
M>>>Толкьо что-то мне подсказывает, что ни JIT'а там не было
PD>>Не было. Нужен он там как зайцу стоп-сигнал или как тот же JIT современному коду, оттранслированнному с неуправляемого C++. По той же причине.
M>Действительно. Речь о TP vs JS а Дворкин говорит о С++. Так вот, в современных JS JIT есть.
>>>ни run-time optimizations
PD>>Ее и сейчас в С++ нет — некому ей заниматься и незачем. И без нее код с ++ быстрее.
M>Действительно. Речь о TP vs JS а Дворкин говорит о С++. Так вот, в современных run-time optimisations есть.
Так, все, довольно. Ты просто начал себя неприлично совсем вести. Сначала ты заявляешь, что в TP не было JIT и этой оптимизации. Я это подтверждаю и объясняю почему. Заодно говорю о том, для примера, что и С++ они не нужен. В ответ — оказывается, я посмел упомянуть C++ в качестве примера, и это, разумеется, недопустимо.
Тратить время на дискуссии с тобой — это тратить его впустую. Дело в том, что ты не брезгаешь никаким способами. Тебе давно уже не нужна никакая истина, тебе нужно во что бы то ни стало доказать, что я неправ. На здоровье. Все, дискуссию с тобой заканчиваю.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Тратить время на дискуссии с тобой — это тратить его впустую. Дело в том, что ты не брезгаешь никаким способами. Тебе давно уже не нужна никакая истина, тебе нужно во что бы то ни стало доказать, что я неправ. На здоровье. Все, дискуссию с тобой заканчиваю.
Он доказывает что аргументы у тебя странные, непонятные, нелогичные и что выглядит это со стороны очень, очень некрасиво.
Более того, на это же тебе указали еще минимум 4 человека
Здравствуйте, Eugeny__, Вы писали:
I>>Смотри, как на это может ответить Дворкин:
I>>"Ну что там такого в этом списке ? Navigation and Search ? Да Search был в турбопаскале а это 20 лет назад ! I>>Code Duplicates Detection ? Так пишите нормально и учитесь код читать и не нужны будут такие фичи."
E__>Хоть так — и то хорошо бутет. Я влегкую найду там весьма сложные и нужные штуки.
Дворкин-стайл:
"Что там сложного ? Поиск текстовых совпадений умели еще в 60х"
E__>Кстати, в этом списке далеко не все. Нет вообще описания мастеров, которых очень много, и они выполняют колоссальную работу.
Дворкин-стайл:
"Что там колоссального ? Мои студенты умеют мастера и визарды писать."
Здравствуйте, Eugeny__, Вы писали:
E__>Ну, геймдев очень, очень специфическая и довольно хаотичная отрасль. Разрешения ростут(а с ними и дикие тормоза), запросы по графике и AI — тоже. Запросы по играбельности меняются. По тематике тоже неясно. Цены на игры невысоки(их и так вчёрную пиратят, повысишь цену — вообще ничего не получишь). Зарплаты обычно невысоки — если проект погорит(ну вот не понравится геймерам что-то, и пиши пропало), то все, покойся с миром. Нанимать мегаспецов, чтобы они за больший деньги сделали производительную гейму глупо. Не понравится игрокам баланс, или еще что-то — и деньги на ветер: купят(скачают), расскажут друзьям и на форумах "не бери — говно" — и плакали денежки. и плевать, что оно работает с 100500 фпс на древнем железе — в неинтересную игру никто играть не будет(а как сделать достоверно интересную, не знает никто). А в интересную — будут, даже если для этого нужно обновить комп.
С геймдевом все намного проще — растут разрешения — растет объем текстур, все упирается в скорость чтения файлов и перекачки их в видюху. Никого же не удивляют высококачественные картинки в глянце, которые и 10 лет назад занимали в фотошопе сотни метров.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, Ikemefula, Вы писали:
I>>Нормально, потому что VS работает и аддоны для нее пишет много контор. Сравни с конкурентами ты поймешь в чем дело.
E__>Ну, потроллим, пивко в крови просит(а Хамон, суко, кончился, и я зол — надо идти в супермаркет, целых 8 минут, а там холодно и мокро).
E__>Ничего, что для Студии самый лучший аддон пишет... Производитель Идеи, ДжетБрэинс — те, кто делает пока что лучшую в мире IDE — но под джаву(а получается комбайн под все что угодно в смешении с любыми языками, в том числе и скриптовыми). Конечно, решарпер неплох, очень неплох, но от Идеи это только тень...
E__>А без Решарпера Студия — УГ, что ни говори. Хотя, это только в сравнении с жабовскими IDE. В сранении с другими — МЕГА УГ все остальное.
Я с VAX как-то справляюсь, и пишут его помидоры. Решарпер вроде хвалят, но для C++ он неприменим.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Mamut, Вы писали:
RW>>а собственно что это и кому доказало? заходишь на какой-то пропиаренный сайт свои <свой браузер> и вылетают ошибки — кому какая разница? говносрач из-за скорости, которая особо юзеру не нужна в обычных сайтах —
M>Самый популярный сайт в мире — Facebook. Зайди, поинтересйся, сколько там яваскрипта.
А я думал что гугл.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Mamut, Вы писали:
RW>>>>разница в 1-2 секунды — кому и что она дает?
M>>>Есть такое понятие — отзывчивость интерфейса. Если на каждое телодвижение в фейсбуке (и так не всегда быстрое) добавить по 1-2 секунды, он будет диким тормозом.
RW>>это все хорошо для того же фейсбука, но посмотрите на обычные сайты, ну хотя бы на кывт — что толку от этой секунды, если загрузка треда происходит явно не за наносекунды
M>Повторю во второй раз
M>Самый популярный в мире сайт, который самостоятельно генерирует 40% заходов только в Штатах, — это facebook. facebok — это самый, что ни на есть обычный веб сайт
M>По России аналогичная ситуация, возможно, с одноклассниками. То есть яваскрипта повсюду сейчас много, пусть и не всегда заметного.
Повторю 2-й раз.
40% не заходов, а траффика. А по заходам гугл вне конкуренции.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
M>>По России аналогичная ситуация, возможно, с одноклассниками. То есть яваскрипта повсюду сейчас много, пусть и не всегда заметного.
Ops>Повторю 2-й раз.
Ops>40% не заходов, а траффика. А по заходам гугл вне конкуренции.
Здравствуйте, Pavel Dvorkin, Вы писали:
>>ни run-time optimizations PD>Ее и сейчас в С++ нет — некому ей заниматься и незачем.
это почему же? вполне нормально оставить на рантайм проверку типа проца, кол-ва итераций цикла, наличия/отсуствия зависимостей по данным (то есть компилятор нагенерит разных вариантов кода, а выбираться, что именно выполнять будет в рантайме)
Здравствуйте, Ops, Вы писали:
Ops>Я с VAX как-то справляюсь, и пишут его помидоры. Решарпер вроде хвалят, но для C++ он неприменим.
Ну, для плюсов это действительно лучшее, что есть. Уж лучше с ним, чем без него. Но у меня сложилось о нем мнение как о глючноватой штуке. Хотя, если привыкнуть, наверное можно не замечать.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
PD>А я не тебе отвечал. Мне написали. я ответил, заодно и на некоторое передергивание указал. Но впрочем, если ты хочешь закрепить за собой права первооткрывателя в области сравнения размеров экрана тогда и сейчас, готов ходатайствовать , чтобы тебе эти права присвоили
Твои слова
"Вот если бы размер экрана увеличился с тех пор раз так в 10 — другое дело. Или страница имела бы размер так примерно Мб 50 против 5"
10 лет назад типичная страница была 50кб размером. 15 лет назад — 5-10.
Сейчас ты спокойно можешь рассчитывать на мегабайты, т.к. для экономии трафика все это жмется.
Итого — увеличение минимум в 10 раз.
По размеру экрана.
10 лет назад это был 800х600 в 16 бит.
Сейчас типичное разрешение это примерно 1280х1024(17") или примерно равное по площади широкоформатное
Увеличение — 4.8 раза только по пикселам. Кроме этого сейчас используется в основном 32 бита, т.е. вдвое больше.
Итого — 4.8 по площади помножить на 2 по расходу на пиксель, это 9.6 раз.
Итого, твои слова "Вот если бы размер экрана увеличился с тех пор раз так в 10 — другое дело. Или страница имела бы размер так примерно Мб 50 против 5"
Размер страницы увеличился в 10 раз (минимум)
Размер данных экрана — в 10 раз (для современных мониторов 20-26" и все 20 будут).
И ты еще с чем то споришь ?
Чисто зла не хватает, такое ощущение что ты арифметики не знаешь.
I>Просто подумай — гуглдокс работает независимо от того, какая у пользователя архитектура компьютера, ОС, версия браузера.
Ну да. Это, например, работает на моей Нокии с Оперой(которая не мини, а мобайл, с полной поддержкой скриптов). Открыть же док файл без кучи геморроя на ней же ну просто не выйдет.
Пока не особо распространено, но веб стремительно идет в массы. И я весьма рад. Чем меньше специализированного софта, тем лучше. Каналы сейчас жирные, доходит до того, что с диска медленее загрузка, чем с инета — почему бы не пользоваться?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>(библиотечные, естественно, опустим). A>>я бы не был так категоричен PD>А я буду. Если речь идет именно о lib. Никто код strcpy не оптимизирует.
нет уж позвольте! речь таки про lib, и strcpy ещё как оптимизируют
никто не мешает насобирать .obj с /GL (примеры для VC), слить их в .lib и затем эти .lib могут использоваться для wpo при /LTCG. про side-effects можно такого можно найти в MSDN.
а конкретно strcpy ещё и под /Oi подпадает, прямо заоптимизируйся.
Здравствуйте, Eugeny__, Вы писали:
I>>Просто подумай — гуглдокс работает независимо от того, какая у пользователя архитектура компьютера, ОС, версия браузера.
E__>Ну да. Это, например, работает на моей Нокии с Оперой(которая не мини, а мобайл, с полной поддержкой скриптов). Открыть же док файл без кучи геморроя на ней же ну просто не выйдет.
А я по твоему говорил про компьютер или про телефон ?
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали:
>>>ни run-time optimizations PD>>Ее и сейчас в С++ нет — некому ей заниматься и незачем. A>это почему же? вполне нормально оставить на рантайм проверку типа проца, кол-ва итераций цикла, наличия/отсуствия зависимостей по данным (то есть компилятор нагенерит разных вариантов кода, а выбираться, что именно выполнять будет в рантайме)
Потому что там чистый машинный код и нет никакой поддерживающей системы. Изменение этого кода может делать только программа сама (самомодифицирующиеся программы, но это экзотика), а если этого нет, то код не изменяется. Проверить тип проца программа может вызовом Win32, а количество итераций цикла управляется обычным способом — писать for( i = 0; i < n; i++) вместо for( i = 0; i < 100; i++) и n вычислять в рантайме
Насчет генерации разных вариантов кода — в принципе идея неплохая, но в варианте неуправляемого кода это будет означать дублирование модулей. Не обязательно всех. Иногда делают — скажем, модуль для CPU и аналогичный модуль для GPU, если он есть. При инсталляции или даже потом выбирается нужный. Не слишком тут много вариантов.
PD>>А я не тебе отвечал. Мне написали. я ответил, заодно и на некоторое передергивание указал. Но впрочем, если ты хочешь закрепить за собой права первооткрывателя в области сравнения размеров экрана тогда и сейчас, готов ходатайствовать , чтобы тебе эти права присвоили
I>Твои слова I>"Вот если бы размер экрана увеличился с тех пор раз так в 10 — другое дело. Или страница имела бы размер так примерно Мб 50 против 5"
I>10 лет назад типичная страница была 50кб размером. 15 лет назад — 5-10.
I>Сейчас ты спокойно можешь рассчитывать на мегабайты, т.к. для экономии трафика все это жмется.
I>Итого — увеличение минимум в 10 раз.
I>По размеру экрана.
I>10 лет назад это был 800х600 в 16 бит.
I>Сейчас типичное разрешение это примерно 1280х1024(17") или примерно равное по площади широкоформатное
I>Увеличение — 4.8 раза только по пикселам. Кроме этого сейчас используется в основном 32 бита, т.е. вдвое больше.
I>Итого — 4.8 по площади помножить на 2 по расходу на пиксель, это 9.6 раз.
I>Итого, твои слова "Вот если бы размер экрана увеличился с тех пор раз так в 10 — другое дело. Или страница имела бы размер так примерно Мб 50 против 5"
I>Размер страницы увеличился в 10 раз (минимум) I>Размер данных экрана — в 10 раз (для современных мониторов 20-26" и все 20 будут).
I>И ты еще с чем то споришь ?
I>Чисто зла не хватает, такое ощущение что ты арифметики не знаешь.
Хорошо тебя арифметике когда-то учили. Если бы не только арифметике...
Если размер экрана увеличился, то в нем можно разместить больше текста. На его форматирование со всеми вашими css, js , DOM и т.д. время нужно. Это да. И на это вам дополнительное по сравнению с 10 лет назад время дать можно. Хотя и скорость процессора вроде как несколько возросла. И количество текста примерно пропорционально площади экрана, а цветовое разрешение тут как бы ни при чем
А вот вывод картинок производят Windows и видеокарта. От того, что суммарная площадь картинок(в пикселях) стала больше, следует, что им (Windows и видеокарте) работы прибавилось, да. Но видеокарты с тех пор хорошо ускорились. Впрочем, главное не это . Главное другое — а вы тут причем ? Как там это, хорошо или плохо, делают Windows и видеокарта — это их проблема, а ваша тут заслуга в чем ? Ваше дело — тег img обработать и картинку Windows передать вместе с координатами для вывода.
И рендеринг текста после форматирования Windows производит. Тут вы тоже ни при чем. Тут растеризатор TTF будет работать, а не ваш js.
Ну и насчет High Color, который якобы был 10 лет назад. Был, не спорю, я его порой сам ставил, чтобы быстрее было. Но опять же — а вы тут причем ? Windows и карта тогда работали с 16 bit HDC быстрее, чем на 32 bit HDC. Вот и все. А исходная картинка задана форматом хотя бы JPG, так что ее все равно где-то там к HBITMAP приводили, и опять же не вы.
Вот если вы эти картинки попиксельно обрабатываете на своем js без использования нативного кода — тогда да.
Здравствуйте, Antikrot, Вы писали:
A>нет уж позвольте! речь таки про lib, и strcpy ещё как оптимизируют
Исходники strcpy.asm VC++ открыты. При работе используется именно ассемблерная версия, проверено. Оптимизировать код, написанный на ассемблере ?
A>никто не мешает насобирать .obj с /GL (примеры для VC), слить их в .lib и затем эти .lib могут использоваться для wpo при /LTCG. про side-effects можно такого можно найти в MSDN.
MSDN:
.obj files produced with /GL and precompiled header files should not be used to build a .lib file unless the .lib file will be linked on the same machine that produced the /GL .obj file.
Так что ответ, видимо, прост . Для своих исходников — да. Но не передавать. Для чужих — нет.
A>а конкретно strcpy ещё и под /Oi подпадает, прямо заоптимизируйся.
Все же не очень пойму, как можно оптимизировать код на ассемблере. Поясни. Или там дизассемблер во 2-й фазе компилятора сидит и чего-то строит ?
Ты горазд читать только первые строчки, потому вывод который должен быть в конце, я помещаю в начало.
Все объяснения, в т.ч. по цвету ниже, потому и обсуждать там.
1 Сегодня процессор+память расходуются как правило на JS + DOM + CSS + Flash + Площадь экрана + Bpp.
2 10 лет назад процессор+память расходовал в основном DOM + подобие JS + зачатки CSS.
3 Очевидно, увеличение расхода процессор+память на полноценный JS + полноценный СSS + Flash + увеличение площади в 4.8 раза + увеличение цветового разрешения
PD>Если размер экрана увеличился, то в нем можно разместить больше текста. На его форматирование со всеми вашими css, js , DOM и т.д. время нужно. Это да. И на это вам дополнительное по сравнению с 10 лет назад время дать можно. Хотя и скорость процессора вроде как несколько возросла. И количество текста примерно пропорционально площади экрана, а цветовое разрешение тут как бы ни при чем
Площадь экрана выросла минимум в 4.8 раз, если сравнивать с нынешними 17" и ноутбуками.
Мне лень считать среднее разрешение, но очевидно это больше по площади чем 1280х1024, потому что новые мониторы это от 20" и выше а их доля суммарная не ниже 30%.
Цветовое разрешение влияет на количество памяти, ты мог бы не паясничать, как будто тебе не ясно.
PD>И рендеринг текста после форматирования Windows производит. Тут вы тоже ни при чем. Тут растеризатор TTF будет работать, а не ваш js.
Рендеринг html со всеми потрохами кстати говоря, тоже жрёт, кроме процессора, еще и память и bpp здесь играет роль.
Просто пойми — никто не будет рендерить баннер или абзац текста по десять раз.
Догадайся, за счет чего это ускорение ?
Т.е. если не считать ни DOM, ни JS, то окажется что рендеринг сам по себе ёмкая по ресурсам операция.
10 лет назад рендеринг был много проще — CSS того же считай не было.
Ты вообще понимаешь, что такое CSS ?
Чуть не на каждой страничке сейчас есть баннер на флеше. Ты понимаешь, что такое флеш ? А он сам ест и память и процессор.
10 лет назад ничего этого просто не было.
>Хотя и скорость процессора вроде как несколько возросла
Да, я слышал, "не пугай меня аббревиатурами". А между тем на каждую аббревиатуру нужен и процессор и память.
Здравствуйте, Klatu, Вы писали:
K>Здравствуйте, Ikemefula, Вы писали:
I>>Нормально, потому что VS работает и аддоны для нее пишет много контор.
K>Это разве оправдывает говнокод?
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, Ops, Вы писали:
Ops>>Я с VAX как-то справляюсь, и пишут его помидоры. Решарпер вроде хвалят, но для C++ он неприменим.
E__>Ну, для плюсов это действительно лучшее, что есть. Уж лучше с ним, чем без него. Но у меня сложилось о нем мнение как о глючноватой штуке. Хотя, если привыкнуть, наверное можно не замечать.
Глюков мало, хоть и встречаются. Из критичных — иногда слетает кастомная подсветка сразу после загрузки IDE (у меня в редакторе темный фон и соответствующая раскраска, а дефолтная рассчитана на светлый фон, так что критично), не всегда выдает подсказки по параметрам функции.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
I>Ты горазд читать только первые строчки, потому вывод который должен быть в конце, я помещаю в начало. I>Все объяснения, в т.ч. по цвету ниже, потому и обсуждать там.
I>1 Сегодня процессор+память расходуются как правило на JS + DOM + CSS + Flash + Площадь экрана + Bpp. I>2 10 лет назад процессор+память расходовал в основном DOM + подобие JS + зачатки CSS. I>3 Очевидно, увеличение расхода процессор+память на полноценный JS + полноценный СSS + Flash + увеличение площади в 4.8 раза + увеличение цветового разрешения
А Flash на js сделан ?
Про разрешение см. ниже.
PD>>Если размер экрана увеличился, то в нем можно разместить больше текста. На его форматирование со всеми вашими css, js , DOM и т.д. время нужно. Это да. И на это вам дополнительное по сравнению с 10 лет назад время дать можно. Хотя и скорость процессора вроде как несколько возросла. И количество текста примерно пропорционально площади экрана, а цветовое разрешение тут как бы ни при чем
I>Площадь экрана выросла минимум в 4.8 раз, если сравнивать с нынешними 17" и ноутбуками.
I>Мне лень считать среднее разрешение, но очевидно это больше по площади чем 1280х1024, потому что новые мониторы это от 20" и выше а их доля суммарная не ниже 30%.
I>Цветовое разрешение влияет на количество памяти, ты мог бы не паясничать, как будто тебе не ясно.
Только если карты хранятся в виде DIB и разрешение 32 вместо 16. Но JPG сам по себе не зависит от разрешения дисплея, у него свой формат. А промежуточная DDB для рисования хранится в системной части АП и в объем памяти юзеровской не входит. Она вообще может в видеопамяти храниться. А битовые карты в формате DIB хранятся так, как они заданы, то есть вполне могут быть в формате, не совпадающем с форматом дисплея. DIB в формате 16 — экзотика. См. CreateDIBSection, например или даже CreateDIBitmap. Можно иметь исходную картинку в формате 8bpp и выводить на дисплей 32 bpp. И в какой именно формат там переводят внутри JPG, я не знаю. Если в DIB, то совсем не обязательно по формату текущего дисплея. А если в DDB — то это не влияет на объем памяти в юзеровской части.
Краткий вывод — объем памяти в системной части будет больше, в юзеровской — скорее всего нет.
Вот тебе и паясничать. Учи основы.
PD>>И рендеринг текста после форматирования Windows производит. Тут вы тоже ни при чем. Тут растеризатор TTF будет работать, а не ваш js.
I>Рендеринг html со всеми потрохами кстати говоря, тоже жрёт, кроме процессора, еще и память и bpp здесь играет роль.
Никакого рендеринга текста у вас нет. Есть его (из html или сформированного или с помощью js или как-то иначе) анализ , форматирование строк для вывода (с помощью CSS и т.д.) и вывод текстовых строк средствами Windows. Вы у себя текст готовите (это да, об этом я говорил), а потом вызывается что-то вроде TextOut или DrawText. А вот дальше — не ваше дело. Этим займется растеризатор шрифта, который находится, скорее всего, в win32k.sys, то есть опять же в ядре.
Рендеринг — это превращение строки в картинку путем рисования букв строки указанным шрифтом. Еще раз — это делает ядро Windows без вашего участия.
I>Просто пойми — никто не будет рендерить баннер или абзац текста по десять раз.
Еще раз — текст вы не рендерите. Вы только указываете шрифт, string и координаты. А дальше броузер делает CreateFontIndirect, выбирает этот шрифт в HDC, передает строку в TextOut — и на этом его работа закончена. Остальное делает Windows.
I>Догадайся, за счет чего это ускорение ?
I>Т.е. если не считать ни DOM, ни JS, то окажется что рендеринг сам по себе ёмкая по ресурсам операция.
Видимо, ты не то понимаешь под рендерингом именно текста. Или не понимаешь, как он делается.
Вот, например, в HTML есть строка "Компания разрабатывает чего-то там и т.д.". Длинная строка. Как ее хорошо вывести, то есть как разбить на куски, отформатировать — это ваша и броузера работа, верно. А вот как только для кусков броузер определил, где какой кусок текста будет выведен — все, остальное работа Windows.
I>10 лет назад рендеринг был много проще — CSS того же считай не было.
Еще раз — это не рендеринг. Это форматирование.
I>Ты вообще понимаешь, что такое CSS ?
Немного понимаю
I>Чуть не на каждой страничке сейчас есть баннер на флеше. Ты понимаешь, что такое флеш ? А он сам ест и память и процессор.
Ты, кстати, в курсе, что за 10 лет размер страницы и кол.во скриптов увеличилось примерно в 10 раз ?
Твой mail.ru 10 лет назад хорошо если 30кб был, а сейчас он на пол-мега тянет.
Не это ли ты имел ввиду "Вот если бы ... — другое дело. Или страница имела бы размер так примерно Мб 50 против 5" ?
А выясняется что и страницы стали больше, и площадь экрана больше и фич разных больше.
I>>1 Сегодня процессор+память расходуются как правило на JS + DOM + CSS + Flash + Площадь экрана + Bpp. I>>2 10 лет назад процессор+память расходовал в основном DOM + подобие JS + зачатки CSS. I>>3 Очевидно, увеличение расхода процессор+память на полноценный JS + полноценный СSS + Flash + увеличение площади в 4.8 раза + увеличение цветового разрешения
PD>А Flash на js сделан ?
Не знаю, но он работает одновременно с другими фичами в браузере Т.е. ему нужны и процессор и память.
PD>Про разрешение см. ниже.
I>>Цветовое разрешение влияет на количество памяти, ты мог бы не паясничать, как будто тебе не ясно.
PD>Краткий вывод — объем памяти в системной части будет больше, в юзеровской — скорее всего нет.
В какой это системной ? Рендерер в браузере !
PD>Еще раз — текст вы не рендерите. Вы только указываете шрифт, string и координаты. А дальше броузер делает CreateFontIndirect, выбирает этот шрифт в HDC, передает строку в TextOut — и на этом его работа закончена. Остальное делает Windows.
И так по сто раз ? Ты в своем уме ? Это надо сделать один раз при условии что html или css не менялись.
А дальше брать закешированую битмапину и выводить ее, например, при прокрутке или переключению страниц.
Одной битмапины недостаточно, нужно делить страницу на части согласно структуре и все это держать в закешированом виде.
Виндовс всего этого не умеет, потому кеширование это твоя забота, виндовс может восстанавливать контент только для простых случаев.
I>>Т.е. если не считать ни DOM, ни JS, то окажется что рендеринг сам по себе ёмкая по ресурсам операция.
PD>Видимо, ты не то понимаешь под рендерингом именно текста. Или не понимаешь, как он делается.
Ты уже хорошо показал — TextOut
Единственно правильный вывод графики — это швырять битмапы на экран. Битмап подготавливается бровзером с помощью апи виндовса и собственного функционала и швыряется на экран, после чего битмап этот хранится в памяти рендерера до следующей отрисовки. Если меняется html или сss, рендерер сбрасывает все кеши.
PD>Вот, например, в HTML есть строка "Компания разрабатывает чего-то там и т.д.". Длинная строка. Как ее хорошо вывести, то есть как разбить на куски, отформатировать — это ваша и броузера работа, верно. А вот как только для кусков броузер определил, где какой кусок текста будет выведен — все, остальное работа Windows.
А второй раз тоже самое надо делать ? Вот крутнул ты страничку, опять что ли будешь отрисовывать это же через Text Out ?
I>>10 лет назад рендеринг был много проще — CSS того же считай не было.
PD>Еще раз — это не рендеринг. Это форматирование.
CSS усложняет рендеринг ! При этом СSS != рендеринг.
I>>Ты вообще понимаешь, что такое CSS ?
PD>Немного понимаю
Вряд ли, в противном случае ты бы знал как он влияет на рендеринг.
I>>Чуть не на каждой страничке сейчас есть баннер на флеше. Ты понимаешь, что такое флеш ? А он сам ест и память и процессор.
PD>А на чем этот флеш написан ?
Какая разница ? Он требует и память и процессор, а кроме него есть кому и процессор и память потреблять.
Здравствуйте, Pavel Dvorkin, Вы писали:
>>>>ни run-time optimizations PD>>>Ее и сейчас в С++ нет — некому ей заниматься и незачем. A>>это почему же? вполне нормально оставить на рантайм проверку типа проца, кол-ва итераций цикла, наличия/отсуствия зависимостей по данным (то есть компилятор нагенерит разных вариантов кода, а выбираться, что именно выполнять будет в рантайме) PD>Потому что там чистый машинный код и нет никакой поддерживающей системы.
это вопрос терминологии. я например считаю ОС поддерживающей системой.
PD>Изменение этого кода может делать только программа сама (самомодифицирующиеся программы, но это экзотика), а если этого нет, то код не изменяется.
идея не в изменении кода, а в том, что на этапе компиляции нельзя сказать, что будет выполняться. изменить код "по месту" или "выбрать готовый фрагмент кода в зависимости от" — не всё ли равно в данном случае?
PD>Проверить тип проца программа может вызовом Win32,
забей уже на Win32. меня так он вообще не интересует — я больше по линуху. да и далеко не всё оттуда узнаешь.
PD>а количество итераций цикла управляется обычным способом — писать for( i = 0; i < n; i++) вместо for( i = 0; i < 100; i++) и n вычислять в рантайме
не, я совсем не это имел в виду, говоря про "итерации цикла". я про то, что если [оценочное] количество итераций неизвестно (совсем никак, и данных с PGO нет), компилятор может сделать разные версии цикла для разного количества итераций — это влияет на оптимизации циклов. например, если trip count маленький, можно запустить выполнение в том же потоке, а если большой — использовать [авто]распараллеленную версию цикла. а определение числа потоков, в которое оно выполняться будет, отдать на откуп отсутствующей по твоим словам "поддерживающей системе" типа openmp.
PD>Насчет генерации разных вариантов кода — в принципе идея неплохая,
да ей сто лет в обед. используется вполне себе.
PD>но в варианте неуправляемого кода это будет означать дублирование модулей. Не обязательно всех. Иногда делают — скажем, модуль для CPU и аналогичный модуль для GPU, если он есть. При инсталляции или даже потом выбирается нужный. Не слишком тут много вариантов.
так ведь любая оптимизация (ну наверное кроме оптимизации по размеру кода) обычно увеличивает объём
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Твой mail.ru 10 лет назад хорошо если 30кб был, а сейчас он на пол-мега тянет.
PD>Вполне допускаю.
Что значит "допускаю" ?
"Вот если бы ... — другое дело. Или страница имела бы размер так примерно Мб 50 против 5" ?
Ты от своих слов отказался или ты плавно решил признать что порол чушь на протяжении двух недель ?
PD>>>А Flash на js сделан ?
I>>Не знаю, но он работает одновременно с другими фичами в браузере Т.е. ему нужны и процессор и память.
PD>Это верно, конечно, но аргументом таким я бы не гордился. А если там не флеш, а настоящее видео начинает работать ? Ему ведь памяти-то ого-го как надо.
И видео нормально работает Флеш например для видео часто используется.
Аргумент простой — флеш+JS+CSS это обычное дело.
PD>Уф... Я в своем уме. Битовые карты в формате DDB хранятся в системной части АП. Кешировать можно что угодно, хоть битовые карты, но от этого они в ином месте храниться не перестанут. Просто потому, что битовые карты в формате DDB не могут храниться в юзеровской части АП. И все.
Какая разница где это хранится ? Юзерская часть или не юзерская, разницы абсолютно никакой с т.з. потребления памяти процессом.
PD>Совершенно верно. Вот я тебе и объяснил, где эти битмапы хранятся.
А вот в каком АП они хранятся, абсолютно не важно, потому что прибавляешь +5мб картинкой, размер потребелния памяти увеличивается на эти 5мб.
И если раньше надо было 16 bpp, то сейчас 32bpp — т.е. расход только в этой части удвоился.
I>>CSS усложняет рендеринг ! При этом СSS != рендеринг.
PD>(1) CSS усложняет форматирование текста. CSS объясняет, грубо говоря, как его надо нарисовать, какие там отступы, цвета, шрифты и т.д. Это ваша работа.
Здравствуйте, Pavel Dvorkin, Вы писали:
A>>нет уж позвольте! речь таки про lib, и strcpy ещё как оптимизируют PD>Исходники strcpy.asm VC++ открыты. При работе используется именно ассемблерная версия, проверено.
у меня в 2008-ой студии оно в strcat.asm, но неважно
; 7 : char a[1000];
; 8 : char* b = "testtest";
; 9 : strcpy(a,b);
xor eax, eax
$LL3@main:
mov cl, BYTE PTR ??_C@_08HMMPHJPD@testtest?$AA@[eax]
mov BYTE PTR _a$[esp+eax+1004], cl
inc eax
test cl, cl
jne SHORT $LL3@main
хоть близко похоже на то, что у тебя в strcpy.asm? и сразу вопрос — как он "проинлайнил" внешнюю функцию?
PD>Оптимизировать код, написанный на ассемблере ?
зачем оптимизировать, выкинуть нафиг
A>>никто не мешает насобирать .obj с /GL (примеры для VC), слить их в .lib и затем эти .lib могут использоваться для wpo при /LTCG. про side-effects можно такого можно найти в MSDN. PD>MSDN: PD>.obj files produced with /GL and precompiled header files should not be used to build a .lib file unless the .lib file will be linked on the same machine that produced the /GL .obj file. PD>Так что ответ, видимо, прост . Для своих исходников — да. Но не передавать. Для чужих — нет.
нет, ответ сложнее. для своих — как два пальца.
и что это ты не предыдущее предложение показал?
You should not ship a .lib file comprised of .obj files that were produced with /GL unless you are willing to ship copies of the .lib file for all versions of Visual C++ you expect your users to use, now and in the future.
так что даже передавать можно.
а чужие — тоже можно, почему нет-то, если я их сам собираю? если конечно тебе всё чужое пришло в бинарном виде (gentoo rulezz!!), то конечно да, обломс.
A>>а конкретно strcpy ещё и под /Oi подпадает, прямо заоптимизируйся. PD>Все же не очень пойму, как можно оптимизировать код на ассемблере. Поясни. Или там дизассемблер во 2-й фазе компилятора сидит и чего-то строит ?
я конкретно за VC не скажу, сидит ли там дизассемблер во второй фазе
но в случае strcpy, как intrinsic-функции, компилятору вполне может быть доступен (и скорее всего доступен) весь IL-код этой функции. и оптимизируется она, может быть, даже и на первой фазе (хотя не уверен — но это необязательно, можно сделать хоть в 1ой, хоть во 2ой).
вообще, вторая фаза работает не(или не только) с native-кодом, а с дополнительной информацией (c IL-кодом). и если она есть в .lib (а как сделать такой lib, уже сказано, естественно я не про import-lib'ы говорю), то считай на второй фазе доступны "исходники" для этих lib
I>>Не знаю, но он работает одновременно с другими фичами в браузере Т.е. ему нужны и процессор и память.
PD>Это верно, конечно, но аргументом таким я бы не гордился. А если там не флеш, а настоящее видео начинает работать ? Ему ведь памяти-то ого-го как надо. Но это ни ваша заслуга, ни упрек вам. И флеш тоже. И прочие ActiveX.
Видео требует меньше ресурсов, чем, например, отрисовка движущегося текста по всем правилам во флеше. Столкнулись уже. Не, на современных процах и то, и то быстро. Но на процах и видеокартах 3-6 летней давности, да на 2 экрана 1280х1024...
Видео преимущественно занимается видеокарта, и сил у нее хватает. А вот отрисовка текста, как ни странно(хоть нативная, хоть из жабы или флеша) ВНЕЗАПНО весьма тормозит — нынче очень хитрые шрифты, и отрисовывать их дело непростое, показать жпег в разы быстрее в тех же условиях(именно что отрисовать жпег с увеличением от точки до полноэкранки раз в 5 быстрее, чем отрендерить текст от минимального размера до размера одной буквы на экране).
А если это все совмещать — вообще весело выходит. Отрисовку флеша на двух 1280х1024, в которых встроено видео, движущиеся тексты, и другие свистелки(необходимые по заданию), плюс жаба в качестве основной логики + управление девайсами(тут как раз нагрузка малая, но само по себе драйвера девайсов на жабе, мультиплатформенные, звучит странно — но работает аки часы, и занимает как по памяти, так и по процу какие-то стотысячные доли — остальное на гуи ресурсы идет) на минималистичном линухе Генту без лишнего(тупо Х сервер без ничего — безопастность сыграла не последнюю роль в таком решении). И все равно тормозит, приходится оптимизировать. В основном, как не смешно — отрисовку текста — она САМАЯ тяжелая по процессору, притом что ни на есть нативная.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А то, что ты называешь рендерером, есть лишь некий код, который передает тексты подсистеме Win32.
Картинки — может быть. Ренерер текста сейчас сложнее на пару порядков древней пиксельной маски.
PD>>>Еще раз — текст вы не рендерите. Вы только указываете шрифт, string и координаты. А дальше броузер делает CreateFontIndirect, выбирает этот шрифт в HDC, передает строку в TextOut — и на этом его работа закончена. Остальное делает Windows.
Даже если системный — он сильно сложнее. Кроме того, браузеры иногда используют свой рендерер. Сафари — точно, Опера тоже вроде. И текст куда сложнее показать, чем картинку. Пиксельная маска давно в прошлом(ну разве что в консоли, и то в линухе графическая консоль по всем правилам рендерится — все сглаживания и прочее).
I>>И так по сто раз ? Ты в своем уме ? Это надо сделать один раз при условии что html или css не менялись.
Отож, по 100 раз с на порядки более сложными алгоритмами. Если раньше просто заполняли пиксели нужным заданным цветом, то сейчас для каждого пикселя расчитывается цвет по нетривиальным алгоритмам. А тут еще и массовое использование CSS, меняющие все, в том числе и layout.
Отобразить современную страницу инета реально в минимум 100 раз сложнее, чем 10 лет назад(а если мы говорим про гуглдокс — там цифра в 100 раз покажется смешной). Хотите просто и быстро — можно использовать lynx. Он ее отобразит, в отличие от древних версий NN(и быстрее на порядки). Но только то, что сможет, и только в текстовом режиме. А сможет немного, и выглядеть это будет как говно.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
I>Какая разница где это хранится ? Юзерская часть или не юзерская, разницы абсолютно никакой с т.з. потребления памяти процессом.
Увы, но это не так. Память ядра не принадлежит процессу.
Вот простейший тест. Создаем MFC Dialog-Based приложение (не хочешь MFC — делай что-нибудь другое). Добавляем на диалог кнопку и в ее обработчике пишем
void CMyDlg::OnBnClickedButton1()
{
CDC *pDC = GetDC();
HDC hdc = pDC->GetSafeHdc();
m_hBmp = CreateCompatibleBitmap(hdc, 1000, 1000); // описание HBITMAP m_hBmp поместить в класс
ReleaseDC(pDC);
}
Компилируем и запускаем. Запускаем Task Manager. Смотрим потребление памяти. Нажимаем кнопку, можно несколько раз, и смотрим опять. Ничего практически не меняется.
А вот если написать
void CMyDlg::OnBnClickedButton1()
{
CDC *pDC = GetDC();
HDC hdc = pDC->GetSafeHdc();
m_hBmp = CreateCompatibleBitmap(hdc, 1000, 1000);
char* p = new char[100000];
ReleaseDC(pDC);
}
то потребление увеличивается после нажатия на 100 Кб.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали:
A>>>нет уж позвольте! речь таки про lib, и strcpy ещё как оптимизируют PD>>Исходники strcpy.asm VC++ открыты. При работе используется именно ассемблерная версия, проверено. A>у меня в 2008-ой студии оно в strcat.asm, но неважно A>
A>; 7 : char a[1000];
A>; 8 : char* b = "testtest";
A>; 9 : strcpy(a,b);
A> xor eax, eax
A>$LL3@main:
A> mov cl, BYTE PTR ??_C@_08HMMPHJPD@testtest?$AA@[eax]
A> mov BYTE PTR _a$[esp+eax+1004], cl
A> inc eax
A> test cl, cl
A> jne SHORT $LL3@main
A>
A>хоть близко похоже на то, что у тебя в strcpy.asm? и сразу вопрос — как он "проинлайнил" внешнюю функцию?
PD>>Оптимизировать код, написанный на ассемблере ? A>зачем оптимизировать, выкинуть нафиг
Хм. Проверил сейчас — действительно странно. В Debug вызывается ассемблерная версия, а в Release при /GL — нечто иное. Интересно. Но суть проблемы не меняет — если бы была только ассемблерная версия, то оптимизация все же невозможна.
A>>>никто не мешает насобирать .obj с /GL (примеры для VC), слить их в .lib и затем эти .lib могут использоваться для wpo при /LTCG. про side-effects можно такого можно найти в MSDN. PD>>MSDN: PD>>.obj files produced with /GL and precompiled header files should not be used to build a .lib file unless the .lib file will be linked on the same machine that produced the /GL .obj file. PD>>Так что ответ, видимо, прост . Для своих исходников — да. Но не передавать. Для чужих — нет. A>нет, ответ сложнее. для своих — как два пальца. A>и что это ты не предыдущее предложение показал? A>
A>You should not ship a .lib file comprised of .obj files that were produced with /GL unless you are willing to ship copies of the .lib file for all versions of Visual C++ you expect your users to use, now and in the future.
A>так что даже передавать можно. A>а чужие — тоже можно, почему нет-то, если я их сам собираю? если конечно тебе всё чужое пришло в бинарном виде (gentoo rulezz!!), то конечно да, обломс.
Что значит в бинарном виде ? Тут все в бинарном виде. Ты же lib готов мне дать, без исходников, так ?
A>>>а конкретно strcpy ещё и под /Oi подпадает, прямо заоптимизируйся. PD>>Все же не очень пойму, как можно оптимизировать код на ассемблере. Поясни. Или там дизассемблер во 2-й фазе компилятора сидит и чего-то строит ? A>я конкретно за VC не скажу, сидит ли там дизассемблер во второй фазе A>но в случае strcpy, как intrinsic-функции, компилятору вполне может быть доступен (и скорее всего доступен) весь IL-код этой функции.
Но не для асма.
>и оптимизируется она, может быть, даже и на первой фазе (хотя не уверен — но это необязательно, можно сделать хоть в 1ой, хоть во 2ой). A>вообще, вторая фаза работает не(или не только) с native-кодом, а с дополнительной информацией (c IL-кодом). и если она есть в .lib (а как сделать такой lib, уже сказано, естественно я не про import-lib'ы говорю), то считай на второй фазе доступны "исходники" для этих lib
Если код транслирован с С++, то да, на второй фазе доступны эти "исходники". Но что там может быть в них, если код на асме ?
Здравствуйте, Eugeny__, Вы писали:
E__>Отобразить современную страницу инета реально в минимум 100 раз сложнее, чем 10 лет назад(а если мы говорим про гуглдокс — там цифра в 100 раз покажется смешной). Хотите просто и быстро — можно использовать lynx. Он ее отобразит, в отличие от древних версий NN(и быстрее на порядки). Но только то, что сможет, и только в текстовом режиме. А сможет немного, и выглядеть это будет как говно.
Только давай все же уточним. Выполнить действия для разметки текста (говорю только о нем) сейчас действительно намного сложнее, и это работа броузера. Я не буду спорить насчет 100 или не 100 раз, но в целом верно.
Выполнить же действия по рисованию этого текста я тоже не знаю, во сколько раз сложнее, чем раньше. Формат TTF не изменился (правда, OTF добавили), так что если что и усложнилось — то все эти сглаживания и прочие спецэффекты. Но это уже работа не броузера, а Windows, и выполняется она не только для окна броузера, а и для других окон.
Конечно, если вы сами парсите TTF, рисуете сплайны и т.д — тогда это ваши проблемы.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Только давай все же уточним. Выполнить действия для разметки текста (говорю только о нем) сейчас действительно намного сложнее, и это работа броузера. Я не буду спорить насчет 100 или не 100 раз, но в целом верно.
Вот про это речь и идёт, это rendering, layout и тд
PD>Выполнить же действия по рисованию этого текста я тоже не знаю, во сколько раз сложнее, чем раньше. Формат TTF не изменился (правда, OTF добавили), так что если что и усложнилось — то все эти сглаживания и прочие спецэффекты. Но это уже работа не броузера, а Windows, и выполняется она не только для окна броузера, а и для других окон. PD>Конечно, если вы сами парсите TTF, рисуете сплайны и т.д — тогда это ваши проблемы.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Что-то я никак не пойму, почему и ты и Мамут пристали ко мне с этим выполнением. Я решительно не понимаю, какое это отношение имеет к потребностям компилятора.
P>А разве не ты перваы сказал о том, что js в Chrome слишком прожорлив? Речь ведь об исполнении шла, нет? И потом, чем отличается исполнение программы на твоем любимом TP от js, объяснено на этом форуме минимум тремя участниками, причем некоторыми из них — более одного раза, причем так, что даже до меня, смею думать, дошло. Стоит ли захламлять форум еще одним таким же, или очень похожим, постом?
До меня это дошло давно, но в корректности этого ответа я не уверен. А вот сформулированный в общем виде вопрос твой насчет потребностей памяти любой программы, откомпилированной TP, изволь пояснить.
PD>>Тогда это будет значить, что я не был достаточно профессионален и не сумел найти правильное решение. Плохо то есть. Придется, скорее всего, все с начала.
P>А если двигаться итеративно, то не всегда откат идет до самого начала. Потому что всегда можно вовремя увидеть уход в сторону. Теоретические расчеты, по-моему, стоит проверять экспериментально. Опять же затрты в конечном итоге ниже.
Ладно, давай это закончим. У нас тут разные подходы явно.
P>Сетевой диск — не более, чем пример. Можно обобщить: каждый компонент в отдельности летает, а при интеграции всегда есть шанс поймать нехилые тормоза.
Это означает сильную связанность системы.
>И если строить компонент сразу от начала до конца, причину такого поведения выявить, imho, гораздо сложнее, чем если двигаться не спеша. Потому что ты видишь реальное поведение программы. При теоретических расчетах ныкоторыми подробностями всегда пренебрегают, а в них, в этих мелочах, собака и зарыта.
Ладно.
PD>>Где, на Ф4 ? Там иначе просто невозможно. На Win32 ? Я тебе тут разные способы приведу, как выделить и при этом не выделить и т.д.
P>Не понял, ты считаешь, что на Ф4 выделение памяти ускоряет вычисления, а в других системах — нет?
Не, я просто считаю, что коль скоре в Ф4 я другого способа не имею, то остается только этим пользоваться. В других системах я имею другие возможности, кроме статического выделения.
P>Динамическое выделение/освобождение памяти, ЕМНИП, не самая дешевая операция.
Смотря как ее делать
P>При выполнении тяжелых расчетов удобнее выделять ее сразу везде, где только можно.
Есть разные способы. Можно, например, только резервировать, а коммитировать потом, и не целиком, и не подряд.
P>Не, ну можно написать свою систему управления памятью, которая будет работать очень быстро. Но этой системе нужна память, которой можно управлять, а ее опять-таки выделяют сразу при запуске.
С чего это вдруг. Ты, видимо , с VirtualAlloc просто незнаком. Посмотри MEM_RESEVRVE и MEM_COMMIT. Не только не при запуске, но и не в самом даже начале можно АП зарезервировать, а потом часями коммитировать.
>И тогда, с точки зрения системы, объем памяти, занимаемый программой, не меняется, а что происходит внутри программы, ОС не интересует.
Нет, VirtualAlloc — это вызов ядра, а поэтому систему это интересует.
P>И когда в памяти находятся некие данные, она выделена или нет?
P>Вопрос в целесообразности постоянного выделения/освобождения. Если такая память мне нужна на каждой итерации, на фига мне все время ее выделять на входе и освобождать на выходе, рискуя, к тому же, нарваться на какой-нибудь OutOfMemory?
Ясно. Если коротко — в Win32 для этого сного механизмов. Согласен, что наиболее быстрым по верени будет "Выделить все сразу на максимум", но при этом потребности могут быть чудовищными на ровном месте. А также есть несколько иных механизмов, которые позволяют по максимуму не выделять, выделять динамически, peak потребности по памяти при этом может оказаться меньше в десятки и сотни раз.
PD>>Почему-то вы все решили, что я его совсем уж не знаю. Вот о Хаскеле, действительно, высказываться не буду — я его совсем не знаю. А о js представление вполне имею.
P>Ну так и погоняй на нем скрипты и посмотри, куда его rumntime память девает.
Или ты меня не хочешь понять, или не можешь. Я как-то объяснил, почему я не хочу смотреть. И привел пример с VS 2010 против VS 2008.
///////////
PD>Не знаю. Меня тут Мамут тысячекратно обвинял в том, что я не хочу заглянуть в исходники. А я действительно не хочу. Зачем ? Ну загляну я в них, и что дальше ? Дальше возможны следующие варианты
1. Я их анализирую и говорю, где можно лучше сделать . Понятно, что это несерьезно, мне на это и месяцев не хватит.
2. Я их анализирую и, потрясенный их мощью, изяществом и оптимальностью, признаю себя неправым. Тоже не реально и по той же причине.
А вот контрпример. Показывают мне некую IDE, занимает 80 Мб без открытого солюшена, и говорят — смотри, как хорошо сделано. А я говорю — не очень-то хорошо. Да ты ничего не понимаешь, отвечают мне. Посмотри исходники и убедись.
А я отвечаю — не нужны мне ваши исходники, и не буду я их смотреть. По очень простой причине — вот вам IDE почти с теми же возможностями (ну немного лучше, да), но занимает она всего 35 Мб (до чего я дожил — защищаю IDE, которая занимает 35 Мб . И ее исходники мне тоже не нужны. И смотреть, как там устроено, я не буду, и рекомендовать ничего никому не буду. Я просто констатирую — вот вам IDE почти с теми же возможностями и с потребностью в памяти в 2.5 раза меньше. Это вы обоснуйте — зачяем вам понадобилось в 2.5 раза увеличить, на что вы их потратили ? На то, чтобы с WinForms (опять до чего я дожил — WinForms защищаю на WPF перевести ?
//////////////
Ты на тот пример ничего вроде как по существу не ответил. Так вот, не хочу я смотреть именно из за этого.
PD>>Увы, но это не так. Память ядра не принадлежит процессу.
I>Какая разница где хранится битмап ? Объясни внятно в контексте обсуждаемого ответа.
Мы начали всю дискуссию исходя из тех потребностей в памяти, которые приводятся Task Manager для процесса (A). Память, занятая DDB, не принадлежит процессу, а принадлежит системе, поэтому в объем (A) не входит. Для ее оценки и сравнения у меня средств нет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Выполнить же действия по рисованию этого текста я тоже не знаю, во сколько раз сложнее, чем раньше. Формат TTF не изменился (правда, OTF добавили), так что если что и усложнилось — то все эти сглаживания и прочие спецэффекты. Но это уже работа не броузера, а Windows, и выполняется она не только для окна броузера, а и для других окон. PD>>>Конечно, если вы сами парсите TTF, рисуете сплайны и т.д — тогда это ваши проблемы.
I>>А это называется os interaction layer
PD>ok, понял. Надо сначала о терминах договариваться. Я-то подумал, что ты под рендерингом понимаешь создание попиксельного изображения.
Подсистема для рендеринга/лайоута это если упрощенно, то 4 дерева — 1 объекты, 2 стили, 3 слои и 4 боксы. Все эти четыре дерева хранят информацию о том, как нужно отрисовывать вплоть до координат конкретных элементов, это делается для того, что бы обрабатыать клики мышом.
То есть, память в браузере расходуется на
1. DOM
2. 4 дерева для рендеринга/лайоута — объекты, стили, слои и боксы
3. JS со всеми потрохами — компилер+объекты рантайма+заинлайненый скомпиленый код
4. различные аддоны вроде Flash, что самое обычное дело
5. Кучу всякой мелочевки
Вся эта кухня, согласно последним новостям, занимает более 1.5 млн строк кода на С++, не считая скриптов. При чем бОльшая часть этого кода это именно рендеринг.
Процессорное время расходуется на работу всей этой кухни.
M>>>>Толкьо что-то мне подсказывает, что ни JIT'а там не было PD>>>Не было. Нужен он там как зайцу стоп-сигнал или как тот же JIT современному коду, оттранслированнному с неуправляемого C++. По той же причине.
M>>Действительно. Речь о TP vs JS а Дворкин говорит о С++. Так вот, в современных JS JIT есть.
>>>>ни run-time optimizations PD>>>Ее и сейчас в С++ нет — некому ей заниматься и незачем. И без нее код с ++ быстрее.
M>>Действительно. Речь о TP vs JS а Дворкин говорит о С++. Так вот, в современных run-time optimisations есть. PD>Так, все, довольно. Ты просто начал себя неприлично совсем вести. Сначала ты заявляешь, что в TP не было JIT и этой оптимизации. Я это подтверждаю и объясняю почему. Заодно говорю о том, для примера, что и С++ они не нужен. В ответ — оказывается, я посмел упомянуть C++ в качестве примера, и это, разумеется, недопустимо.
PD>Тратить время на дискуссии с тобой — это тратить его впустую. Дело в том, что ты не брезгаешь никаким способами. Тебе давно уже не нужна никакая истина, тебе нужно во что бы то ни стало доказать, что я неправ. На здоровье. Все, дискуссию с тобой заканчиваю.
Действительно. Тебе про Фому, а ты про Ерему.
Тебе: JS y етолько компилируется, но и выполняется
Ты: Компиляция, Компиляция, Компиляция, Компиляция, Компиляция, Компиляция, Компиляция, Компиляция
Тебе: JS — динамически типизируемый язык, когда он работает, нужны еще и JIT и оптимизации и т.п.
Ты: А вот TP! А вот C++!
Хотя ни ТР ни С++ не являются динамически типизируемыми языками
Тебе: Толпа технологий
Ты: А что там, вывод текста и все.
Хотя в CSS правила по форматированию текста не занимают и 5% от стандарта, наверное.
И после этого ты смеешь утверждать, что я веду дискуссию неправильно? Ты в зеркало-то посмотрись.
P>>А про выполнение опять не вспомнил.
PD>Что-то я никак не пойму, почему и ты и Мамут пристали ко мне с этим выполнением. Я решительно не понимаю, какое это отношение имеет к потребностям компилятора. TP-чистый компилятор, при выполнении он не участвует, даже если компилируем в память. Он не интерпретатор!!!
Потому что в браузере Javascrpt не только компилируется, но и выполняется! До тебя это трудно доходит?
Это ты зациклился на компиляции ТР, а не мы. Хорошо. Компиляция JS тоже помещается в 1 мегабайт. Доволен?
PD>Но если уж так хочется получить от меня ответ про выполнение — пожалуйста.
PD>Программа "Hello, World" будет занимать несколько Кб PD>Та же программа, если к ней добавить массив на 60 Кб — 60 с чем-то Кб PD>Если что-то посерьезнее написать — может, и сотня понадобится. PD>Если уж очень серьезное (по меркам DOS, конечно) — займем все 640 минус то, что заняли MS-DOS и BIOS PD>Если компилятор для Win16 возьмем — потенциально до 16 Мб, предел для 16-битной модели PD>Для Win32 TP не было, это уже Дельфи. Там — как обычно в Win32
PD>Ну и что интересного тут ты нашел ?
Теперь переноси это на Javascript. Например, тебе привели пример с поллумиллионом объектов. ВНЕЗАПНО, если брать по 4 байта на объект, мегабайта не хватит.
Но ты же, как попугай, твердишь только про компиляцию
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>До меня это дошло давно, но в корректности этого ответа я не уверен.
Попробуй заDDoSить Google вопросом о потреблении памяти Хромом. Думаю, что когда тебе это удастся, ты получишь письмо за подписью руководителя разработки Хрома и Брина, в котором все будет расписано до последнего байта.
PD>А вот сформулированный в общем виде вопрос твой насчет потребностей памяти любой программы, откомпилированной TP, изволь пояснить.
Что-то я не могу вспомнить, о чем речь. Считай, что я старый маразматик, но напомни.
PD>В других системах я имею другие возможности, кроме статического выделения.
Эти возможности — не цель, а средство.
P>>Динамическое выделение/освобождение памяти, ЕМНИП, не самая дешевая операция.
PD>Смотря как ее делать
Да как угодно. Если выделять/освобождать слишком часто штатными средствами ОС, можно словить нехилые тормоза при их использовании. А если писать свою систему управления памятью, работать, мопжет, и быстро будет, но тогда затраты на разработку могут превысить все мыслимые пределы. Упревление памятью все же не самая простая часть любой разрабатываемой системы.
PD>Ясно. Если коротко — в Win32 для этого сного механизмов. Согласен, что наиболее быстрым по верени будет "Выделить все сразу на максимум", но при этом потребности могут быть чудовищными на ровном месте.
Почему? Ведь ты выделяешь столько, сколько нужно. Иначе тебе может не хватить байта-другого при динамическом выделении под массив 10000*10000.
PD>Или ты меня не хочешь понять, или не можешь. Я как-то объяснил, почему я не хочу смотреть. И привел пример с VS 2010 против VS 2008.
PD>http://rsdn.ru/forum/flame.comp/4052754.1.aspx
Так ведь ты уже в который раз ничем не обосновываешь свое заявление. Я понимаю: в КСВ аргументация не нужна. Про VS я ничего не говорю именно потому, что не исследовал ее. Я не знаю, разумно она память использует, или нет. Сравнивать ее с предыдущими версиями только по этому критерию, imho, не самый лучший способ.
Здравствуйте, Privalov, Вы писали:
P>Попробуй заDDoSить Google вопросом о потреблении памяти Хромом. Думаю, что когда тебе это удастся, ты получишь письмо за подписью руководителя разработки Хрома и Брина, в котором все будет расписано до последнего байта.
Слушай, ты же не Мамут, попробуй меня понять.
Я верю, что они могут все это расписать.
Но вот смотри. Есть некая программа. Авторы ее готовы подробно опписать, на что им потребляемая память , нужна.
А ты мне предлагаешь оценить, правильно ли они сделали и можно ли меньше ?
Чтобы оценить, мне надо
1. Разобрать их код по косточкам, так, чтобы знать его не хуже всех авторов вместе взятых.
2. Проанализировать тот подход(ы), которые там используются. Сравнить их с другими, если они есть.
3. Провети серьезное профилирование их кода, не только по времени, но и по памяти.
4 И т.д.
А вот Икемефула утверждает, что там (не знаю, в Хроме или нет) только рендеринг — это 1.5 миллиона строк на С++.
Это мне реально сделать за разумное время ? И за неразумное тоже ?
А мне в ответ — да посмотри, как там сделано.
Некая фирма готова точный отчет представить о том, куда деньги потрачены. И отчет там до цента совершенно честный. На 500 страницах.
И дело не в том, что я там уворованные деньги найду. А гораздо серьезнее.
Вот скажите, а этот завод, стоивший 100 млн. долларов — его точно строить надо было ? А может, дешевле было купить его потенциальную продукцию где-то ?
И вообще — а почему завод, построенный в США для тех же целей, обошелся на 50 млн. дешевле ?
Вот и вся причина, почему я не хочу в эти исходники заглядывать и почему мне их отчет не нужен. Тут Счетная Палата нужна со всеми своим экспертами , и то нет гарантии.
PD>>А вот сформулированный в общем виде вопрос твой насчет потребностей памяти любой программы, откомпилированной TP, изволь пояснить.
P>Что-то я не могу вспомнить, о чем речь. Считай, что я старый маразматик, но напомни.
Ладно, бог с ним
PD>>В других системах я имею другие возможности, кроме статического выделения.
P>Эти возможности — не цель, а средство.
P>>>Динамическое выделение/освобождение памяти, ЕМНИП, не самая дешевая операция.
PD>>Смотря как ее делать
P>Да как угодно. Если выделять/освобождать слишком часто штатными средствами ОС, можно словить нехилые тормоза при их использовании. А если писать свою систему управления памятью, работать, мопжет, и быстро будет, но тогда затраты на разработку могут превысить все мыслимые пределы. Упревление памятью все же не самая простая часть любой разрабатываемой системы.
Тут от многого зависит. Слишком часто — это что такое ? Своя система — это что такое ? К примеру, я свою систему писал, но у меня не было удаления, только добавление , так что все было не просто, а очень просто.
PD>>Ясно. Если коротко — в Win32 для этого сного механизмов. Согласен, что наиболее быстрым по верени будет "Выделить все сразу на максимум", но при этом потребности могут быть чудовищными на ровном месте.
P>Почему? Ведь ты выделяешь столько, сколько нужно. Иначе тебе может не хватить байта-другого при динамическом выделении под массив 10000*10000.
Что значит "сколько нужно" ? Это дело динамическое. Вот сейчас мне нужно 100 байт, потом я их отдам, но попрошу 200, потом отдам, но опять 100 попршу. Под разные, замечу, цели. А всего мне надо запросить за время работы программы 10 Гб. Но одновременно суммарно более 1 Мб не нужно
PD>>Или ты меня не хочешь понять, или не можешь. Я как-то объяснил, почему я не хочу смотреть. И привел пример с VS 2010 против VS 2008.
PD>>http://rsdn.ru/forum/flame.comp/4052754.1.aspx
P>Так ведь ты уже в который раз ничем не обосновываешь свое заявление. Я понимаю: в КСВ аргументация не нужна. Про VS я ничего не говорю именно потому, что не исследовал ее. Я не знаю, разумно она память использует, или нет.
Ловлю на слове! А если бы тебе ее исходники открыть — возьмешься исследовать и сделать такой вывод ?
Кстати, IDE написана на дотнете, так что , возможно, исходники можно рефлектором посмотреть, если они не обсфуцированы.
>Сравнивать ее с предыдущими версиями только по этому критерию, imho, не самый лучший способ.
А почему только ? Я что, обязан по всем критериям сравнить ? Я сказал ясно — возможности (при отсутствии открытого солюшена) почти те же, памяти в 2.5 раза больше. Где деньги, Зин ?
PD>>До меня это дошло давно, но в корректности этого ответа я не уверен.
P>Попробуй заDDoSить Google вопросом о потреблении памяти Хромом. Думаю, что когда тебе это удастся, ты получишь письмо за подписью руководителя разработки Хрома и Брина, в котором все будет расписано до последнего байта.
Отправил и решил добавить.
P>>Попробуй заDDoSить Google вопросом о потреблении памяти Хромом. Думаю, что когда тебе это удастся, ты получишь письмо за подписью руководителя разработки Хрома и Брина, в котором все будет расписано до последнего байта.
Вот тебе простой пример.
Некто Dvorkin Pavel решил написать программу, перемножающую 3 матрицы — A,B,C
Для этой цели он завел четвертую матрицу D
Вычислил D = A*B
Вычислил E = D*C.
Все сделано.
К Dvorkin Pavel обращается Privalov с требованием сообщить, куда он потратил каждый байт.
Dvorkin Pavel честно отвечает (см. выше).
Вопрос к Privalov — он может на основании этого честного ответа сделать вывод , что Dvorkin Pavel потратил память правильно ? А ?
Алгоритм-то верный. И подход не то, чтобы уж совсем ущербный, не так ли ?
А между тем не надо тут никакой матрицы D. И без нее можно обойтись.
Но тут 50 строчек от силы. И все равно анализировать надо. Просто по коду — сразу не скажешь. Перемножение двух матриц написано как положено. Оба раза.
А когда строчек сотни тысяч или миллион ?
P.S. Dvorkin Pavel, совсе молодой и начинающий программист, вынужден был искать решение этой задачи на Ф4 лет так 30 назад. Потому что дело происходило на БЭСМ-6 с 32 Килословами ОП. И матрица D означала, что придется уменьшить размеры матриц A,B,C. А это допустить было никак нельзя, так как физическая задача требовала именно таких размеров.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Некто Dvorkin Pavel решил написать программу, перемножающую 3 матрицы — A,B,C PD>Для этой цели он завел четвертую матрицу D PD>Вычислил D = A*B PD>Вычислил E = D*C. PD>А между тем не надо тут никакой матрицы D. И без нее можно обойтись.
а некто Dvorkin Pavel уверен, что без матрицы D не будет медленнее *в любом случае*?
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Некто Dvorkin Pavel решил написать программу, перемножающую 3 матрицы — A,B,C PD>>Для этой цели он завел четвертую матрицу D PD>>Вычислил D = A*B PD>>Вычислил E = D*C. PD>>А между тем не надо тут никакой матрицы D. И без нее можно обойтись. A>а некто Dvorkin Pavel уверен, что без матрицы D не будет медленнее *в любом случае*?
Ну в те времена. когда он это писал, точно не было бы медленнее, потому что про кеш-память никто и не слышал. А сейчас — не уверен, но для того, чтобы заявить, что мол, эту память потратили не зря, надо не тупо на код смотреть, а потратить приличное время — тут от ряда факторов скорость будет зависеть как с 4 матрицами, так и с 3.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>А между тем не надо тут никакой матрицы D. И без нее можно обойтись. A>>а некто Dvorkin Pavel уверен, что без матрицы D не будет медленнее *в любом случае*? PD>Ну в те времена. когда он это писал, точно не было бы медленнее, потому что про кеш-память никто и не слышал. А сейчас — не уверен, но для того, чтобы заявить, что мол, эту память потратили не зря, надо не тупо на код смотреть, а потратить приличное время — тут от ряда факторов скорость будет зависеть как с 4 матрицами, так и с 3.
но не ставит ли это под сомнение вообще "оптимизацию по расходу памяти" (в настоящее время)?
ps. просто как вспомню как извращались с matmul... кроме секундомера в руке, никому уже не верю
Здравствуйте, Antikrot, Вы писали:
PD>>Ну в те времена. когда он это писал, точно не было бы медленнее, потому что про кеш-память никто и не слышал. А сейчас — не уверен, но для того, чтобы заявить, что мол, эту память потратили не зря, надо не тупо на код смотреть, а потратить приличное время — тут от ряда факторов скорость будет зависеть как с 4 матрицами, так и с 3. A>но не ставит ли это под сомнение вообще "оптимизацию по расходу памяти" (в настоящее время)?
В данном случае — не ставит. Удастся ли сделать вариант с 3 матрицами, который работал бы столь же быстро, как и вариант с 4 — не берусь судить. Но и вариант с 4, если его запрограммировать "против шерсти" — будет тоже тормозить. Тут нужен серьезный анализ и тестирование. В результате не исключено, что некий вариант с 3 будет самым быстродействующим.
Я все это к тому, что посмотреть на некие исходники размером в миллион строк и сказать : да, здесь все правильно и разумно, ничего лишнего — не очень, мягко говоря, серьезно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Некто Dvorkin Pavel решил написать программу, перемножающую 3 матрицы — A,B,C PD>Для этой цели он завел четвертую матрицу D PD>Вычислил D = A*B PD>Вычислил E = D*C.
PD>К Dvorkin Pavel обращается Privalov с требованием сообщить, куда он потратил каждый байт.
Имена, как я понимаю, вымышлены, а совпадения случайны?
PD>Dvorkin Pavel честно отвечает (см. выше).
PD>Вопрос к Privalov — он может на основании этого честного ответа сделать вывод , что Dvorkin Pavel потратил память правильно ? А ?
PD>Алгоритм-то верный. И подход не то, чтобы уж совсем ущербный, не так ли ?
Делается все на Windows, оперативы 1Г.
Предполагается, что для двух матриц Dvorkin Pavel провел анализ: погрешности при вычислениях там, ну, в общем все, что требуется. Я понимаю, что умножение двух матриц — не самая серьезная операция в алгебре, но работаем строго по правилам. Тогда Privalov, безусловно, данный алгоритм одобрит, потому как он работает приемлемое время и лишняя матрица особо не мешает.
А вот если Dvorkin Pavel начнет рассказывать, что можно применить другой алгоритм, экономящий память, Privalov потребует провести его строгий численный анализ, не забывая, разумеется, о сроках выполнения и бюджете. Вот нельзя эти составляющие проекта игнорировать.
Потому что в данном случае Privalov — специалист в умножении матриц. И его интересуют: минимизация погрешности вычислений, сроки исполнения. Память есть.
Ну и конкуренция в области умножителей матриц приличная, чего Dvorkin Pavel не может игнорировать. Privalov хочет получить хорошо работающую программу в указанные сроки, чем идеальную неизвестно когда. Потому что у него уже заключены договора на умножение матриц в паре-тройке контор, и его заказчики не хотят и слышать о переносе сроков из-за какой-то экономии одной матрицы.
PD>P.S. Dvorkin Pavel, совсе молодой и начинающий программист, вынужден был искать решение этой задачи на Ф4 лет так 30 назад. Потому что дело происходило на БЭСМ-6 с 32 Килословами ОП. И матрица D означала, что придется уменьшить размеры матриц A,B,C. А это допустить было никак нельзя, так как физическая задача требовала именно таких размеров.
Privalov тоже с подобным сталкивался. В условиях жестких ограничений (бортовой компьютер под MS-DOS) и подход к решению особый, и планируется все по-другому, и бюджет, черт его подери, формируется иначе.
PD>>Алгоритм-то верный. И подход не то, чтобы уж совсем ущербный, не так ли ?
P>Делается все на Windows, оперативы 1Г.
P>Предполагается, что для двух матриц Dvorkin Pavel провел анализ: погрешности при вычислениях там, ну, в общем все, что требуется. Я понимаю, что умножение двух матриц — не самая серьезная операция в алгебре, но работаем строго по правилам. Тогда Privalov, безусловно, данный алгоритм одобрит, потому как он работает приемлемое время и лишняя матрица особо не мешает.
Откуда сведения, что не мешает ? Кто мне говорил про 10000*10000 ? . Но это так, к слову. Пусть не мешает.
P>А вот если Dvorkin Pavel начнет рассказывать, что можно применить другой алгоритм, экономящий память, Privalov потребует провести его строгий численный анализ, не забывая, разумеется, о сроках выполнения и бюджете. Вот нельзя эти составляющие проекта игнорировать.
Тут я чего-то не понял. Почему это при использовании 4 матриц этот самый строгий численный анализ Privalov не требовал привести, а для 4- требовал. Вроде как по количеству матриц априорно никак нельзя сказать, где погрешности при вычислении будут больше. Не связано одно с другим. Так что пусть уж Privalov потребует это в равной мере для обоих алгоритмов.
О сроках выполнения. Молодой Pavel Dvorkin потратил примерно 2-3 часа, пытаясь понять, как эти циклы написать, чтобы без промежуточной
P>Потому что в данном случае Privalov — специалист в умножении матриц. И его интересуют: минимизация погрешности вычислений, сроки исполнения. Память есть.
P>Ну и конкуренция в области умножителей матриц приличная, чего Dvorkin Pavel не может игнорировать. Privalov хочет получить хорошо работающую программу в указанные сроки, чем идеальную неизвестно когда. Потому что у него уже заключены договора на умножение матриц в паре-тройке контор, и его заказчики не хотят и слышать о переносе сроков из-за какой-то экономии одной матрицы.
А вот это серьезнее. Только тут одно "но" есть. Если бы Dvorkin Pavel писал это не в годы своей молодости, а немного позже, то вариант с 4 матрицами просто не появился бы на свет, просто потому, что имея уже некоторый опыт, он тут же заметил бы, что промежуточная матрица не нужна. И времени ушло бы столько же и т.д.
Я ведь этот пример привел не для того, чтобы обсуждать преобразование алгоритма-4 в алгоритм-3. Я о том, что априорно по коду сказать : а можно ли лучше (в любом смысле) — нельзя. Даже для кода в 50 строчек. А от меня требуют — посмотри код размером в миллион строк и признай, что он написан идеально! А может, надо было с самого начала алгоритм-3 употребить ?
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>Предполагается, что для двух матриц Dvorkin Pavel провел анализ: погрешности при вычислениях там, ну, в общем все, что требуется. Я понимаю, что умножение двух матриц — не самая серьезная операция в алгебре, но работаем строго по правилам. Тогда Privalov, безусловно, данный алгоритм одобрит, потому как он работает приемлемое время и лишняя матрица особо не мешает.
PD>Откуда сведения, что не мешает ? Кто мне говорил про 10000*10000 ? . Но это так, к слову. Пусть не мешает.
Так это ж академический пример. В реальном мире 10000*10000 еще получить как-то надо, да еще сохранить где-то.
P>>А вот если Dvorkin Pavel начнет рассказывать, что можно применить другой алгоритм, экономящий память, Privalov потребует провести его строгий численный анализ, не забывая, разумеется, о сроках выполнения и бюджете. Вот нельзя эти составляющие проекта игнорировать.
PD>Тут я чего-то не понял. Почему это при использовании 4 матриц этот самый строгий численный анализ Privalov не требовал привести, а для 4- требовал.
Не торопись, ты, похоже, по диагонали читаешь. Я выделил вверху. Для двух матриц Dvorkin Pavel такой анализ провел, что естественно. Поэтому провести такой анализ для другого случая столь же естественно.
PD>О сроках выполнения. Молодой Pavel Dvorkin потратил примерно 2-3 часа, пытаясь понять, как эти циклы написать, чтобы без промежуточной
Там особые условия. Просто физически памяти нет, вот и приходится извращаться. Я ведь говорил, что в курсе и сам такой был.
PD>А вот это серьезнее. Только тут одно "но" есть. Если бы Dvorkin Pavel писал это не в годы своей молодости, а немного позже, то вариант с 4 матрицами просто не появился бы на свет, просто потому, что имея уже некоторый опыт, он тут же заметил бы, что промежуточная матрица не нужна. И времени ушло бы столько же и т.д.
А если нужно умножать произвольное число матриц? Тогда рекурсивно сводим задачу к умножению двух матриц и всего делов. Предполагаем, что всякие там погрешности вычислений в пределах нормы. Ты же не будешь, в самом деле, писать для каждого количества матриц свой алгоритм?
PD>Я ведь этот пример привел не для того, чтобы обсуждать преобразование алгоритма-4 в алгоритм-3. Я о том, что априорно по коду сказать : а можно ли лучше (в любом смысле) — нельзя. Даже для кода в 50 строчек. А от меня требуют — посмотри код размером в миллион строк и признай, что он написан идеально! А может, надо было с самого начала алгоритм-3 употребить ?
В обычных условиях алгоритм-3, с точки зрения заказчика, не нужен.
Здравствуйте, Privalov, Вы писали:
PD>>Тут я чего-то не понял. Почему это при использовании 4 матриц этот самый строгий численный анализ Privalov не требовал привести, а для 4- требовал.
P>Не торопись, ты, похоже, по диагонали читаешь. Я выделил вверху. Для двух матриц Dvorkin Pavel такой анализ провел, что естественно. Поэтому провести такой анализ для другого случая столь же естественно.
Я все понял, но я же ниже ответил.
PD>>О сроках выполнения. Молодой Pavel Dvorkin потратил примерно 2-3 часа, пытаясь понять, как эти циклы написать, чтобы без промежуточной
P>Там особые условия. Просто физически памяти нет, вот и приходится извращаться. Я ведь говорил, что в курсе и сам такой был.
Я не потому, а просто чтобы показать, что затраты могут и близкими к нулю оказаться.
PD>>А вот это серьезнее. Только тут одно "но" есть. Если бы Dvorkin Pavel писал это не в годы своей молодости, а немного позже, то вариант с 4 матрицами просто не появился бы на свет, просто потому, что имея уже некоторый опыт, он тут же заметил бы, что промежуточная матрица не нужна. И времени ушло бы столько же и т.д.
P>А если нужно умножать произвольное число матриц? Тогда рекурсивно сводим задачу к умножению двух матриц и всего делов. Предполагаем, что всякие там погрешности вычислений в пределах нормы. Ты же не будешь, в самом деле, писать для каждого количества матриц свой алгоритм?
Хм... Я сейчас не поручусь, но сдается мне, что можно написать такой алгоритм для произвольного числа матриц.
PD>>Я ведь этот пример привел не для того, чтобы обсуждать преобразование алгоритма-4 в алгоритм-3. Я о том, что априорно по коду сказать : а можно ли лучше (в любом смысле) — нельзя. Даже для кода в 50 строчек. А от меня требуют — посмотри код размером в миллион строк и признай, что он написан идеально! А может, надо было с самого начала алгоритм-3 употребить ?
P>В обычных условиях алгоритм-3, с точки зрения заказчика, не нужен.
Да нужен, не нужен, не в этом дело. Не об этом же сейчас речь, а о совсем другом. Меня уверяют , что там наилучшее решение. Не просто говорят — мол, для заказчика это приемлемо, а заявляют — посмотри на это решение и убедись, что он очень хорошее. Ты, к примеру, там где говорил, что мне могут отчет дать о каждом потраченном байте. А я в ответ — не в состоянии я оценить, очень оно хорошее или не очень. И привожу тебе пример, когда алгоритм-4 по крайней мере по одному параметру , может быть, не очень, но и на то, чтобы это понять, надо некоторое время потратить.
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>Для двух матриц Dvorkin Pavel такой анализ провел, что естественно. Поэтому провести такой анализ для другого случая столь же естественно.
PD>Я все понял, но я же ниже ответил.
Договорились. Речь в этом месте идет, разумеется, об анализе собственно алгоритма, а не потребляемой памяти. Это я так, во избежание.
P>>Там особые условия. Просто физически памяти нет, вот и приходится извращаться. Я ведь говорил, что в курсе и сам такой был.
PD>Я не потому, а просто чтобы показать, что затраты могут и близкими к нулю оказаться.
Я понимаю. Но глагол "могут" всегда звучит двусмысленно.
PD>Хм... Я сейчас не поручусь, но сдается мне, что можно написать такой алгоритм для произвольного числа матриц.
Да вот я тоже давно матрицами не занимался. Можно — это, конечно, здорово, только снова-таки в полный рост встают все те же вопросы, что и раньше: сроки, бюджет, погрешности...
PD>>>Я ведь этот пример привел не для того, чтобы обсуждать преобразование алгоритма-4 в алгоритм-3.
P>>В обычных условиях алгоритм-3, с точки зрения заказчика, не нужен.
PD>Да нужен, не нужен, не в этом дело. Не об этом же сейчас речь, а о совсем другом. Меня уверяют , что там наилучшее решение. Не просто говорят — мол, для заказчика это приемлемо, а заявляют — посмотри на это решение и убедись, что он очень хорошее.
Для данных условий — домашний комп или даже нетбук — решение действительно очень хорошее. Это видно невооруженным глазом, особенно на не очень мощном нетбуке. А решений, одинаково хорошо работающих в любых условиях, не существует. Я, по крайней мере, о таких не слышал.
PD>Ты, к примеру, там где говорил, что мне могут отчет дать о каждом потраченном байте.
Могут. При условии, что тебе удастся уронить Google соответствующим запросом.
PD>А я в ответ — не в состоянии я оценить, очень оно хорошее или не очень. И привожу тебе пример, когда алгоритм-4 по крайней мере по одному параметру , может быть, не очень, но и на то, чтобы это понять, надо некоторое время потратить.
Конечно. Как вариант — увидеть, что он физически в память не влезает.
P>Для данных условий — домашний комп или даже нетбук — решение действительно очень хорошее. Это видно невооруженным глазом, особенно на не очень мощном нетбуке. А решений, одинаково хорошо работающих в любых условиях, не существует. Я, по крайней мере, о таких не слышал.
Опять же — не то я обсуждаю.
PD>>Ты, к примеру, там где говорил, что мне могут отчет дать о каждом потраченном байте.
P>Могут. При условии, что тебе удастся уронить Google соответствующим запросом.
PD>>А я в ответ — не в состоянии я оценить, очень оно хорошее или не очень. И привожу тебе пример, когда алгоритм-4 по крайней мере по одному параметру , может быть, не очень, но и на то, чтобы это понять, надо некоторое время потратить.
P>Конечно. Как вариант — увидеть, что он физически в память не влезает.
Ну не в этом дело, это крайний случай. Но в принципе — ты согласен, что не могу я дать оценку этому решению, хорошее оно или плохое, на основании изучения исходников или чтения мнения разработчиков, к чему меня тут призывают ?
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>А решений, одинаково хорошо работающих в любых условиях, не существует. Я, по крайней мере, о таких не слышал.
PD>Опять же — не то я обсуждаю.
Тогда я не понимаю, что же ты обсуждаешь.
PD>Но в принципе — ты согласен, что не могу я дать оценку этому решению, хорошее оно или плохое, на основании изучения исходников или чтения мнения разработчиков, к чему меня тут призывают ?
На основании чего тогда твой вердикт об ущербности интерпретатора js в Chrome? Ущербность самого js оставляем в стороне, это нас не интересует.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
P>>>А решений, одинаково хорошо работающих в любых условиях, не существует. Я, по крайней мере, о таких не слышал.
PD>>Опять же — не то я обсуждаю.
P>Тогда я не понимаю, что же ты обсуждаешь.
PD>>Но в принципе — ты согласен, что не могу я дать оценку этому решению, хорошее оно или плохое, на основании изучения исходников или чтения мнения разработчиков, к чему меня тут призывают ?
P>На основании чего тогда твой вердикт об ущербности интерпретатора js в Chrome? Ущербность самого js оставляем в стороне, это нас не интересует.
Во-первых, ты не ответил на вопрос. Он сам по себе не вообще имеет отношения к тому, как я отношусь к JS и Хрому.
А вердикта нет. Есть лишь некие сомнения в том, что он написан наилучшим образом, на основании сравнения с аналогами. Я тебе уже несколько раз пример с VS 2010/2008 приводил, но ты его аккуратно игнорируешь.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Но в принципе — ты согласен, что не могу я дать оценку этому решению, хорошее оно или плохое, на основании изучения исходников или чтения мнения разработчиков, к чему меня тут призывают ?
P>>На основании чего тогда твой вердикт об ущербности интерпретатора js в Chrome? Ущербность самого js оставляем в стороне, это нас не интересует.
PD>Во-первых, ты не ответил на вопрос. Он сам по себе не вообще имеет отношения к тому, как я отношусь к JS и Хрому.
На вопрос про чтение исходников? на основании только изучения исходников окончательный ответ дать нельзя. Если я где-то утверждал иное, то в пьяном бреду.
Окончательное заключение можно получить только в комплексе: читать исходники и смотреть поведение полученного из них продукта. Так вот, даже не читая исходников, а только используя продукт, я нахожу, что его расход памяти приемлем.
Да, кстати. Ты там начал с "во-первых". А "во-вторых" будет?
Ничего себе! Откуда мне знать — я не автор, а исходники его не открыты. Более того, там если и надо оптимизировать, то работу с сетью. Кешировать там, скорее всего, нечего — одни и те же данные там не появляются дважды.
Что изменится, если тебе открыть исходники обсуждаемого в той ветке продукта? Или это следует читать: дайте исходники, и я вам скажу, что не так?
PD>А вердикта нет. Есть лишь некие сомнения в том, что он написан наилучшим образом, на основании сравнения с аналогами.
По каким параметрам сравнивал? FireFox ест памяти чуть меньше, но ощутимо притормаживает на моем нетбуке по сравнению с Chrome. И какие у тебя основания для подобных сомнений? Я это не к тому, что считаю Chrome идеальным, я далек от этого. Идеальных продуктов не бывает. И что за аналоги ты имел в виду? Имена, адреса, явки, пароли?
PD>Я тебе уже несколько раз пример с VS 2010/2008 приводил, но ты его аккуратно игнорируешь.
Про студию я говорил: после 2005 я их не видел, а потому не могу обсуждать их достоинства и недостатки.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>Но в принципе — ты согласен, что не могу я дать оценку этому решению, хорошее оно или плохое, на основании изучения исходников или чтения мнения разработчиков, к чему меня тут призывают ?
P>>>На основании чего тогда твой вердикт об ущербности интерпретатора js в Chrome? Ущербность самого js оставляем в стороне, это нас не интересует.
PD>>Во-первых, ты не ответил на вопрос. Он сам по себе не вообще имеет отношения к тому, как я отношусь к JS и Хрому.
P>На вопрос про чтение исходников? на основании только изучения исходников окончательный ответ дать нельзя. Если я где-то утверждал иное, то в пьяном бреду.
Нет, ты это не утверждал. Это мне другие советовали.
P>Окончательное заключение можно получить только в комплексе: читать исходники и смотреть поведение полученного из них продукта. Так вот, даже не читая исходников, а только используя продукт, я нахожу, что его расход памяти приемлем.
Имеешь право . Но мне тут некоторые личности именно на основании чтения исходников советовали делать вывод.
P>Да, кстати. Ты там начал с "во-первых". А "во-вторых" будет?
Видимо, я что-то имел в виду, когда писал, но потом передумал. Не будет
P>И вот. Здесь
P>Ничего себе! Откуда мне знать — я не автор, а исходники его не открыты. Более того, там если и надо оптимизировать, то работу с сетью. Кешировать там, скорее всего, нечего — одни и те же данные там не появляются дважды.
P>Что изменится, если тебе открыть исходники обсуждаемого в той ветке продукта? Или это следует читать: дайте исходники, и я вам скажу, что не так?
Отсюда лишь следует, что и для флашгета я тоже вряд ли на этот вопрос отвечу, даже с исходниками.
PD>>А вердикта нет. Есть лишь некие сомнения в том, что он написан наилучшим образом, на основании сравнения с аналогами.
P>По каким параметрам сравнивал? FireFox ест памяти чуть меньше, но ощутимо притормаживает на моем нетбуке по сравнению с Chrome. И какие у тебя основания для подобных сомнений? Я это не к тому, что считаю Chrome идеальным, я далек от этого. Идеальных продуктов не бывает. И что за аналоги ты имел в виду? Имена, адреса, явки, пароли?
Да говорил же много раз. Броузеры 10-летней давности.
PD>>Я тебе уже несколько раз пример с VS 2010/2008 приводил, но ты его аккуратно игнорируешь.
P>Про студию я говорил: после 2005 я их не видел, а потому не могу обсуждать их достоинства и недостатки.
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>Если я где-то утверждал иное, то в пьяном бреду.
PD>Нет, ты это не утверждал. Это мне другие советовали.
(Облегченно вздыхая) А я уже подумал было...
P>>Так вот, даже не читая исходников, а только используя продукт, я нахожу, что его расход памяти приемлем.
PD>Имеешь право . Но мне тут некоторые личности именно на основании чтения исходников советовали делать вывод.
Да, имею. И вот почему. Предположим, ты продолжил увеличивать возможности своей мегапрограммы по умножению матриц (по моему заказу). Допустим, она должна обрабатывать N... нет, многовато, пусть будет K матриц для начала, а там посмотрим. Когда ты делал вариант с 3 матрицами, ты их все загружал в память, так? А если продолжать в том же духе и загружать одновременно пусть не N, пусть всего K матриц — это не перерасход? Его, кстати, можно увидеть при чтении исходника.
Есть ведь и другой путь. Перемножать матрицы одну за другой. Пока две матрицы перемножаются, запустить поток, готовящий очередную матрицу. Дать ему приоритет на единичку выше, чем вычислителю. В таком варианте нам не страшны не только K или N, но даже, страшно сказать, P матриц. Так что прямой перенос с БЭСМ на PC программы для 3 матриц практически бесполезен.
P>>И вот. Здесь
P>>Ничего себе! Откуда мне знать — я не автор, а исходники его не открыты. Более того, там если и надо оптимизировать, то работу с сетью. Кешировать там, скорее всего, нечего — одни и те же данные там не появляются дважды.
P>>Что изменится, если тебе открыть исходники обсуждаемого в той ветке продукта? Или это следует читать: дайте исходники, и я вам скажу, что не так?
PD>Отсюда лишь следует, что и для флашгета я тоже вряд ли на этот вопрос отвечу, даже с исходниками.
Зачем тогда вопрос поднял? Там нагрузочное тестирование покажет, это сеть или что иное. Исходники понадобятся, когда нужно будет отвечать на вопрос: как его лечить.
PD>>>А вердикта нет. Есть лишь некие сомнения в том, что он написан наилучшим образом, на основании сравнения с аналогами.
P>> И что за аналоги ты имел в виду? Имена, адреса, явки, пароли?
PD>Да говорил же много раз. Броузеры 10-летней давности.
Браузеры 10-летней давности написаны лучше современных? А сие из чего следует?
Здравствуйте, Privalov, Вы писали:
PD>>Имеешь право . Но мне тут некоторые личности именно на основании чтения исходников советовали делать вывод.
P>Да, имею. И вот почему. Предположим, ты продолжил увеличивать возможности своей мегапрограммы по умножению матриц (по моему заказу). Допустим, она должна обрабатывать N... нет, многовато, пусть будет K матриц для начала, а там посмотрим. Когда ты делал вариант с 3 матрицами, ты их все загружал в память, так? А если продолжать в том же духе и загружать одновременно пусть не N, пусть всего K матриц — это не перерасход? Его, кстати, можно увидеть при чтении исходника. P>Есть ведь и другой путь. Перемножать матрицы одну за другой. Пока две матрицы перемножаются, запустить поток, готовящий очередную матрицу. Дать ему приоритет на единичку выше, чем вычислителю. В таком варианте нам не страшны не только K или N, но даже, страшно сказать, P матриц. Так что прямой перенос с БЭСМ на PC программы для 3 матриц практически бесполезен.
Именно. Золотые слова. Я же не утверждаю, что всегда и везде надо-таки экономить каждый байт. От задачи зависит. Может, с этими матрицами и иначе надо. Надо исследовать и найти лучшее решение.
Только вот при этом исследовании надо исходить из задачи, а не только из того, что память подешевела в 5 раз и ее объем увеличился тоже в 5 раз.
PD>>Отсюда лишь следует, что и для флашгета я тоже вряд ли на этот вопрос отвечу, даже с исходниками.
P>Зачем тогда вопрос поднял? Там нагрузочное тестирование покажет, это сеть или что иное. Исходники понадобятся, когда нужно будет отвечать на вопрос: как его лечить.
Что-то теперь я перестал понимать, о чем речь. Какой вопрос я поднял ? Я там просто мимоходом ответил на вопрос Икемефула
I>"какое направление оптимизации выбрали для написания флешгета". P>Ничего себе! Откуда мне знать ...
PD>>Да говорил же много раз. Броузеры 10-летней давности.
P>Браузеры 10-летней давности написаны лучше современных? А сие из чего следует?
Не лучше, а экономнее. Соотношение цена(в данном случае объем памяти)/результат. Потому что если результат, конечно, лучше по качеству, чем 10 лет назад, то вот цена увеличена непропорционально. Ну как если бы скорость автомобиля подняли на 10% и стоимость бы при этом увеличили в 2 раза. Но об этом я уже говорил.
А вообще, похоже, мы по второму кругу пошли. Пора завершать эту дискуссию, не находишь ?
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>Да, имею.
P>>Есть ведь и другой путь. Перемножать матрицы одну за другой.
PD>Именно. Золотые слова. Я же не утверждаю, что всегда и везде надо-таки экономить каждый байт. От задачи зависит. Может, с этими матрицами и иначе надо. Надо исследовать и найти лучшее решение.
Про матрицы? Так там все просто. Голые массивы, все перед глазами. И тем не менее, требуется исследование. Причем чисто теоретические расчеты здесь мало помогут. О Хроме я вообще не говорю. Я не могу утверждать, что он неэкономно расходует память. У меня нет для этого объективной информации.
PD>Только вот при этом исследовании надо исходить из задачи, а не только из того, что память подешевела в 5 раз и ее объем увеличился тоже в 5 раз.
И из этого тоже. Уж если есть у нас в 5 раз больше памяти за те же деньги, почему бы не использовать? Критерий — максимум эффективности при минимуме затрат. Задача рассматривается комплексно и никак иначе.
PD>Что-то теперь я перестал понимать, о чем речь. Какой вопрос я поднял ? Я там просто мимоходом ответил на вопрос Икемефула
Ты там исходники зачем-то просил.
P>>Браузеры 10-летней давности написаны лучше современных? А сие из чего следует?
PD>Не лучше, а экономнее. Соотношение цена(в данном случае объем памяти)/результат. Потому что если результат, конечно, лучше по качеству, чем 10 лет назад, то вот цена увеличена непропорционально. Ну как если бы скорость автомобиля подняли на 10% и стоимость бы при этом увеличили в 2 раза. Но об этом я уже говорил.
Так и объяснение, почему так, ты получил достаточно аргументированное. Я читал. И это в КСВ.
PD>А вообще, похоже, мы по второму кругу пошли. Пора завершать эту дискуссию, не находишь ?
К сессии готовиться надо?
Пойду в соседнюю ветку посмотрю, там что-то про .net началось.
PD>
P>>>Есть ведь и другой путь. Перемножать матрицы одну за другой.
PD>>Именно. Золотые слова. Я же не утверждаю, что всегда и везде надо-таки экономить каждый байт. От задачи зависит. Может, с этими матрицами и иначе надо. Надо исследовать и найти лучшее решение.
P>Про матрицы? Так там все просто. Голые массивы, все перед глазами. И тем не менее, требуется исследование. Причем чисто теоретические расчеты здесь мало помогут. О Хроме я вообще не говорю. Я не могу утверждать, что он неэкономно расходует память. У меня нет для этого объективной информации.
Ладно, давай закончим. а то по третьему разу пойдем.
PD>>Только вот при этом исследовании надо исходить из задачи, а не только из того, что память подешевела в 5 раз и ее объем увеличился тоже в 5 раз.
P>И из этого тоже. Уж если есть у нас в 5 раз больше памяти за те же деньги, почему бы не использовать?
Вот тут все наши с тобой расхождения.
PD>>Что-то теперь я перестал понимать, о чем речь. Какой вопрос я поднял ? Я там просто мимоходом ответил на вопрос Икемефула
P>Ты там исходники зачем-то просил.
Да не просил, нужны мне они... Просто сказал, что без них уж точно не могу на его вопрос ответить. Из этого вовсе не следует, что я готов был бы ответить, если мне исходники дать — по причине, которую я много раз озвучивал.
P>>>Браузеры 10-летней давности написаны лучше современных? А сие из чего следует?
PD>>Не лучше, а экономнее. Соотношение цена(в данном случае объем памяти)/результат. Потому что если результат, конечно, лучше по качеству, чем 10 лет назад, то вот цена увеличена непропорционально. Ну как если бы скорость автомобиля подняли на 10% и стоимость бы при этом увеличили в 2 раза. Но об этом я уже говорил.
P>Так и объяснение, почему так, ты получил достаточно аргументированное. Я читал. И это в КСВ.
PD>>А вообще, похоже, мы по второму кругу пошли. Пора завершать эту дискуссию, не находишь ?
P>К сессии готовиться надо?
Да нет, до сессии еще далеко. И потом это студентам готовиться к ней надо, а мне-то зачем ? У меня, кстати, экзаменов нет, а вот с зачетами будет в конце декабря весело
P>Пойду в соседнюю ветку посмотрю, там что-то про .net началось.
PD>>Не лучше, а экономнее. Соотношение цена(в данном случае объем памяти)/результат. Потому что если результат, конечно, лучше по качеству, чем 10 лет назад, то вот цена увеличена непропорционально. Ну как если бы скорость автомобиля подняли на 10% и стоимость бы при этом увеличили в 2 раза. Но об этом я уже говорил.
P>Так и объяснение, почему так, ты получил достаточно аргументированное. Я читал. И это в КСВ.
Этим ты его не убедишь. Десяток технологий, которых в 20-м не существовало он легко приводит к JPEG/GIF. В общем, по его улыбочке на эту фразу и так видно
. Надеюсь к чему-то прийти. В идеале — прояснить и этот вопрос. В свое время Нильсу Бору стоило немалых усилий доказать Эйнштейну справедливость квантовой теории.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Во времена MS-DOS. Я не шучу. 640 Кб по тем временам — очень много. (вспомни фразу Б. Гейтса насчет 256 Кб)
Какое ж много, если для большинства серьезных программ надо было спец-конфиги писать. Например прога требует 600кб, где их взять если на систему остаётся 40 кб ?
Потому и надо было разбираться, как бы систему перекинуть куда повыше, сдвинуть видеобуфер, что бы освободить 600кб под прогу.
PD>И тем не менее писали аккуратно, памятью не бросались, лишнюю не использовали.
PD>Почему ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не удержался и решил еще один аргумент озвучить.
Ну давай посмотрим.
PD>Во времена БЭСМ-6 и прочих ЕС памяти было мало, надо было экономить. Согласен.
На ЕС 1036 48 Мб виртуальных на 4 реальных было вполне достаточно. 16 виртуальных машин работали парраллельно, не мешая друг другу, если только системщики не запускали SYSPRG и не загружали на ней СВМ. Т. е. если кто-то при запуске задания получал нехватку памяти (не помню, какой это ABEND), спокойно увеличивал REGION хоть до 4 М. Если и тогда валилось, надо было разбираться. Особенно если задание не местной разработки.
PD>Во времена Win16 и даже Windows 9x памяти было мало, поэтому надо ее было экономить. Тоже согласен.
Однажды мы собрали целый вагон памяти — 20 М. И всю засунули в 386/DX-40. Ты бы видел, как обрадовалась Windows 95.
PD>А много ее когда-нибудь было ?
PD>Было!
PD>Во времена MS-DOS. Я не шучу. 640 Кб по тем временам — очень много. (вспомни фразу Б. Гейтса насчет 256 Кб)
По каким "тем временам"? В 1981 году — да, до фига. В 1991 — изобретаются всякие там EMS/XMS, настольные СУБД захватывают каждый свободный байт. Я что, от хорошей жизни запихивал резиденты в неиспользуемую область PSP — минимум 128 байт? Да, мне пришлось написать парочку. Так что поторопился Билл Гейтс.
PD>В 1984 году 1 Мб ОП и примерно 600 Кб доступных уже было. В 1983 году мы примерно так вдесятером мучили одну ЕС-1022 на ВЦ ИОХ АН СССР. С памятью 512 Мб (доступно примерно 400) и быстродействием 70 тысяч операций в секунду. После 1983 года я оттуда ушел, но она еще не один год работала.
Нехило в те годы.
PD>А тут 600. И что самое интересное — экономить совершенно не надо. Помешать некому, потому что ОС однопрограммная. Так что бери 100 Кб или все 600 — все равно, никакого профита ни для кого.
Надо, надо. И разве Borland придумала динамические оверлеи просто так?
PD>И тем не менее писали аккуратно, памятью не бросались, лишнюю не использовали.
Даже наоборот: глобальные переменные в одних фрагментах программы имели один смысл, а в других — другой. Из-за экономии. Чтобы в эти самые 640 К залезть и с XMS/EMS. не связываться. Потому что производительность проседала по сравнению с работой только в основной памяти. А сейчас зато могут себе позволить вообще глобальных переменных не использовать. И о том, что к разным типам памяти по-разному обращаться нужно, тоже.
PD>Почему ?
Потому что еще с БЭСМ и ЕС осталась привычка: машинное время дорого. Оно там было намного дороже рабочего времени программиста. Потому и отлаживали на бумаге, с карандашиком в руках проходя каждую строчку по распечатке. И PRIMUS был далек от современных средств разработки. Хотя вещь хорошая.
Здравствуйте, Privalov, Вы писали:
M>>Этим ты его не убедишь. Десяток технологий, которых в 20-м не существовало он легко приводит к JPEG/GIF. В общем, по его улыбочке на эту фразу и так видно
P>Да, и, сдается мне, я могу понять, почему. Озвучивать пока не буду. Надеюсь, что ошибаюсь.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Не удержался и решил еще один аргумент озвучить.
P>Ну давай посмотрим.
PD>>Во времена БЭСМ-6 и прочих ЕС памяти было мало, надо было экономить. Согласен.
P>На ЕС 1036 48 Мб виртуальных на 4 реальных было вполне достаточно. 16 виртуальных машин работали парраллельно, не мешая друг другу, если только системщики не запускали SYSPRG и не загружали на ней СВМ. Т. е. если кто-то при запуске задания получал нехватку памяти (не помню, какой это ABEND), спокойно увеличивал REGION хоть до 4 М. Если и тогда валилось, надо было разбираться. Особенно если задание не местной разработки.
OK.
PD>>Во времена Win16 и даже Windows 9x памяти было мало, поэтому надо ее было экономить. Тоже согласен.
P>Однажды мы собрали целый вагон памяти — 20 М. И всю засунули в 386/DX-40. Ты бы видел, как обрадовалась Windows 95.
Я бы тоже обрадовался.
PD>>А много ее когда-нибудь было ?
PD>>Было!
PD>>Во времена MS-DOS. Я не шучу. 640 Кб по тем временам — очень много. (вспомни фразу Б. Гейтса насчет 256 Кб)
P>По каким "тем временам"? В 1981 году — да, до фига. В 1991 — изобретаются всякие там EMS/XMS, настольные СУБД захватывают каждый свободный байт. Я что, от хорошей жизни запихивал резиденты в неиспользуемую область PSP — минимум 128 байт? Да, мне пришлось написать парочку. Так что поторопился Билл Гейтс.
Совершенно верно. Очень короткий период, время 80286, то есть первых AT. EMS будет только на 80386, а это уже 1987.
PD>>В 1984 году 1 Мб ОП и примерно 600 Кб доступных уже было. В 1983 году мы примерно так вдесятером мучили одну ЕС-1022 на ВЦ ИОХ АН СССР. С памятью 512 Мб (доступно примерно 400) и быстродействием 70 тысяч операций в секунду. После 1983 года я оттуда ушел, но она еще не один год работала.
P>Нехило в те годы.
PD>>А тут 600. И что самое интересное — экономить совершенно не надо. Помешать некому, потому что ОС однопрограммная. Так что бери 100 Кб или все 600 — все равно, никакого профита ни для кого.
P>Надо, надо. И разве Borland придумала динамические оверлеи просто так?
Динамические оверлеи были придуманы для Turbo Pascal 1.0 и 64 Кб. В TP 6.0 их ИМХО уже не было.
PD>>И тем не менее писали аккуратно, памятью не бросались, лишнюю не использовали.
P>Даже наоборот: глобальные переменные в одних фрагментах программы имели один смысл, а в других — другой. Из-за экономии. Чтобы в эти самые 640 К залезть и с XMS/EMS. не связываться. Потому что производительность проседала по сравнению с работой только в основной памяти. А сейчас зато могут себе позволить вообще глобальных переменных не использовать. И о том, что к разным типам памяти по-разному обращаться нужно, тоже.
Нет-нет, давай до всяких EMS . Вдруг стало 600 Кб и никаких пока что EMS нет.
PD>>Почему ?
P>Потому что еще с БЭСМ и ЕС осталась привычка: машинное время дорого. Оно там было намного дороже рабочего времени программиста. Потому и отлаживали на бумаге, с карандашиком в руках проходя каждую строчку по распечатке. И PRIMUS был далек от современных средств разработки. Хотя вещь хорошая.
Лукавишь . Я о времени ни слова не сказал. Я о памяти говорил.
I>Какое ж много, если для большинства серьезных программ надо было спец-конфиги писать. Например прога требует 600кб, где их взять если на систему остаётся 40 кб ?
На какую систему ? MS-DOS ? Ее в himem отправляли, начиная с MS-DOS 5.0. Впрочем, и без этого я это учел, говоря о 600 Кб — это за вычетом памяти для ОС.
I>Потому и надо было разбираться, как бы систему перекинуть куда повыше, сдвинуть видеобуфер, что бы освободить 600кб под прогу.
Это потом уже, во времена VESA, кое что изменилось.
PD>>И тем не менее писали аккуратно, памятью не бросались, лишнюю не использовали.
PD>>Почему ?
I>Потому что памяти было мало.
Еще раз — после ЕС-1022, после СМ-4 — в 2-3 раза больше, и к тому же монопольно.
P>>Так что поторопился Билл Гейтс.
PD>Совершенно верно. Очень короткий период, время 80286, то есть первых AT. EMS будет только на 80386, а это уже 1987.
EMS появилась в 1984 году. Другое дело, что в б.СССР я нигде ее не видел, только слышал. В 1987 ее научились эмулировать, используя возможности 80386.
P>>Надо, надо. И разве Borland придумала динамические оверлеи просто так?
PD>Динамические оверлеи были придуманы для Turbo Pascal 1.0 и 64 Кб. В TP 6.0 их ИМХО уже не было.
Посмотри на досуге типы исполняемых файлов, определявшиеся в опциях компилятора/линкера, в BC++ 2.0/3.x.
P>>Даже наоборот: глобальные переменные в одних фрагментах программы имели один смысл, а в других — другой. Из-за экономии. Чтобы в эти самые 640 К залезть и с XMS/EMS. не связываться.
PD>Нет-нет, давай до всяких EMS . Вдруг стало 600 Кб и никаких пока что EMS нет.
Как выяснили выше, таки есть. И появились всякие там Stacker или DoubleSpace. И на 80286 сразу все вернулось. В том смысле, что MS-DOS 5.0 /6.xx умела грузиться в HMA, а освободившуюся память занимали драйверы уплотнителей дисков.
А чтобы без EMS — работать, так глобальные переменные, как я уже сказал,- наше все.
PD>>>Почему ?
P>>Потому что еще с БЭСМ и ЕС осталась привычка: машинное время дорого. PD>Лукавишь . Я о времени ни слова не сказал. Я о памяти говорил.
Так экономили больше время (машинное), за счет снижения количества компиляций, прогонов. Иногда, делая нелегкий выбор, что сэкономить, решали в пользу микросекунд, а не байтов. Зато рабочего времени программиста особо не жалели.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Видобуфер никуда сдвинуть было нельзя.
Про драйвер 736.sys что-нибудь слышал? Он, в случае неиспользования графики на EGA/VGA отдавал адресное пространство от A0000 до B7FFF под основную память и не давал включать гравический режим видеоадаптера.
PD>c8000:0 — текстовый цветной или CGA-графика PD>c0000:0 — текстовый монохромный PD>a0000:0 — EGA/VGA графика.
B800:0 — видеорежимы 2 и 3.
B000:0 — видеорежим 7
C800:0 (5?) — на оригинальной XT, и только на ней, перейдя по этому адресу отладчиком и запустив выполнение, можно было отформатировать жесткий диск
Не вводи молодежь в заблуждение. Они ведь работу по железу в MS-DOS изучают.
Здравствуйте, Privalov, Вы писали:
PD>>Совершенно верно. Очень короткий период, время 80286, то есть первых AT. EMS будет только на 80386, а это уже 1987.
P>EMS появилась в 1984 году. Другое дело, что в б.СССР я нигде ее не видел, только слышал. В 1987 ее научились эмулировать, используя возможности 80386.
Ладно, не буду спорить, все равно реально на 80286 был 1 Мб ОП, так что если она и была — много от этого не получишь.
PD>>Динамические оверлеи были придуманы для Turbo Pascal 1.0 и 64 Кб. В TP 6.0 их ИМХО уже не было.
P>Посмотри на досуге типы исполняемых файлов, определявшиеся в опциях компилятора/линкера, в BC++ 2.0/3.x.
Можно в двух словах о чем речь идет ? У меня их нет сейчас.
PD>>Нет-нет, давай до всяких EMS . Вдруг стало 600 Кб и никаких пока что EMS нет.
P>Как выяснили выше, таки есть. И появились всякие там Stacker или DoubleSpace.
Stacker или DoubleSpace — это сжатие на диске, не имеет к моему вопросу отношения.
> на 80286 сразу все вернулось. В том смысле, что MS-DOS 5.0 /6.xx умела грузиться в HMA, а освободившуюся память занимали драйверы уплотнителей дисков.
Пусть уплотняют чего хотят, я про 600 Кб ОП. Ты меня не собьешь своими стакерами
P>А чтобы без EMS — работать, так глобальные переменные, как я уже сказал,- наше все.
PD>>>>Почему ?
P>>>Потому что еще с БЭСМ и ЕС осталась привычка: машинное время дорого. PD>>Лукавишь . Я о времени ни слова не сказал. Я о памяти говорил.
P>Так экономили больше время (машинное), за счет снижения количества компиляций, прогонов. Иногда, делая нелегкий выбор, что сэкономить, решали в пользу микросекунд, а не байтов. Зато рабочего времени программиста особо не жалели.
Опять лукавишь. Не про скорость я, а только про память, и только про ОП. Так что к богу скорость компиляции, и даже скорость работы, сейчас не обсуждаем. Только память.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Какое ж много, если для большинства серьезных программ надо было спец-конфиги писать. Например прога требует 600кб, где их взять если на систему остаётся 40 кб ?
PD>На какую систему ? MS-DOS ? Ее в himem отправляли, начиная с MS-DOS 5.0. Впрочем, и без этого я это учел, говоря о 600 Кб — это за вычетом памяти для ОС.
Ну так указывай конкретные версии MS-DOS. Я вот с 3.30 начинал
PD>Видобуфер никуда сдвинуть было нельзя. PD>Это потом уже, во времена VESA, кое что изменилось.
Ты бы определился, что ли ? То нельзя, то изменилось
Здравствуйте, Privalov, Вы писали:
P>Про драйвер 736.sys что-нибудь слышал? Он, в случае неиспользования графики на EGA/VGA отдавал адресное пространство от A0000 до B7FFF под основную память и не давал включать гравический режим видеоадаптера.
Нет. Ну и что ? Я в свое время придумал, как стек в UMB пересадить и даже статью на этот счет написал в Компьютер-Пресс
PD>>c8000:0 — текстовый цветной или CGA-графика PD>>c0000:0 — текстовый монохромный PD>>a0000:0 — EGA/VGA графика.
P>B800:0 — видеорежимы 2 и 3. P>B000:0 — видеорежим 7
Да, виноват. Ошибся. Не с, а b . Ну хоть про a правильно.
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>EMS появилась в 1984 году. Другое дело, что в б.СССР я нигде ее не видел, только слышал. В 1987 ее научились эмулировать, используя возможности 80386.
PD>Ладно, не буду спорить, все равно реально на 80286 был 1 Мб ОП, так что если она и была — много от этого не получишь.
smartdrv туда запихивали.
Видел 80286 с 2 Мб, на нем UNIX с Oracle 5.x крутился.
PD>Можно в двух словах о чем речь идет ? У меня их нет сейчас.
Там где-то в опциях установить можно было: обычный exe или с оверлейный. В последнем случае, ЕМНИП, организовывался страничный обмен, прямо, как виртуальная память. В деталях боюсь запутаться, у меня BC тоже сейчас нет. Хотя проверить не помешает, вдруг я наврал? Но, опять же, ЕМНИП, TC 2.0 еще не поддерживал оверлейных exe, а вот все, что за ним — да.
PD>Stacker или DoubleSpace — это сжатие на диске, не имеет к моему вопросу отношения.
А что драйвер DoubleSpace тоже с диска работал? И памяти совсем-совсем не занимал?
PD>Пусть уплотняют чего хотят, я про 600 Кб ОП. Ты меня не собьешь своими стакерами
Тот же вопрос о драйверах.
PD>Опять лукавишь. Не про скорость я, а только про память, и только про ОП. Так что к богу скорость компиляции, и даже скорость работы, сейчас не обсуждаем. Только память.
Дак если забить на скорость, то все можно воткнуть в 1 М. Правда, еще куча удобств уйдет.
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>Про драйвер 736.sys что-нибудь слышал?
PD>Нет. Ну и что ? Я в свое время придумал, как стек в UMB пересадить и даже статью на этот счет написал в Компьютер-Пресс
А как ты туда прорвался? У него же подзаголовок бык: обозрение зарубежной прессы. Ты что, для Byte что-то писал? И UMB — это 80386.
P>>B800:0 — видеорежимы 2 и 3. P>>B000:0 — видеорежим 7
PD>Да, виноват. Ошибся. Не с, а b . Ну хоть про a правильно.
Извини, при работе на таком уровне правильные адреса — это исключительно важно, сам понимаешь. Вот и вмешался.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
P>>>EMS появилась в 1984 году. Другое дело, что в б.СССР я нигде ее не видел, только слышал. В 1987 ее научились эмулировать, используя возможности 80386.
PD>>Ладно, не буду спорить, все равно реально на 80286 был 1 Мб ОП, так что если она и была — много от этого не получишь.
P>smartdrv туда запихивали. P>Видел 80286 с 2 Мб, на нем UNIX с Oracle 5.x крутился.
Черт с ним. Я про 600 Кб ОП
P>Там где-то в опциях установить можно было: обычный exe или с оверлейный. В последнем случае, ЕМНИП, организовывался страничный обмен, прямо, как виртуальная память. В деталях боюсь запутаться, у меня BC тоже сейчас нет. Хотя проверить не помешает, вдруг я наврал? Но, опять же, ЕМНИП, TC 2.0 еще не поддерживал оверлейных exe, а вот все, что за ним — да.
Не помню. Вот в TP помню. Красиво было сделано
overlay procedure f1(...)
begin
end
overlay procedure f2(...)
begin
end
и все. Они друг друга на одном и том же адресе сменяли. Конечно, диск нужен был.
PD>>Stacker или DoubleSpace — это сжатие на диске, не имеет к моему вопросу отношения.
P>А что драйвер DoubleSpace тоже с диска работал? И памяти совсем-совсем не занимал?
Это все в Recycled Bin. Я же сказал — 600. Не нравится — давай 580 . Остальное под ДОС, драйверы, TSR. У меня было свободно примерно 600. VC показывал. Можешь в этом и сейчас убедиться. Достань Hiren Boot CD, загрузи DOS и VC
PD>>Пусть уплотняют чего хотят, я про 600 Кб ОП. Ты меня не собьешь своими стакерами
P>Тот же вопрос о драйверах.
См. выше.
PD>>Опять лукавишь. Не про скорость я, а только про память, и только про ОП. Так что к богу скорость компиляции, и даже скорость работы, сейчас не обсуждаем. Только память.
P>Дак если забить на скорость, то все можно воткнуть в 1 М. Правда, еще куча удобств уйдет.
И все же, почему памятью не швырялись ? Почему, когда есть 500-600, лишнее не брали и если можно было в 100-200 уложить — укладывались ?
PD>Мне тут описывали, насколько все улучшилось в вебе за 10 лет. Google mail в пример приводили, и прочие Google продукты
PD>Ну давай посмотрим. Без Google.
Какой ты все таки ограниченный человек, ей-богу
Давайте будем сравнивать не возможности студии, а только ее подмножество, равное BC++ 5.5
Давайте будем сравнивать не все возможности веба, а только его подмножество, равное 2001-му году
Давайте будем сравнивать не новые возможности, в которых я ни ухом, ни рылом, а только те, которые я еще как-то знаю — уровня 10-15-летней давности.
Здравствуйте, genre, Вы писали:
PD>>Есть у психологов такое понятие — "профессиональный кретинизм" — которое означает, что работа человека формирует у него стереотипы, через которые он воспринимает весь окружающий мир, по крайней мере это стереотипы его действий, попыток решения возникающих задач.
G>То есть ты хочешь сказать, что работа в IT вынуждает всех присутствующих в данном форуме быть дурачками неспособными оперировать фактами? G>А ты молодец!
Может, он пытался незаметно выразить мысль, что у некоторых преподавателей с годами вырабатывается стереотип, что все вокруг — зеленые студенты, которые ничего не знают? Ну и что дополнительно вырабатывается стереотип, что нельзя показать окружающим, что ты чего-то не знаешь — засмеют же зеленые студенты.
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>Надо, надо. И разве Borland придумала динамические оверлеи просто так?
PD>Динамические оверлеи были придуманы для Turbo Pascal 1.0 и 64 Кб. В TP 6.0 их ИМХО уже не было.
Вообще то оверлеи появились где то в 3й версии и продержались до самого конца MS-DOS версий.
PD>>Динамические оверлеи были придуманы для Turbo Pascal 1.0 и 64 Кб. В TP 6.0 их ИМХО уже не было.
I>Вообще то оверлеи появились где то в 3й версии и продержались до самого конца MS-DOS версий.
Я использовал их в версии 1.0 для Ямахи (портирована из CP/M).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Мне тут описывали, насколько все улучшилось в вебе за 10 лет. Google mail в пример приводили, и прочие Google продукты
PD>Ну давай посмотрим. Без Google.
PD>Сайт rbc.ru. Не последний новостной сайт в России.
Ну то есть ты не в курсе что такие утвеждения контрпримерами не опровергаются?
Здравствуйте, genre, Вы писали:
PD>>Сайт rbc.ru. Не последний новостной сайт в России.
G>Ну то есть ты не в курсе что такие утвеждения контрпримерами не опровергаются?
А примерами доказываются ? Мне в качестве примера Google дают, он — доказательство, так ? А то, что для других сайтов все это не нужно — не годится в качестве аргумента ? Хорошенькое получается дело — примеры что-то доказывают, а контрпримеры — ничего. Тогда уж считать надо — сколько примеров, а сколько контрпримеров. И какова их роль, конечно, тоже.
Если бы мне предложили вернуться к rbc.ru 2001 года, я только рад бы был — нужны мне эти баннеры!
PD>Если бы мне предложили вернуться к rbc.ru 2001 года, я только рад бы был — нужны мне эти баннеры!
Зато они нужны rbc. Или, может, ты хочешь платить за доступ к информационным сайтам, но без рекламы?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
PD>>Если бы мне предложили вернуться к rbc.ru 2001 года, я только рад бы был — нужны мне эти баннеры!
E__>Зато они нужны rbc. Или, может, ты хочешь платить за доступ к информационным сайтам, но без рекламы?
Вот это уже лучше. А то мне доказывали (не ты), что, мол, это все в интересах пользователей, что они жить без этого не могут. А получается, что это в интересах компаний, которые у меня (не у меня лично) деньги таким образом выманивают (ну хотя бы оплата трафика, если не безлимит или если на всяких там смартфонах) и рекламу мне гонят.
Кстати, а в 2001 году они как-то жили ? Ну вот пусть так бы и жили. Почему это я должен им повышенные доходы обеспечить ?
P.S. Я крайне далек от всяких идей заговоров, на всякий случай.
PD>>>Если бы мне предложили вернуться к rbc.ru 2001 года, я только рад бы был — нужны мне эти баннеры!
E__>>Зато они нужны rbc. Или, может, ты хочешь платить за доступ к информационным сайтам, но без рекламы?
PD>Вот это уже лучше. А то мне доказывали (не ты), что, мол, это все в интересах пользователей, что они жить без этого не могут. А получается, что это в интересах компаний, которые у меня (не у меня лично) деньги таким образом выманивают (ну хотя бы оплата трафика, если не безлимит или если на всяких там смартфонах) и рекламу мне гонят.
PD>Кстати, а в 2001 году они как-то жили ? Ну вот пусть так бы и жили. Почему это я должен им повышенные доходы обеспечить ?
Интернет коммерциализировался. В свое время сайты были не для заработка, а больше for fun. Сейчас это уже редкость.
Кстати, с вирусами то же самое произошло. Когда-то народ писал вирусы ради прикола — переворот букв на экране, или вывод на печать матерных слов в определенных местах теста — это все именно что приколы. Ну и злые тоже были, и немало, но деньги на них не зарабатывали. Вирусописатель тешил свое ЧСВ, да и вирусы были произведением искусства. А сейчас клепают очень глупых троянов(см. троянский слон
), под видом сисек впаривают юзерам, и создают ботнеты, или крадут данные карточек.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Ну в те времена. когда он это писал, точно не было бы медленнее, потому что про кеш-память никто и не слышал. А сейчас — не уверен, но для того, чтобы заявить, что мол, эту память потратили не зря, надо не тупо на код смотреть, а потратить приличное время — тут от ряда факторов скорость будет зависеть как с 4 матрицами, так и с 3. A>>но не ставит ли это под сомнение вообще "оптимизацию по расходу памяти" (в настоящее время)? PD>В данном случае — не ставит. Удастся ли сделать вариант с 3 матрицами, который работал бы столь же быстро, как и вариант с 4 — не берусь судить. Но и вариант с 4, если его запрограммировать "против шерсти" — будет тоже тормозить. Тут нужен серьезный анализ и тестирование. В результате не исключено, что некий вариант с 3 будет самым быстродействующим.
также не исключено, что вариант реализации JS в хроме будет самым быстродействующим. может провести серьёзный анализ и тестирование, прежде чем утверждать что он почём зря память скушал?
PD>Я все это к тому, что посмотреть на некие исходники размером в миллион строк и сказать : да, здесь все правильно и разумно, ничего лишнего — не очень, мягко говоря, серьезно.
ровно также, как и посмотреть на потребление памяти и сказать : да, тут всё неправильно и неразумно. ведь даже сравнить-то не с чем.
вот берёшься ли ты утверждать, что можно *полностью повторить функционал и производительность vc++*, ограничиваясь ресурсами времён 96ого года?
PD>>Вот это уже лучше. А то мне доказывали (не ты), что, мол, это все в интересах пользователей, что они жить без этого не могут. А получается, что это в интересах компаний, которые у меня (не у меня лично) деньги таким образом выманивают (ну хотя бы оплата трафика, если не безлимит или если на всяких там смартфонах) и рекламу мне гонят.
PD>>Кстати, а в 2001 году они как-то жили ? Ну вот пусть так бы и жили. Почему это я должен им повышенные доходы обеспечить ?
E__>Интернет коммерциализировался. В свое время сайты были не для заработка, а больше for fun. Сейчас это уже редкость. E__>Кстати, с вирусами то же самое произошло. Когда-то народ писал вирусы ради прикола — переворот букв на экране, или вывод на печать матерных слов в определенных местах теста — это все именно что приколы. Ну и злые тоже были, и немало, но деньги на них не зарабатывали. Вирусописатель тешил свое ЧСВ, да и вирусы были произведением искусства. А сейчас клепают очень глупых троянов(см. троянский слон
), под видом сисек впаривают юзерам, и создают ботнеты, или крадут данные карточек.
Все верно, вполне согласен. Но тогда возвращаюсь к своей посылке : если бы рост объема памяти остановился, скажем, на 256 Мб — он бы не коммерциализировался ? Не думаю. Он бы коммерциализировался вс еравно, но это уложили бы в 32 Мб (броузер etc.). Ну а всякие флешки и баннеры — тут не столько от ОП зависит, сколько от ширины канала.
Здравствуйте, Antikrot, Вы писали:
A>вот берёшься ли ты утверждать, что можно *полностью повторить функционал и производительность vc++*, ограничиваясь ресурсами времён 96ого года?
Утверждать категорически — нет. Но если позволишь все же взять 98 год (VC6) и немного все же памяти добавишь (ну так процентов 30-50) — думаю, да . Правда, имей в виду — я сказал про C++, я ничего не говорил про дотнет. Аргумент простой — не так уж много нового даже в IDE для C++ по сравнению с VC6.
Правда, оговорюсь — по VC 2008 включительно. В VC 2010 есть компиляция по ходу набора текста (как в C#, eclipse и т.д.), на это память нужна. Но и здесь я бы мог сформулировать так : если ее отключить — укладывайтесь, ну а если включить — берите еще памяти.
Здравствуйте, Pavel Dvorkin, Вы писали:
A>>вот берёшься ли ты утверждать, что можно *полностью повторить функционал и производительность vc++*, ограничиваясь ресурсами времён 96ого года? PD>Утверждать категорически — нет. Но если позволишь все же взять 98 год (VC6) и немного все же памяти добавишь (ну так процентов 30-50) — думаю, да . Правда, имей в виду — я сказал про C++, я ничего не говорил про дотнет.
а я говорил "полностью", ибо небольшая на взгляд фича может оказаться потяжелее всего остального.
и кстати я имел в виду vc++ то есть cl.exe из например 2008ой студии — вот его функционал можно *полностью*, со всеми видимыми и невидимыми фичами, повторить на ресурсах, которые требовал cl.exe из vc6, и не просесть в производительности? (ну пусть +50%, так и быть)
PD>Аргумент простой — не так уж много нового даже в IDE для C++ по сравнению с VC6.
да фиг с ними с IDE — изначально вообще про интерпретатор JS шёл разговор, вот и давай "базовый" функционал сравнивать, без плюшек
PD>Правда, оговорюсь — по VC 2008 включительно. В VC 2010 есть компиляция по ходу набора текста (как в C#, eclipse и т.д.), на это память нужна. Но и здесь я бы мог сформулировать так : если ее отключить — укладывайтесь, ну а если включить — берите еще памяти.
интересный момент — на сколько больше брать памяти?
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>Там где-то в опциях установить можно было: обычный exe или с оверлейный.
PD>Не помню. Вот в TP помню. Красиво было сделано
В BC++ оверлеи автоматом, ЕМНИП, строились. А здесь руками надо делать. В системах от MS (MCS 6.0, MSC++7.0) линкеру надо было указывать, что в памяти, а что в оверлей.
PD>Это все в Recycled Bin. Я же сказал — 600. Не нравится — давай 580 .
Да, на 386 можно было выжать и 620, верно. Я в те времена был окружен 286, там столько не выжмешь. UMB на нем не было.
PD>>>Пусть уплотняют чего хотят, я про 600 Кб ОП. Ты меня не собьешь своими стакерами
Нас никому не сбить с пути, нам все равно, куда идти (c)
PD>Не собьешь ты меня драйверами, химемами и прочим!
См. выше.
Химем — это himem.sys? А как без него-то на 286?
Вывод. Заявление Билла Гейтса больше похоже на рекламный ход. Суди сам: в 1981 году появляются первые PC, и сразу же начинается разработка EMS. И участвует в ней тот самый Microsoft, глава которого изрек про 640 К. Вместе с Lotus и Intel. Так что твой тезис "640 К — до фига", похоже, критики не выдержал. И до кучи — QEMM, RAMBOOST, даже EMM386 делались с целью максимально освободить основную память. Ту самую, которой до фига. Да, BC++ 3.1 вообще отказывался запускаться в 1 M.
Здравствуйте, Pavel Dvorkin, Вы писали:
E__>>Интернет коммерциализировался. В свое время сайты были не для заработка, а больше for fun. Сейчас это уже редкость. E__>>Кстати, с вирусами то же самое произошло. Когда-то народ писал вирусы ради прикола — переворот букв на экране, или вывод на печать матерных слов в определенных местах теста — это все именно что приколы. Ну и злые тоже были, и немало, но деньги на них не зарабатывали. Вирусописатель тешил свое ЧСВ, да и вирусы были произведением искусства. А сейчас клепают очень глупых троянов(см. троянский слон
), под видом сисек впаривают юзерам, и создают ботнеты, или крадут данные карточек.
PD>Все верно, вполне согласен. Но тогда возвращаюсь к своей посылке : если бы рост объема памяти остановился, скажем, на 256 Мб — он бы не коммерциализировался ? Не думаю. Он бы коммерциализировался вс еравно, но это уложили бы в 32 Мб (броузер etc.). Ну а всякие флешки и баннеры — тут не столько от ОП зависит, сколько от ширины канала.
А в этом случае уже другое. Причем здесь уже упоминали. Когда машины были большими, время и ресурсы компьютеров были дороже времени программистов. Но уже довольно давно все стало наоборот: время программиста стало дороже машинных ресурсов, и пока эта тенденция только усиливается. Вот возьмем хотя-бы 2000 долларов — далеко не самую высокую программерскую зп. На эти деньги можно приобрести 60-80 гигабайт оперативной памяти. Ну, если для серверов, то порядка 40 гигабайт — пофиг, это все равно немало. За месячную зп команды программеров легко приобретается современный сервер в сборе от ведущих производителей(а то и не один — смотря какая команда). Обычный расчет показывает, что дешевле просто написать рабочее ПО, и в случае нехватки ресурсов просто докупить их. Это в корпоративной среде даавно уже поняли. Там безраздельно рулят манагед среды выполнения, так как писать это дело на плюсах неприлично дорого.
В случае клиентского ПО эти правила тоже действуют, хоть и не настолько безраздельно. Но все равно оптимизировать до килобайт никто не будет — привлекательности продукту это не добавит в массе. Вот смотри, Опера у меня сейчас занимает 300 метров в оперативе. В ней 11 вкладок. Это много? А почему это много? Я лично вообще не замечаю, что много — у меня еще 6.5 гектаров свободно(запущена не только Опера). Я не буду использовать продукт только за то, что он меньше весит в памяти. Мне функционал нужно, а памяти всяко хватит. Ну конечно, если браузер сожрет 8 гектар, то я скажу себе "OMG, какое говно" и деинсталлю его. Но пока 300 метров — мне пофигу. Итого, при разработке клиентского ПО руководствуются тем принципом, что оно должно нормально работать у среднего юзера, и оптимизируют ровно до этого момента. Дальнейшая оптимизация не принесет профита, зато потеряется время, которое конкуренты тратят на разработку новых фич. Оно надо?
Конечно, есть и исключения. Это всяческие специализированные, обычно промышленные/оборонные системы, embedded. Там правила другие, и результаты тоже.
По поводу, если бы все остановилось на 32 мб. Да, укладывали бы. Но возможности ПО были бы на порядки меньше. И, если предположить, что каким-то чудом было бы такое же распространение компов, как сейчас, зп программистов вообще стартанула бы в стратосферу(но это взаимоисключающие параграфы — даже если бы технически было бы только 32 мб, но цена упала бы(что есть необходимое условие для массовых компов у населения), полезли бы кластеры, позволяющие куда больше).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Он бы коммерциализировался вс еравно, но это уложили бы в 32 Мб (броузер etc.). Ну а всякие флешки и баннеры — тут не столько от ОП зависит, сколько от ширины канала.
В нарисованном тобой сценарии кажется логичным появление неких коробок типа декодеров для спутникового телевидения, берущих на себя всю основную работу. Браузеру осталось бы не так много. На роль гадалки не претендую.
Здравствуйте, Ikemefula, Вы писали:
I>Тем кто пишет странички, в т.ч. непрограммисты. Обязательно для упрощения и кроссплатформенности.
Мда уж. Джаваскрипт выносит мозг почище F#-а
I>Все остальные подходы показали свою несостоятельность.
Ну конечно. Пока что я наблюдаю ситуацию, что народ бежит со скриптов при первой возможности.
Здравствуйте, Mamut, Вы писали:
M>Какое отношение, скажем, имеет VB.NET к клиентскому скриптингу Хрома или Оперы?
Про сильверлайт слышал или так поболтать ни о чем вышел?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Antikrot, Вы писали:
A>>вот берёшься ли ты утверждать, что можно *полностью повторить функционал и производительность vc++*, ограничиваясь ресурсами времён 96ого года?
PD>Утверждать категорически — нет. Но если позволишь все же взять 98 год (VC6) и немного все же памяти добавишь (ну так процентов 30-50) — думаю, да . Правда, имей в виду — я сказал про C++, я ничего не говорил про дотнет. Аргумент простой — не так уж много нового даже в IDE для C++ по сравнению с VC6.
Для плюсов — да. Основная ставка МС сейчас — дотнет и всякие интеграции.
Хотя и для плюсов плюшки есть. Помидоры написали весьма неплохую(учитывая кошмарность С++ в плане автоматического управления кодом) штуку. И да, во времена vc6 ассист тоже был, но такой кошмарный, что сейчас от этого хочется плакать кровавыми слезами. Про возможности жавовской Идеи я тут уже писал(ты, кстати, почитал? Там много интересного) — VC6 до них как до соседней галактики.
PD>Правда, оговорюсь — по VC 2008 включительно. В VC 2010 есть компиляция по ходу набора текста (как в C#, eclipse и т.д.), на это память нужна. Но и здесь я бы мог сформулировать так : если ее отключить — укладывайтесь, ну а если включить — берите еще памяти.
Компиляция по ходу набора текста для джавы была еще в древнючем жбилдере начала 2000-х(а ихний ГУИ редактор рвал все шаблоны, когда с ним нормально познакомишься*1). Просто МС в плане возможностей IDE тупит по-страшному. Хотя 2010 студия как раз у меня тоже вызывала недоумение своей странной неповоротливостью на ровном месте, что-то они там перемутили.
*1. Когда я понял, как в жбилдере работает дизайнер ГУИ, я, очень мягко сказано, охренел. Начнем с того, что такое создание ГУИ на swing в жаве? Это тупо код, типа такого:
JFrame frame = new JFrame("My cool form");
frame.addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
});
//Создается панель
JPanel panel = new JPanel();
//добавление границы к панели
panel.setBorder(BorderFactory.createTitledBorder("border"));
panel.add(new JLabel("label"));
//Добавление панели к фрейму
frame.getContentPane().add(panel);
//метод рack(); сообщает Swing о том,
//что нужно придать компонентам необходимые размеры для
//правильного помещения их в форму.
//Другой способ - вызвать setSize(int width, int height).
frame.pack();
//Для того, чтобы увидеть окно на экране
//вы должны вызвать метод setVisible(true)
frame.setVisible(true);
Билдер по-умолчанию этот код создавал в что-то вроде "initComponents". Тут пока все норм, так многие делают. Но обычно редактирование этого метода запрещено, либо перезатирается дизайнером. Но не в билдере! Там можно было, например, сделать так:
public void initComponents(){
button = new JButton(); // это дизайнер сделал автоматом
configureButton(); // это дописано ручками
}
private void configureButton() {
button.setText("кнопочка");
}
А теперь магия: Билдер в пропертях кнопочки корректно отображал "кнопочка", рисовал это в дизайнере, и позволял это менять! Причем если поменять значение, то изменеия он писал именно в то место, где записан исходный код — в данном случае в методе configureButton(), получалось
private void configureButton() {
button.setText("измененный в дизайнере текст");
}
Нужно сказать, что раскидистость дерева вызовов ничем не ограничивалась: вполне корректно отрабатывало и задание пропертей в другом классе, пакете, или проекте! Причем отлично отрабатывало, скажем, отображение в дизайнере данных из БД, или из сети(сложность кода для получения значения ничем не ограничивалась, и неважно, из прокета он, или из либы, или вообще из класса, поднятого кастомным класслоадером из сети, и выполненного через рефлекшн его метода), правда, менять значение такой проперти не получалось(что логично).
И да, жбилдер спокойно работал не только со стандартными компонентами. Любой визуальный компонент(наследник java.awt.Component), неважно, твой или чужой, корректно отображался(напомню, мы говорим о ГУИ дизайнере), и можно было менять его проперти(все методы setXXX(Type Name) отображались в пропертях компоненты в дизайнере, и их можно было менять). Апофеозом стало добавление на форму самого окошка жбилдера(он же тоже на жаве написан) — все прошло ок: билдер с пустым проектом вполне добавился как компонент формы, можно было менять его размеры и свойства. Мои глаза в тот момент уже занимали половину лица. А было это давно еще...
А потом, в очередной версии, они все это выкинули... Ну а потом и сам жбилдер сдох, RIP, но я врядли забуду его дизайнер — даже сейчас вроде ничего такого ни у кого нет и близко, видимо, нет спроса.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, Mamut, Вы писали:
M>>Какое отношение, скажем, имеет VB.NET к клиентскому скриптингу Хрома или Оперы? O>Про сильверлайт слышал или так поболтать ни о чем вышел?
Сильверлайт пока не более распространен, чем жаба апплеты, даже менее. Так что пока это только в разделе "слышал".
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Сильверлайт пока не более распространен, чем жаба апплеты, даже менее. Так что пока это только в разделе "слышал".
Соглашусь, но речь шла о совместимости с браузерами, а не о распространенности.
Здравствуйте, olegkr, Вы писали:
I>>Тем кто пишет странички, в т.ч. непрограммисты. Обязательно для упрощения и кроссплатформенности. O>Мда уж. Джаваскрипт выносит мозг почище F#-а
Да не гони. Джаваскрипт учится на раз безо всяких книжек и даже туториалов.
Во первых, он легко понятен любому, кто имел дело с Си-подобным языком.
Во вторых, в нем достаточно мало фич относительно того же F#
I>>Все остальные подходы показали свою несостоятельность. O>Ну конечно. Пока что я наблюдаю ситуацию, что народ бежит со скриптов при первой возможности.
Странно бегут как то. Каждый год количество джаваскрипта только увеличивается на сайтах. Уже нормальное дело загружать по 1мб этого скрипта.
Здравствуйте, Antikrot, Вы писали:
A>а я говорил "полностью", ибо небольшая на взгляд фича может оказаться потяжелее всего остального. A>и кстати я имел в виду vc++ то есть cl.exe из например 2008ой студии — вот его функционал можно *полностью*, со всеми видимыми и невидимыми фичами, повторить на ресурсах, которые требовал cl.exe из vc6, и не просесть в производительности? (ну пусть +50%, так и быть)
A>интересный момент — на сколько больше брать памяти?
Я думаю, раза в 1.5. И вот почему
Контрвопрос — насколько меньше памяти потреблял компилятор от VC 4.2, 5.0 ? Опять же — от силы раза в 1.5, ну пусть 2. А предположить, что от 4.2 до 6.0 он не развивался, а тут уж прямо в гору пошел — как-то сомнительно.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>Пусть уплотняют чего хотят, я про 600 Кб ОП. Ты меня не собьешь своими стакерами
P>Нас никому не сбить с пути, нам все равно, куда идти (c)
PD>>Не собьешь ты меня драйверами, химемами и прочим!
P>См. выше.
P>Химем — это himem.sys? А как без него-то на 286?
Она на 286 был, но работал иначе, чем на 386.
P>Вывод. Заявление Билла Гейтса больше похоже на рекламный ход. Суди сам: в 1981 году появляются первые PC, и сразу же начинается разработка EMS. И участвует в ней тот самый Microsoft, глава которого изрек про 640 К. Вместе с Lotus и Intel. Так что твой тезис "640 К — до фига", похоже, критики не выдержал. И до кучи — QEMM, RAMBOOST, даже EMM386 делались с целью максимально освободить основную память. Ту самую, которой до фига. Да, BC++ 3.1 вообще отказывался запускаться в 1 M.
Все чудненько.
Я задал простой вопрос — почему при 640 К памятью не швырялись.
Ответа на него я не получил. Зато получил массу ответов с уходом в самые разные стороны — от оверлеев до Оракла
А ответ простой.
Посто потому, что тогда с памятью работали профессионалы (а непрофессионалы писали на Бейсике, и отнюдь не Вижуал), которые умели писать как следует, вместо того, чтобы с умным видом рассуждать об абстракциях и паттернах и т.п.
Здравствуйте, Pavel Dvorkin, Вы писали:
P>>Химем — это himem.sys? А как без него-то на 286?
PD>Она на 286 был, но работал иначе, чем на 386.
Да я знаю. Просто без него доступ к верхней памяти вообще не открывался (QEMM не считается, к тому же он с 386 начинался, по крайней мере, с определенной версии).
P>>Вывод. Заявление Билла Гейтса больше похоже на рекламный ход. PD>Все чудненько.
PD>Я задал простой вопрос — почему при 640 К памятью не швырялись.
Потому что, как мы только что увидели, швыряться особо было нечем.
PD>Ответа на него я не получил.
А что ты хочешь? Это же КСВ.
PD>Зато получил массу ответов с уходом в самые разные стороны — от оверлеев до Оракла
Оверлеи — один из методов борьбы с 640 К. И если их приходилось делать руками, нужно было приложить определенные усилия.
PD>А ответ простой.
Угу, см. выше.
PD>Посто потому, что тогда с памятью работали профессионалы...
Которые упорно боролись с ее постоянной нехваткой, вместо того, чтобы решать целевую задачу.
PD>...(а непрофессионалы писали на Бейсике, и отнюдь не Вижуал), которые умели писать как следует, вместо того, чтобы с умным видом рассуждать об абстракциях и паттернах и т.п.
Про "Искру-226" я тебе рассказывал уже. Там была совсем уродливая версия Бейсика (далекая даже от GWBASIC). Так вот там ни разу не любители работали. В таких условиях — ни одной строчки спагетти-кода.
Здравствуйте, Eugeny__, Вы писали:
E__>А в этом случае уже другое. Причем здесь уже упоминали. Когда машины были большими, время и ресурсы компьютеров были дороже времени программистов. Но уже довольно давно все стало наоборот: время программиста стало дороже машинных ресурсов, и пока эта тенденция только усиливается. Вот возьмем хотя-бы 2000 долларов — далеко не самую высокую программерскую зп. На эти деньги можно приобрести 60-80 гигабайт оперативной памяти. Ну, если для серверов, то порядка 40 гигабайт — пофиг, это все равно немало. За месячную зп команды программеров легко приобретается современный сервер в сборе от ведущих производителей(а то и не один — смотря какая команда). Обычный расчет показывает, что дешевле просто написать рабочее ПО, и в случае нехватки ресурсов просто докупить их. Это в корпоративной среде даавно уже поняли. Там безраздельно рулят манагед среды выполнения, так как писать это дело на плюсах неприлично дорого. E__>В случае клиентского ПО эти правила тоже действуют, хоть и не настолько безраздельно. Но все равно оптимизировать до килобайт никто не будет — привлекательности продукту это не добавит в массе. Вот смотри, Опера у меня сейчас занимает 300 метров в оперативе. В ней 11 вкладок. Это много? А почему это много? Я лично вообще не замечаю, что много — у меня еще 6.5 гектаров свободно(запущена не только Опера). Я не буду использовать продукт только за то, что он меньше весит в памяти. Мне функционал нужно, а памяти всяко хватит. Ну конечно, если браузер сожрет 8 гектар, то я скажу себе "OMG, какое говно" и деинсталлю его. Но пока 300 метров — мне пофигу. Итого, при разработке клиентского ПО руководствуются тем принципом, что оно должно нормально работать у среднего юзера, и оптимизируют ровно до этого момента. Дальнейшая оптимизация не принесет профита, зато потеряется время, которое конкуренты тратят на разработку новых фич. Оно надо? E__>Конечно, есть и исключения. Это всяческие специализированные, обычно промышленные/оборонные системы, embedded. Там правила другие, и результаты тоже.
Совершенно верно. Вот смотри.
Жил да был в 1980-е годы некто Иван Иванович Иванов. Зарабатывал 200 руб. в месяц, с премиями выходило 250. Мечтал о том, чтобы с этой зарплаты 500 руб. накопить и жене купить шубу из цигейки.
А тут 1990-е. Трах-бах, и вдруг у И.И. на счету миллиард долларов.
Не у всех так было, конечно. Но вот у данного И.И. — да. Честно он их заработал или нет — не обсуждаем.
И что с ними делать ?
Можно, конечно, вложить в какое-то производство и т.д. Или уже имеющееся развивать. Ну как Б. Гейтс, например в те же времена. Или как китайцы.
А можно яхты покупать и дебоши в Куршавеле устраивать. Гуляй, рванина. Тем более, что этот самый И.И., скажем так, воспитывался не в Пажеском корпусе.
А за 1990-ми приходят 2000-е. И появляется масса мальчиков и девочек, которые про 200 руб. в месяц ничего не знают. Для них норма — это когда ну пусть не миллиарды, но хоть сотни тысяч этих зеленых есть. Потому что тратить их таким образом — это и есть смысл жизни.
А потом набегают журналисты, которые тут же и берутся доказать всем, что именно в этом смыссл жизни и заключается. Идейную базу подводят.
Сравнение, конечно, хромает. Все по миллиарду не получили. А вот памяти получили — все.
И тут просто выяснилось, что вкладывать-то ее некуда! Вот ведь в чем вопрос-то. Нет у бизнеса таких задач, где эти гигабайты нужны.
Нет, кое у какого бизнеса есть. Какие-нибудь там прогнозы на 10 лет вперед у компаний уровня Газпрома. И другие есть.
А у большинства фирм — просто нет. Как их бизнес мог бы выглядеть в 1980 (если бы не было советской власти) или в 1990-е, так он и сейчас выглядит. Кое у кого масштабы расширились, ассортимент сменился, а в общем, производство шарикоподшипников не превратилось в полет на Марс.
Если уж из такой, в общем-то, простой задачи, как электронная почта, пусть и с хранением писем на каком-то сервере, сделали выдающееся достижение и сказали. что меньше чем на 100 миллионов долларов это решение не тянет — значит, просто вам эти 100 миллионов некуда тратить было.
Вот и начали эти свалившиеся с неба ресурсы на все что попало тратить. Компьютерные яхты покупать и компьютерные дебоши устраивать.
И идейную базу под это подвели. Без журналистов. Мы тут люди грамотные, язык кое у кого неплохо подвешен, сами справимся.
P>>>Химем — это himem.sys? А как без него-то на 286?
PD>>Она на 286 был, но работал иначе, чем на 386.
P>Да я знаю. Просто без него доступ к верхней памяти вообще не открывался (QEMM не считается, к тому же он с 386 начинался, по крайней мере, с определенной версии).
Доступ к верхней памяти не открывался, да, а почему памятью не швырялись ?
P>>>Вывод. Заявление Билла Гейтса больше похоже на рекламный ход. PD>Все чудненько.
PD>>Я задал простой вопрос — почему при 640 К памятью не швырялись.
P>Потому что, как мы только что увидели, швыряться особо было нечем.
Было. Почему, если можно было обойтись 100 Кб, обходились 100, а не хватали все 600 ? Это же по соотношению — те же 20 Мб против 120! NN 4.7 против Хрома.
PD>>Ответа на него я не получил.
P>А что ты хочешь? Это же КСВ.
Выкидывай белый флаг
PD>>Зато получил массу ответов с уходом в самые разные стороны — от оверлеев до Оракла
P>Оверлеи — один из методов борьбы с 640 К. И если их приходилось делать руками, нужно было приложить определенные усилия.
Оверлеи — один из методов борьбы, да, а почему памятью не швырялись ?
PD>>А ответ простой.
P>Угу, см. выше.
PD>>Посто потому, что тогда с памятью работали профессионалы...
P>Которые упорно боролись с ее постоянной нехваткой, вместо того, чтобы решать целевую задачу.
А почему они ей не швырялись, когда имелось 600, а надо было только 100 ?
PD>>...(а непрофессионалы писали на Бейсике, и отнюдь не Вижуал), которые умели писать как следует, вместо того, чтобы с умным видом рассуждать об абстракциях и паттернах и т.п.
P>Про "Искру-226" я тебе рассказывал уже. Там была совсем уродливая версия Бейсика (далекая даже от GWBASIC). Так вот там ни разу не любители работали. В таких условиях — ни одной строчки спагетти-кода.
На Искре была уродливая версия Бейсика, да, а почему в MS-DOS при 600 Кб памятью не швырялись ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Доступ к верхней памяти не открывался, да, а почему памятью не швырялись ?
На самом деле памятью не швырялись, только если не было возможности.
Однажды в детстве я попал на один ВЦ, где стояла, может, уже не работавшая, ЭВМ первого поколения. Разумеется про то, что это была ЭВМ, да еще первого поколения, я узнал гораздо позже. Из того визита у меня в памяти отложилась одна вещь: какой-то дядька в белом халате подошел ко мне, держа в руках какую-то хреновину, и сказал: "Смотри, это — память". Я хорошо рассмотрел две стеклуанные колбы приличных размеров. Позже я узнал, что это лампы.
Такой памятью особо не расшвыряешься. Стекло, осколки... Оно кому-то надо?
На ЕСках с этим было проще. Модуль извлекаетли из корпуса машины и швыряли в ящик с инструментами.
На PC /XT/AT опять памятью швыряться перестали. Там она была припаяна к материнской плате со всеми вытекающими оттута последствиями. На 386 и выше ситуация вновь улучшилась. Вынул SIMM или DIMM из мамки и швырнул его в мусор.
PD>Было. Почему, если можно было обойтись 100 Кб, обходились 100, а не хватали все 600 ? Это же по соотношению — те же 20 Мб против 120! NN 4.7 против Хрома.
PD>>>Ответа на него я не получил.
Теперь, думаю, получил.
P>>А что ты хочешь? Это же КСВ.
PD>Выкидывай белый флаг
У меня его никогда не было. А если бы и был, я бы его не выкинул: жалко. В хозяйстве всегда белая ткань пригодиться может.
PD>Оверлеи — один из методов борьбы, да, а почему памятью не швырялись ?
PD>>>А ответ простой.
P>>Угу, см. выше.
PD>Карфаген должен быть разрушен
Сдается мне, я и сегодня про дотнет ничего нового не узнаю.
E__>>Сильверлайт пока не более распространен, чем жаба апплеты, даже менее. Так что пока это только в разделе "слышал". O>Соглашусь, но речь шла о совместимости с браузерами, а не о распространенности.
M>>Покажи мне эти языки для клиентского скриптинга в браущере с покрытием хотя бы 50% рынка браузеров
O>C#, VB.NET, F# плюс куча других
С какого перепугу они покрывают 50% рынка браузеров?
PD>>Он бы коммерциализировался вс еравно, но это уложили бы в 32 Мб (броузер etc.). Ну а всякие флешки и баннеры — тут не столько от ОП зависит, сколько от ширины канала.
P>В нарисованном тобой сценарии кажется логичным появление неких коробок типа декодеров для спутникового телевидения, берущих на себя всю основную работу. Браузеру осталось бы не так много. На роль гадалки не претендую.
Попроси его декодировать и показать HD-видео во флэше без ОП (и процессора). Но он же не ответит.
Здравствуйте, Pavel Dvorkin, Вы писали:
E__>>А в этом случае уже другое. Причем здесь уже упоминали. Когда машины были большими, время и ресурсы компьютеров были дороже времени программистов. Но уже довольно давно все стало наоборот: время программиста стало дороже машинных ресурсов, и пока эта тенденция только усиливается. Вот возьмем хотя-бы 2000 долларов — далеко не самую высокую программерскую зп. На эти деньги можно приобрести 60-80 гигабайт оперативной памяти. Ну, если для серверов, то порядка 40 гигабайт — пофиг, это все равно немало. За месячную зп команды программеров легко приобретается современный сервер в сборе от ведущих производителей(а то и не один — смотря какая команда). Обычный расчет показывает, что дешевле просто написать рабочее ПО, и в случае нехватки ресурсов просто докупить их. Это в корпоративной среде даавно уже поняли. Там безраздельно рулят манагед среды выполнения, так как писать это дело на плюсах неприлично дорого. E__>>В случае клиентского ПО эти правила тоже действуют, хоть и не настолько безраздельно. Но все равно оптимизировать до килобайт никто не будет — привлекательности продукту это не добавит в массе. Вот смотри, Опера у меня сейчас занимает 300 метров в оперативе. В ней 11 вкладок. Это много? А почему это много? Я лично вообще не замечаю, что много — у меня еще 6.5 гектаров свободно(запущена не только Опера). Я не буду использовать продукт только за то, что он меньше весит в памяти. Мне функционал нужно, а памяти всяко хватит. Ну конечно, если браузер сожрет 8 гектар, то я скажу себе "OMG, какое говно" и деинсталлю его. Но пока 300 метров — мне пофигу. Итого, при разработке клиентского ПО руководствуются тем принципом, что оно должно нормально работать у среднего юзера, и оптимизируют ровно до этого момента. Дальнейшая оптимизация не принесет профита, зато потеряется время, которое конкуренты тратят на разработку новых фич. Оно надо? E__>>Конечно, есть и исключения. Это всяческие специализированные, обычно промышленные/оборонные системы, embedded. Там правила другие, и результаты тоже.
PD>Вот и начали эти свалившиеся с неба ресурсы на все что попало тратить. Компьютерные яхты покупать и компьютерные дебоши устраивать.
А что ты предлагаешь? Сейчас писать так, как будто памяти 32 мб? Внимание, вопрос: а кто за это будет платить?. Такая оптимизация при широком функционале банально дорого стоит. В самом прямом смысле, в зеленых бумажках. Но это если говорить про себестоимость. Цена же на рынке такой оптимизации близка к нулю. Получается товар, у которого себестоимость превышает рыночную цену — нафиг, снимаем с производства. И налаживаем производство новых фич — это как раз востребовано.
Да, дешевле взять готовую либу для решения задачи, пусть она потянет за собой еще десяток, и сожрет N мегабайт памяти, а не писать свой велосипед и тем более не париться с ассемблерами там всякими. Это как пример.
Так что никаких яхт и куршавелей. Чистый бизнес.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Все чудненько.
PD>Я задал простой вопрос — почему при 640 К памятью не швырялись.
PD>Ответа на него я не получил. Зато получил массу ответов с уходом в самые разные стороны — от оверлеев до Оракла
Получил ответ — нечем было швыряться.
PD>А ответ простой.
PD>Посто потому, что тогда с памятью работали профессионалы (а непрофессионалы писали на Бейсике, и отнюдь не Вижуал), которые умели писать как следует, вместо того, чтобы с умным видом рассуждать об абстракциях и паттернах и т.п.
"были люди как люди а теперь в один день кретинами стали" @
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Доступ к верхней памяти не открывался, да, а почему памятью не швырялись ?
Нечем было швыряться.
PD>Было. Почему, если можно было обойтись 100 Кб, обходились 100, а не хватали все 600 ? Это же по соотношению — те же 20 Мб против 120! NN 4.7 против Хрома.
Вообще то NN этот не может отрыть ту страницу, на которой Хром ест 120мб в шести процессах.
P>>Оверлеи — один из методов борьбы с 640 К. И если их приходилось делать руками, нужно было приложить определенные усилия.
PD>Оверлеи — один из методов борьбы, да, а почему памятью не швырялись ?
Потому что нечем было. Ради мелочевки приходилось заниматься всякой фигней вместо решения основной задачи.
P>>Которые упорно боролись с ее постоянной нехваткой, вместо того, чтобы решать целевую задачу.
PD>А почему они ей не швырялись, когда имелось 600, а надо было только 100 ?
Привычка. 100кб занимает система. 50-100 — довески вроде NC, русификаторов, еще 200-300 занимает ИДЕ или отладчик. Сколько места на отлаживаемую программу ?
Правильно — 100-200кб
Взять Turbo Vision — минимальная прога займет в памяти около 60кб, если с оверлеями на паскале.
Вот Turbo Vision на Borland C++ уже надо было 200 для этого же минимума, потому что оверлеев BC не умел и это надо было делать руками, что умели не многие.
P>>Про "Искру-226" я тебе рассказывал уже. Там была совсем уродливая версия Бейсика (далекая даже от GWBASIC). Так вот там ни разу не любители работали. В таких условиях — ни одной строчки спагетти-кода.
PD>На Искре была уродливая версия Бейсика, да, а почему в MS-DOS при 600 Кб памятью не швырялись ?
I>Вот Turbo Vision на Borland C++ уже надо было 200 для этого же минимума, потому что оверлеев BC не умел и это надо было делать руками, что умели не многие.
Вот сдается мне, что в BC++ 2.0/3.x оверлеи были, причем устроены они были, как современная виртуальная память, — страницами по 4 К. Там же файлы получались огромные, особенно с TV. Сам IDE BC был размером больше мегабайта.
ЕМНИП, при сборке тип файла надо было указать соответствующий. Хотя не исключено, что я наврал: проверить с ходу не получается по причине отсутствия BC++ под рукой. В TC оверлеев не было.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Доступ к верхней памяти не открывался, да, а почему памятью не швырялись ?
P>На самом деле памятью не швырялись, только если не было возможности. P>Однажды в детстве я попал на один ВЦ, где стояла, может, уже не работавшая, ЭВМ первого поколения. Разумеется про то, что это была ЭВМ, да еще первого поколения, я узнал гораздо позже. Из того визита у меня в памяти отложилась одна вещь: какой-то дядька в белом халате подошел ко мне, держа в руках какую-то хреновину, и сказал: "Смотри, это — память". Я хорошо рассмотрел две стеклуанные колбы приличных размеров. Позже я узнал, что это лампы.
P>Такой памятью особо не расшвыряешься. Стекло, осколки... Оно кому-то надо?
P>На ЕСках с этим было проще. Модуль извлекаетли из корпуса машины и швыряли в ящик с инструментами.
P>На PC /XT/AT опять памятью швыряться перестали. Там она была припаяна к материнской плате со всеми вытекающими оттута последствиями. На 386 и выше ситуация вновь улучшилась. Вынул SIMM или DIMM из мамки и швырнул его в мусор.
Вот! Наконец-то!
PD>>Было. Почему, если можно было обойтись 100 Кб, обходились 100, а не хватали все 600 ? Это же по соотношению — те же 20 Мб против 120! NN 4.7 против Хрома.
PD>>>>Ответа на него я не получил.
P>Теперь, думаю, получил.
Теперь получил.
P>>>А что ты хочешь? Это же КСВ.
PD>>Выкидывай белый флаг
P>У меня его никогда не было. А если бы и был, я бы его не выкинул: жалко. В хозяйстве всегда белая ткань пригодиться может.
PD>>Оверлеи — один из методов борьбы, да, а почему памятью не швырялись ?
PD>>>>А ответ простой.
P>>>Угу, см. выше.
PD>>Карфаген должен быть разрушен
P>Сдается мне, я и сегодня про дотнет ничего нового не узнаю.
Здравствуйте, genre, Вы писали:
PD>>А примерами доказываются ? Мне в качестве примера Google дают, он — доказательство, так ? А то, что для других сайтов все это не нужно — не годится в качестве аргумента ? Хорошенькое получается дело — примеры что-то доказывают, а контрпримеры — ничего. Тогда уж считать надо — сколько примеров, а сколько контрпримеров. И какова их роль, конечно, тоже.
G>Ты что правда не знаешь? Это же основы логики. G>Контрпримером опровергается утверждение вида: для всех А верно В G>но G>Контрпримером не опровергается утверждение вида: для некоторых А верно В
G>то есть утверждение G>"Все сайты стали требовать много ресурсов" опровергается твоим контрпримером. G>Но утверждение "Некоторые сайты стали требовать много ресурсов" твоим кнотрпримером не опровергается.
Основы логики тут не годятся, потому что утверждение "для всех А верно В" я вовсе и не выдвигал. Но если окажется, что для 95% A верно B (а это можно доказать контрпримерами и примерами), то еще большой вопрос — а нужны ли оставшиеся 5% в том виде, как они есть сейчас, и нельзя ли было эти 5% сделать так, чтобы и для них верно было B
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали:
A>>>а я говорил "полностью", ибо небольшая на взгляд фича может оказаться потяжелее всего остального. A>>>и кстати я имел в виду vc++ то есть cl.exe из например 2008ой студии — вот его функционал можно *полностью*, со всеми видимыми и невидимыми фичами, повторить на ресурсах, которые требовал cl.exe из vc6, и не просесть в производительности? (ну пусть +50%, так и быть)
A>>>интересный момент — на сколько больше брать памяти? PD>>Я думаю, раза в 1.5. И вот почему A>про "насколько больше брать памяти" было к A>
A>В VC 2010 есть компиляция по ходу набора текста (как в C#, eclipse и т.д.), на это память нужна.
A>и откуда тут полтора, не пойму. мне почему-то кажется, что тут надо брать больше на столько, сколько жрёт собственно компилятор (в наивном приближении — у меня нет vc2010 и я не могу даже посмотреть как он там компиляет)
Стоп! Или ты меня неправильно понял, или передергиваешь. Я ведь ясно сказал чуть раньше. Выделяю
PD>Правда, оговорюсь — по VC 2008 включительно. В VC 2010 есть компиляция по ходу набора текста (как в C#, eclipse и т.д.), на это память нужна. Но и здесь я бы мог сформулировать так : если ее отключить — укладывайтесь, ну а если включить — берите еще памяти.
Почему же ты из этой фразы кусок убрал ?
Так что в полтора — это либо до VC2008 включительно, либо VC2010, но с отключением этой фичи.
PD>>Контрвопрос — насколько меньше памяти потреблял компилятор от VC 4.2, 5.0 ? Опять же — от силы раза в 1.5, ну пусть 2. А предположить, что от 4.2 до 6.0 он не развивался, A>вообще-то такие предположения неплохо бы обосновать
PD>>а тут уж прямо в гору пошел — как-то сомнительно. A>тебе вроде как целую гору фич показали новых. так что ещё как в гору.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Доступ к верхней памяти не открывался, да, а почему памятью не швырялись ?
I>Нечем было швыряться.
PD>>Было. Почему, если можно было обойтись 100 Кб, обходились 100, а не хватали все 600 ? Это же по соотношению — те же 20 Мб против 120! NN 4.7 против Хрома.
I>Вообще то NN этот не может отрыть ту страницу, на которой Хром ест 120мб в шести процессах.
Я не про NN и хром, а только про соотношение. А NN не может открыть страницу, потому что версия языка изменилась, ты это сам подтвердил.
PD>>А почему они ей не швырялись, когда имелось 600, а надо было только 100 ?
I>Привычка. 100кб занимает система. 50-100 — довески вроде NC, русификаторов, еще 200-300 занимает ИДЕ или отладчик. Сколько места на отлаживаемую программу ?
Примерно 600. NC — штука была довольно умная, она основную свою часть динамически подгружала. ОС-то однопрограммная, когда моя программа работает — NC делать нечего. Более того, даже command.com был полурезидентным и уходил, когда моя программа запускалась.
I>Правильно — 100-200кб
I>Взять Turbo Vision — минимальная прога займет в памяти около 60кб, если с оверлеями на паскале.
Угу. И при этом интерфейс с edit, listbox, combobox... Почти как в Windows 3.x, только в текстовом режиме. И все это в 60 Кб. Насчет оверлеев — не помню, чтобы внутри TVision были оверлеи. Впрочем, может я и не прав.
I>Вот Turbo Vision на Borland C++ уже надо было 200 для этого же минимума, потому что оверлеев BC не умел и это надо было делать руками, что умели не многие.
Кто умел — тот делал. Кто не умел — писаь свои шедевры на Turbo Basic и не философствовал.
P>>>Про "Искру-226" я тебе рассказывал уже. Там была совсем уродливая версия Бейсика (далекая даже от GWBASIC). Так вот там ни разу не любители работали. В таких условиях — ни одной строчки спагетти-кода.
PD>>На Искре была уродливая версия Бейсика, да, а почему в MS-DOS при 600 Кб памятью не швырялись ?
I>Нечем было.
Что мне еще сказать ? Ну повторю, если не понимаешь. Было всего 600. Использовали, скажем, 100. А можно было использовать 600, потому что никакого дохода от того, что эти лишние 500 не брать, быть не могло, ибо ОС однопрограммная. 600 — 100 == 500, 600/100 == 5. То есть брали в 5 раз меньше , чем могли бы. А могли бы еще 500 взять, просто так. Но не брали. Так было чем или опять скажешь, что нечем было ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я просто говорю : делаете так — делайте, только бога ради не оправдывайте свои деяния глубокими философскими соображениями и не доказывайте. что, мол, иначе нельзя.
а вопрос-то именно философский. ведь пока ты не покажешь *абсолютно равные по функционалу и производительности* аналоги (с меньшим ресурсопотреблением), не докажешь, что можно иначе. а ты не покажешь, так как их нет
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>> тогда возвращаюсь к своей посылке : если бы рост объема памяти остановился, скажем, на 256 Мб — он бы не коммерциализировался ? Не думаю. Он бы коммерциализировался вс еравно, но это уложили бы в 32 Мб (броузер etc.).
G>>Может ты все-таки будешь доказывать подобные утверждения? Тут кроме тебя все считают совсем наоборот.
PD>Тебя же докаательства такого рода не удовлетворяют. Допустим, я докажу, что 95% сайтов сейчас не лучше, чем 10 лет назад.
А при чем тут процент лучше не лучше? Выше ты утверждаешь, что если бы не было памяти, то сайты все равно были бы такие же как сейчас. Ну то есть ты считаешь, что фейсбук или гмейл можно переписать так, что бы они работали в 32мб памяти?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Основы логики тут не годятся,
даже не знаю что уже и сказать.
PD>потому что утверждение "для всех А верно В" я вовсе и не выдвигал.
выдвигал. оно звучит как "для всех современных сайтов верно, что их можно впихнуть в 32мб памяти"
PD>Но если окажется, что для 95% A верно B (а это можно доказать контрпримерами и примерами), то еще большой вопрос — а нужны ли оставшиеся 5% в том виде, как они есть сейчас, и нельзя ли было эти 5% сделать так, чтобы и для них верно было B
PD>>Я просто говорю : делаете так — делайте, только бога ради не оправдывайте свои деяния глубокими философскими соображениями и не доказывайте. что, мол, иначе нельзя. A>а вопрос-то именно философский. ведь пока ты не покажешь *абсолютно равные по функционалу и производительности* аналоги (с меньшим ресурсопотреблением), не докажешь, что можно иначе. а ты не покажешь, так как их нет
Железная логика. Если чего-то на свете нет, значит, этого и быть не может.
G>А при чем тут процент лучше не лучше? Выше ты утверждаешь, что если бы не было памяти, то сайты все равно были бы такие же как сейчас. Ну то есть ты считаешь, что фейсбук или гмейл можно переписать так, что бы они работали в 32мб памяти?
Думаю, что да. Может, не на 32, но уж на 256 да.
Контрвопрос к тебе — а если бы рост памяти остановился на 256 Мб — следовало бы из этого, что сайты, аналогичные gmail или фейсбук вообще не могли бы быть созданы, в принципе ?
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Вообще то NN этот не может отрыть ту страницу, на которой Хром ест 120мб в шести процессах.
PD>Я не про NN и хром, а только про соотношение. А NN не может открыть страницу, потому что версия языка изменилась, ты это сам подтвердил.
А какой смысл имеет соотношение если браузер не может страницу открыть ? Как ты сравниваешь, только тебе одному известно
I>>Взять Turbo Vision — минимальная прога займет в памяти около 60кб, если с оверлеями на паскале.
PD>Угу. И при этом интерфейс с edit, listbox, combobox... Почти как в Windows 3.x, только в текстовом режиме. И все это в 60 Кб. Насчет оверлеев — не помню, чтобы внутри TVision были оверлеи. Впрочем, может я и не прав.
А вот если насовать эдитов и тд и тд, то будет гораздо больше 60кб.
I>>Нечем было.
PD>Что мне еще сказать ? Ну повторю, если не понимаешь. Было всего 600. Использовали, скажем, 100.
Могло быть и 400 и меньше, например на многих компах было не 640 а всего 512,система + куча резидентов на все случаи жизни что было самым обычным делом.
>А можно было использовать 600, потому что никакого дохода от того, что эти лишние 500 не брать, быть не могло,
Могло, в том то и дело. Используешь 600, прога откажется запускаться там где есть всего 400.
А если используешь 400, то не сможешь запустить её под отладчиком.
>ибо ОС однопрограммная. 600 — 100 == 500, 600/100 == 5. То есть брали в 5 раз меньше , чем могли бы. А могли бы еще 500 взять, просто так. Но не брали. Так было чем или опять скажешь, что нечем было ?
Итого — практически все книги учили тому как экономить память и выравнивание на границу слова было жутко дорогой прихотью.
Именно от недостатка памяти пошли оверлеи и всякие хитрости. И именно от недостатка было нечем бросаться.
PD>>Но если окажется, что для 95% A верно B (а это можно доказать контрпримерами и примерами), то еще большой вопрос — а нужны ли оставшиеся 5% в том виде, как они есть сейчас, и нельзя ли было эти 5% сделать так, чтобы и для них верно было B
G>фейсбук, гмейл, рсдн — не нужны?
фейсбука и гмейла тогда не было. Насчет них ответил в предыдущем своем письме, там и вопрос задал тебе.
Здравствуйте, Ikemefula, Вы писали:
PD>>Я не про NN и хром, а только про соотношение. А NN не может открыть страницу, потому что версия языка изменилась, ты это сам подтвердил.
I>А какой смысл имеет соотношение если браузер не может страницу открыть ? Как ты сравниваешь, только тебе одному известно
Ну если ты фразу не понимаешь — что я могу еще сказать ?
I>А вот если насовать эдитов и тд и тд, то будет гораздо больше 60кб.
Будет. Но не 600.
I>Могло быть и 400 и меньше, например на многих компах было не 640 а всего 512,система + куча резидентов на все случаи жизни что было самым обычным делом. I>Могло, в том то и дело. Используешь 600, прога откажется запускаться там где есть всего 400.
Много чего могло быть, но было 600. На PC AT 512 не было.
I>А если используешь 400, то не сможешь запустить её под отладчиком.
>>ибо ОС однопрограммная. 600 — 100 == 500, 600/100 == 5. То есть брали в 5 раз меньше , чем могли бы. А могли бы еще 500 взять, просто так. Но не брали. Так было чем или опять скажешь, что нечем было ?
I>Итого — практически все книги учили тому как экономить память и выравнивание на границу слова было жутко дорогой прихотью.
I>Именно от недостатка памяти пошли оверлеи и всякие хитрости. И именно от недостатка было нечем бросаться.
В общем, и то и другое и третье, а не бросались. И не надо посторонние аргументы приводить. Суть остается — не брали лишнюю. Умели писать как следует.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Думаю, что да. Может, не на 32, но уж на 256 да.
PD>Контрвопрос к тебе — а если бы рост памяти остановился на 256 Мб — следовало бы из этого, что сайты, аналогичные gmail или фейсбук вообще не могли бы быть созданы, в принципе ?
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Чем больше индусов будет писать сайты, тем лучше.
PD>Супер! Умри, Денис, лучше не скажешь! Так им и надо, сайтам
Представь себе, если бы китайцы и азиаты всякие не начали клапать компьютеры-железо и тд, то и по сей день, например, оперативная память была бы жутко дорогим ресурсом.
PD>>Ну и как ? Сильно отличается ?
G>про это тут тебе уже писали где-то. про раскрытие веток и подобное.
Охотно верю. Но вот незадача — в Windows95 эти ветки в treeview умели раскрывать довольно таки шустро, правда, вне броузераЮ зато на 8 Мб. Доказательство простое — — regedit же работал! А там уж не меньше порой ключей одного уровня, чем сообщений в любом топике на всех уровнях.
Здравствуйте, Antikrot, Вы писали:
PD>>Железная логика. Если чего-то на свете нет, значит, этого и быть не может. A>мсье теоретик?
Нет. Мсье автор программ, от которых требовали как можно большую скорость и при этом не расходовать память понапрасну. Windows.
A>сможешь доказать, что это может быть? или только обвинять в распиле можешь?
Железная логика. Если я чего-то не могу доказать, значит, этого быть не может
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Antikrot, Вы писали:
PD>>>Железная логика. Если чего-то на свете нет, значит, этого и быть не может. A>>мсье теоретик?
PD>Нет. Мсье автор программ, от которых требовали как можно большую скорость и при этом не расходовать память понапрасну. Windows.
А сейчас не требуют. Такие дела...
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
PD>>>>Железная логика. Если чего-то на свете нет, значит, этого и быть не может. A>>>мсье теоретик?
PD>>Нет. Мсье автор программ, от которых требовали как можно большую скорость и при этом не расходовать память понапрасну. Windows.
E__>А сейчас не требуют. Такие дела...
Как раз наоборот, требуют. Например, требует тот же Javascript.
Здравствуйте, Ikemefula, Вы писали:
I>Во первых, он легко понятен любому, кто имел дело с Си-подобным языком.
Загляни в исходный джаваскрипт код какого-нибудь грида и сравни с тем же гридом на сильверлайте. То, что язык примитивный не означает, что на нем легко и приятно писать и потом читать написанное.
I>Странно бегут как то.
В интранете бегут с огромной скоростью. В интернете мешает только то, что рантайм стоит далеко не у всех, да и клиентский UI в массе своей примитивен и убог, так что скриптов кое-как хватает.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>А какой смысл имеет соотношение если браузер не может страницу открыть ? Как ты сравниваешь, только тебе одному известно
PD>Ну если ты фразу не понимаешь — что я могу еще сказать ?
Собственно в данном случае сравнение сродни сравнению расхода топлива современного исправного авто и старенького неисправного. Фигня что неисправное авто проехать дистанцию не может, так ведь зато топлива вообще не ест. Вывод — разучились делать машины, ибо по расходу старая машина делает новую. Указания что машина вообще говоря и не едет скромно игнорируем .
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, Ikemefula, Вы писали:
I>>Поставь себе прокси и посмотри, сколько трафика занимает требует например gmail за месяц и сколько из этого уходит на js. O>Очень хороший пример того, что для написания примитивного UI требуются неимоверные усилия на написания огромного количества скриптового кода. В отличии от...
В отличие от чего ?
html+css+js+flash работает практически везде — виндовс, макось, линукс, фрибсд, мобильные платформы, примерно десяток различных браузеров и тд.
Покажи, что может выступить заменой и что бы а) работало на всех аппаратных платформах б) на всех основных ОС в) во всех основных барузерах
Здравствуйте, genre, Вы писали:
G>Внимание, ты начинаешь отнимать хлеб у Шеридана. Оценивать производительность виндовой гуи по линуксовой это его прерогатива!
Меня не интересует, в какой это среде. Это сделать можно. И было можно.
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Pavel Dvorkin, Вы писали:
G>>>в том виде в котором они существуют сейчас — нет.
PD>>То есть 256 Мб ОП недостаточно в принципе, чтобы решить такую задачу. Любыми способами ?
PD>>Подтверди, пожалуйста, свой "нет" (или ответь иначе).
G>В твоей формулировке вопроса отсутствует очень важная вещь, а конкретно — точная постановка задачи. G>А для точной количественной оценки это необходимо, как, надеюсь, ты понимаешь.
ИМХО я достаточно точно сформулировал. Если нужны были уточнения, надо было их попросить конкретно. Впрочем, ответ от тебя есть.
G>Я считаю, что за разумное время и с разумными затратами и с разумными требованиями по производительности существование сайтов подобных фейсбуку и гмейлу в условиях 256мб в компьютере невозможно. И ведь это мы еще не вспоминаем про бэк-энды этих сайтов, были бы возможны они при отсутствии прогресса в железе?
Слишком много оговорок. Ты от меня просишь точной формулировки, а сам скрылся за тремя "разумными", а что тут разумно и что нет — не определил.
G>Если нужны уточнения ответа уточняй требования
Да нет, в общем-то, все ясно. То есть ты считаешь, что если бы прогресс остановился на 256 — такое сделать было бы нельзя, и никогда мы бы его не имели. Потому что с неразумными (выбери любое из трех) делать никто не будет, а значит — невозможно.
Все, можно закончить, твоя позиция ясна. Моя, полагаю, тоже. Естественно, я не согласен. Продолжать ИМХО не стоит.
Здравствуйте, Eugeny__, Вы писали:
PD>>Нет. Мсье автор программ, от которых требовали как можно большую скорость и при этом не расходовать память понапрасну. Windows.
E__>А сейчас не требуют. Такие дела...
В той области, которой занимается автор — и сейчас требуют.
Здравствуйте, Cadet, Вы писали:
C>Собственно в данном случае сравнение сродни сравнению расхода топлива современного исправного авто и старенького неисправного. Фигня что неисправное авто проехать дистанцию не может, так ведь зато топлива вообще не ест. Вывод — разучились делать машины, ибо по расходу старая машина делает новую. Указания что машина вообще говоря и не едет скромно игнорируем .
Все было бы ничего, если бы ты непонятно почему не объявил старое авто неисправным. Оно вполне исправным было на момент своего употребления. Тут скорее иная аналогия. Представь себе, что создана дорога, при проезде по которой нужно обязательно иметь GPS-приемник, без него не пускают. Естественно, все старые автомобили сюда не поедут, но из этого не следует, что они неисправны.
Здравствуйте, Pavel Dvorkin, Вы писали:
G>>Внимание, ты начинаешь отнимать хлеб у Шеридана. Оценивать производительность виндовой гуи по линуксовой это его прерогатива! PD>Меня не интересует, в какой это среде. Это сделать можно. И было можно.
Что это? Сделать какой-то абстрактный treeview? Ну какой-то конечно можно.
Фиг с ним, что ты сравниваешь нативное виндовое приложение с веб-сайтом, да кто нынче на такие мелочи внимание обращает, да? Вообще все офигели, вот у меня когда-то zx spectrum был, 50 игрух на аудиокассету помещалось, они все офигели, работать не умеют, такие нынче требования к аппаратным ресурсам выдвигают. Памяти им гигабайты нужны. Обленились! 64Кб оперативки и аудиокассета!
Так?
G>Что это? Сделать какой-то абстрактный treeview? Ну какой-то конечно можно.
Почему абстрактный ? Я тебе про вполне конкретный привел, во вполне конкретном regedit. Тривью это 1) некое изображение на экране и 2) некие реакции на события от мыши и клавиатуры, включая действия за сценой и изменение изображения. И вот был тривью для Windows 95, в регедите. Он вполне конкретно рисовался на экране, ветви вполне открывались и т.д. И я не понимаю, почему это изображение + обработчики нажатий для нативного клиента можно было в 8 Мб уложить, а для вашего веб-клиента, в котором рисуется почти такое же изображение и имеются практически те же обработчики нажатий, нужно то ли 50, то ли 100. Можешь объяснить ? ОС Windows. Аргументы насчет сервера и передачи информации с него не принимаются — я только клиент обсуждаю.
G>Фиг с ним, что ты сравниваешь нативное виндовое приложение с веб-сайтом, да кто нынче на такие мелочи внимание обращает, да? Вообще все офигели, вот у меня когда-то zx spectrum был, 50 игрух на аудиокассету помещалось, они все офигели, работать не умеют, такие нынче требования к аппаратным ресурсам выдвигают. Памяти им гигабайты нужны. Обленились! 64Кб оперативки и аудиокассета! G>Так?
Здравствуйте, olegkr, Вы писали:
I>>Во первых, он легко понятен любому, кто имел дело с Си-подобным языком. O>Загляни в исходный джаваскрипт код какого-нибудь грида и сравни с тем же гридом на сильверлайте. То, что язык примитивный не означает, что на нем легко и приятно писать и потом читать написанное.
Для сильверлайта надо смотреть еще и в XAML. И недавно в Микрософте сказали, что Silverlight это круто, и добавили — учите Html5 и Javascript
I>>Странно бегут как то. O>В интранете бегут с огромной скоростью. В интернете мешает только то, что рантайм стоит далеко не у всех, да и клиентский UI в массе своей примитивен и убог, так что скриптов кое-как хватает.
Интранет как правило сильно гомогенная среда в контексте ОС, бровзеров и прочего софта.
Здравствуйте, olegkr, Вы писали:
I>>Покажи, что может выступить заменой и что бы а) работало на всех аппаратных платформах б) на всех основных ОС в) во всех основных барузерах O>Сильверлайт уже работает, если не на 100%, то 90% покрывает влегкую.
90% это можно теоретически инсталировать. А реально 40% не имеет инсталированого сильверлайта. Еще есть такие у которых Сильверлайта есть, но не той версии
>Причем совместимость между разными платформами и браузерами у него просто отличная в отличии от html+css+jscript.
А ну, покажи ка сильверлайт на андроиде, ифоне, блекбери, линуксе ?
PD>Почему абстрактный ? Я тебе про вполне конкретный привел, во вполне конкретном regedit. Тривью это 1) некое изображение на экране и 2) некие реакции на события от мыши и клавиатуры, включая действия за сценой и изменение изображения. И вот был тривью для Windows 95, в регедите. Он вполне конкретно рисовался на экране, ветви вполне открывались и т.д. И я не понимаю, почему это изображение + обработчики нажатий для нативного клиента можно было в 8 Мб уложить, а для вашего веб-клиента, в котором рисуется почти такое же изображение и имеются практически те же обработчики нажатий, нужно то ли 50, то ли 100. Можешь объяснить ? ОС Windows. Аргументы насчет сервера и передачи информации с него не принимаются — я только клиент обсуждаю.
Я начинаю терять веру в человечество.
Ты правда не понимаешь чем отличается нативный тривью в виндах и его броузерный родственник? Ты вообще понимаешь, что в них общего только название?
Здравствуйте, Ikemefula, Вы писали:
I>И недавно в Микрософте сказали, что Silverlight это круто, и добавили — учите Html5 и Javascript
Это да. Это они сильно выступили. Типа прорекламировали IE9 с его полной поддержкой HTML5. Потом долго отмывались в блогах.
Да и похоже менеджерье MS-овской воспринимает сильверлайт, как конкурента флешу для отображения порнобаннеров и прочей анимации, а не как самостоятельный серьезный продукт. Иначе давно бы уже пропихнули рантайм через windows update или новую версию IE. Посему, несмотря на техническую зрелость, перспективы сильверлайта неясны. Для интранета самое оно, для интернета будем продолжать городить давно устаревший html/jscript.
I>Интранет как правило сильно гомогенная среда в контексте ОС, бровзеров и прочего софта.
У нас даже с разными версиями IE была куча проблем.
Здравствуйте, Ikemefula, Вы писали:
I>90% это можно теоретически инсталировать. А реально 40% не имеет инсталированого сильверлайта. Еще есть такие у которых Сильверлайта есть, но не той версии
40% — это я бы даже сказал весьма оптимистично.
I>А ну, покажи ка сильверлайт на андроиде, ифоне, блекбери, линуксе ?
На линуксе есть мунлайт и по слухам оно работает. Для андроида, ифона и блекбери один черт приходится писать в своей среде разработки, если дело выходит за пределы отображения простенькой странички.
Здравствуйте, olegkr, Вы писали:
I>>И недавно в Микрософте сказали, что Silverlight это круто, и добавили — учите Html5 и Javascript O>Это да. Это они сильно выступили. Типа прорекламировали IE9 с его полной поддержкой HTML5. Потом долго отмывались в блогах.
Они вынуждены гнаться за HTML5 потому что Гугл проталкивает его
O>Да и похоже менеджерье MS-овской воспринимает сильверлайт, как конкурента флешу для отображения порнобаннеров и прочей анимации, а не как самостоятельный серьезный продукт.
Ну так про то и речь. А раньше планов было громадьё — не передать словами.
>Посему, несмотря на техническую зрелость, перспективы сильверлайта неясны. Для интранета самое оно, для интернета будем продолжать городить давно устаревший html/jscript.
Не совсем ясно, где ты углядел техническую зрелость.
I>>Интранет как правило сильно гомогенная среда в контексте ОС, бровзеров и прочего софта. O>У нас даже с разными версиями IE была куча проблем.
При желании можно написать код который будет плохо работать под любым браузером. Даже на сильверлайте такое возможно
Здравствуйте, olegkr, Вы писали:
I>>90% это можно теоретически инсталировать. А реально 40% не имеет инсталированого сильверлайта. Еще есть такие у которых Сильверлайта есть, но не той версии O>40% — это я бы даже сказал весьма оптимистично.
Это компания которая ведет бизнес в инете и находится в топ100, собрала инфу по своим кастомерам.
I>>А ну, покажи ка сильверлайт на андроиде, ифоне, блекбери, линуксе ? O>На линуксе есть мунлайт и по слухам оно работает. Для андроида, ифона и блекбери один черт приходится писать в своей среде разработки, если дело выходит за пределы отображения простенькой странички.
А почему мой iPad с такой же iOs как и в IPhone все сайты показывает на раз ?
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Почему абстрактный ? Я тебе про вполне конкретный привел, во вполне конкретном regedit. Тривью это 1) некое изображение на экране и 2) некие реакции на события от мыши и клавиатуры, включая действия за сценой и изменение изображения. И вот был тривью для Windows 95, в регедите. Он вполне конкретно рисовался на экране, ветви вполне открывались и т.д. И я не понимаю, почему это изображение + обработчики нажатий для нативного клиента можно было в 8 Мб уложить, а для вашего веб-клиента, в котором рисуется почти такое же изображение и имеются практически те же обработчики нажатий, нужно то ли 50, то ли 100. Можешь объяснить ? ОС Windows. Аргументы насчет сервера и передачи информации с него не принимаются — я только клиент обсуждаю.
G>Я начинаю терять веру в человечество. G>Ты правда не понимаешь чем отличается нативный тривью в виндах и его броузерный родственник? Ты вообще понимаешь, что в них общего только название?
Хорошо. Аргументировать не буду. Давай так.
Предположим, тебе дали интерфейс, с помощью которого можно получить доступ к реестру из web-приложения. Как именно — неважно, ActiveX, к примеру.
Можешь написать в web-виде редактор реестра, так чтобы все это уложилось в 2-3 Мб ?
Задача та же самая, решение ее нативное существует, этим требованиям удовлетворяет. Вы приходите и говорите — а можно сделать web-приложение. Отлично, говорю, делайте, но больше памяти не дам — вот вам доказательство, что для этой задачи (редактирование реестра) 2-3 Мб вполне достаточно (для W95). Рисовать можешь как хочешь, мне это все равно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Предположим, тебе дали интерфейс, с помощью которого можно получить доступ к реестру из web-приложения. Как именно — неважно, ActiveX, к примеру.
Это плохой пример, чисто для виндовс+IE, т.е. это менеее 50% всего рынка
PD>Можешь написать в web-виде редактор реестра, так чтобы все это уложилось в 2-3 Мб ?
ты в курсе, что html, js, css запускаются не только на виндовсе и не только в IE?
PD>>Можешь написать в web-виде редактор реестра, так чтобы все это уложилось в 2-3 Мб ?
I>ты в курсе, что html, js, css запускаются не только на виндовсе и не только в IE?
В другой ОС есть свой тривью, и если даже нет реестра и его редактора, так есть какая-нибудь другая программа, выводящая тривью , которой, скорее всего, понадобится столько же — иначе пришлось бы признать, что в Windows это написано на порядок лучше. а это вряд ли. Тривью — визуальное представление дерева, а деревья у нас везде растут
Здравствуйте, Ikemefula, Вы писали:
I>А почему мой iPad с такой же iOs как и в IPhone все сайты показывает на раз ?
Видимо потому, что это практически полноценный комп. Ты не представляешь, как я мучаюсь со своим блекберри.
Здравствуйте, hattab, Вы писали:
H>Сайт сделан на Silverlight 4, и это и есть главный фэйл, судя по разъяренным комментариям в блоге разработчика, например:
Скажу честно. Совсем не понимаю зачем нужно делать такие сайты на сильверлайте/флеше/с кучей джаваскрипта. Там же по сути текста, статичных картинок и гиперлинков заглаза. За исключением разве что интерактивной карты. В разы проще и удобнее для посетителя.
Здравствуйте, olegkr, Вы писали:
o> H>Сайт сделан на Silverlight 4, и это и есть главный фэйл, судя по разъяренным комментариям в блоге разработчика, например:
o> Скажу честно. Совсем не понимаю зачем нужно делать такие сайты на сильверлайте/флеше/с кучей джаваскрипта. Там же по сути текста, статичных картинок и гиперлинков заглаза. За исключением разве что интерактивной карты. В разы проще и удобнее для посетителя.
Вопрос не в том, нужно или не нужно. Вопрос в том, что кроссплатформенная, по сути, технология таковой в реальности не является, в отличии от того же флэша (что, в общем то, и не удивительно).
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Netscape 3.0 Gold. Ему, правда, не 10 лет, а немного побольше. С NN 4.x началось ухудшение.
VD>Паш, но ведь все же очевидно.
Влад, попробуй все же понять, о чем я. Попробуй, прежде чем критиковать. Дело ведь совсем не в Хроме и не в js.
Здравствуйте, olegkr, Вы писали:
I>>Они уже давно этим занимаются. O>Только безуспешно. В основном штампуют то, что разработано в штатах.
а вы отличаете "штатовских" и "нативных" индусов и китайцев?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А сравнивать студию без решарпера (которого, к слову, в С++ никогда не было и нет) с BC++ 5.0 все же можно или нет ? Если нет — что в ней такое новое появилось , чего в ВС 5.0 не было ?
Нельзя конечно. Или тогда уж можно сразу с Блокнотом сравинивать или Фаром.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В IDE VC++ до 2010 я не вижу ничего такого, чего не было в BC++ 5.0.
Ты бредишь? Как минимум VS 2010 — это расширяемая IDE для (мягко говоря) более чем одного языка.
Такое сравнение скорее говорит о степени использования возможностей IDE. Когда пользователю достаточно подсветки синтаксиса и запуска отладчика из редактора, то что ему можно объяснить о современных IDE?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
P>Сдается мне, пришло время перейти от генерации случайных объемов памяти к более или менее точным расчетам. Ясно, что это вызовет некоторые затруднения, но сделать это необходимо.
Ну что же, давай.
P>Предположим, у нас есть стандартная конфигурация середины 90-х: комп 80386 DX-40, 4 М оперативки. Комп вполне может быть 386 SX/16 c 2 M, для MS-DOS это не имеет никакого значения.
Я вообще-то говорил о временах 286, но ладно, принимаю.
P>Итак, 640 К основной и еще 384+ К Extended памяти. На компе такой, как у нас, конфигурации вполне реально было получить после загрузки системы приблизительно 620 К. Отлично.
P>Резидентные программы можно не рассматривать: во-первых, в них сражались за каждый байт, а во-вторых, в предложенной конфигурации они все ушли в HMA или UMB, на усмотрение оптимизатора памяти QEMM.
P>Рассмотрим, как использовали память распространенные продукты. Командир Нортон, например, брал минимум 300 К. Командир Волков занимал меньше, но все время выделял/освобождал память средствами ОС. Тот и другой состояли из резидентной и транзитной части и умели, запуская приложение, отдать ему память по максимуму.
Согласен.
P>Утилиты Нортона. Какая из них укладывалась в 100 К? SysInfo, да и то в версии 4.5. Может быть, еще UnErase той же версии. Больше – не знаю. Не будешь же ты, в самом деле, утверждать, что SpeedDisk или Norton disk Destroyer Doctor укладывались в 100 К? А DiskEdit? Он был весьма и весьма увесистый.
Отлично.
P>PCTools – примерно то же самое.
Тоже хорошо. Впрочем, это не утилита ИМХО, а целый пакет их. Если я не ошибаюсь.
P>Настольные БД. Из всех известных мне я попытался бы засунуть в 100 К только dBase III. Что касается остальных, посмотри в доку тех лет: годится любая дополнительная память в любых количествах. Верно, по крайней мере, для FoxPro и Paradox 3.5. Боюсь наврать, Paradox 4.x уже в 1 М просто не влезал.
Тоже принято.
P>Текстовые редакторы. Lexicon – помещал тексты в память целиком. Всегда 100 К? MultiEdit – работал с огромными файлами, но хватало ли ему на все про все 100 К? Word 5.0? Скажу, что на стандартной XT я вообще не сумел его запустить. На 386 пойдет без проблем, но неужели кто-то будет утверждать, что он не влезает в 100 к только потому, что "сделано в Microsoft”? MultiEdit? Сомневаюсь. Он же написан на своем встроенном языке. Значит, исполняющая система запускала собственно редактор, а тот уже начинал всю основную работу. А если кто на нем свою собственную систему обработки текстов напишет – все, нужно снова перетряхивать всю память, выискивая в ней свободные байты.
И это принято.
P>Я могу продолжать еще долго. Я не упоминал всякие там SuperCalc или Quatro Pro.
И их примем.
P>И я не говорю о софте типа AutoCAD, он специального назначения. Я старался упоминать то, что было установлено везде.
Тоже примем.
P>В общем, попробуй дать хотя бы парочку примеров распространенных продуктов, которые нормально работают в 100 К. Потому что загрузить программу в 100 К – не вопрос. Мой любимый редактор QEdit занимал 48 К, но все тексты держал в памяти. И размер этих текстов был побольше 100 К.
Опустим его.
P>А сможешь ли ты сказать, какая из упомянутых мною программ швыряется памятью, какая хватает ее, а какая, если таковая найдется, использует память правильно?
А вот теперь ответ.
Я со всеми твоими примерами согласен. И все их отличает одна особенность. Но начну издалека.
Пусть нам надо отредактировать картинку 10000*10000*32bpp. Тут надо 400 Мб. Можно сразу. Можно по частям. Как угодно. Но без 400 Мб не обойдется.
В MS-DOS придется по частям. В Windows сейчас можно и целиком.
И никаких возражений у меня это не вызовет. Потому что здесь самым явным образом огромный массив данных.
А вот если картинка 1000*1000*32bpp — извольте обойтись 4 Мб. Можете тоже сразу или частями.
К чему я это ? А вот к чему. Объем данных можно легко увеличить. И это, конечно, требует памяти. Тут никуда не денешься.
DiskEdit. Про размеры FAT говорить не буду. А кластеры ?
NDD — то же самое.
Текстовый редактор. Если текста 10 Кб — незачем. А если 300 — берите, и 500 берите. Глупо не брать в однопрограммной среде. (В Win16 еще поговорим!)
SuperCalc — то же самое.
И т.д.
Вот и все.
А вот за каким богом понадобилось ее резко увеличивать при том, что данных-то больше не стало? Я тут два сайта в качестве примера приводил — rbc.ru и rsdn.ru, читал, наверное. Так вот. Если бы в версиях этих сайтов изображали бы в 2003 на одной странице 100 Кб текста и картинок, а сейчас на одной странице — 100 Мб, я бы первым сказал — надо больше памяти. Но ничего такого нет. Объем, может, и увеличился — в 2-3 раза. Сложность тоже увеличилась (мне тут про раскрытие тривью говорили... м-да... если для того, чтобы решить такую задачу, надо сотню Мб — слов нет), ну пусть тоже в 2-3 раза. Так и быть, памяти тоже в 2-3 раза можно больше дать (хотя и это еще вопрос, что в 2003 не было страниц большого размера ?).
Впрочем. я об этом уже говорил, когда Мамут (не к ночи будь помянут) мне про Фотошоп сказал.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Аналогично в свое время VC.NET перетащили на WinForms.
Кончай нести откровенную пургу! Не было в природе никакого VC.NET. Ты его сам только что придумал. И на WinForms никто ничего не переводил. VS NET (2000) использовало WinForms только для пакетов для дотнет-языков. Там на WinForms было написано окно свойств и дизайнер того самого WinForms. Пакет C++ как тогда, так и сейчас был написан на С++ и безбожно глючил (и глючит по сей день, могу привести минимум три способа завалить им студию).
PD>Ну там хоть интерфейс существенно изменили, в общем, он, конечно, стал удобнее, чем в VC6, но его можно было изменить и без того, чтобы все это на WinForms перетаскивать.
Не позорься уж так откровенно. Это же форменный берд.
Если хочешь я тебе немного расскажу об архитектуре VS и отличиях VS 6 (в которой был только С++) от VS следующих поколений.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, olegkr, Вы писали:
I>>А почему мой iPad с такой же iOs как и в IPhone все сайты показывает на раз ? O>Видимо потому, что это практически полноценный комп. Ты не представляешь, как я мучаюсь со своим блекберри.
Представляю, такое г. не передать словами. Правда те что с тачскрином куда то еще годятся.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>ты в курсе, что html, js, css запускаются не только на виндовсе и не только в IE?
PD>В другой ОС есть свой тривью, и если даже нет реестра и его редактора, так есть какая-нибудь другая программа, выводящая тривью , которой, скорее всего, понадобится столько же — иначе пришлось бы признать, что в Windows это написано на порядок лучше. а это вряд ли. Тривью — визуальное представление дерева, а деревья у нас везде растут
Вот и посчитай, сколько кода-памяти надо будет нагнать-затратить, что бы написать дерево на С++ что бы работало под всеми платформами, где можно сделать дерево на html-js-css.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Стоп! Или ты меня неправильно понял, или передергиваешь. Я ведь ясно сказал чуть раньше. Выделяю
да, похоже тут непонимание
PD>http://rsdn.ru/forum/flame.comp/4059602.1.aspx
PD>>Правда, оговорюсь — по VC 2008 включительно. В VC 2010 есть компиляция по ходу набора текста (как в C#, eclipse и т.д.), на это память нужна. Но и здесь я бы мог сформулировать так : если ее отключить — укладывайтесь, ну а если включить — берите еще памяти. PD>Почему же ты из этой фразы кусок убрал ? PD>Так что в полтора — это либо до VC2008 включительно, либо VC2010, но с отключением этой фичи.
я так понял, что на "компиляцию по ходу набора текста" ты допускаешь добрать памяти(в 1.5 раза?). а так как она появилась в 2010, я и убрал то что про 2008. я бы конечно поигрался с этой фичей и посмотрел бы, сколько она там откушивает (и вообще приблизительно как работает), да у меня на это памяти нет (дисковой)
PD>>>Контрвопрос — насколько меньше памяти потреблял компилятор от VC 4.2, 5.0 ? Опять же — от силы раза в 1.5, ну пусть 2. А предположить, что от 4.2 до 6.0 он не развивался, A>>вообще-то такие предположения неплохо бы обосновать PD>>>а тут уж прямо в гору пошел — как-то сомнительно. A>>тебе вроде как целую гору фич показали новых. так что ещё как в гору. PD>В VC ?
в VC. в байтофобской теме тебе понадобились "фичи, которых нет в BC и есть в VC". учитывая упомянутый тобой 96ой год, и тот факт, что vc6 — это 98ой год, можно(в достаточном количестве случаев) трактовать те фичи как разницу между vc6 и vc2002-2008 (раз уж ты про десятку отдельно говоришь)
таки повторю что было и добавлю ещё чего-нибудь:
— улучшенная поддержка языковых конструкций (типа шаблонов)
— поддержка managed extensions for c++
— поддержка х64
— оптимизация под процы новее 98ого года
— WPO
— PGO
— SIMD
— openmp
— всякая мелочёвка
— то что я мог забыть, вроде хитрых оптимизиций
последние два пункта можно наверное убрать, так как я не имею возможности посмотреть на vc изнутри (но в целом представляю, сколько всего стоит за остальным)
неужели ты считаешь, что всё вышеперечисленного максимум вполовину более ресурсоёмко, чем "компиляция в базовый набор x86"?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Netscape 3.0 Gold. Ему, правда, не 10 лет, а немного побольше. С NN 4.x началось ухудшение.
VD>>Паш, но ведь все же очевидно.
PD>Влад, попробуй все же понять, о чем я. Попробуй, прежде чем критиковать. Дело ведь совсем не в Хроме и не в js.
"Если бы я видел, что нынешнее ПО требует в 10 раз больше памяти и быстродействия , чем ПО 10-20 летней давности. я бы и слова не сказал. Но когда я вижу, что потребности в памяти увеличились в 100 раз, скорость процессора — в 50-100, в все вопят — памяти мало, программы тормозят (и это правда), то объяснение только одно — разучились писать как следует."
Раньше тоже кстати кричали, только компьютер был не у каждого, как сейчас и просто криков было мало.
Здравствуйте, Antikrot, Вы писали:
A>в VC. в байтофобской теме тебе понадобились "фичи, которых нет в BC и есть в VC". учитывая упомянутый тобой 96ой год, и тот факт, что vc6 — это 98ой год, можно(в достаточном количестве случаев) трактовать те фичи как разницу между vc6 и vc2002-2008 (раз уж ты про десятку отдельно говоришь) A>таки повторю что было и добавлю ещё чего-нибудь: A>- улучшенная поддержка языковых конструкций (типа шаблонов)
Шаблоны в BC 5.0 были, изменений с тех пор немного.
A>- поддержка managed extensions for c++
Речь не шла о дотнете
A>- поддержка х64 A>- оптимизация под процы новее 98ого года A>- WPO A>- PGO A>- SIMD A>- openmp A>- всякая мелочёвка
Да, все это есть, не спорю. Мог бы сказать, что это скорее к компилятору относится, а не к IDE, но ладно, не буду. А вот что скажу. Впрочем, я это уже говорил
BC 5.0 vs BC 3.1
Новые фичи
Работает IDE в графическом режиме. Это само по себе не шутка. BC 3.1 отладку проводил только в текстовом режиме (TurboDebugger)
Встроенная отладка. В BC 3.1 для Windows-приложений ее не было.
Масса всяких фич в IDE, одно перечисление займет много времени.
А главное — полная смена target-модели. Вместо сегментированной 16:16 плоская 0:32. Это тебе не переход x86->x64
, где модель осталась без изменений, только размер адреса удвоился. Это гораздо серьезнее.
I>>>>В старые добрые времена, когда программисты были умными, а программы — быстрыми и компактными, был написан интерпретатор JS.
K>>>Для полноты картины надо добавить, что в "старые добрые времена" программиста, который захотел бы написать что-то сложное на JavaScript, немедленно отправили бы в дурку. K>>>Сейчас это безумие вошло в моду, и здравый смысл только еле-еле пищит где то в углу "а на _уя вообще писать на JS, когда есть куча языков, которые намного быстрее, удобнее и надежнее?"
M>>Покажи мне эти языки для клиентского скриптинга в браущере с покрытием хотя бы 50% рынка браузеров
ЕА>Си Шарп не устроит?
ЕА>По риастату сильверлайт стоит где-то на 65% подключенных к интернету устройств, может у них немного искаженная статистика на 50% точно есть
ЕА>Можно сделать все, что можно на ява скрипте
Ну разве что. И то, такого они достигли совсем-совсем недавно
PD>После этого я говорю — а знаешь ли, что в 2010 году найдутся люди, которые скажут. что при такой конфигурации невозможно будет решить задачу, которая в конечном счете сводится к созданию картинки размером в несколько экранов и изменении этой картинки в лучшем случае десяток раз в секунду ? И это при том, что большую часть работы по формированию этой картинки возьмет на себя ОС (напомню, что в DOS тебе пришлось бы TTF растеризовать самому и jpg рисовать тоже, через видеоадаптер).
PD>И ты бы не сказал, что это уж окончательный и бесповоротный бред ?
Слушайте, расскажите ему, как формируется эта самая картинка. Как самый лучший вариант — кастаните сюда c-smile'а, как знающего это не по наслышке.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И ты не мог этого не видеть. Зачем тогда передергиваешь ?
Ну КСВ все же. Счас посмотрим.
PD>>>А вот теперь ответ.
P>>Скипнут как не имеющий отношения к делу.
PD>Ах вот оно что... Не имеющий отношения к делу. Вот это не имеет отношения к делу ? (выделил сейчас)
А сможешь ли ты сказать, какая из упомянутых мною программ швыряется памятью, какая хватает ее, а какая, если таковая найдется, использует память правильно?
Какая именно — я не нашел в твоем ответе. Тем более не увидел, как это связано с моим вопросом про память. А надеялся.
PD>/////////////////
[skip] PD>/////////////////
PD>И все это не имеет отношения к делу ? Текст, в котором я объясняю суть своей точки зрения.
И какое отношение имеет суть твоей точки зрения к заданному мной вопросу. Да, именно так: суть твоей точки зрения. Не указывая, на что.
P>>Ты ведь сам предложил 286. а теперь внезапно картинки, сайты, 400 Мб, Винда... И ни слова по теме, тобой, к тому же, поднятой.
PD>И то, что я выделил в слешах — ни слова ?
Можешь думать, что я читать не умею. Может, и проскочило слово-другое, но сами по себе, без увязки с сутью вопроса, они не имеют значения.
PD>Извини, но ты начинаешь мне Мамута напоминать.
Особенность моей физиономии: всем кажется, что где-то меня видели. (c)
PD>Он упорно заявлял, что, дескать, я ничего не хочу о выполнении говорить. Я его тыкал носом — а он мне в ответ : почему ты не говоришь ?
PD>Если и ты собираешься таким образом дискутировать — давай лучше сейчас и закончим
Пока что было так: ты выставляешь условия, я строго их придерживаюсь. Но могу же я задавать уточняющие вопросы. А то, что ответы на них твою точку зрения не подтверждают — это не мой головняк.
Помнишь, я говорил об одном разработчике, чей опыт вдруг стал для него балластом? Ему однажды здорово сказали: "Вы остановились на уровне ДОС ЕС 60-х годов и НЕ ХОТИТЕ двигаться дальше". Искренне желаю тебе никогда такого не слышать.
Здравствуйте, Privalov, Вы писали:
P>Какая именно — я не нашел в твоем ответе. Тем более не увидел, как это связано с моим вопросом про память. А надеялся.
Какая бросается, а какая нет ? Точно не было ответа. Для этого надо их исследовать, а как я могу сейчас это сделать ?
P>И какое отношение имеет суть твоей точки зрения к заданному мной вопросу. Да, именно так: суть твоей точки зрения. Не указывая, на что.
P>>>Ты ведь сам предложил 286. а теперь внезапно картинки, сайты, 400 Мб, Винда... И ни слова по теме, тобой, к тому же, поднятой.
PD>>И то, что я выделил в слешах — ни слова ?
P>Можешь думать, что я читать не умею. Может, и проскочило слово-другое, но сами по себе, без увязки с сутью вопроса, они не имеют значения.
Ну ладно, не имеет, так не имеет. Что я могу еще сказать ? По-моему, имеет, по-твоему — нет. Стрижено — брито
PD>>Если и ты собираешься таким образом дискутировать — давай лучше сейчас и закончим
P>Пока что было так: ты выставляешь условия, я строго их придерживаюсь. Но могу же я задавать уточняющие вопросы. А то, что ответы на них твою точку зрения не подтверждают — это не мой головняк.
Ладно. Давай заканчивать.
P>Помнишь, я говорил об одном разработчике, чей опыт вдруг стал для него балластом? Ему однажды здорово сказали: "Вы остановились на уровне ДОС ЕС 60-х годов и НЕ ХОТИТЕ двигаться дальше". Искренне желаю тебе никогда такого не слышать.
Не волнуйся. web-сайты я разрабатывать не буду, js мне без надобности, а в том, чем я занимаюсь, все эти методы годятся, как лобзики для валки леса.
Здравствуйте, Pavel Dvorkin, Вы писали:
A>>в VC. в байтофобской теме тебе понадобились "фичи, которых нет в BC и есть в VC". учитывая упомянутый тобой 96ой год, и тот факт, что vc6 — это 98ой год, можно(в достаточном количестве случаев) трактовать те фичи как разницу между vc6 и vc2002-2008 (раз уж ты про десятку отдельно говоришь) A>>таки повторю что было и добавлю ещё чего-нибудь: A>>- улучшенная поддержка языковых конструкций (типа шаблонов) PD>Шаблоны в BC 5.0 были, изменений с тех пор немного.
забей на BC 5.0. тут мы про vc6 <-> vc>6
а про поддержку шаблонов в vc6 говорить не надо, поищи по плюсовому форуму
A>>- поддержка managed extensions for c++ PD>Речь не шла о дотнете
а куда ж ты его денешь, если это в тот же cl.exe засунуто?
A>>- поддержка х64 A>>- оптимизация под процы новее 98ого года A>>- WPO A>>- PGO A>>- SIMD A>>- openmp A>>- всякая мелочёвка PD>Да, все это есть, не спорю. Мог бы сказать, что это скорее к компилятору относится, а не к IDE, но ладно, не буду.
я тебе больше скажу, тут всё что я перечислил, относится к компилятору я до IDE ещё не дошёл
PD>А главное — полная смена target-модели. Вместо сегментированной 16:16 плоская 0:32. Это тебе не переход x86->x64 PD>, где модель осталась без изменений, только размер адреса удвоился. Это гораздо серьезнее.
ты кстати почему-то оставил без ответа моё сообщение о том, что в x64 тоже совсем не одна модель
да и поддержка сегментированной модели — ничто по сравнению с любым вышеперечисленным пунктом
Здравствуйте, VladD2, Вы писали:
VD>И если пользователь готов платить за фичи большим потреблением ресурсов, то зачем ломать копья и заниматься?
Проблема в том, что потребление ресурсов растет совершенно непропорционально росту фич. Зачастую новых фич вообще ноль, только интерфейс немного перерисовали. А рост отжирания ресурсов — огого.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Какая бросается, а какая нет ? Точно не было ответа. Для этого надо их исследовать, а как я могу сейчас это сделать ?
Вот именно, надо исследовать. А ты не хочешь исследовать. А вопрос-то ты поднял. Возникает встречный вопрос — зачем?
P>>Пока что было так: ты выставляешь условия, я строго их придерживаюсь. Но могу же я задавать уточняющие вопросы. А то, что ответы на них твою точку зрения не подтверждают — это не мой головняк.
PD>Ладно. Давай заканчивать.
Да, пожалуй можно. Правда, тут пятница на носу, можно бы и потрындеть.
P>>Помнишь, я говорил об одном разработчике, чей опыт вдруг стал для него балластом? Ему однажды здорово сказали: "Вы остановились на уровне ДОС ЕС 60-х годов и НЕ ХОТИТЕ двигаться дальше". Искренне желаю тебе никогда такого не слышать.
PD>Не волнуйся.
Кто, я? Я примерно знаю, в чем я ретроград, а в чем — старпер. Надеюсь за счет этого знания проскочить.
PD>web-сайты я разрабатывать не буду, js мне без надобности, а в том, чем я занимаюсь, все эти методы годятся, как лобзики для валки леса.
Это не очень понял, в части про "эти методы".
PD>
PD>
Здравствуйте, VladD2, Вы писали:
VD>На повышение надежности нужно или затратить существенно больше времени или выбрать другие средства разработки. Скажем тот же дотнет. И если пользователь готов платить за фичи большим потреблением ресурсов, то зачем ломать копья и заниматься? И наоборот, если рынок требует максимально оптимизированного решения и при этом надежного, то скорее всего придется заплатить функциональностью.
Да? Очень интересно, какие такие фичи получили юзеры атишных карточек с конфигуратором написанным под дотнет? Гуй выглядит как говно, тормоза просто дичайшие, потребление ресурсов безумное. И еще очень интересно, какой такой функциональностью пожертвовала NVidia, которая пишет свой конфигуратор (а там, в отличии от атишного, не только настройками дров рулить можно, но и много чего другого) на сях? Вот смотри, продукты одинаковой направленности, но подход совершенно разный. Хоть кто нибудь может сказать, что дотнет чего то дал атишникам окромя тормозов?
PD>А вот за каким богом понадобилось ее резко увеличивать при том, что данных-то больше не стало? Я тут два сайта в качестве примера приводил — rbc.ru и rsdn.ru, читал, наверное. Так вот. Если бы в версиях этих сайтов изображали бы в 2003 на одной странице 100 Кб текста и картинок, а сейчас на одной странице — 100 Мб, я бы первым сказал — надо больше памяти. Но ничего такого нет. Объем, может, и увеличился — в 2-3 раза. Сложность тоже увеличилась (мне тут про раскрытие тривью говорили... м-да... если для того, чтобы решить такую задачу, надо сотню Мб — слов нет), ну пусть тоже в 2-3 раза. Так и быть, памяти тоже в 2-3 раза можно больше дать (хотя и это еще вопрос, что в 2003 не было страниц большого размера ?).
Потому что задача — не "раскрыть тривью", а "реализовать дерево, структура и способ отображения которого передаются с сервера, и отображаются корректно и единообразно во всех системах без установки дополнительного ПО". Вот эта задача с помощью стандартного тривью не решается. Потому сравнивать просто некорректно.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>В IDE VC++ до 2010 я не вижу ничего такого, чего не было в BC++ 5.0.
VD>> Ты бредишь? Как минимум VS 2010 — это расширяемая IDE для (мягко говоря) более чем одного языка.
PD>Как минимум — VS6 была расширяемой средой с как минимум еще одним вcтраиваемым языком — Compaq Fortran, даже если не брать во внимание о ICC++. Это раз. А во вторых — причем тут это ? Я говорил о возможностях IDE, и только, в плане С++, и только его.
Видишь ли, студия грузит сразу все свои модули, так как поддерживает одновременную работу со всеми поддерживаемыми языками. Иначе это было бы адским геморроем как для программеров студии, так и для ее пользователей, у которых проекты смешанные(а явление это частое).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали:
A>>>в VC. в байтофобской теме тебе понадобились "фичи, которых нет в BC и есть в VC". учитывая упомянутый тобой 96ой год, и тот факт, что vc6 — это 98ой год, можно(в достаточном количестве случаев) трактовать те фичи как разницу между vc6 и vc2002-2008 (раз уж ты про десятку отдельно говоришь) A>>>таки повторю что было и добавлю ещё чего-нибудь: A>>>- улучшенная поддержка языковых конструкций (типа шаблонов) PD>>Шаблоны в BC 5.0 были, изменений с тех пор немного. A>забей на BC 5.0. тут мы про vc6 <-> vc>6
Я так вроде начинал со сравнения BC 5 против VC 6.
A>а про поддержку шаблонов в vc6 говорить не надо, поищи по плюсовому форуму
A>>>- поддержка managed extensions for c++ PD>>Речь не шла о дотнете A>а куда ж ты его денешь, если это в тот же cl.exe засунуто?
В cl.exe еще и генерация кода под IA-64 засунута, и под другие платформы. Это просто разные куски компилятора(кодогенератора).
A>>>- поддержка х64 A>>>- оптимизация под процы новее 98ого года A>>>- WPO A>>>- PGO A>>>- SIMD A>>>- openmp A>>>- всякая мелочёвка PD>>Да, все это есть, не спорю. Мог бы сказать, что это скорее к компилятору относится, а не к IDE, но ладно, не буду. A>я тебе больше скажу, тут всё что я перечислил, относится к компилятору я до IDE ещё не дошёл
Я вообще-то и начинал именно с IDE, и сравнивал именно IDE. Почитай выше по треду.
PD>>А главное — полная смена target-модели. Вместо сегментированной 16:16 плоская 0:32. Это тебе не переход x86->x64 PD>>, где модель осталась без изменений, только размер адреса удвоился. Это гораздо серьезнее. A>ты кстати почему-то оставил без ответа моё сообщение о том, что в x64 тоже совсем не одна модель
В x64 не одна модель, но они отличаются друг от друга не столько генерацией кода , сколько требованиями по его размещению в памяти.
Они вводят ограничения на код или данные, и только. Это все намного проще сегментированной модели — ни размеров сегментов, ни прямой работы с LDT/GDT..., ни проблемы 64K
И вообще это все мы с тобой уже обсуждали
A>да и поддержка сегментированной модели — ничто по сравнению с любым вышеперечисленным пунктом
Можно, конечно, утверждать что угодно, тем более здесь, но аргументация, что ограничения в 64-моделях ничто по сравнению с генерацией кода на сегментированную модель — уж очень хлипкая.
Здравствуйте, Eugeny__, Вы писали:
E__>Видишь ли, студия грузит сразу все свои модули, так как поддерживает одновременную работу со всеми поддерживаемыми языками. Иначе это было бы адским геморроем как для программеров студии, так и для ее пользователей, у которых проекты смешанные(а явление это частое).
Вот это верно. Грузит. Насчет адского геморроя — не вижу причин. Загрузить нужный модуль в нужное время при правильной архитектуре — не такая уж проблема. Не при архитектуре VS20xx
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Ikemefula, Вы писали:
I>>Раньше тоже кстати кричали, только компьютер был не у каждого, как сейчас и просто криков было мало.
P>И не просто раньше. В свое время велись довольно шумные войны Assembler vs Fortran. Ассебблерщики обвиняли программистов на ЯВУ, в частности, Фортране, ровно в том же, в чем Павел обвиняет своих оппонентов. И где сейчас тот ассемблер?
Кстати, наблюдаются интересные штуки. Раньше оптимизация на асме давала выигрыш по сравнению с компилятором. Сегодня компиляторы оптимизируют так хорошо, что влезая ручками, очень вероятно только все испортить. Тот же процесс происходит с js/java/.net — JIT уже сейчас на некоторых тестах обгоняет С++, и возможностей для роста там еще тьма, рантаймовые компиляторы еще весьма молоды. Но у JIT потенциальных возможностей по оптимизации куда больше, чем у статического компилятора, так что в этом направлении ожидается стремительное развитие.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Klatu, Вы писали:
K>Проблема в том, что потребление ресурсов растет совершенно непропорционально росту фич. Зачастую новых фич вообще ноль, только интерфейс немного перерисовали. А рост отжирания ресурсов — огого.
Да. Только представь — я на ассемблере как то написал вьюер текстовых файлов.
Было около 400 байт одним COM файлом. Так после этого я оптимизировал пока 300 байт не получилось.
А сделай ты такое на современном православном С++ будет мегов наверное 10 только на либы.
Здравствуйте, Eugeny__, Вы писали:
E> Кстати, наблюдаются интересные штуки. Раньше оптимизация на асме давала выигрыш по сравнению с компилятором. Сегодня компиляторы оптимизируют так хорошо, что влезая ручками, очень вероятно только все испортить. Тот же процесс происходит с js/java/.net — JIT уже сейчас на некоторых тестах обгоняет С++, и возможностей для роста там еще тьма, рантаймовые компиляторы еще весьма молоды. Но у JIT потенциальных возможностей по оптимизации куда больше, чем у статического компилятора, так что в этом направлении ожидается стремительное развитие.
Ты в курсе о приборах работающих в кожухе, а не в принципе?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> Вот это верно. Грузит. Насчет адского геморроя — не вижу причин. Загрузить нужный модуль в нужное время при правильной архитектуре — не такая уж проблема. Не при архитектуре VS20xx
Грузить в нужное время не проблема. Проблема в том, что я выбрав в меню пункт Options хочу сразу увидеть диалог настроек, а не ждать, пока она его поднимет из сборок и проинициализирует. Отзывчивость гуя должна быть молниеносной, иначе он начинает раздражать.
Здравствуйте, Pavel Dvorkin, Вы писали:
A>>>>в VC. в байтофобской теме тебе понадобились "фичи, которых нет в BC и есть в VC". учитывая упомянутый тобой 96ой год, и тот факт, что vc6 — это 98ой год, можно(в достаточном количестве случаев) трактовать те фичи как разницу между vc6 и vc2002-2008 (раз уж ты про десятку отдельно говоришь) A>>>>таки повторю что было и добавлю ещё чего-нибудь: A>>>>- улучшенная поддержка языковых конструкций (типа шаблонов) PD>>>Шаблоны в BC 5.0 были, изменений с тех пор немного. A>>забей на BC 5.0. тут мы про vc6 <-> vc>6 PD>Я так вроде начинал со сравнения BC 5 против VC 6.
в другой теме — да. а вот тут, чуть выше по ветке:
Контрвопрос — насколько меньше памяти потреблял компилятор от VC 4.2, 5.0 ? Опять же — от силы раза в 1.5, ну пусть 2. А предположить, что от 4.2 до 6.0 он не развивался, а тут уж прямо в гору пошел — как-то сомнительно
никакого BC5 уже нет
A>>а про поддержку шаблонов в vc6 говорить не надо, поищи по плюсовому форуму A>>>>- поддержка managed extensions for c++ PD>>>Речь не шла о дотнете A>>а куда ж ты его денешь, если это в тот же cl.exe засунуто? PD>В cl.exe еще и генерация кода под IA-64 засунута, и под другие платформы. Это просто разные куски компилятора(кодогенератора).
надо полагать, ты его изнутри видел? насколько я понял, это уже другой cl.exe будет
A>>>>- поддержка х64 A>>>>- оптимизация под процы новее 98ого года A>>>>- WPO A>>>>- PGO A>>>>- SIMD A>>>>- openmp A>>>>- всякая мелочёвка PD>>>Да, все это есть, не спорю. Мог бы сказать, что это скорее к компилятору относится, а не к IDE, но ладно, не буду. A>>я тебе больше скажу, тут всё что я перечислил, относится к компилятору я до IDE ещё не дошёл PD>Я вообще-то и начинал именно с IDE, и сравнивал именно IDE. Почитай выше по треду.
выше по треду:
Контрвопрос — насколько меньше памяти потреблял компилятор от VC 4.2, 5.0 ?
PD>>>А главное — полная смена target-модели. Вместо сегментированной 16:16 плоская 0:32. Это тебе не переход x86->x64 PD>>>, где модель осталась без изменений, только размер адреса удвоился. Это гораздо серьезнее. A>>ты кстати почему-то оставил без ответа моё сообщение о том, что в x64 тоже совсем не одна модель PD>В x64 не одна модель, но они отличаются друг от друга не столько генерацией кода , сколько требованиями по его размещению в памяти. PD>Они вводят ограничения на код или данные, и только. Это все намного проще сегментированной модели — ни размеров сегментов, ни прямой работы с LDT/GDT..., ни проблемы 64K PD>И вообще это все мы с тобой уже обсуждали
было дело. но не помню, чтоб тогда ты на всё ответил
кстати, выражаясь твоими же словами, могу сказать что "это просто разные куски компилятора (кодогенератора)"
A>>да и поддержка сегментированной модели — ничто по сравнению с любым вышеперечисленным пунктом PD>Можно, конечно, утверждать что угодно, тем более здесь, но аргументация, что ограничения в 64-моделях ничто по сравнению с генерацией кода на сегментированную модель — уж очень хлипкая.
а если бы ещё цитирование не хлипким было, то там вот:
поддержка сегментированной модели — ничто по сравнению с любым вышеперечисленным пунктом
вышеперечисленные пункты повторю:
— улучшенная поддержка языковых конструкций (типа шаблонов)
— поддержка managed extensions for c++
— поддержка х64
— оптимизация под процы новее 98ого года
— WPO
— PGO
— SIMD
— openmp
поддержка х64 это намного больше, чем "ограничения в 64-моделях"
какая аргументация нужна?
Здравствуйте, Klatu, Вы писали:
K>Проблема в том, что потребление ресурсов растет совершенно непропорционально росту фич. Зачастую новых фич вообще ноль, только интерфейс немного перерисовали. А рост отжирания ресурсов — огого.
Ну, это конечно же полная чушь. Конечно же никто не будет вкладывать деньги или время в разработку нового продукта если он ничем не отличается от старого.
Бывает так, что потребности конкретного пользователя ограничены и ему просто не нужны новые плюшки новой версии. Но делать на основании этого выводы об отсутствии новых фич не верно.
Каждый программист понимает, что никто и никогда не будет намеренно писать софт так чтобы тот жрал лишние ресурсы. Просто когда пишутся новые версии, то в распоряжении появляется больше ресурсов (по сравнению с временами когда писались старые) и программисты могу забить на оптимизацию использования ресурсный или выбрать более качественные/удобные/быстрые/простые/навороченные алгоритмы но при этом более ресурсоемкие (по памяти например). Если при этом потребитель примет такой продукт, то производитель прав. Конечно езде бывают перегибы. И тут очень важно мнение потребителя. Если он не сочтет приемлемыми изменения, то он может просто отказаться от продукта.
Что касается конкретно VS 2010, то с ним была как раз очень интересная история. Первая бэта дико тормозила и жрала ресурсы по чем зря. Но релиз был основательно тюнингован и потребляет, ресурсов хотя и больше чем 2008-а студия, но все же не так уж и много (сравнимо с 2008-ой).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD> H>Да? Очень интересно, какие такие фичи получили юзеры атишных карточек с конфигуратором написанным под дотнет?
VD> Он их получил в реальное время и за малые деньги для производителя.
Итак, список фичь пожалуйста...
VD> H>Гуй выглядит как говно, тормоза просто дичайшие, потребление ресурсов безумное.
VD> Врешь (мягко говоря).
Он у меня перед глазами, если что. Уже 2011 маячит, а атишники не ослили даже поддержку XP themes реализовать Переход по настройкам сопровождается нормальными такими притормаживаниями, хотя там этих настроек кот наплакал, вот чему бы там тормозить... Потребление этого чуда-юда переваливает за сотню метров, а это, всего лишь, тупая конфигурялка. Так что не надо ля-ля о вранье
VD> H>И еще очень интересно, какой такой функциональностью пожертвовала NVidia, которая пишет свой конфигуратор
VD> Почему обязательно функциональность? Жертвы могут быть другими ресурсами — деньгами, временем (что те же деньги).
Ты сказал, что за оптимизированное решение придется платить функциональность. Вот я и хочу увидеть, где там функциональность нвидишных решений просела (хотя все ровно наоборот, нвидишные утили сильно функциональнее атишных).
VD> H>(а там, в отличии от атишного, не только настройками дров рулить можно, но и много чего другого) на сях? Вот смотри, продукты одинаковой направленности, но подход совершенно разный. Хоть кто нибудь может сказать, что дотнет чего то дал атишникам окромя тормозов?
VD> Назвать продуктами мелкие утилиты у меня язык не поворачивается. Продукт там — драйвер. Он несомненно написан на низкоуровневом языке просто из-за требований задачи.
Вообще говоря, продукт там не драйвер, а железяка. Но у нвидии софт сильно лучше не смотря на его нативность, а у ати неудобное тормозное и вырвиглазное нечто.
VD> Конечно на столь мелких утилитах как ГУЙ-конфигурации выигрышь будет не существенен. Но все же он по любому будет. ATI-шная утилита изобилует визуализацией и прочими излишествами (которые, в прочем, возможно очень привлекают неопытных пользователей). Реализация всех эти финтифлюшек занимает время. Не удивлюсь если узнаю, что на ATI-шную и NVidia-вскоую утилиту ушло примерно одинаковое время. Но за счет упрощения написания и отладки основной части ATI-шники успели (смогли) написать эти финтифлюшки.
Прикол в том, что нвидишные утили изобилуют анимациями и визуализацией ни чуть не меньше атишных. Но помимо того, у нвидии есть еще и десктоп-менеджер для управления окошками/рабочими столами.
G>Вот смотри. Есть у тебя база телефонных номеров. И занимает она например все доступные 4Мб. И отлично работает. G>Только поиск телефона занимает (к примеру) минуту.
Если поиск в БД на 4 Мб занимает минуту — программиста уволить с волчьим билетом, и все переписать.
G>И оказывается что либо ты делаешь различные индексы и выделяешь еще памяти, либо пользователи посылают тебя нафиг с твоей тормозной поделкой.
Я нечто подобное сам писал. Поиск в своем собственном файле (хочешь — назови его БД , хоть и не телефонов. Только поиск этот занимал не минуту, а 5-10 мсек.
G>Так яснее откуда расход памяти может взяться?
И память при этм не транжирил. Был там mmf на базу (она была примерно так 300 Мб), маппировались страницы, а больше никакой памяти и не выделялось. Зачем ?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>> Вот это верно. Грузит. Насчет адского геморроя — не вижу причин. Загрузить нужный модуль в нужное время при правильной архитектуре — не такая уж проблема. Не при архитектуре VS20xx
H>Грузить в нужное время не проблема. Проблема в том, что я выбрав в меню пункт Options хочу сразу увидеть диалог настроек, а не ждать, пока она его поднимет из сборок и проинициализирует. Отзывчивость гуя должна быть молниеносной, иначе он начинает раздражать.
Угу. Зайди в этой ГУИ на вкладку ToolBox и подожди, пока он все это не проинициализирует перед показом. У меня на Athlon64 4200 на работе секунд так 10.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Но когда вам просто надо нарисовать картинку из тега img — давайте все же обойдитесь width*height*4 байт. A>ты забыл 54 байта на заголовок
Посыпаю голову пеплом. Признаю свою полную неправоту по всем вопросам. Эти 54 байта радикально меняют всю ситуацию. Если бы их не было — еще можно было бы спортить, но раз уж они есть — спорить не приходится
Впрочем, я разве сказал, что там будет DIB ? Не помню. А раз так, можно и обойтись без BITMAPINFOHEADER, я же не обязан из jpg создавать именно DIB. Можно и DDB обойтись. А в ней только информация из BITMAP, а она меньше по размеру, чем 54 байта. Воодушевленный эти фактом и возможностью сэкономить 10-20 байт, пока что не буду посыпать голову пеплом и не признаю своей неправоты
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Впрочем, я разве сказал, что там будет DIB ? Не помню. А раз так, можно и обойтись без BITMAPINFOHEADER, я же не обязан из jpg создавать именно DIB. Можно и DDB обойтись. А в ней только информация из BITMAP, а она меньше по размеру, чем 54 байта.
да, так мы сэкономим 40 байт
но вероятность того, что в теге img будет что-то похожее на bmp, ничтожно мала. я посмотрю как ты будешь распаковывать gif/ani-gif/jpg/png используя лишь массив WxHx4... особенно для >32битных картинок
PD>>Впрочем, я разве сказал, что там будет DIB ? Не помню. А раз так, можно и обойтись без BITMAPINFOHEADER, я же не обязан из jpg создавать именно DIB. Можно и DDB обойтись. А в ней только информация из BITMAP, а она меньше по размеру, чем 54 байта. A>да, так мы сэкономим 40 байт A>но вероятность того, что в теге img будет что-то похожее на bmp, ничтожно мала. я посмотрю как ты будешь распаковывать gif/ani-gif/jpg/png используя лишь массив WxHx4... особенно для >32битных картинок
Распаковывать — фигня. Их еще нарисоаввать надо. С учетом всех прозрачностей и наложений друг на друга. Layout в HTML+CSS — это очень злая штука.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну и пусть. Синтанализатор останется без изменений, а кодогенератор можно в виде отдельной DLL сделать, по одной на каждый процессор. И на IL тоже.
Синтаксический анализатор у BC кривенький. Посмотри сколько сообщений репортит VC и сколько твой BC. VC показывает все ошибки, BC — бывает только одну и глядя на такие фокусы совсем не удивительно, что экс-Борланд банкротится чуть не раз в год.
PD>Да, конечно. Я думаю, что кодогенерация на плоскую модель несколько проще, чем на сегментированную, но если бы надо было соорудить компилятор, который на обе модели компилировал (он, кстати, был, BC 4.5), то, действительно, его стоило бы сделать из двух кусков.
А BC сможет драйвер какой сбилдить под нынешнюю вындоус х86 32 что бы драйвер еще и работал ?
Здравствуйте, Antikrot, Вы писали:
A>да, так мы сэкономим 40 байт
Ну вот видишь!
A>но вероятность того, что в теге img будет что-то похожее на bmp, ничтожно мала. я посмотрю как ты будешь распаковывать gif/ani-gif/jpg/png используя лишь массив WxHx4... особенно для >32битных картинок
Хм. Распаковать можно в массив байтов, потом SetDIBits (она DDB создает), а BITMAPINFOHEADER и массив байтов удалить
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> PD>> Вот это верно. Грузит. Насчет адского геморроя — не вижу причин. Загрузить нужный модуль в нужное время при правильной архитектуре — не такая уж проблема. Не при архитектуре VS20xx
PD> H>Грузить в нужное время не проблема. Проблема в том, что я выбрав в меню пункт Options хочу сразу увидеть диалог настроек, а не ждать, пока она его поднимет из сборок и проинициализирует. Отзывчивость гуя должна быть молниеносной, иначе он начинает раздражать.
PD> Угу. Зайди в этой ГУИ на вкладку ToolBox и подожди, пока он все это не проинициализирует перед показом. У меня на Athlon64 4200 на работе секунд так 10.
Нету сейчас студии под руками. Но вот ты как раз и привел пример, как оно будет работать если все грузить on demand (хотя в случае с опциями это вполне допустимо, благо не самая частая операция). Сильно приятно? А прикинь, если бы она это делала на каждый чих?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, VladD2, Вы писали:
VD>>На повышение надежности нужно или затратить существенно больше времени или выбрать другие средства разработки. Скажем тот же дотнет. И если пользователь готов платить за фичи большим потреблением ресурсов, то зачем ломать копья и заниматься? И наоборот, если рынок требует максимально оптимизированного решения и при этом надежного, то скорее всего придется заплатить функциональностью.
H>Да? Очень интересно, какие такие фичи получили юзеры атишных карточек с конфигуратором написанным под дотнет? Гуй выглядит как говно, тормоза просто дичайшие, потребление ресурсов безумное. И еще очень интересно, какой такой функциональностью пожертвовала NVidia, которая пишет свой конфигуратор (а там, в отличии от атишного, не только настройками дров рулить можно, но и много чего другого) на сях? Вот смотри, продукты одинаковой направленности, но подход совершенно разный. Хоть кто нибудь может сказать, что дотнет чего то дал атишникам окромя тормозов?
Ну, вообще-то, на современных игровых компах(а нахрена не на игровых АТИ?) оно не тормозит совсем. Ну а что до стремности — у АТИ и до времен дотнета Каталист кривой был, с чего бы после перелезания на дотнет это поменялось?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
PD>> Угу. Зайди в этой ГУИ на вкладку ToolBox и подожди, пока он все это не проинициализирует перед показом. У меня на Athlon64 4200 на работе секунд так 10.
H>Нету сейчас студии под руками. Но вот ты как раз и привел пример, как оно будет работать если все грузить on demand (хотя в случае с опциями это вполне допустимо, благо не самая частая операция). Сильно приятно? А прикинь, если бы она это делала на каждый чих?
Ты наешь, загрузка DLL отнюдь не такой уж длительный процесс. Подумаешь — сотню Кб в ОП перенести. Тем более, что они все туда не перенесутся — механизм mmf тебе, наверное, известен.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>В IDE VC++ до 2010 я не вижу ничего такого, чего не было в BC++ 5.0.
VD>> Ты бредишь? Как минимум VS 2010 — это расширяемая IDE для (мягко говоря) более чем одного языка.
PD>Как минимум — VS6 была расширяемой средой с как минимум еще одним вcтраиваемым языком — Compaq Fortran,
Откуда дровишки? Насколько я знаю официального SDK для VS 6 не существует. Так что если интеграция и была, то скорее всего сделанная хакерскими методами (вроде Томаты — интеллисенса для С++).
PD>даже если не брать во внимание о ICC++.
ICC++ — это компилятор Intel C++ что ли? Если так, то ты нагло врешь. Небыло никакой интеграции для него. Компилятор можно было вызвать. Но это никакого отношения к интеграции не имеет. Интеграция — это поддержка проектов, интлисенса, отладки и т.п. Не путай божий дар с яичницой.
PD>Это раз.
Это похоже — 0.
PD>А во вторых — причем тут это ? Я говорил о возможностях IDE, и только, в плане С++, и только его.
А ты не говри. VS 2010 это не текстовый редактор с подсветкой синтаксиса для C++. И не надо ее сравнивать с таковым. VS 2010 рассчитана на кучу языков, и кучу технологий многим С++-никам (вроде тебя) даже не знакомых.
VD>>Такое сравнение скорее говорит о степени использования возможностей IDE. Когда пользователю достаточно подсветки синтаксиса и запуска отладчика из редактора, то что ему можно объяснить о современных IDE?
PD>А я вполне согласен. Надо было развивать VS6, а не переписывать на дотнет.
Тебя забыли спросить. Вот спросили бы и было бы всем счастье.
В студии до 2010 дотнета практически не было. Если взять к примеру пакет С++, то при его запуске использовался один дотнетный компонент — страница свойств файлов. А время загрузки определяется огромным числом ДЛЛ-ей грузящихся в память. Большая часть из них КОМ-овские (нэйтивные). По данным ПроцессЭксплорера под дотнетные хипы закомичено 24 мега памяти, а ворксет студии в этот момент 150 мег. Не трудно сделать выводы, что большая часть памяти расходуется на нэйтив код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
E__>>Потому что задача — не "раскрыть тривью", а "реализовать дерево, структура и способ отображения которого передаются с сервера, и отображаются корректно и единообразно во всех системах без установки дополнительного ПО". Вот эта задача с помощью стандартного тривью не решается. Потому сравнивать просто некорректно.
PD>Вот это уже лучше.
PD>Структура и способ с сервера — это к делу не относится. Или ты считаешь, что с помощью windows treeview нельзя изображать дерево, структура которого передается с сервера ? Вполне можно. Кстати, тот же регедит может показывать удаленный реестр. Не сервер, конечно, но тоже по сети.
Способ отображения в тривью с сервера задать сложнее.
PD>А вот насчет корректно и единообразно — тут я согласен. Надо корректно и единообразно. Например, работа с файлами в нынешних системах делается корректно и примерно однообразно, потому что когда-то взяли юниксовскую модель работы с ними и портировали в другие ОС. А до этого было очень уж не единообразно — в Фортране одно, в ПЛ/1 другое и т.д.
PD>Так может, надо было просто взять да и сформулировать эти общие правила для клиентов, изображающих это все ? А то ведь мало того, что они на разных платформах изображаются все равно по-разному, так ведь и на одной платформе в разных броузерах тоже. И порядочную часть своего времени вы тратите на то, чтобы это прилично выглядело в разных броузерах.
Дык, потихоньку к этому идет. Тот же html5 — это замена многих фич, которые ранее делались через жопу сторонними средствами на стандарт реализации новых тегов в браузере. Я только за. Только медленно это все и со скрипом — само по себе это очень обширная тема для обсуждения.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
E>> Кстати, наблюдаются интересные штуки. Раньше оптимизация на асме давала выигрыш по сравнению с компилятором. Сегодня компиляторы оптимизируют так хорошо, что влезая ручками, очень вероятно только все испортить. Тот же процесс происходит с js/java/.net — JIT уже сейчас на некоторых тестах обгоняет С++, и возможностей для роста там еще тьма, рантаймовые компиляторы еще весьма молоды. Но у JIT потенциальных возможностей по оптимизации куда больше, чем у статического компилятора, так что в этом направлении ожидается стремительное развитие.
H>Ты в курсе о приборах работающих в кожухе, а не в принципе?
Чего?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, hattab, Вы писали:
H>Он у меня перед глазами, если что. Уже 2011 маячит, а атишники не ослили даже поддержку XP themes реализовать Переход по настройкам сопровождается нормальными такими притормаживаниями, хотя там этих настроек кот наплакал, вот чему бы там тормозить... Потребление этого чуда-юда переваливает за сотню метров, а это, всего лишь, тупая конфигурялка. Так что не надо ля-ля о вранье
А что за комп? У меня дома(Феном х3, 8Г памяти) летает без притормаживаний вообще.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
PD>>Как минимум — VS6 была расширяемой средой с как минимум еще одним вcтраиваемым языком — Compaq Fortran,
VD>Откуда дровишки? Насколько я знаю официального SDK для VS 6 не существует. Так что если интеграция и была, то скорее всего сделанная хакерскими методами (вроде Томаты — интеллисенса для С++).
Ставил сам и работал. Образуется еще несколько визардов — консольное Win32 Фортран приложение, GUI приложение (это меня позабавило, не хватало только GUI на фортране делать) и DLL.
Отладка работала, прочие фичи тоже. В общем, все как при работе с С++, только Фортран.
История тут такая. Для студии 4.2 существовал компилятор с Фортрана, встраиваемый в Студию 4.2 (про 5.0 не в курсе), причем от MS. Потом они его продали Compaq и он его продолжил и довел до Visual Fortran 6.6. Так что это не хакерство. Кстати, если ставить Visual Fortran 6.6 на машине, где нет VS6, то там появлялась VS6, с фортраном, но без С++.
На остальное не отвечу, так как участие в этой дискуссии прекратил.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> Ты наешь, загрузка DLL отнюдь не такой уж длительный процесс. Подумаешь — сотню Кб в ОП перенести. Тем более, что они все туда не перенесутся — механизм mmf тебе, наверное, известен.
Увы, одной только загрузкой DLL дело не ограничивается. Нужна еще инициализация, на нее тратится время. В случае со сборками дотнета времени тратится сильно больше, что прекрасно видно на практике. Ну и уж коли студия переходит на управляемый код, для нее загрузки сборок on demand это всегда (уж первая загрузка точно) будут тормоза. Уж лучше все грузить сразу, чем дергаться потом.
Здравствуйте, Eugeny__, Вы писали:
E> Ну, вообще-то, на современных игровых компах(а нахрена не на игровых АТИ?) оно не тормозит совсем.
У меня не игровой комп, это да, всего лишь Phenom II X4 940BE 3.3GHz, 8Gb RAM (ATI Radeon 3300HD, на момент покупки мамки это было самое производительное встроенное видео). Как на таком железе вообще можно тормозить? Однако же факты штука упрямая
E> Ну а что до стремности — у АТИ и до времен дотнета Каталист кривой был, с чего бы после перелезания на дотнет это поменялось?
У меня давным-давно была атишная карточка All-In-Wonder какая-то-там (с тв-тюнером). Там был прекрасный нативный софт, который отлично работал на моем Celeron 300MHz.
Здравствуйте, Eugeny__, Вы писали:
E> H>Ты в курсе о приборах работающих в кожухе, а не в принципе?
E> Чего?
Есть такая фраза: прибор должен работать в кожухе, а не в принципе. Очень уместна, когда кто нибудь потенциалом размахивает. Коли JIT так хорош, чего же весь .NET за'ngen'еный вусмерть?
Здравствуйте, Eugeny__, Вы писали:
E> H>Он у меня перед глазами, если что. Уже 2011 маячит, а атишники не ослили даже поддержку XP themes реализовать Переход по настройкам сопровождается нормальными такими притормаживаниями, хотя там этих настроек кот наплакал, вот чему бы там тормозить... Потребление этого чуда-юда переваливает за сотню метров, а это, всего лишь, тупая конфигурялка. Так что не надо ля-ля о вранье
E> А что за комп? У меня дома(Феном х3, 8Г памяти) летает без притормаживаний вообще.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>> Ты наешь, загрузка DLL отнюдь не такой уж длительный процесс. Подумаешь — сотню Кб в ОП перенести. Тем более, что они все туда не перенесутся — механизм mmf тебе, наверное, известен.
H>Увы, одной только загрузкой DLL дело не ограничивается. Нужна еще инициализация, на нее тратится время. В случае со сборками дотнета времени тратится сильно больше, что прекрасно видно на практике. Ну и уж коли студия переходит на управляемый код, для нее загрузки сборок on demand это всегда (уж первая загрузка точно) будут тормоза. Уж лучше все грузить сразу, чем дергаться потом.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ставил сам и работал. Образуется еще несколько визардов — консольное Win32 Фортран приложение, GUI приложение (это меня позабавило, не хватало только GUI на фортране делать) и DLL.
Ага, я тоже с ним работал. Это называлось Fortran Power Station. У него, помимо GUI-приложений можно было делать QuickWin-приложения. Оно в простейшем случае собиралось, как консольное, но вывод вместо консоли валился в окно. Этому окну были доступны Copy/Paste. Было какое-то простейшее меню, которое можно было расширять. Я из DOS в Windows перетащил программу построения неких графиков, построил этот самый QuickWin. Сразу же получил нормальную печать этих графиков и возможность их переноса в Word — понадобилось для отчетов.
PD>История тут такая. Для студии 4.2 существовал компилятор с Фортрана, встраиваемый в Студию 4.2 (про 5.0 не в курсе), причем от MS.
Ну да, у них оболочка общая была. В нее таким же манером J++ (пародия на Java от MS) добавлялся.
PD>Потом они его продали Compaq и он его продолжил и довел до Visual Fortran 6.6. Так что это не хакерство. Кстати, если ставить Visual Fortran 6.6 на машине, где нет VS6, то там появлялась VS6, с фортраном, но без С++.
Вот с этой не работал. Установил, но ничего серьезного не делал. ЕМНИП, MS при продаже разрешила Compaq (а не DEC?) использовать Visual Studio.
Здравствуйте, hattab, Вы писали:
E>> H>Ты в курсе о приборах работающих в кожухе, а не в принципе?
E>> Чего?
H>Есть такая фраза: прибор должен работать в кожухе, а не в принципе. Очень уместна, когда кто нибудь потенциалом размахивает. Коли JIT так хорош, чего же весь .NET за'ngen'еный вусмерть?
Наверное потому, что пока JIT еще так себе. Но согласись, что возможностей у него поболе. Он знает архитектуру и особенности системы, в которой работает. Он знает статистику исполнения — что чаще всего выполняется и что желательно оптимизировать, а на что забить. Вобщем, поле для действий широкое, но пока реализация еще не доведена до нужного уровня. Посмотрим, что дальше будет.
Кстати, джава на закомпилена вусмерть(этот подход вообще не применяется, пре-компиляторы джавы вообще штука редкая). Но там своя специфика — зоопарк поддерживаемых систем и сотни популярных фреймворков — задолбаешься все в нативы компилить. Но тем не менее, джава весьма популярна, хоть и на серваках.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Pavel Dvorkin, Вы писали:
H>>Увы, одной только загрузкой DLL дело не ограничивается. Нужна еще инициализация, на нее тратится время. В случае со сборками дотнета времени тратится сильно больше, что прекрасно видно на практике. Ну и уж коли студия переходит на управляемый код, для нее загрузки сборок on demand это всегда (уж первая загрузка точно) будут тормоза. Уж лучше все грузить сразу, чем дергаться потом.
PD>Или грузить потом, но неуправляемый код
"Неуправляемый код" звучит как-то стремно . Полагаю, лучше будет "не упровляемый"[а нативный].
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
M>>Распаковывать — фигня. Их еще нарисоаввать надо. С учетом всех прозрачностей и наложений друг на друга. Layout в HTML+CSS — это очень злая штука. A>пусть аппаратный ускоритель рисует. хотя... "а вот раньше для просмотра интернета 3d ускоритель не нужен был! и ведь отрисовывали!"
Ну, в 9-м эксплорере таки будет Но рисование — это тоже фигня. Вот формирование этого рисунка — это огого
Здравствуйте, VladD2, Вы писали:
VD>ICC++ — это компилятор Intel C++ что ли? Если так, то ты нагло врешь. Небыло никакой интеграции для него. Компилятор можно было вызвать. Но это никакого отношения к интеграции не имеет. Интеграция — это поддержка проектов, интлисенса, отладки и т.п. Не путай божий дар с яичницой.
а какая нужна интеграция плюсового компилятора в плюсовый environment? он там просто выбирался вместо vc, если был "проинтегрирован". всё остальное использовалось что было.
E__>Кстати, джава на закомпилена вусмерть(этот подход вообще не применяется, пре-компиляторы джавы вообще штука редкая). Но там своя специфика — зоопарк поддерживаемых систем и сотни популярных фреймворков — задолбаешься все в нативы компилить. Но тем не менее, джава весьма популярна, хоть и на серваках.
Я бы сказал — тем более на серваках. И базы данных на ней хитрые пишут (hadoop/hbase, cassandra, neo4j)
Здравствуйте, Privalov, Вы писали:
PD>>Ставил сам и работал. Образуется еще несколько визардов — консольное Win32 Фортран приложение, GUI приложение (это меня позабавило, не хватало только GUI на фортране делать) и DLL. P>Ага, я тоже с ним работал. Это называлось Fortran Power Station.
PD>>Потом они его продали Compaq и он его продолжил и довел до Visual Fortran 6.6. Так что это не хакерство. Кстати, если ставить Visual Fortran 6.6 на машине, где нет VS6, то там появлялась VS6, с фортраном, но без С++. P>Вот с этой не работал. Установил, но ничего серьезного не делал. ЕМНИП, MS при продаже разрешила Compaq (а не DEC?) использовать Visual Studio.
ms ->dec->compаq->intеl неисповедимы пути фортрановы (студия которая с ним обзывается vs shell)
Здравствуйте, Pavel Dvorkin, Вы писали:
A>>но вероятность того, что в теге img будет что-то похожее на bmp, ничтожно мала. я посмотрю как ты будешь распаковывать gif/ani-gif/jpg/png используя лишь массив WxHx4... особенно для >32битных картинок PD>Хм. Распаковать можно в массив байтов,
в процессе распаковки типа совсем память для "временных данных" не надо?
PD>потом SetDIBits (она DDB создает), а BITMAPINFOHEADER и массив байтов удалить
и как там у неё с прозрачностью?
Здравствуйте, Eugeny__, Вы писали:
E> H>Есть такая фраза: прибор должен работать в кожухе, а не в принципе. Очень уместна, когда кто нибудь потенциалом размахивает. Коли JIT так хорош, чего же весь .NET за'ngen'еный вусмерть?
E> Наверное потому, что пока JIT еще так себе. Но согласись, что возможностей у него поболе. Он знает архитектуру и особенности системы, в которой работает. Он знает статистику исполнения — что чаще всего выполняется и что желательно оптимизировать, а на что забить. Вобщем, поле для действий широкое, но пока реализация еще не доведена до нужного уровня. Посмотрим, что дальше будет.
Ну да, в теории у джита все красиво, но только в теории. Время для оптимизаций сильно ограничено. Знание о системе тоже вопрос спорный, ведь производители компиляторов не бросаются оптимизировать джит под конкретные архитектурные возможности/особенности (такие, как размер кэша, наборы доп. инструкции и прочее) процессоров, а делают просто средненький вариант. И вряд ли что-то в этом плане будет меняться
E> Кстати, джава на закомпилена вусмерть(этот подход вообще не применяется, пре-компиляторы джавы вообще штука редкая). Но там своя специфика — зоопарк поддерживаемых систем и сотни популярных фреймворков — задолбаешься все в нативы компилить. Но тем не менее, джава весьма популярна, хоть и на серваках.
Во-во, в том-то и дело, что не на десктопе. Для серверов это вообще не сильно критично ведь за задержками сети любые задержки джита будут невидны
Здравствуйте, Eugeny__, Вы писали:
E> H>У меня не игровой комп, это да, всего лишь Phenom II X4 940BE 3.3GHz, 8Gb RAM (ATI Radeon 3300HD, на момент покупки мамки это было самое производительное встроенное видео). Как на таком железе вообще можно тормозить? Однако же факты штука упрямая
E> Странно это. А комп вполне может стать игровым, если в него втаращить более производительную видяху .
Я намеренно не стал брать дискретное видео. Этой видяхи для моих любимых игрушек хватает вполне, и дополнительный нагреватель воздуха себя не оправдает
E> H>У меня давным-давно была атишная карточка All-In-Wonder какая-то-там (с тв-тюнером). Там был прекрасный нативный софт, который отлично работал на моем Celeron 300MHz.
E> У меня как-то catalyst всегда вызывал легкое недоумение. Впрочем, производители железа частенько тянут страшненькие глючненькие утилитки с собой. Телефонный софт это вообще мрак. А что до АТИ — я вполне готов мириться с ихним софтом — железки мне их как раз наоборот, очень нравятся. На более слабых компах я просто убирал каталист из автозагрузки, сейчас пофигу — памяти дочерта, пусь себе висит.
У меня предпочтений по железу нет, были и ATI и NVidia, устраивали и те и другие, но вот касаемо софта... Нет, конечно кривость каталиста не будет стоп-фичей для покупки карточки на десктоп, но вот покупать нетбук (а ведь скоро выйдет APU Ontario) с атишным видео что-то страшновато.
Здравствуйте, Antikrot, Вы писали:
A>а какая нужна интеграция плюсового компилятора в плюсовый environment? он там просто выбирался вместо vc, если был "проинтегрирован". всё остальное использовалось что было.
Это уже отдельная тема. К делу не относящаяся. В прочем наверно не секрет, что VC6 шел с компилятором только отдаленно напоминающим С++ (стандарт). Ител в этом плане был сильно более продвинутый. Ну, и интеграция у него была тоже далека от идела. Реально без Томаты пользоваться его интелесеносом было трудно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hattab, Вы писали:
E>> Ну, вообще-то, на современных игровых компах(а нахрена не на игровых АТИ?) оно не тормозит совсем.
H>У меня не игровой комп, это да, всего лишь Phenom II X4 940BE 3.3GHz, 8Gb RAM (ATI Radeon 3300HD, на момент покупки мамки это было самое производительное встроенное видео). Как на таком железе вообще можно тормозить? Однако же факты штука упрямая
Ммм, меняю свое мнение. Таки в Линухе реально быстрее работает и грузится(а оно нативное) — видео, учтите, что это еще и при загруженном каптурере + тормоза конвертации(видно, что мыша отнюдь не плано перемещается). Виндовая версия таки менее отзывчивая — с 200-300 мс таки думает, а тут вообще мгновенно. Хотя я вообще, загружая дома линух, фигею, насколько он более быстрый(по юзеринтерфейсу), и это при том, что он стоит в файле(!!) на виндовом диске ntfs(C:\Ubuntu\ubuntu.<чего-то там>) — то есть, фс ext4 просто эмулируется в файлике на нтфс(мне влом искать диски, чтобы на реальный раздел поставить, а с флеша у меня мать грузиться не умеет ).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Я так вроде начинал со сравнения BC 5 против VC 6. A>>в другой теме — да. а вот тут, чуть выше по ветке: A>>
A>>Контрвопрос — насколько меньше памяти потреблял компилятор от VC 4.2, 5.0 ? Опять же — от силы раза в 1.5, ну пусть 2. А предположить, что от 4.2 до 6.0 он не развивался, а тут уж прямо в гору пошел — как-то сомнительно
A>>никакого BC5 уже нет PD>Нет, конечно, ну и что ? Сравнивать нельзя ?
сравнивай, мне не жалко. только давай пока ограничимся vc
PD>>>В cl.exe еще и генерация кода под IA-64 засунута, и под другие платформы. Это просто разные куски компилятора(кодогенератора). A>>надо полагать, ты его изнутри видел? насколько я понял, это уже другой cl.exe будет PD>Ну и пусть. Синтанализатор останется без изменений, а кодогенератор можно в виде отдельной DLL сделать, по одной на каждый процессор.
не всё так просто. есть hw-specific интринсики, так что такие dll тебе придётся делать к каждой части компилятора, которая их затронуть может.
PD>И на IL тоже.
на IL, это если про MC++, там и в синтаксисе добавлено
A>>выше по треду: A>>
A>>Контрвопрос — насколько меньше памяти потреблял компилятор от VC 4.2, 5.0 ?
PD>Так что ? Вопрос-то тебе был, а не мне.
так вот я про компилятор и трындю, раз вопрос был
PD>Так, как я понял, -mcmodel исключена из списка.
mcmodel была приплетена в том обсуждении ввиду того, что ты сказал что в x64 только одна модель
PD>(вопрос в скобках — а она поддерживается вообще в VC++ ? Я что-то опций не нашел) Google в основном про GNU C++ пишет.
а хз. я про х64 в общем сказал. не уверен что она у кого под виндой есть. кстати, там в разных моделях адресация разная...
PD>Про шаблоны я ответил. Естественно, надо было это написать как следует, исправить ошибки. Но основной код был написан, я думаю, еще как минимум, в VS 4.2, потом его только исправляли и совершенствовали. PD>/CLR — туда же, куда и IA-64 и прочие MIPS. Отдельный модуль, тут мы вроде бы уже согласились.
уже сказал. отдельных модулей у тебя будет до жопы — он там не только в кодгенерации появляется.
PD>x64 — смените некоторые константы 4->8, кое-что поправьте и перекомпилируйте.
ага, "кое-что поправьте" ниче, что там вдвое больше регистров general и xmm, что влияет на оптимизатор (можно гораздо больше себе позволить. а уж сколько регистров в ia-64... ууу... отдельный модуль, да), exception handling другой и т.д.?
кстати, windows abi для x64 явно требует использовать xmm, так что совсем вынести simd в отдельный модуль будет не просто
PD>Я абсолютно не вижу, почему тут хорошо написанный код должен увеличиться в размере.
как нефиг делать. не скажу за vc, но одного удвоения количества регистров может хватить чтоб повлиять на оптимизатор в сторону увеличения размеров кода (например, больше развернуть цикл)
PD>Берем любую программу на С++ и перекомпилируем на x64.
ну так скомпилируй и выложи сюда результат
PD>Остальное. Да, это серьезно. Кодогенератор с тем же SIMD весьма серьезно отличается от кодогенератора для обычного x86. Тут спорить не приходится. PD>Но! PD>Эти все опции включаемые. И включаются они далеко не всегда. И даже когда включены, далеко не всегда реализуются. Можешь поставить SSEi, но это еще не значит, что ты ее получишь.
ха, если у тебя под виндой x64 и функции получают/возвращают плавточку, то получишь.
PD>Никто не мешает опять же оформить это в виде отдельной DLL. По сути ведь мы опять имеем то же самое — иной выходной язык. Можно x86 чистый,
это какой? 386DX?
если разбивать "по-твоему", будет столько этих dll, что тебе не понравится.
PD> иожно x64 чистый,
без sse практически нельзя
PD>Кстати, а в IA-64 часом нет той же векторизации в какой-нибудь упаковке ?
смотря что считать под упаковкой, но считай что есть. да там и без этого извращений хватит.
Здравствуйте, Eugeny__, Вы писали:
E__>"Неуправляемый код" звучит как-то стремно . Полагаю, лучше будет "не упровляемый"[а нативный].
А, черт. Читать "не управляемый" — ну надо же так ошибиться. Можете называть меня безграмотным неучем...
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E> Ммм, меняю свое мнение. Таки в Линухе реально быстрее работает и грузится(а оно нативное) — видео, учтите, что это еще и при загруженном каптурере + тормоза конвертации(видно, что мыша отнюдь не плано перемещается). Виндовая версия таки менее отзывчивая — с 200-300 мс таки думает, а тут вообще мгновенно. Хотя я вообще, загружая дома линух, фигею, насколько он более быстрый(по юзеринтерфейсу), и это при том, что он стоит в файле(!!) на виндовом диске ntfs(C:\Ubuntu\ubuntu.<чего-то там>) — то есть, фс ext4 просто эмулируется в файлике на нтфс(мне влом искать диски, чтобы на реальный раздел поставить, а с флеша у меня мать грузиться не умеет ).
Кстати да, линуксовый гуй отзывчивее виндового. Жаль что у меня не срослось с Убунтой...
Здравствуйте, Antikrot, Вы писали:
A>в процессе распаковки типа совсем память для "временных данных" не надо?
Надо. Распаковать, установить биты, удалить. От броузера не зависит.
PD>>потом SetDIBits (она DDB создает), а BITMAPINFOHEADER и массив байтов удалить A>и как там у неё с прозрачностью?
Встречный вопрос — а <img всегда рисуются с прозрачностью ? .
Ну а если она нужна и при этом per-pixel- например, посыпать голову пеплом и вернуть обратно 54 байта
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Но сначала докажите, что она ресурсоемкая.
G>Так как же тебе докажешь, если ты ничего слушать не хочешь? Читать не хочешь, оппонентов не слушаешь. G>ПРо полмиллиона объектов на странице гмейла тебе написали. G>Ссылку на новые возможности современных иде давали. G>ПРо компилятор с++ рассказывали. G>про исполнение js тоже.
G>А ты байку про "нарисовать картинку на экране" заводишь.
Я дискуссию закончил. Свои аргументы изложил. Не нравится — имеешь полное право не согласиться. Все.
Здравствуйте, hattab, Вы писали:
H> Гуй выглядит как говно, тормоза просто дичайшие, потребление ресурсов безумное.
Ну, от внешнего вида CCC-гуя я тоже не в восторге, но это дело вкуса. Насчет тормозов — не знаю, не заметил. А вот насчет потребления ресурсов ты, имхо, что-то путаешь. В свернутом виде CCC у меня потребляет 1.5 метра, что в 10 раз меньше, чем к примеру гуй к интеловскому драйверу видео на соседней машине, каковой интеловский гуй написан на С++, насколько я понимаю. В открытом виде да, CCC разворачивается до 30 мег, но кто ж такие вещи держит открытыми постоянно?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Тогда ответ прост. Пишите эту ресурсоемкую операцию, используя увеличенное количество ресурсов. Но сначала докажите, что она ресурсоемкая.
I>А ты хотя бы изредка читаешь что тебе пишут ?
I>Вот суммарно основные составляющие
I>1 JS V8 I>2 полмиллиона объектов I>3 сотни килобайт скрипта и даже мегабайты не редкость I>4 DOM, CSS — сложный рендеринг I>5 экран увеличился в 5 раз по самой щадящей оценку, реально 10 раз это нормально I>6 куча всяких абревиатур которые браузеры умеют сейчас и не умели раньше
I>Вопрос — все 6 пунктов вместе взятые могут являться ресурсоёмкой задачей или нет ?
I>GIF, JPEG и Турбопаскль оставь детям, ответь внятно — браузер которйы умеет перечисленные 6 пунктов, имеели ли он право с твоей точки зрения кушать по 100 и более мб памяти ?
Дискуссию закончил, все аргументы изложил, и не раз.
Здравствуйте, lazymf, Вы писали:
l> H> Гуй выглядит как говно, тормоза просто дичайшие, потребление ресурсов безумное.
l> Ну, от внешнего вида CCC-гуя я тоже не в восторге, но это дело вкуса.
Классик-контролы под Аэро выглядят ужасно, как это может кому-то нравиться я не понимаю.
l> Насчет тормозов — не знаю, не заметил. А вот насчет потребления ресурсов ты, имхо, что-то путаешь. В свернутом виде CCC у меня потребляет 1.5 метра, что в 10 раз меньше, чем к примеру гуй к интеловскому драйверу видео на соседней машине, каковой интеловский гуй написан на С++, насколько я понимаю. В открытом виде да, CCC разворачивается до 30 мег,
Тут все просто, запускаешь ProcessExplorer и считаешь сам (PrivateBytes):
Процесс MOM.exe — 40Mb;
Процесс CCC.exe — 54Mb (когда диалог закрыт), 71Mb (когда диалог открыт).
l> но кто ж такие вещи держит открытыми постоянно?
H>Тут все просто, запускаешь ProcessExplorer и считаешь сам (PrivateBytes):
H>Процесс MOM.exe — 40Mb; H>Процесс CCC.exe — 54Mb (когда диалог закрыт), 71Mb (когда диалог открыт).
l>> но кто ж такие вещи держит открытыми постоянно?
H>Вопрос так не стоит. Вопрос стоит иначе
: какого х..я простейшая утиль жрет столько памяти?
Сейчас — как минимум потому, что может. При даже не моих 8Г, а минимальных 4Г для игрового компа(а на неигровом этим утилитам грош цена) даже эта память — крохи. Хотя мне не удалось на х64 винде добиться 54 мб — в закрытом виде 1-4 мб(первое значение — private bytes, это после открытия и закрытия, если просто после загрузки — 1.5 мб), в открытом — около 50. Хотя по сравнению с линух версией таки притормаживает интерфейс. Ради прикола сейчас грузану Убунту, померяю память там.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
H>>Тут все просто, запускаешь ProcessExplorer и считаешь сам (PrivateBytes):
H>>Процесс MOM.exe — 40Mb; H>>Процесс CCC.exe — 54Mb (когда диалог закрыт), 71Mb (когда диалог открыт).
l>>> но кто ж такие вещи держит открытыми постоянно?
H>>Вопрос так не стоит. Вопрос стоит иначе
: какого х..я простейшая утиль жрет столько памяти?
E__>Сейчас — как минимум потому, что может. При даже не моих 8Г, а минимальных 4Г для игрового компа(а на неигровом этим утилитам грош цена) даже эта память — крохи. Хотя мне не удалось на х64 винде добиться 54 мб — в закрытом виде 1-4 мб(первое значение — private bytes, это после открытия и закрытия, если просто после загрузки — 1.5 мб), в открытом — около 50. Хотя по сравнению с линух версией таки притормаживает интерфейс. Ради прикола сейчас грузану Убунту, померяю память там.
Отчеты о текущем положении. Скрины делать влом, напишу текстом.
Винда(7, х64, видяха 5800 series, дрова с офсайта, скачанные и установленные хоть и с геморроем, но работают теперь на отл).
ССС — каталист контрол центр. Жрет 1-4 мегабайта памяти постоянно, загружен в памяти всегда. При загрузке явной может сожрать до 40 мб памяти, но через несколько секунд возвращается к 4 мб. При загрузке опций видео появляется новый процесс cccprev.exe, который жрет порядка 75 мб памяти(отображает динамически созданную и меняющую ракурс картинку с текущими настройками(какой-то фонтан в готическом стиле), кулер на видяхе повышает обороты). После указания настроек и закрытия окна уничтожается, освобождая все — опять те же 4 мб на CCC.exe. Версия ССС — 2010.0825.2146.37182(тут мой луч поноса разработчикам винапи, из-за которых скопировать из статика ничего нельзя — 4 раза запускал окошко с версией, в линухе по умолчанию статические контролы выделяются, и из них можно копировать).
Линух(Убунту 10.10 АМД64, оборудование то же, дрова поставлены стандартным средством — нажатие кнопки "активировать пропритарный драйвер", работает не менее на отл).
ССС не существует — в памяти нет постоянно работающего контрол центра. При загрузке оного вручную занимает 13.5 метров памяти. Но — картинка статическая — тот же фонтан, с теми же графическими опциями, но просто один кадр, а не анимация. Правда, и работает быстрее — но в винде мы анимацию видели, а тут просто перерисованная та же картинка, только с выбранными опциями. Но и память 13.5 — и не меняется, причем отзыв юзеринтерфейса контролцентра порядка единиц миллисекунд.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
: какого х..я простейшая утиль жрет столько памяти?
E> Сейчас — как минимум потому, что может. При даже не моих 8Г, а минимальных 4Г для игрового компа(а на неигровом этим утилитам грош цена) даже эта память — крохи.
Ну причем тут игровой не игровой? У ATI, что, встроенной графики нет, или ее не ставят на нетбуки? На счет цены вопрос интересный. Чем прикажешь пользоваться юзеру нетбука с чипсетным radeon для настройки подключения оного к телевизору, настройки цветности (ты ведь в курсе каким говном бывают TN'матрицы?), зажимания всех настроек для запуска чуть более жручей игрушки (на нетбуках играют, да).
E> мб(первое значение — private bytes, это после открытия и закрытия, если просто после загрузки — 1.5 мб), в открытом — около 50.
Класс! Я говорю о ProcessExplorer, ты выкладываешь скриншот TaskManager'а (в котором, для семерки, нужно смотреть на CommitSize).
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>В броузер в принципе ничто не мешает засунуть что угодно. Тебе про ActiveX напомнить ? S>Чувство юмора — это прекрасно. Но всё же, что делать с твоим мега-ActiveX владельцам, скажем, iPad? Веб-сайты сейчас крутятся в огромном количестве всего, и винда — это не очень значительная доля рынка.
Чувство юмора здесь ни при чем. Объясняю популярно :
1."В броузер в принципе ничто не мешает засунуть что угодно". Это тезис.
2. "Тебе про ActiveX напомнить ?" Это пример, демонстирующий один из вариантов этого "что угодно". И не более, как легко понять.
Так что целью этого высказывания является именно тезис , а вовсе не этот пример. Поэтому обсуждать его в ином контексте не имеет смысла.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Вот если бы размер экрана увеличился с тех пор раз так в 10 — другое дело. Или страница имела бы размер так примерно Мб 50 против 5 S>Бойся чего-либо желать, ибо желаемое исполнится: 640x480x1 = 307200 байт. 1440*900*4 = 5184000 байт. Итого, размер экрана вырос в 16.875 раз.
: какого х..я простейшая утиль жрет столько памяти?
E>> Сейчас — как минимум потому, что может. При даже не моих 8Г, а минимальных 4Г для игрового компа(а на неигровом этим утилитам грош цена) даже эта память — крохи.
H>Ну причем тут игровой не игровой? У ATI, что, встроенной графики нет, или ее не ставят на нетбуки? На счет цены вопрос интересный. Чем прикажешь пользоваться юзеру нетбука с чипсетным radeon для настройки подключения оного к телевизору, настройки цветности (ты ведь в курсе каким говном бывают TN'матрицы?), зажимания всех настроек для запуска чуть более жручей игрушки (на нетбуках играют, да).
Ну, если к телику подключать, или пытаться таки играть — то да. Я просто как-то и не подумал об этом: если не считать телика у родителей, я этих девайсов уже много лет ни у кого не наблюдал.
E>> мб(первое значение — private bytes, это после открытия и закрытия, если просто после загрузки — 1.5 мб), в открытом — около 50.
H>Класс! Я говорю о ProcessExplorer, ты выкладываешь скриншот TaskManager'а (в котором, для семерки, нужно смотреть на CommitSize).
Ммм, признаю, протупил. В процессэксплорере и правда 78 метров. Правда, пальма первенства все равно не за ССС — нокиевские тулзы в сумме 150 метров жрут.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Sinclair, Вы писали:
S>В итоге получается, что в принципе засунуть что-либо в браузер в твоём понимании мешает здравый смысл. S>А в жизни у тебя выбор между JS, Flash, Java Applet и ActiveX. Двое из которых — тихий ужос. Микрософт пытается добавить к списку субплатформ Silverlight. Как видим, пока что даже софтверный гигант с капитализацией Газпрома не может "засунуть в каждый броузер что угодно".
Под одним из "тихих ужасов" понимается java applet, как я понимаю?
Просто во время появления эта технология несколько опережала время. И тормозила, отчего сыскала неодобрение юзеров. Сейчас апплеты и выполняются быстро(ну а с системой безопастности там всегда хорошо было, просто только сейчас процы могут обеспечить этот функционал без потерь для пользователя), и JVM уже у очень многих стоит. Просто поезд немного ушел.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Просто во время появления эта технология несколько опережала время. И тормозила, отчего сыскала неодобрение юзеров. Сейчас апплеты и выполняются быстро(ну а с системой безопастности там всегда хорошо было, просто только сейчас процы могут обеспечить этот функционал без потерь для пользователя), и JVM уже у очень многих стоит. Просто поезд немного ушел.
Я не знаю, в чём там дело. Но и сейчас те немногие апплеты, которые я встречаю, работают из рук вон плохо. Торможение при инициализации, плохое взаимодействие с браузером (типа когда нечаянный клик мимо апплета приводит к навигации с молчаливым убиением нафиг всего введённого к этому моменту) и так далее. Возможно, это проблемы конкретных решений, а не технологии в целом. Однако, флэш-приложения при прочих равных вызывают у меня меньше отторжения.
Нет, конечно и JS не запрещает делать отстой. Но почему-то к апплетам у меня веры как-то нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Советую впредь внимательнеее читать всю дискуссию. В ней и речи не было о том, что делается на серверной стороне. Речь шла только о том, что делается на клиенте. В броузере то есть.
А ты попробуй перечитать что пишет Синклер — он пишет про клиентскую часть. Но вообще вряд ли будет толк, ты длинные сообщения читать не умеешь.
Нельзя в браузер засунуть все что угодно — это краткая выжимка из его поста.
Ниже
JS невероятно хорош по очень многим параметрам (и плох по тем же 
