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

CC>Ну с руками разработчика пакета офис2007 мне и так все ясно. Про 2003 лучше расскажи.

2003 давно нет, апдейт для открывания новых версий себя не оправдал. К тому же ограничения на размер таблицы Excel имели не последнее значение.

CC>К томуж ты рассказывал про то, что на серверах с ресурсами — хоть попой жуй. Собственно ожидался такой же обстоятельный рассказ что и как с доступными ресурсами на десктопах.

Не ресурсы вообще, процессор. На дектопах, с появлением дешёвых многоядерных процессоров, ситуация если не такая, то очень скоро станет такой.

CC>Скажи честно, ты разве в моих постах что нибудь подобное читал? Я не знаю кто тебе рассказывал про "качество Буст и гений Александреску".

Извини, лично ты мне этого не говорил. Просто изначальный пост не был ответом кому-то конкретно, а скорее протест простив многих некорректных сообщений. В последующих постах это немного осталось. я постараюсь отвечать только тебе или явно обговаривать, когда отвечаю не на твою реплику.

A>>но реальная жизнь показывает что Си++ программы в большинстве своём — говно, как впрочем большинство программ вообще, и использование Си++ не улучшает программу.
CC>
CC>Если поменять в этой фразе "C++" на любой другой достаточно распространенный язык то ничего не изменится. Програмы в своем большинстве говно безотносительно языка или ОС.

Почти так. Есть компромисы. Ява и .Net медленее, чем Си++ но некоторый пласт ошибок, возможный в Си++ программе благодаря кривым рукам программиста, не возможен в C# программе. Обратное тоже верно, но присутсвует в существенно меньшем объёме. Собственно потому C# и лучше: не отдельно по каждому пункту, а в общем зачёте. Когда нужен конкретный пункт, ситуация меняется.

CC>А ты их используй. Проги запускай, которые что нить полезное делают. А если компом не пользоваться то будут простаивать, да.
CC>Разумеется у меня проц тоже не загружен если я сижу и на комп просто смотрю. А вот если проц используется, то прога, которая ведет себя с ресурсами как с бесплатными очень быстро начинает мешать другим.

Visual Studio, VMWare Workstation хватит? 4 ядра сложно загрузить даже на половину.

CC>2003:
CC>Нету там в таскманагере поля Free.
CC>Есть только:
CC>Total: 2 096 620
CC>Available: 1 452 704
CC>System cache: 516 920

CC>Больше всего жрут янус и запущенная 2005я вижуалка: оба .NET процессы по утверждению ProcXP
CC>Janus.exe Virtual: 470 080 K WS: 79 280 K Private: 156 552 K
CC>devenv.exe Virtual: 468 168 K WS: 51 688 K Private: 145 660 K

Сверни их и так проверь. Кстати devevn.exe это Си++ приложение большей частью, просто в нём хоститься runtime ради дизайнера и прочей мелочёвки.

что касается памяти...
Вот тут со скриншотами
http://www.codinghorror.com/blog/archives/000688.html

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

a> Cредняя загрузка серверного процессора — 5%. Всё упирается в диски и сетевой интерфейс. Ввод вывод через 4Гбит оптику и 2Гбит сетевухи (2 в teaming) не могут на 100% нагрузить процессор. Генерировать осмысленный набор данных подобного объёма тоже нельзя.

Это все здорово, пока серверов в стойке меньше десятка. Потом тебе твои 32 CPU в каждом из них могут аукнуться толстой-толстой граблей.

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

AB>Это все здорово, пока серверов в стойке меньше десятка. Потом тебе твои 32 CPU в каждом из них могут аукнуться толстой-толстой граблей.

А много задач, где надо больше 10 серверов? Ну кроме захвата мира и конкуренции с Гуглом.

Lloyd wrote:

>>> Сколько у тебя занимает загрузка твоей системы?
> S>Не засекал, но явноо быстрее висты на том-же компе. Чтото около 30-40 секунд.

> Не так уж и быстро. Это out-of-box или специально тюнил?
Да нет, ничего вроде специально не тюнил... Напротив, вырубил параллельный старт сервисов изза того что некрасиво потом процесс загрузки отображается — по две записи на сервис
(стартует... стартовал успешно...)

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

g> AB>Не вопрос. Откомпилируй свой код на C# под Linux. Желательно, чтобы на выходе получилось "кросплатформенное десктопное приложение, в том числе с неплохой производительностью".
g> Я разработкой для десктопов не занимаюсь. Если бы понадобилось писать что-то для десктопов, потенциально работающее на разных платформах, то взял бы mono.

Под веб разрабатываешь? Тем интереснее. Apache + mod_mono + кросс-браузерная верстка. Твой текущий код на C# взлетит?

g> Далеко не всем приложениям нужна кросплатформенность.

Мы сейчас обсуждаем не это. Когда кросс-платформенность не нужна, то про моно вообще не вспоминают.

g> В случае RDP/VNC/SSH/etc пользователю не пофиг так как он сталкивается с особенностями ОС при таком подходе.
g> При использовании веб-приложений не сталкивается вообще.

У меня не работает Гугл.Блокнот, например (потому что гугл не удосужился выпустить версию под мой браузер). Или пресловутый Silverlight (потому что ОС не та). В веб-приложениях, помимо ограничений ОС добавляются еще и ограничения браузеров.

g> Не хотите — не пишите под моно, вас же никто не заставляет.

Как эта фраза соотносится с обсуждаемой темой?

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

a> AB>Это все здорово, пока серверов в стойке меньше десятка. Потом тебе твои 32 CPU в каждом из них могут аукнуться толстой-толстой граблей.
a> А много задач, где надо больше 10 серверов? Ну кроме захвата мира и конкуренции с Гуглом.

Их есть в гораздо меньших масштабах.

Когда у тебя в распоряжении мощный сервер, то это явно тебя не стимулирует к написаню масштабируемого проекта и обычно думают, что тех самых "640 килобайт" хватит на все и навсегда.

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

AB>Их есть в гораздо меньших масштабах.
AB>Когда у тебя в распоряжении мощный сервер, то это явно тебя не стимулирует к написаню масштабируемого проекта и обычно думают, что тех самых "640 килобайт" хватит на все и навсегда.

Антон, вот какие-то у тебя не такие аргументы. На серверах заканчивается не память. Хочешь открою секрет? Оперативки сейчас на серверах очень много, гораздо больше чем надо. Настолько много, что например самые обыкновенные HPшные блейды поддерживают RAID-1 на оперативке. Втыкаешь её в 2 раза больше чем надо и сгоревшая планка перестаёт быть проблемой. Сечёшь тенденцию?

Заканчивается пропускная способность дисков и сетевой карты. На серверах, объективно, больше ничего не заканчивается, если архитектор не козёл.

A> Оперативки сейчас на серверах очень много, гораздо больше чем надо. Настолько много, что например самые обыкновенные HPшные блейды поддерживают RAID-1 на оперативке.

Более того, память настолько не проблема, что в ней хранят целые базы данных (используя сжатие столбцов в SqlServer). Выйгрыш в производительности себя оправдывает.
Был на эффектной презентации: в начале человек показывает SSMS и запрос к базе, где хранятся все sales компании. Запускает выполнение, бублик закрутился. Человек проводит презентацию, а запроса все еще работает. А потом он выполняет то же самое для базы в памяти: клик-бум, готово.

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

a> Антон, вот какие-то у тебя не такие аргументы. На серверах заканчивается не память.

Да я не про память, просто цитата. Поставь вместо памяти что хочешь.

a> Заканчивается пропускная способность дисков и сетевой карты. На серверах, объективно, больше ничего не заканчивается, если архитектор не козёл.

Вот я и писал о том, что твое высказывание верно только для маленького числа серверов (тут я ошибся, надо было написать "оборудования") в стойке.

Потому как по поводу "козлов-архитекторов" (как ты их назвал) существует и противоположное мнение, кторое гласит о том, что если на сервере нельзя загрузить процессор (т.е. узким горлышком являются диски, сеть и т.д.), то сервис спроектирован плохо.

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

a>> Антон, вот какие-то у тебя не такие аргументы. На серверах заканчивается не память.

AB>Да я не про память, просто цитата. Поставь вместо памяти что хочешь.

a>> Заканчивается пропускная способность дисков и сетевой карты. На серверах, объективно, больше ничего не заканчивается, если архитектор не козёл.

AB>Вот я и писал о том, что твое высказывание верно только для маленького числа серверов (тут я ошибся, надо было написать "оборудования") в стойке.

AB>Потому как по поводу "козлов-архитекторов" (как ты их назвал) существует и противоположное мнение, кторое гласит о том, что если на сервере нельзя загрузить процессор (т.е. узким горлышком являются диски, сеть и т.д.), то сервис спроектирован плохо.

Чаще всего узким местом является не память, а, собственно, дисковая подсистема.
Памяти чисто количественно с избытком сейчас.

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

c> Чаще всего узким местом является не память, а, собственно, дисковая подсистема.
c> Памяти чисто количественно с избытком сейчас.

Данные с диска часто можно подкачать в память (особенно когда ее много) и дисковая подсистема будет курить (потихоньку скидывая данные в логи).

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

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

c>> Чаще всего узким местом является не память, а, собственно, дисковая подсистема.
c>> Памяти чисто количественно с избытком сейчас.

AB>Данные с диска часто можно подкачать в память (особенно когда ее много) и дисковая подсистема будет курить (потихоньку скидывая данные в логи).

А как быть с записью на диски данных СУБД? Там не кэшируется запись. Можно использовать только кэш контороллера с батарейным питанием — и все.

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

_> А как быть с записью на диски данных СУБД? Там не кэшируется запись. Можно использовать только кэш контороллера с батарейным питанием — и все.

Ну тут мы сейчас уйдем в частности скорее всего, т.к. начинает играть роль что/как/куда/с_какой_скоростью пишешь. В контексте большой памяти можно вспомнить, например, про NDB Cluster — диски продолжают курить или неспешно записывать снапшоты.

Здравствуйте, abibok, Вы писали:
A>Более того, память настолько не проблема, что в ней хранят целые базы данных (используя сжатие столбцов в SqlServer). Выйгрыш в производительности себя оправдывает.
A>Был на эффектной презентации: в начале человек показывает SSMS и запрос к базе, где хранятся все sales компании. Запускает выполнение, бублик закрутился. Человек проводит презентацию, а запроса все еще работает. А потом он выполняет то же самое для базы в памяти: клик-бум, готово.
Ага. А еше народ начинает получать шок от экспериментов с SSD для Gemstone и IODrive для SQL Server.

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

A>Увы и ах, но не зависит. Никаких преимуществ у Си++ перед C# кроме зачатков метапрограммирования (которых, скажу честно, не хватает порой) большей скорости работы специфических операций нет. Разработчик не может быть более продуктивным на Си++, чем на C#, точно так же как он может быть более продуктивным на Си, чем на Си++.

У C# нет никаких зачатков метапрограммирования, есть зачатки функционального программирования. А что самое смешно, лично я гораздо более продуктивнее на C++, чем на C#, парадокс Может тут дело скорее всего в опыте, на С++ я писал больше 10-ти лет, а на C#'е писал последние года 2-3...

Недавно делал заказ, мелкий, на месяц работы, на С++. В качестве ГУИ надо было использовать MFC, а как БД надо было использовать MySQL. Почему-то незнаю почему, но у меня в голове сидела такая мысль (наверное отчасти из-за этого форума ), что работать с БД на C++, это самоубийство. Ну и давненько на C++ не писал. На практике оказалось совсем все наоборот, легко и просто, я аж удивился. Закончил за полмесяца работу. Ни одного Access Violation, ни одной утечки памяти, была одна логическая ошибка, но я ее быстро подправил. По мере работы, охватывали ностальгические чувства Вообщем, я получил от этой работы своего рода оргазм растянутый на месяц

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

A>Почему дискуссия о .Net всегда выливается в какой-то пиписькометрический бред людей из альтернативной реальности? Причём на это ведуться те кто .Net защищает.

Меня одно удивляет — за каким богом уважаемые программисты на .Net каждый раз бросаются на ее защиту ? Скажет кто-нибудь слово о ее недостатках — и с пеной у рта ее адепты начинают опровергать. А то и просто так, без всяких нападок, как уважаемый Werig ни с того ни с сего начал. При этом в сотый раз повторяются одни и те же аргументы, которые в сотый раз убеждают тех, кто в этом и так убежден и не действуют на тех, кто с этим не согласен.

"Добродетель, которая нуждается в защите, едва ли стоит того, чтобы ее защищать" (C) не помню чей.

Pavel Dvorkin wrote:

> Меня одно удивляет — за каким богом уважаемые программисты на .Net каждый раз бросаются на ее защиту ?
Видимо всетаки точит червь сомнения их бессмертные души

yumi wrote:

> Недавно делал заказ, мелкий, на месяц работы, на С++. В качестве ГУИ надо было использовать MFC, а как БД надо было использовать MySQL. Почему-то незнаю почему, но у меня в голове
сидела такая мысль (наверное отчасти из-за этого форума ), что работать с БД на C++, это самоубийство. Ну и давненько на C++ не писал. На практике оказалось совсем все наоборот,
легко и просто, я аж удивился. Закончил за полмесяца работу. Ни одного Access Violation, ни одной утечки памяти, была одна логическая ошибка, но я ее быстро подправил. По мере работы,
охватывали ностальгические чувства Вообщем, я получил от этой работы своего рода оргазм растянутый на месяц

Вот и я об чем....
Не С++ плохой, а сила внушения довольно велика у микрософтовцев.

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

Y>Недавно делал заказ, мелкий, на месяц работы, на С++. В качестве ГУИ надо было использовать MFC, а как БД надо было использовать MySQL. Почему-то незнаю почему, но у меня в голове сидела такая мысль (наверное отчасти из-за этого форума ), что работать с БД на C++, это самоубийство. Ну и давненько на C++ не писал. На практике оказалось совсем все наоборот, легко и просто, я аж удивился. Закончил за полмесяца работу. Ни одного Access Violation, ни одной утечки памяти, была одна логическая ошибка, но я ее быстро подправил. По мере работы, охватывали ностальгические чувства Вообщем, я получил от этой работы своего рода оргазм растянутый на месяц

После слов про затянувшийся оргазм, прям таки напрашивается аналогия с той педалирующей мышкой

y> У C# нет никаких зачатков метапрограммирования, есть зачатки функционального программирования. А что самое смешно, лично я гораздо более продуктивнее на C++, чем на C#, парадокс Может тут дело скорее всего в опыте, на С++ я писал больше 10-ти лет, а на C#'е писал последние года 2-3...

y> Ни одного Access Violation, ни одной утечки памяти, была одна логическая ошибка, но я ее быстро подправил. По мере работы, охватывали ностальгические чувства Вообщем, я получил от этой работы своего рода оргазм растянутый на месяц

Выделенное выше играет очень большую роль