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

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

PD>>>Но я-то его писал для других целей. Не могу же я отвечать за использование моего цикла в иной ситуации.
G>>Какой иной ситуации. Ситуация та же — суммирование массива по столбцам. Только способ получения массива другой.

PD>Ничего себе! В одном (твоем случае) речь идет об операциях в памяти. В другом (моем) — системные вызовы. И массива как такового в памяти, между прочим, нет вообще
Алгоритм от этого не меняется. Адерстенд?

G>>Вообще изначально код ущербный был. Надо получить весь массив пикселей, а потом сумировать вместо GetPixel на каждой итерации.
PD>Если не секрет, чем это лучше ? Я вижу в этой идее только дополнительный массив, который тут совсем не нужен, и никаких плюсов.
Я думаю считать все пиксели в память а потом суммировать будет лучше.



G>>Согласен. Я вполне могу убрать оттуда и окно, и GetPixel, а просто предложить просуммировать столбцы некоего двумерного массива, каким-то образом заданного. Правда, чтобы время померить, придется либо в цикл это вставить, либо уж очень большой массив использовать.
G>>Кто же это писал???

PD>Я писал и я выделил сейчас то, на что ты внимание не обратил
Это мелочи. Измерять время можно с помощью rdtsc, программа от этого не изменится.

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

G>>Вообще изначально код ущербный был. Надо получить весь массив пикселей, а потом сумировать вместо GetPixel на каждой итерации.

PD>Если не секрет, чем это лучше ? Я вижу в этой идее только дополнительный массив, который тут совсем не нужен, и никаких плюсов.

Тем что быстрее. Функции GetPixel и SetPixel работают очень медленно, т.к. внутри себя вызвают BitBlt. Напрямую получить весь массив с той же BitBlt гораздо быстрее.

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

PD>Вообще-то об этом стоило бы сказать с самого начала.

var notparallel2 = from col in matrix2
             select col.Sum();

PD>А если придется идти и так и так, скажем, в алгоритмах линейной алгебры ?

Если задача будет другой, то и решение будет другим.

PD>А вообще это хоть как-то сделать можно с помощью LinQ ? Разумееется, без транспонирования матрицы и без заведения каких-бы то ни было дополнительных массивов любой размерности хоть явно, хоть неявно.

На этот вопрос уже отвечал AndrewVK. Можно. Пишете итератор и обходите. Хоть матрицу, хоть дерево, хоть граф. Отображаете, свертываете. Промежуточные массивы не создаются. Non strict семантика.

PD>А никакого.

Внезапно, прямой ответ. Благодарю.

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

PD>Я другое не понимаю. Почему, как только заходит речь о работе на пределе возможностей железа, так сразу начинается нечто в роде "да , сейчас это еще не очень, но вот лет через 10 будет..." Не знаю я, что через 10 лет будет, и мне это сейчас не так уж важно. Будет — тогда и говорить будем. А мне сейчас работать надо.

А с чего вообще все это обсуждение началось? Какой смысл говорить о том, что есть здесь и сейчас. Тут вообще никакого обсуждения не будет, голая статистика. Мы же говорим о "перспективе". И все наши "войны" в таком конктексте и начинаются — вытеснит ли C# через 10 лет С++? вытеснит ли Немерле через 10 лет C#? вытеснит ли юникс винду? и пр.
С твоей стороны можно было бы например показать что такая задача как "работа на пределе возможностей железа" будет существовать всегда, независимо от уровня развития этого железа (для меня, например, это далеко не очевидно).

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

ВВ>>Мне теоретический "суперкомплятор" неинтересен.
S>В таком случае я в очередной раз предлагаю отказаться от обсуждения теоретического ассемблерщика.

Я никогда и не писал, что "теоретического ассемблерщик" всех порвет по производительности. А писал, кстати, прямо противоположное. Ни с кем меня не путаете?

ВВ>>Развитие ASP.NETа — причем заметьте в понятие ASP.NET обычно вкладывается не технология "интеграции конвеера с IIS", а собственно web forms — это постепенное превращение его в чистой воды конструктор.
S>Мне всё равно, что именно вкладывается в это понятие обычно. Точно так же, как и то, что среднестатистический программист обычно только ухудшает код при первых попытках вставить что-то на ассемблере.

А может, стоит вообще забыть об ассемблере? Речь изначально о том, всегда ли есть abstraction gain, как вы говорите. А тут не надо далеко ходить — можно оставаться в рамках того же C#.

ВВ>>Программирование мышкой. В свое время над Дельфи за этой посмеивались. То же самое в ASP.NET — как вы сказали? — высокотехнлогичность или как там? Неувязочка получается, нет?
S>Программирование мышкой здесь ни при чем. Можно хоть подмышкой программировать, вопрос в том, какие возможности дает фреймворк, какой объем кода при этом нужно писать вручную, и какая при этом получается эффективность конечного решения.

"Программирование мышкой" — это практика, которая неизбежно влияет на квалификацию программиста. А объем кода, который необходимо писать вручную, в случае с АСП.НЕТ все равно остается немаленький, стоить лишь только отойти от стандартного способа работы с компонентами, что случается довольно часто. При этом получается забавная ситуация, что среднестатистический асп.нет-чик может не знать ни базовые вещи по работе с HTTP, не уметь работать с джава-скриптом и пр. Я человек сто наверное прособеседовал, так что можно уже статистику составлять.

ВВ>>Во-первых, сама по себе концепция веб-форм ущербна изначально.
S>Да.
ВВ>>Но что принпиально новое в нес ASP.NET? Чего добились создатели ASP.NET? Разделения логики и представления? Как бы не так. Ничем в сущности ASP.NET приложение не отличается от того же PHP. И там, и там одинаковая по большому счету свалка — только несколько иначе организованная. И там и там можно писать нормально, если уж очень захочется.
S>Щас прямо. PHP рядом не валялся.
ВВ>>А ведь в описанной выше технике не используется ничего специфичного для АСП.НЕТ. Ее при желании можно реализовать и на ПХП.
S>А ты попробуй — реализуй. И посмотри на то, сколько кода тебе для этого потребуется, и какое будет быстродействие.

А в чем проблема? Ты пробовал и получилось слишком медленно? И что являлось "бутылочным горлышком"? Типа база летала, странички были заоптимизированы, скрипты клиентские не тормозили, а тормозил конкретно интерпретируемый PHP?
А что с "количеством" кода? Надо много писать, чтобы вызвать XSLT-преобразование? В каких конкретно частях системы, при решение каких задач пришлось писать много кода?

ВВ>>Я так смотрю хамство — это нынче модный тренд на RSDN.
S>А ты перечитай свой предыдущий постинг, эстет ты наш.

А ты перечитай всю ветку сообщений, до как ты мне "отписался". Я утверждал, что abstraction gain есть не всегда, abstraction penalty — всегда. В ответ началось, извините, передергивание на тему теоретического комплятора, который "заоптимизирует" все насмерть, и АСП.НЕТ-а, который на ассемблере реализовать невозможно.
Говорите, Дворкин плохой? Утверждает, что абстракции это всегда плохо? А линия вашей партии чем отличается? Абстракции это всегда хорошо? Ну молодцы, да Я высказал более нейтральную точку зрения в постинге, который был, кстати, возражением Дворкину — и, что называется, "понеслась".
Что-то вместо "философии" программирования тут больше попахивает "религией".

S>>>Просто веб-сервер — это типичный пример высоконагруженного приложения.
ВВ>>Еще раз повторяю — причем здесь вообще ASP.NET? Каким образом ASP.NET вообще возникает при разговоре об ассемблере?
S>При том, что ASP.NET — лучший в мире фреймворк для веб-приложений.

Угу, при архитектуре, которая ущербна изначально. В каком страшном мире мы живем
Даже если он и лучший, это никак не отменяет того факта, что ASP.NET — [censored]. А про "инкарнации" ASP.NET в виде MOSS цензурно вообще ничего написать не получится.

ВВ>>Я в принципе понимаю, в чем ваша проблема. Не "ваша" конкретно, а вообще. Почему в принципе при разговоре об ассемблере возникает предложение написать на нем аналог ASP.NET приложения?
S>Ну а почему как начинается речь об управляемых языках — так сразу давайте матрицы умножать?
ВВ>>А правда в том, что есть задачи, в к-х abstraction не дает никаких gain-ов, одни penalty. И такие ситуации также реалистичны как и те, где введение уровня абстракции позволяет сделать приложение более производительным.
S>С этим никто и не спорил. На всякий случай напомню, что местная притча во языцех — Павел Дворкин, с юношеским задором объявлял повышение производительности за счет введения уровней абстракции нереалистичными.

И что мне с этого? Причем тут Дворкин? Я ему не родственник и не занимаюсь его апологией. Может, вместо того, чтобы приписывать мне чужие утверждения стоит мои сначала прочитать?

S>>>Как зачем? Чтобы рассуждения "теоретически, самый быстрый код — это написанный вручную на ассемблере" перестали быть голословными.
ВВ>>Большинство рассуждений здесь голословны. Про суперкомпляторы, которые никто не видел в глаза
S>Идем по ссылке, смотрим на суперкомпилятор джавы. В чем проблема?

Кто реально использует супер-компилятор для C#?

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

Дело не ассемблере или C#. Игры, пожалуй, единственный софт, который я знаю, который имеет тенденцию выживать самый максимум из железа, несмотря даже на мощность этого самого железа. И от того, насколько удачно они смогут провести это "соковыживание" зависит их конкурентноспособность, ибо встречают-то все-таки по одежке.
А в таких случаях "абстракции" противопоказаны.

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


ВВ>А с чего вообще все это обсуждение началось? Какой смысл говорить о том, что есть здесь и сейчас. Тут вообще никакого обсуждения не будет, голая статистика. Мы же говорим о "перспективе". И все наши "войны" в таком конктексте и начинаются — вытеснит ли C# через 10 лет С++?

Вообще-то обсуждение началось в текущем контексте, то есть как это сейчас хорошо. Что будет через 10 лет — это ИМХО обсуждать не стоит. Спроецируйся назад на 10 лет (1998г) и попробуй предсказать будущее. Я не уверен, что в этом предсказании .Net вообще бы оказалась.

>вытеснит ли Немерле через 10 лет C#?



>вытеснит ли юникс винду?



какого размера кремни будут в продаже ?

Если уж вопрос о 10 годах ставить, то я бы другое обсудить предложил

1. Сольются ли мобильные девайсы и настольные системы ?
2. Сольются ли телевидение и персональные компьютеры ? Останется ли "волновое" телевидение или только цифровое будет ?

И т.д. Впрочем, все равно получатся великолепно обточенные кремни

А прогнозы насчет языков и их будущего на 10 лет — дело ИМХО пустое. Придет время — увидим.

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

Будет ли она существовать всегда — не знаю. "Мне не нужна вечная игла, я не намерен жить вечно". Пока что как мощности ни росли, всегда находились задачи, которым этих мощностей не хватало. В науке их полно, а научные задачи имеют свойство превращаться в производственные. Но вообще эта тема слишком серьезная, чтобы за 5 минут дать развернутое объяснение.

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

PD>>Ничего себе! В одном (твоем случае) речь идет об операциях в памяти. В другом (моем) — системные вызовы. И массива как такового в памяти, между прочим, нет вообще
G>Алгоритм от этого не меняется. Адерстенд?

Если ты готов алгоритм без анализа применять где угодно — что тут скажешь...

G>Я думаю считать все пиксели в память а потом суммировать будет лучше.

А я так думаю, что введение лишнего массива без всякого обоснования не есть лучшее.



G>Это мелочи. Измерять время можно с помощью rdtsc, программа от этого не изменится.

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

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

КБ>Тем что быстрее. Функции GetPixel и SetPixel работают очень медленно, т.к. внутри себя вызвают BitBlt.

Можно ссылочку на источник, где говорится, что они вызывают BitBlt ? Куда она копирует ? Где второй HDC ?


>Напрямую получить весь массив с той же BitBlt гораздо быстрее.

BitBlt все-таки копирует битовую карту , а вовсе не возвращает биты. А получить биты можно, GetBitmapBits / GetDIBIts, но это совсем другая история

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

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

PD>>>Ничего себе! В одном (твоем случае) речь идет об операциях в памяти. В другом (моем) — системные вызовы. И массива как такового в памяти, между прочим, нет вообще
G>>Алгоритм от этого не меняется. Адерстенд?
PD>Если ты готов алгоритм без анализа применять где угодно — что тут скажешь...
Такое барахло как этот код сумрования я бы вообще в продакшн ен пустил.

G>>Я думаю считать все пиксели в память а потом суммировать будет лучше.
PD>А я так думаю, что введение лишнего массива без всякого обоснования не есть лучшее.
Добро пожаловать в настоящее, копромис время-память уже давно сместился в сторону времени, память теперь никто не жалеет. Ну может кроме тебя.



G>>Это мелочи. Измерять время можно с помощью rdtsc, программа от этого не изменится.
PD>Программа не изменится. Изменятся выводы, так как их нельзя делать на данных, которые не позволяют делать эти выводы. В общем,см. курс матстатистики — сравнение двух средних и т.д.
Это нельяз делать потому что нельзя... смешно.

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

PD>Вообще-то обсуждение началось в текущем контексте, то есть как это сейчас хорошо. Что будет через 10 лет — это ИМХО обсуждать не стоит.

Ну с позицией, что введение высокоуровневых абстракций рулит всегда и в любом случае я и сам не согласен. Эта проблема в общем-то не столько даже к асму сводится. Но очень частно они действительно рулят. И необязательно только в веб-приложениях
Высокоуровневый код легко написать и проще поддерживать, его проще масштабировать. А соответственно проще реализовать другое архитектурное решение, которое поможет нам улучшить производительность системы в целом. Ведь если наше приложение, скажем, не зависит от способа работы с хранилищем данных, то мы всегда сможем подменить это хранилище — скажем, прикрутить базу данных вместо файловой системы "напрямую" и пр. Причем "снаружи", для клиентского кода, эти изменения вообще останутся незаметными. И это нормальная ситуация, когда действительно проще "оптимизировать" высокоуровневую систему.

И такие ситуация происходят очень часто. А часто бывают и ситуации когда дешевле купить железо, а не заниматься оптимизацией криво спроектированного приложения. Причем все это может касаться также и систем с достаточно высокими требованиями к производительности. Причем даже безотносительно к "оптимизации" — удешевление разработки и поддержки это ведь реально круто. Часто выгоднее продать систему + наши железки, чем заоптимизированную до смерти систему на *ваши* железки.

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

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

G>Такое барахло как этот код сумрования я бы вообще в продакшн ен пустил.

Чудненько. Можешь еще заявить, что суммирование вообще есть барахло, а поэтому его и не надо делать. Или придумай другой способ суммирования.

G>>>Я думаю считать все пиксели в память а потом суммировать будет лучше.
PD>>А я так думаю, что введение лишнего массива без всякого обоснования не есть лучшее.
G>Добро пожаловать в настоящее, копромис время-память уже давно сместился в сторону времени, память теперь никто не жалеет. Ну может кроме тебя.

И поэтому надо без всякого смысла создавать новый массив и тратить время на его заполнение. Когда выбор идет между временем и памятью — это имеет смысл и решение может быть и в ту и в другую пользу. Когда же увеличивают и то и другое без всякого смысла — это уже иначе называется.


PD>>Программа не изменится. Изменятся выводы, так как их нельзя делать на данных, которые не позволяют делать эти выводы. В общем,см. курс матстатистики — сравнение двух средних и т.д.
G>Это нельяз делать потому что нельзя... смешно.

Да не смешно, а очень грустно, что элементарные понятия из матстатистики для тебя тайна за семью печатями.

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

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

Да не надо чересчур много про асм. Я вовсе не предлагаю на асме писать все. И на С++ не предлагаю. Вот попробуй найди, где я предлагаю сайты на C++ писать . Не говоря уж об асме . Это мои оппоненты предлагают C++ и асм похоронить.

ВВ>Высокоуровневый код легко написать и проще поддерживать, его проще масштабировать.

+1.

>А соответственно проще реализовать другое архитектурное решение, которое поможет нам улучшить производительность системы в целом.

Может быть, да. Но только может быть. Не всегда.

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

+1

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

+1

Как видишь, я согласился почти со всеми твоими доводами. А теперь начинается "но"

Все это верно — но до поры до времени. А точнее — когда есть запас подкожного жира. Иными словами, если работать можно не на пределе, а как бы это скахать... слегка помягче. Можно лишних 20-50 Мб скушать. Можно скорость иметь не 100%, а только 70, скажем. И т.д.

Если так — можно себе позволить несколько проиграть в настоящем, рассчитывая при этом получить некие преимущества в будущем. Реализовать не лучшее, зато более гибкое решение, которое в случае чего (новая аппаратура, новое ПО) позволит легче перейти к иному решению. Оно, это иное решение, опять-таки будет не оптимальным, но и его легче будет заменить решением 3 поколения. И т.д.

Если же подкожного жира нет, то всем этим приходится пренебречь. Решение будет плохо масштабируемо и плохо сопровождаемо — не потому, что оно плохо написано, а потому, что оно уж больно конкретно. К БД не перейдешь, там стоит явное чтение из файла да еще асинхронное, , а то и MMF, вместо абстракций НезнаюЧтоReader. Снаружи это будет очень даже заметным, так как придется и снаружи менять, и как бы не все. В общем, плохо во всем, кроме одного — это сейчас единственно возможное решение, потому что все остальные не дают нужной производительности.

И вот обстановка сложилась такая, что у вас этого подкожного жира много. Если что-то из нижесказанного будет обидным — заранее прошу извинения, я не хочу обижать.

Вот такой вопрос задам . Большинство сайтов , разрабатываемых средними программистскими группами — на каком числе физических компьютеров это работать будет ( я имею в виду, конечно, серверную часть, а на JS). Боюсь, что во многих случаях ответ будет прост — на одном. На сайте этой самой фирмы. И если это не Газпром и не IBM, то скорее всего у них будет один сервер, где все это и будет крутиться. Ну в крайнем случае кластер на несколько машин. И эти машины будут хорошими (подумаешь, выложить несколько тыс. долларов) и на них, вполне возможно, ничего, кроме этого сайта, и не будет работать.

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

И в этих условиях вы можете себе позволить от максимальной производительности отступить. Может даже аргументировать — мол, дешевле новый компьютер поставить. Можете про abstraction gain рассуждать. Верно. Есть у вас подкожный жир, можете позволить. И позволяя себе это, вы начинаете распространять свое видение на всю остальную область. А автор драйвера, к примеру, не имеет этого жира и не может себе ничего позволить — вторая машина тут ничего не даст, напишет он драйвер неэффективно — будет тормозить, и все. И я не могу.

Это раз. Но есть и два. Отношение к сопровождаемости и поддержке вообще зависит от того, о чем речь идет. В одном случае (те же сайты) — это очень важно, так как , действительно, кому нужен сайт. в котором нельзя произвести легко даже простое изменение при том. что автор давно уволился. Но есть и другие задачи, в которых это далеко не так важно. Иногда задача формулируется так, что по сути не предполагает модификаций, иногда модификации в ней легко предсказуемы и могут быть заложены как TODO еще при ее разработке. Мне кажется. что и в этом многие перегибают палку — пытаются распространить принципы, хорошо себя зарекомендовавшие, скажем, при разработке www-сайтов, на весь остальной программистский мир. Да, вас большинство, но из этого отнюдь не следует, что ваши боги есть боги для всех остальных


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

Я же тебе предлагал посчитать, что будет, если программа работает на сотне компьютеров, а ее работу удастся ускороить хотя бы в 5 раз. Ладно, посчитаю сам. Это значит, что вместо 100 компьютеров можно поставить 20. Считая стоимость компьютера за $1000, имеем 80 тыс долларов. Кому это 80 тыс за месяц работы платят ?

А если их не 100 ? А если вообще число компьютеров увеличить нельзя ? Под 1000 компьютеров придется ведь здание новое строить... А если и не надо все их в одном месте собирать, но придется к программе писать такое требование — RAM не менее 4 Гб, как минммум четырехядерный процессор ? Многие готовы выложить еще 1.5 тыс долларов , чтобы иметь возможность эту программу запустить ? На их компьютере она же не пойдет!


ВВ>И разговор о "тенденциях" возникает потому, что такой подход потихоньку распространяется. И даже появляется другой подход — описание программы в средствах бизнес-нотаций — как в каком-нибудь биз-толке — соединил стрелочками пару квадратиков — а на выходе у тебя уже соотвествующий код на "низкоуровневом" C#.

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

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

AVK>>Вобщем понятно, кода так и не будет. Приятно, когда твои предсказания сбываются .

PD>Очень дешевый прием, ты уж меня извини.

Дешевый примем это свалить в кусты вместо признания собственной неправоты.

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

ВВ>А в таких случаях "абстракции" противопоказаны.

Прочитай то, что я процитировал, еще раз. На всякий случай, если непонятно — Mono.Simd это та самая абстракция, которая, якобы, противопоказана.

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

PD>Если же подкожного жира нет, то всем этим приходится пренебречь. Решение будет плохо масштабируемо и плохо сопровождаемо — не потому, что оно плохо написано, а потому, что оно уж больно конкретно. К БД не перейдешь, там стоит явное чтение из файла да еще асинхронное, , а то и MMF, вместо абстракций НезнаюЧтоReader. Снаружи это будет очень даже заметным, так как придется и снаружи менять, и как бы не все. В общем, плохо во всем, кроме одного — это сейчас единственно возможное решение, потому что все остальные не дают нужной производительности.

Довод твоих оппонентов в том, что даже в таком случае высокоуровневое приложение может быть производительнее. Что если ты упрешься в ограничения "файлухи"? И она станет узким горлышком? А чтобы переделать все на БД, придется "все переписать", а сделать ты это не сможешь.
На мой взгляд эта одна из "крупиц истины" в вашем споре

PD>Вот такой вопрос задам . Большинство сайтов , разрабатываемых средними программистскими группами — на каком числе физических компьютеров это работать будет ( я имею в виду, конечно, серверную часть, а на JS). Боюсь, что во многих случаях ответ будет прост — на одном. На сайте этой самой фирмы. И если это не Газпром и не IBM, то скорее всего у них будет один сервер, где все это и будет крутиться. Ну в крайнем случае кластер на несколько машин. И эти машины будут хорошими (подумаешь, выложить несколько тыс. долларов) и на них, вполне возможно, ничего, кроме этого сайта, и не будет работать.

Ну вот тут ты не очень прав. Могу рассказать о своем опыте. Я архитектор. Контора в основном специализируется на крупных клиентах (ибо с ними банально работать проще). Один клиент, с к-м я работал, крупный мобильный оператор. Там интранет, интеграция MOSS. Load balancing на всех staging серверах. При этом приложение глобальное — доступно всем сотрудникам компании в т.ч. и в регионах. MOSS — это ASP.NET в худшем его проявлении.
Вторая компания — нефтяной гигант с английскими корнями. Число только прямых сотрудников более 100 тыс. С "непрямыми", к к-м отношусь и я, больше, пожалуй, на порядок. Разрабатывали портальный движок, он внедрен в нескольких странах. Даже количество внедрений в рамках одной стороны сейчас уже приближается к десяткам — "внедрение" означение среду с всей цепочкой staging серверов. Портальный движок реализован еще на .NET 1.1. Основной "паттерн" использования — что-то вроде веб-десктопа для пользователя. Т.е. у сотен тысяч пользователей он грузится всякий раз когда они открывают браузер в кач. домашней страницы.
По производительности — тестили — тупо упиравается в оракловый кластер.

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

А что по твоему в крупных компаниях? В крупных компаниях WebShpere портал, Sharepoint и пр. В компанию на букву "Г" тоже недавно продали приложение под MOSS, кстати. И ничего, крутится у них все.

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

А мы еще и железо продаем Если подкожного жира нет, то его надо нарастить.

PD>Это раз. Но есть и два. Отношение к сопровождаемости и поддержке вообще зависит от того, о чем речь идет. В одном случае (те же сайты) — это очень важно, так как , действительно, кому нужен сайт. в котором нельзя произвести легко даже простое изменение при том. что автор давно уволился. Но есть и другие задачи, в которых это далеко не так важно. Иногда задача формулируется так, что по сути не предполагает модификаций, иногда модификации в ней легко предсказуемы и могут быть заложены как TODO еще при ее разработке. Мне кажется. что и в этом многие перегибают палку — пытаются распространить принципы, хорошо себя зарекомендовавшие, скажем, при разработке www-сайтов, на весь остальной программистский мир. Да, вас большинство, но из этого отнюдь не следует, что ваши боги есть боги для всех остальных

Честно, ни разу не встречался с "сайтами", которые не предполагают модификаций.

ВВ>>И такие ситуация происходят очень часто. А часто бывают и ситуации когда дешевле купить железо, а не заниматься оптимизацией криво спроектированного приложения.
PD>Я же тебе предлагал посчитать, что будет, если программа работает на сотне компьютеров, а ее работу удастся ускороить хотя бы в 5 раз. Ладно, посчитаю сам. Это значит, что вместо 100 компьютеров можно поставить 20. Считая стоимость компьютера за $1000, имеем 80 тыс долларов. Кому это 80 тыс за месяц работы платят ?

Компания-интегратор далеко не такие счеты тебе выставит И далеко не месяц насчитает
Ты правда думаешь, что в Газпроме сто компов не купят?

PD>А если их не 100 ? А если вообще число компьютеров увеличить нельзя ? Под 1000 компьютеров придется ведь здание новое строить...

Здание не надо строить. Купил сервера у IBM, ну там и запарковал их. У IBM места хватит, это их бизнес.

PD>А если и не надо все их в одном месте собирать, но придется к программе писать такое требование — RAM не менее 4 Гб, как минммум четырехядерный процессор ? Многие готовы выложить еще 1.5 тыс долларов , чтобы иметь возможность эту программу запустить ? На их компьютере она же не пойдет!

Ни к одному из приложений, к-е мы разрабатывали не приходилось такие требования писать. Мы все еще о вебе говорим?

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

Не знаю о программах расчета погоды, но сдается мне, что представлениях о многих типах задач у тебя не совсем верное.

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

ВВ>>А в таких случаях "абстракции" противопоказаны.
AVK>Прочитай то, что я процитировал, еще раз. На всякий случай, если непонятно — Mono.Simd это та самая абстракция, которая, якобы, противопоказана.

А такая абстракция как отсутствие прямого доступа к памяти не помешает в реализации движка, как думаешь?

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

ВВ>Довод твоих оппонентов в том, что даже в таком случае высокоуровневое приложение может быть производительнее. Что если ты упрешься в ограничения "файлухи"? И она станет узким горлышком? А чтобы переделать все на БД, придется "все переписать", а сделать ты это не сможешь.

Ну во-первых, еще вопрос, что тут быстрее будет. Лично мне как раз пришлось свой файл писать, так как с SQL скорости были недостаточны. Почему ты считаешь, что я должен в них упереться ? Я , в общем-то, знаю, что от нее можно ожидать. Кстати, когда я этот свой собственный файл писал (псевдо-БД) подход мой был таков — я не могу сделать время чтения с диска сколь угодно малым, не от меня это зависит, но остальное от меня зависит, и время должно быть сведено почти к нулю. Что я и сделал, 10-20 мсек. Так что это решение станет неэффектиынм только если резко изменится скорость работы БД vs скорость файловой системы, что маловероятно, так как БД все же поверх ФС работают.

Но не в этом даже дело. Мне надо было максимальную скорость обеспечить. Сейчас. А через 5 лет — не так уж важно. Такая вот ситуация.


ВВ>На мой взгляд эта одна из "крупиц истины" в вашем споре

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

ВВ>Ну вот тут ты не очень прав. Могу рассказать о своем опыте. Я архитектор.

<skipped>

Я же не говорю — все. Я лишь о некоторой средней ситуации говорю. Мне прилось около года участвовать в создании нескольких сайтов небольших компаний, вот и все.

ВВ>Вторая компания — нефтяной гигант с английскими корнями.

Так гигант все же . Я не спорю, есть и такие задачи. Но увы, большинство все же не работает с гигантами в 100000 человек

ВВ>А что по твоему в крупных компаниях? В крупных компаниях WebShpere портал, Sharepoint и пр. В компанию на букву "Г" тоже недавно продали приложение под MOSS, кстати. И ничего, крутится у них все.
ВВ>А мы еще и железо продаем Если подкожного жира нет, то его надо нарастить.

Я не против, но вроде мы не тебя обсуждаем и не твою фирму

PD>>Это раз. Но есть и два. Отношение к сопровождаемости и поддержке вообще зависит от того, о чем речь идет. В одном случае (те же сайты) — это очень важно, так как , действительно, кому нужен сайт. в котором нельзя произвести легко даже простое изменение при том. что автор давно уволился. Но есть и другие задачи, в которых это далеко не так важно. Иногда задача формулируется так, что по сути не предполагает модификаций, иногда модификации в ней легко предсказуемы и могут быть заложены как TODO еще при ее разработке. Мне кажется. что и в этом многие перегибают палку — пытаются распространить принципы, хорошо себя зарекомендовавшие, скажем, при разработке www-сайтов, на весь остальной программистский мир. Да, вас большинство, но из этого отнюдь не следует, что ваши боги есть боги для всех остальных

ВВ>Честно, ни разу не встречался с "сайтами", которые не предполагают модификаций.

Василий, прочти внимательно. что я написал. Я же именно это и сказал — что такой сайт не нужен.

ВВ>>>И такие ситуация происходят очень часто. А часто бывают и ситуации когда дешевле купить железо, а не заниматься оптимизацией криво спроектированного приложения.
PD>>Я же тебе предлагал посчитать, что будет, если программа работает на сотне компьютеров, а ее работу удастся ускороить хотя бы в 5 раз. Ладно, посчитаю сам. Это значит, что вместо 100 компьютеров можно поставить 20. Считая стоимость компьютера за $1000, имеем 80 тыс долларов. Кому это 80 тыс за месяц работы платят ?

ВВ>Компания-интегратор далеко не такие счеты тебе выставит И далеко не месяц насчитает

И что ? Это как-то опровергает мой расчет ?

ВВ>Ты правда думаешь, что в Газпроме сто компов не купят?

Ну здравствуйте! Я же не об этом, нетрудно же понять. Я просто о том. что в данном случае оптимизировать программу куда выгоднее, чем 100 компов купить.

PD>>А если их не 100 ? А если вообще число компьютеров увеличить нельзя ? Под 1000 компьютеров придется ведь здание новое строить...

ВВ>Здание не надо строить. Купил сервера у IBM, ну там и запарковал их. У IBM места хватит, это их бизнес.

Психология web-программирования неистребима . Предложи Газпрому поставить свои компьютеры в IBM

PD>>А если и не надо все их в одном месте собирать, но придется к программе писать такое требование — RAM не менее 4 Гб, как минммум четырехядерный процессор ? Многие готовы выложить еще 1.5 тыс долларов , чтобы иметь возможность эту программу запустить ? На их компьютере она же не пойдет!

ВВ>Ни к одному из приложений, к-е мы разрабатывали не приходилось такие требования писать. Мы все еще о вебе говорим?

Нет. О моих задачах.

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

ВВ>Не знаю о программах расчета погоды, но сдается мне, что представлениях о многих типах задач у тебя не совсем верное.

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

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

ВВ>>Довод твоих оппонентов в том, что даже в таком случае высокоуровневое приложение может быть производительнее. Что если ты упрешься в ограничения "файлухи"? И она станет узким горлышком? А чтобы переделать все на БД, придется "все переписать", а сделать ты это не сможешь.

PD>Ну во-первых, еще вопрос, что тут быстрее будет. Лично мне как раз пришлось свой файл писать, так как с SQL скорости были недостаточны. Почему ты считаешь, что я должен в них упереться ?

Задачи есть разные. Где-то будет БД быстрее, где прямая работа с файлухой. Но это даже неважно. Можем "перевернуть" пример. Вот написал ты приложение через БД, а потом понимаешь что напрямую через ФС будет побыстрее.

PD>Я же не говорю — все. Я лишь о некоторой средней ситуации говорю. Мне прилось около года участвовать в создании нескольких сайтов небольших компаний, вот и все.

То, что творится в небольших компаниях одному богу известно. Я вот завтра организую фирмы и поставлю сотрудникам 386-е.

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

А с какими "гигантами" работает большинство? Это крупные предприятия, банки и пр. Ну не 100, но тысячи человек.

ВВ>>А что по твоему в крупных компаниях? В крупных компаниях WebShpere портал, Sharepoint и пр. В компанию на букву "Г" тоже недавно продали приложение под MOSS, кстати. И ничего, крутится у них все.
ВВ>>А мы еще и железо продаем Если подкожного жира нет, то его надо нарастить.
PD>Я не против, но вроде мы не тебя обсуждаем и не твою фирму

А любая фирма поступит также. Мы что ли свою уникальную нишу нашли? Или уж по крайней мере вендоры софта и железа будут рука об руку. Потому что, ты представляешь, вендорам железа тоже надо как-то свои железки продавать.

PD>>>Это раз. Но есть и два. Отношение к сопровождаемости и поддержке вообще зависит от того, о чем речь идет. В одном случае (те же сайты) — это очень важно, так как , действительно, кому нужен сайт. в котором нельзя произвести легко даже простое изменение при том. что автор давно уволился. Но есть и другие задачи, в которых это далеко не так важно. Иногда задача формулируется так, что по сути не предполагает модификаций, иногда модификации в ней легко предсказуемы и могут быть заложены как TODO еще при ее разработке. Мне кажется. что и в этом многие перегибают палку — пытаются распространить принципы, хорошо себя зарекомендовавшие, скажем, при разработке www-сайтов, на весь остальной программистский мир. Да, вас большинство, но из этого отнюдь не следует, что ваши боги есть боги для всех остальных
ВВ>>Честно, ни разу не встречался с "сайтами", которые не предполагают модификаций.

PD>Василий, прочти внимательно. что я написал. Я же именно это и сказал — что такой сайт не нужен.

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

ВВ>>>>И такие ситуация происходят очень часто. А часто бывают и ситуации когда дешевле купить железо, а не заниматься оптимизацией криво спроектированного приложения.
PD>>>Я же тебе предлагал посчитать, что будет, если программа работает на сотне компьютеров, а ее работу удастся ускороить хотя бы в 5 раз. Ладно, посчитаю сам. Это значит, что вместо 100 компьютеров можно поставить 20. Считая стоимость компьютера за $1000, имеем 80 тыс долларов. Кому это 80 тыс за месяц работы платят ?
ВВ>>Компания-интегратор далеко не такие счеты тебе выставит И далеко не месяц насчитает
PD>И что ? Это как-то опровергает мой расчет ?

Железо купить дешевле.

ВВ>>Ты правда думаешь, что в Газпроме сто компов не купят?
PD>Ну здравствуйте! Я же не об этом, нетрудно же понять. Я просто о том. что в данном случае оптимизировать программу куда выгоднее, чем 100 компов купить.

Да не выгоднее. Никто не разрабатывает "уникальные" программы с повышенными требованиями к железу. 99% решений для корпоративного обладают такими требованиями. Эксчендж-сервер, шарепоинт и пр. Ты предлагаешь весь софт переделывать под древние железки? И считаешь, что это будет дешевле?

PD>>>А если их не 100 ? А если вообще число компьютеров увеличить нельзя ? Под 1000 компьютеров придется ведь здание новое строить...
ВВ>>Здание не надо строить. Купил сервера у IBM, ну там и запарковал их. У IBM места хватит, это их бизнес.
PD>Психология web-программирования неистребима . Предложи Газпрому поставить свои компьютеры в IBM

Ну да. BP вот религия позволяет сервера у IBM парковать. Видимо, там "веб-программисты" руководящие посты занимают

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

ВВ>А такая абстракция как отсутствие прямого доступа к памяти не помешает в реализации движка, как думаешь?

Так он присутствует.