Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Назови все, какие знаешь, чисто managed продукты, дистрибутив которых занимает хотя бы один сидюк.
Sharepoint 2007?
Я его давно правда ставил — уже не помню. Вроде с дивидюка ставил, но не помню сколько он там занимал

Здравствуйте, Константин, Вы писали:
К>Хорошо, давайте-ка напишем пару идентичных приложений: я на плюсах, вы на дот-нете, с идентичным простеньким функционалом. А потом запустим их на свежезагруженной винде XP. Через какое время появится окно дот-нетовского приложения, пока там фреймворк загрузится, пока джит отработает?
Для идентичного простенького функционала разницу не будет видно даже в микроскоп. Для непростенького — все никак не будет зависеть от платформы.
Я же сказал — взрослые люди над таким бредом уже даже не смеются.

К>И через какое — плюсового, где всей этой муры нет? Да, когда оно загрузится, соптимизируется для текущей платформы — оно будет работать достаточно быстро. Но такое подходит для сложных вычислительных программ, которые во время запуска выполняют столько работы, что загрузка лишнего фреймворка или Джава-рантайма на общей скорости практически не сказывается. Но когда .NET используется для мизерного приложения, которое открыл, глянул и закрыл… Я лично терпеть не могу, когда приходится 2-3 секунды ждать одного только запуска простейшей прожки.
2-3 секунды никак не связаны с платформой.
К>Особенно зная, что абсолютно такого же результата можно достичь без тормозов. Покажите мне хоть одну .NET- или Java-программу, которая запустится мгновенно, как плюсовая, и я призна?ю, что был не прав.
Ок, давай покажи мне тайминг запуска hello world на дотнете.
К>(Я, разумеется, не имею в виду ситуацию, когда прожка уже десяток запускалась на машине, и всё, что можно, винда закэшировала.)
Ну, вообще-то это неспортивно. Если тебе приложение приходится запускать один раз в жизни, то лишние три секунды ничего не решают. А если десяток раз, то винда уже всё закэширует.

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

К>Хорошо, давайте-ка напишем пару идентичных приложений: я на плюсах, вы на дот-нете, с идентичным простеньким функционалом. А потом запустим их на свежезагруженной винде XP. Через какое время появится окно дот-нетовского приложения, пока там фреймворк загрузится, пока джит отработает? И через какое — плюсового, где всей этой муры нет?
Ну и как ты это все мерять будешь? На глаз разницу не оценишь в общем случае.
Самые большие тормоза на современном железе — дисковые операции и иногда сеть.
Соответственно разница заметна будет если в процессе инициализации у кого то из них будут дисковые операции.

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

К>>Хорошо, давайте-ка напишем пару идентичных приложений: я на плюсах, вы на дот-нете, с идентичным простеньким функционалом. А потом запустим их на свежезагруженной винде XP. Через какое время появится окно дот-нетовского приложения, пока там фреймворк загрузится, пока джит отработает? И через какое — плюсового, где всей этой муры нет?
CC>Ну и как ты это все мерять будешь? На глаз разницу не оценишь в общем случае.
CC>Самые большие тормоза на современном железе — дисковые операции и иногда сеть.
CC>Соответственно разница заметна будет если в процессе инициализации у кого то из них будут дисковые операции.

На первом запуске разница будет заметна на глаз даже для Hello World — в связи с вызовами JIT-компиллятора. Если сделать сразу native image с помощью ngen, то да — на глаз разницы видно быть не должно.

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

kuj>То есть тормоза нынче измеряются по скорости первого запуска простенькой программки?

Ох люблю я СВ… Как же любят здесь собеседники вырывать слова из контекста. Тормоза при запуске программы — это частный случай тормозов. Одна из частей. На всех известных мне Java-приложениях (к примеру) тормоза заключаются: а) в долгом запуске, б) в тормозной обработке гуёв, в) в замедленной реакции гуёв на пользовательские действия. Это как минимум, потому как все они чётко заметны невооружённым глазом, и есть с чем сравнивать. Остальные операции требуют как минимум наличия аналогичной проги, написанной на другом языке, а это редкость (самому же писать прожки для тестов некогда, да и не настолько хорошо я знаком с Джавой и дот-нетом, чтобы гарантировать качество кода).

kuj>Ну так прогони ngen во время установки, если уж тебя так волнует время первого запуска...

А вот об этом поподробнее. Где об этом можно почитать? Что за прожка? Можно ли её применять к готовым чужим приложениям или только к самописным?

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

К>>Увы, платить три штуки баксов за операционку, когда есть возможность получить фактически то же самое в 20 раз дешевле…
CC>Это вы про пиратов что ли?

140 баксов за пиратку? Это где такие продаются?

CC>Если нет — то эквивалентом будет пожалуй только 64bit XP.
CC>У меня на работе сейчас стоит 32bit XP SP3 — есть с чем сравнить. До того времени я считал что XP и 2003 отличаются незначительно. Теперь же убедился что отличие кошмарное и не в пользу ХР. В чем технически такая разница — ума не приложу, но ощущения от работы на примерно одинаковом железе кардинальные. По сравнению с host ХР даже guest 2003-я в vmWare летает. Хотя вроде бы должно быть наоборот. Впрочем по чистым замерам производительности гостевая разумеется несколько сливает хосту. Но по ощущениям по отклику интерфейса, работе с файлами и т.п. — 2003 быстрее. Почему —

Открою страшнейшую тайну: у меня на виртуалке винда XP тоже работает шустрее, чем хостовая XP. Ставились абсолютно с одного и того же диска, основные настройки идентичные. В чём секрет? Не знаю, детально не анализировал. Частично, думаю, в том, что хост замусорен всякой гадостью, кучей программ, огрызками от когда-то установленных и ныне удалённых дистрибов. Плюс к тому, обратиться к диску в пределах нескольких гигабайт файла-образа (если он не дико фрагментирован) всегда быстрее, чем гонять головки по всей поверхности. Возможно также, есть какие-то оптимизации на уровне самой вм-твари.

Что касается хостов, то, как я уже говорил, я ставил себе на комп 2003-ю винду (32-битку). Особой разницы в производительности по сравнению с XP не ощутил.

К>Хорошо, давайте-ка напишем пару идентичных приложений: я на плюсах, вы на дот-нете, с идентичным простеньким функционалом.

ГУИ там будет? Если да, то ГУИ на плюсах не слишком шустрее дотнетовского

РД>>Но с другой стороны, идея обязательной сертификации — на мой взгляд здравая. Ибо задрали меня кривые дрова некоторых вендоров...
CC>Дык пока 32бит не вымрет (ну или хотяб 64 не будет доминировать) этот вендор и не почешется под 64 делать если его дрова не пропустят. А в результате кто больше всех пострадает? Юзер 64биток.

Если вендор не умеет писать дрова — то чтобы пройти сертификацию, ему придется напрячься и научиться это делать. В итоге юзер 64-битной оси только выиграет.
Ну или вендор умрет, не выдержав заслуженного притеснения. В этом случае юзер тоже выиграет — выкинет кривую железку, купит нормальную, и будет тратить время на работу, а не войну с глюками.

Здравствуйте, Роман Дубров, Вы писали:

РД>>>Но с другой стороны, идея обязательной сертификации — на мой взгляд здравая. Ибо задрали меня кривые дрова некоторых вендоров...
CC>>Дык пока 32бит не вымрет (ну или хотяб 64 не будет доминировать) этот вендор и не почешется под 64 делать если его дрова не пропустят. А в результате кто больше всех пострадает? Юзер 64биток.

РД>Если вендор не умеет писать дрова — то чтобы пройти сертификацию, ему придется напрячься и научиться это делать.
А может и вообще ничего не делать — пока устраивают продажи 32битной версии.

РД> В итоге юзер 64-битной оси только выиграет.
Или проиграет на данном конкретном этапе.

РД>В этом случае юзер тоже выиграет — выкинет кривую железку, купит нормальную, и будет тратить время на работу, а не войну с глюками.
Это если есть альтернатива.
А если она есть то можно уже прямо щас выкидывать

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

РД>>Если вендор не умеет писать дрова — то чтобы пройти сертификацию, ему придется напрячься и научиться это делать.
CC>А может и вообще ничего не делать — пока устраивают продажи 32битной версии.
конечно может. Хозяин — барин

РД>> В итоге юзер 64-битной оси только выиграет.
CC>Или проиграет на данном конкретном этапе.
отдельно взятые личности, купившие на последние деньги "фидорулез" — чтоб и дешево было, и было с чем потрахаться — мож и проиграют
в глобальном масштабе — выиграют, тк кривого продукта станет в мире меньше

РД>>В этом случае юзер тоже выиграет — выкинет кривую железку, купит нормальную, и будет тратить время на работу, а не войну с глюками.
CC>Это если есть альтернатива.
CC>А если она есть то можно уже прямо щас выкидывать
знаешь, даже так сразу не назову такую железку, для которой бы не было альтернативы
разве что какая-нить узкая специфика типа PC3000 или промышленки, дык там единожды собранный/проинсталленный комп работает до полной замены всей линии

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

kuj>>То есть тормоза нынче измеряются по скорости первого запуска простенькой программки?

К>Ох люблю я СВ… Как же любят здесь собеседники вырывать слова из контекста. Тормоза при запуске программы — это частный случай тормозов. Одна из частей. На всех известных мне Java-приложениях (к примеру) тормоза заключаются:

А Java тут при чем? Речь вроде шла о .NET, нет?

К>а) в долгом запуске, б) в тормозной обработке гуёв, в) в замедленной реакции гуёв на пользовательские действия.

Посмотри IntelliJ IDEA.

А вообще говоря, Java почти не используется для написания GUI-интерфейсов. Основная область применения — enterprise, web-морды и т.п.

kuj>>Ну так прогони ngen во время установки, если уж тебя так волнует время первого запуска...

К>А вот об этом поподробнее. Где об этом можно почитать? Что за прожка? Можно ли её применять к готовым чужим приложениям или только к самописным?

Утилита в составе .NET framework. Натравливаешь ее на любую .NET-сборку и она генерирует native image (на целевой машине). В итоге JIT-компиляции производиться не будет пока сборка неизменна (если подменить на другую версию image конечно станет invalid).

Почитать где? На MSDN — первая ссылка в гугл по слову ngen.

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

К>Я полностью согласен: есть области, где преимущества от оптимизации оказываются крайне низкими, а затраты — чрезмерно высокими. Но зачем писать на дот-нете, скажем, микро-программку, которая определяет размер удалённого файла по HTTP? Код на плюсах для такой задачи писать если и сложнее, то ненамного, а стартовать прога будет на порядки быстрее.

т.е. не 0.0001 секунды, а 0.001 секунду? в этом ты порядки считаешь? ... написать как раз такую прогу будет на порядки проще на дотнете, а стартовать она будет _так же_ ... на микропрограмме ты разницы уж точно в старте программы не найдешь

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

НС>>Назови все, какие знаешь, чисто managed продукты, дистрибутив которых занимает хотя бы один сидюк.
CC>Sharepoint 2007?

Дистрибутив Sharepoint Server под x86 занимает 294 мега. Причем там море неуправляемого кода (куски офиса), куча картинок и html кода, словари для поиска. Так что пример неудачный.

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

К>>Но зачем писать на дот-нете, скажем, микро-программку, которая определяет размер удалённого файла по HTTP? Код на плюсах для такой задачи писать если и сложнее, то ненамного, а стартовать прога будет на порядки быстрее.

S>т.е. не 0.0001 секунды, а 0.001 секунду? в этом ты порядки считаешь? ... написать как раз такую прогу будет на порядки проще на дотнете, а стартовать она будет _так же_ ... на микропрограмме ты разницы уж точно в старте программы не найдешь

На порядки — это 6 секунд против малой доли секунды. Сейчас перегружал машину, заодно проверил: запуск простенького .NET-приложения занял 6 секунд. Приложение представляет из себя небольшую форму форму (TrIDNet, если кому интересно), грузиться там, по идее, нечему, что подтверждается последующими запусками, которые выполняются достаточно быстро. Для сравнения запустил другую прожку, которую сам писал в своё время на плюсах с MFC (VS 6.0). Диалог появляется на экране практически мгновенно. Точно засечь столь малое время, разумеется, не могу, но ориентировочно оно составляет от 0,1 до 0,2 секунд. Время повторных запусков TrIDNet, хоть и небольшое, всё же заметно больше и приблизительно равно 0,3-0,4 секунды. Вот и получаем: первый запуск — в 30–60 раз дольше, последующие — в 1,5–4 раза.

Не хочется мне ждать 6 секунд, пока прога, наконец, запустится. Потом будет быстрее — да, пока я какую-нибудь громадную виртуалку не запущу, которая все неиспользуемые DLL-ки из памяти вытеснит. И следующий запуск .NET-прожки снова будет несколько секунд.

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

РД>>Но с другой стороны, идея обязательной сертификации — на мой взгляд здравая. Ибо задрали меня кривые дрова некоторых вендоров...
CC>Дык пока 32бит не вымрет (ну или хотяб 64 не будет доминировать) этот вендор и не почешется под 64 делать если его дрова не пропустят. А в результате кто больше всех пострадает? Юзер 64биток.

Ты все перевернул с ног на голову. Вот лично у меня железо 64-хбитное и для всех двух устройств, которые Виста не знает в лицо 64-хбитные драйвера имеются. Но стоит 32битная ОС, потому что ни одного бенефита от установки 64-хбитной я не вижу и не понимаю, зачем мне платить повышенным расходом памяти и тормозами при работе 32-хбитных приложений.
Вот сервера, там совсем другое дело. Тому же сиквелу возможность жрать больше 2-3 гигов оперативки весьма полезна. Поэтому отказ от 32-хбитных серверных ОС вполне логичен.

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

kuj>А Java тут при чем? Речь вроде шла о .NET, нет?

Речь шла о фреймворках, которые позволяют ускорить разработку приложений за счёт увеличенной тормознутости полученных приложений. .NET и Java — самые известные примеры, хотя наверняка есть и другие.

kuj>А вообще говоря, Java почти не используется для написания GUI-интерфейсов. Основная область применения — enterprise, web-морды и т.п.

А вот об этом не все в курсе. И немалое число любителей Джавы клепает на ней всё что ни попадя. Разве что драйвера пока не удосужились…

К>>А вот об этом поподробнее. Где об этом можно почитать? Что за прожка? Можно ли её применять к готовым чужим приложениям или только к самописным?

kuj>Утилита в составе .NET framework. Натравливаешь ее на любую .NET-сборку и она генерирует native image (на целевой машине). В итоге JIT-компиляции производиться не будет пока сборка неизменна (если подменить на другую версию image конечно станет invalid).

Спасибо, я не знал, что это стандартная от MS. Правда, толку от неё оказалось немного. Видимо, основное время занимает именно загрузка фреймворка, а не JIT.

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

kuj>>А Java тут при чем? Речь вроде шла о .NET, нет?

К>Речь шла о фреймворках, которые позволяют ускорить разработку приложений за счёт увеличенной тормознутости полученных приложений. .NET и Java — самые известные примеры, хотя наверняка есть и другие.

Все же мне не ясно где ты видишь тормознутость. Нет, конечно можно и на .NET и на Java писать так, что приложения будут тормозить, но и на C++ это тоже очень реально.

Быстрее разработка — больше времени будет на оптимизацию (если необходимо), а главное — больше времени на тщательное проектирование, что в конечном итоге положительно скажется на scalability приложения. Код же будет (с большой вероятностью) более качественный, а главное — хорошее покрытие юнит-тестами и слабые взаимосвязи между классами, что делает архитектуру гибкой и легко расширяемой, что ОЧЕНЬ важно, учитывая что в большинстве случаев нереально учесть все-все-все еще на этапе постановки задачи. Постоянно меняющиеся требования это бич в программировании, поэтому очень важно достичь максимальной гибкости архитектуры...

kuj>>Утилита в составе .NET framework. Натравливаешь ее на любую .NET-сборку и она генерирует native image (на целевой машине). В итоге JIT-компиляции производиться не будет пока сборка неизменна (если подменить на другую версию image конечно станет invalid).

К>Спасибо, я не знал, что это стандартная от MS. Правда, толку от неё оказалось немного. Видимо, основное время занимает именно загрузка фреймворка, а не JIT.

Я не знаю что у тебя там за проблемы с загрузкой... У меня штук пять мелких самописных тулзовин (консольные и GUI) после 2-3 запусков загружаются уже мгновенно.
Еще есть "толстый" клиент с довольно "навороченным" интерфейсом (на SQL Server 2005) — загружающий более 20 разных сборок, грузится по профайлеру ~2-3 секунды, остальные ~4-5 уходят на подключение и выборку данных из БД. Жалоб о производительности от пользователей пока не поступало, хотя крутится на довольно слабых компьютерах.

Ночной Смотрящий пишет:

> Ты все перевернул с ног на голову. Вот лично у меня железо 64-хбитное и
> для всех двух устройств, которые Виста не знает в лицо 64-хбитные
> драйвера имеются. Но стоит 32битная ОС, потому что ни одного бенефита от
> установки 64-хбитной я не вижу и не понимаю, зачем мне платить
> повышенным расходом памяти и тормозами при работе 32-хбитных приложений.

Зато 64-битные приложения потенциально могут работать значительно
быстрее 32-битных аналогов. Не знаю, правда, компиляторы уже подтянулись
или все еще тупят.

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

>> Ты все перевернул с ног на голову. Вот лично у меня железо 64-хбитное и
>> для всех двух устройств, которые Виста не знает в лицо 64-хбитные
>> драйвера имеются. Но стоит 32битная ОС, потому что ни одного бенефита от
>> установки 64-хбитной я не вижу и не понимаю, зачем мне платить
>> повышенным расходом памяти и тормозами при работе 32-хбитных приложений.

S>Зато 64-битные приложения потенциально могут работать значительно
S>быстрее 32-битных аналогов. Не знаю, правда, компиляторы уже подтянулись
S>или все еще тупят.

Смысл в 64-битной ОС появляется тогда, когда появляется необходимость в > 3.2GB доступного RAM.

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

kuj>Я не знаю что у тебя там за проблемы с загрузкой... У меня штук пять мелких самописных тулзовин (консольные и GUI) после 2-3 запусков загружаются уже мгновенно.

После 2-3 запусков у меня-то тоже почти мгновенно. Я об этом писал чуть выше по ветке

Автор: Константин
Дата: 29.05.08

… Проблема в недолговечности подобного "ускорения".

kuj>Еще есть "толстый" клиент с довольно "навороченным" интерфейсом (на SQL Server 2005) — загружающий более 20 разных сборок, грузится по профайлеру ~2-3 секунды, остальные ~4-5 уходят на подключение и выборку данных из БД. Жалоб о производительности от пользователей пока не поступало, хотя крутится на довольно слабых компьютерах.

И об этом тоже уже говорил (например, тут

Автор: Константин
Дата: 28.05.08

), что, если время загрузки фреймворка по сравнению с временем других старт-ап действий невелико, а особенности платформы на производительности основных операций сказываются не сильно, то можно и забить в угоду удобству разработки.