Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Гм. Вообще-то не вижу связи между кривой архитектурой и языком.
А связи и нет. Приложение, которое тормозит, это в 99.99% случаев неправильно спроектированное приложение, а не приложение, к-е тормозит, потому что его реализовали с использованием средств разработки, вносящих большой "оверхед".
>>Что в осном народ-то пишет? Бизнес-приложения, распределенные приложения, всякие там корпоративные шины и проч., веб-сервисы и другую подобную дрянь. Там совсем другие проблемы возникают, на другом уровне. Если, к примеру, у тебя плохо продумана связь с каким-нибудь нодом, идет слишком частый обмен пакетами, некорректно обрабатывается таймаут нода, нет кэширования и пр. — тебе тут не поможет переделка твоего приложения на более низкоуровневый асм. PD>+100. Безусловно верно. Насчет "дряни" — я бы не стал так говорить, все задачи имеют право на существование.
"Дрянь" — это любя
ВВ>>А теперь представь — вот люди пишут всякие ESB, передают тонны ХМЛя (ХМЛя, понимаешь? ), а ты их пытаешься убедить, что "существуют задачи, для решения которых использование высокоуровневых средств... неэффективно и нецелесообразно". Как на фиг высокоуровневые средства, у нас сплошной ХМЛ, блин PD>Со всем можно согласиться, но... Есть же задачи, в которых нет тонн XML и т.д. Пусть их становится меньше (меньше в каком смысле — меньше количество програмистов, ими занимающихся или меньше их роль ? со вторым не согласен, первое бесспорно).
Меньше роль или больше роль — это философия. Таких задач становится меньше по количеству. То, что раньше реализовывали только на асме, сейчас могут делать на более высокоуровневых средствах, чуть ли не на C#.
Понятно, что те задачи, которые по-прежнему решают с помощью низкоуровневных средств супер важные. Управление буровыми, космическими кораблями и пр. — кто ж будет отрицать роль всего этого? Только вот надо понимать, что лет через -надцать та же джава действительно полетит в космос.
PD>Проблема же в том, что адепты этих новых технологий претендуют на их универсальность для всех задач.
Я не слышал заявления типа "что C# позволяет решить любую задачу по разработке". Может, пропустил? Но дело-то не в C#. Дело в том, что в перспективе ЯВУ типа C# или Немерле действительно позволит решать любую задачу.
ВВ>>И будет еще меньше. Сейчас у банальной игровой приставки — под которую игры выпускают, кстати, в "обрезанном" по сравнению с PC варианте — прозводительность терафлопами мерится. О чем тут можно говорить-то? Какой асм?
PD>Не знаю насчет игровых приставок, а вот в моей задаче асм будет на днях. Не в чистом виде, а через intrinsic. Для реализации SSE2. Распараллеливание, так сказать, на одном процессоре, и даже без всяких потоков. Тест показал примерно 3.5- кратный выигрыш
А что за задача? Можно по-подробнее? Только подробности не в стиле, что нужно писать используя опредленные инструкции процессора, а бизнес-формулировка задачи какая?
ВВ>>Собственно, такова позиция твоих оппонентов, как я ее понимаю. И я с ней согласен. А вот твою позицию я не очень понимаю. Какой смысл все сводить к тому, что "есть задачи для к-х асм подходит"? Ну да, пока еще есть. Но мне действительно кажется, что ты переоцениваешь роль и количество таких задач. PD>Из того, что большинство задач — это задачи бизнеса, еще не следует, что все остальное вымирает.
Павел, все задачи — это задачи бизнеса! Ты что, в стране ОЗ находишься? Это если, конечно, не рассматривать развлечения гиков по вечерам — но тут, как говорится, любые средства хороши. И бизнесу дешевле тратиться на железо, чем на разработку супер-производительного софта на этом железе. И это реальность. Софт на дотнете стоит дешево. Железо стоит дешево. Разработка/поддержка на асме — дорого. Зачем платить больше?
У меня кот есть. Он очень любит, когда его по шерсти гладят, и очень не любит, когда против шерсти или даже поперек шерсти
G> for (int x = pChunk->xStart; x <= xEnd; x++) G> { G> unsigned s = 0; G> for ( int y = 0; y < nHeight; y++) G> { G> s += matrix[x + y * matrixWidth];//! G> } G> columnSum[x] = s; G> }
Я-то в оригинальном своем примере GetPixel суммировал, там все равно, как суммировать, время, на GetPixel требуемое, все перекроет. А ты за память взялся. И расположил ты эту матрицу по строкам, как все сейчас делают. А вот доступ к ней оставил по столбцам, что в таком случае лучше не делать. Оптимзатору компилятора это нравится не более, чем моему коту, да и доступ к памяти тут тоже не ахти.
Заменим этот код на
for (int x = pChunk->xStart; x <= xEnd; x++)
columnSum[x] = 0;
for ( int y = 0; y < nHeight; y++)
for (int x = pChunk->xStart; x <= xEnd; x++)
columnSum[x] += matrix[x + y * matrixWidth];//!
ну и для непараллельного алгоритма тоже.
Кроме того, сравнивать значения, полученные по GetTickCount, при столь малых величинах, не очень корректно. У нее точность порядка 15 мсек, так что 60 и 70 — это одно и то же в пределах ошибки. Поэтому я увеличил
const int matrixWidth = 12800;
При этом.
С++, Release, VS 2005
по столбцам (твой то есть)
359 344
по строкам (мой)
16 15
Замечу в скобках, что и умножение в цикле там ни к чему, так как y * matrixWidth не меняется во внутреннем цикле, но не стал переделывать, компилятор разберется и сам.
В общем, ты выбрал наихудший способ из всех возможных .
G>На C# c Paralle Extension June CTP
Paralle Extension June CTP у меня нет, так что оставил только непараллельный алгоритм. Для него на моей машине 450.
Здравствуйте, gandjustas, Вы писали:
G>На .NET тоже не надо
Не надо
AS>>>Вот только, есть мнение, память и процессор новые дешевле месяца твоей работы. Не так ли? Это раз. PD>>Да. Только вот одна проблема — именно моя текущая работа требует выжать из этого железа максимум того, что можно. Не выжму — цена месяца моей работы будет равна 0. И что делать ? G>Я выше приводил тест, где не напрягаясь мой код на C# выжимает из железа больше, чем ваш на C.
Я твой тест не заметил, извини. Сейчас попробовал. Ответ да в ответе на то письмо.
PD>>Вот тебе пример. Делал как-то приложение на C#. Ничего особенного, форма с табами, на них всякие листбоксы и т.д. За сценой никаких больших объектов (потом при работе они появятся, но до первого запроса их нет). 17 Мб вся эта прелесть занимает. Уверен, что больше 4-5 Мб она занимать не должна — на MFC. На чистом Win API — думаю, в 2-3 Мб уложился бы, но на это точно много моего времени уйдет. G>Пусть лучше прога занимает больше памяти, но работает быстрее.
Если бы она работала быстрее — я бы согласился (не всегда).
>Мне десяток мегов оперативки сейчас вообще не жалко.
Тебе не жалко, другим не жалко, а в итоге...
PD>>Ну а насчет скорости — тут меня лучше не трогай, я именно этим сейчас и занимаюсь. И если меня лишить прямого доступа к памяти (указателей, выравнивания, иными словами) — все , что я сделал — коту под хвост. А так — уже в 6 раз быстрее. G>И вы наверное предпочитаете руками реализовывать файловое хранилище, вместо использования БД...
В этой задаче нет никаких файлов. А вообще было такое. И скорость работы была намного выше. Практически любой запрос делался за 15-20 мсек. Правда, одно но — вставки и изменения в этом хранилище не производились, оно было константым. Генерация его производилась один раз в 3 месяца и занимала 5 часов — вытаскивались все данные из БД и записывались в это хранилище.
G>Для таких задач редко приходится сталкиваться с низкоуровневневой оптимизацией. Обычно производительность упирается в передачу данных.
С передачей данных нет никаких проблем, 20-30 Мб передать можно со свистом. А вот потом ...
Здравствуйте, Воронков Василий, Вы писали:
WH>>Суперкомпилятор это вполне конкретный давно усоявшейся термин. Появившейся еще в 70какомто году. ВВ>Это как-нибудь применимо, скажем, к C#?
Для жабы уже даже реализовано. http://www.supercompilers.com/white_paper.shtml
Переделать это для C# дело техники.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я-то в оригинальном своем примере GetPixel суммировал, там все равно, как суммировать, время, на GetPixel требуемое, все перекроет. А ты за память взялся. И расположил ты эту матрицу по строкам, как все сейчас делают. А вот доступ к ней оставил по столбцам, что в таком случае лучше не делать. Оптимзатору компилятора это нравится не более, чем моему коту, да и доступ к памяти тут тоже не ахти.
Не я писал этот цикл.
PD>Кроме того, сравнивать значения, полученные по GetTickCount, при столь малых величинах, не очень корректно. У нее точность порядка 15 мсек, так что 60 и 70 — это одно и то же в пределах ошибки. Поэтому я увеличил
Не я придумал использовть GetTickCount.
PD>В общем, ты выбрал наихудший способ из всех возможных .
Вообще-то не я выбрал, а ты Я просто GetPixel заменил назначение из матрицы.
G>>На C# c Paralle Extension June CTP PD>Paralle Extension June CTP у меня нет, так что оставил только непараллельный алгоритм. Для него на моей машине 450. PD>Чудес на свете не бывает.
Конечно не бывает. Код на шарпе очень далек от оптимального.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А связи и нет. Приложение, которое тормозит, это в 99.99% случаев неправильно спроектированное приложение, а не приложение, к-е тормозит, потому что его реализовали с использованием средств разработки, вносящих большой "оверхед".
Понимаешь, у меня нет приложения. Есть просто алгоритм некоторой обработки матрицы. Он может, и не наилучший, но лучше в мире нет, не нашел. А неправильно его спроектировать нельзя, потому что там нечего проектировать. А тормозит он потому, что там сотни миллионов операций. Вот и все. Так что оно тормозит, и , видимо, попадает в 0.01%. Впрочем, уже не торомозит.
ВВ>Я не слышал заявления типа "что C# позволяет решить любую задачу по разработке". Может, пропустил? Но дело-то не в C#. Дело в том, что в перспективе ЯВУ типа C# или Немерле действительно позволит решать любую задачу.
Улитка едет, когда-то будет
ВВ>А что за задача? Можно по-подробнее?
Увы, нет.
>Только подробности не в стиле, что нужно писать используя опредленные инструкции процессора, а бизнес-формулировка задачи какая?
А нет тут бизнес-формулировки вообще . Например, для умножения матриц — какая тут бизнес-формулировка ? И у меня примерно то же.
ВВ>Павел, все задачи — это задачи бизнеса!
Задачи бизнеса — да. В том смысле, что за это кто-то платит и это кому-то нужно. Но и только. Формулировка же задачи чисто математическая. Ну вот, к примеру, предложу я тебе задачу создания некоторого графического фильтра, который позарез кому-то нужен и за который кто-то готов заплатить. Но это все же математическая задача или, если угодно, задача из машинной графики, но не задача из бизнес-сферы. Вот в этом смысле и надо было понимать мое высказывание.
>Ты что, в стране ОЗ находишься?
Нет
>И бизнесу дешевле тратиться на железо, чем на разработку супер-производительного софта на этом железе.
Представь себе, не всегда. Иначе бы мне за это не платили.
>И это реальность. Софт на дотнете стоит дешево. Железо стоит дешево. Разработка/поддержка на асме — дорого. Зачем платить больше?
А просто — не работает тут экстенсивный метод. Не успевает, проще говоря. Нет возможности тратить 5 секунд на компьютере на один образец. А одну задачу распараллелить между компьютерами тоже нельзя, да и не даст это ничего. Это во-первых. А во-вторых, по сравнению с той экономией, что даст эта оптимизация, расходы на мою зарплату — копейки. Я на эту задачу потрачу месяц, ну пусть два, а работать это будет на сотнях компьютеров. Посчитай.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Здравствуйте, samius, Вы писали:
S>>А я подразумевал ту задачу с процентами.
SJA>Можно ссылочку на задачу, или своими словами? А то все похоже знают, что за задача, кроме меня Отсюда
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Понимаешь, у меня нет приложения. Есть просто алгоритм некоторой обработки матрицы. Он может, и не наилучший, но лучше в мире нет, не нашел. А неправильно его спроектировать нельзя, потому что там нечего проектировать. А тормозит он потому, что там сотни миллионов операций. Вот и все. Так что оно тормозит, и , видимо, попадает в 0.01%. Впрочем, уже не торомозит. PD>А нет тут бизнес-формулировки вообще . Например, для умножения матриц — какая тут бизнес-формулировка ? И у меня примерно то же.
Мне вот непонятно, что за задача такая — помножение матриц. И, думаю, не только мне. Для чего/для кого она делается?
ВВ>>Павел, все задачи — это задачи бизнеса! PD>Задачи бизнеса — да. В том смысле, что за это кто-то платит и это кому-то нужно. Но и только. Формулировка же задачи чисто математическая. Ну вот, к примеру, предложу я тебе задачу создания некоторого графического фильтра, который позарез кому-то нужен и за который кто-то готов заплатить. Но это все же математическая задача или, если угодно, задача из машинной графики, но не задача из бизнес-сферы. Вот в этом смысле и надо было понимать мое высказывание.
Математика, исследования, обучение студентов — это все понятно, тут базара нет
Но мы ведь говорили о промышленном программировании, разве нет? В противном случае вообще непонятно к чем тут проценты "распространенности" сравнивать — 90 там на 10 или 80 на 20. Собственно говоря, непонятно что мы вообще сравниваем.
>>И бизнесу дешевле тратиться на железо, чем на разработку супер-производительного софта на этом железе. PD>Представь себе, не всегда. Иначе бы мне за это не платили.
А я представляю. Именно поэтому асм еще не умер. Понятно, что до сих пор есть железки растираживанные сотнями тысяч экземпляров, на которых ну никак дотнет не встанет, и асм чуть ли единственное решение.
Но неужели ты считаешь, что через 5-10 лет эти железки не изменятся кардинально?
>>И это реальность. Софт на дотнете стоит дешево. Железо стоит дешево. Разработка/поддержка на асме — дорого. Зачем платить больше? PD>А просто — не работает тут экстенсивный метод. Не успевает, проще говоря. Нет возможности тратить 5 секунд на компьютере на один образец.
Ты представляешь скорость с которой железо развивается? Сегодня у тебя на старом компьютере твой алгоритм выполняется за 2 сек. на асме, завтра на новом компьютере тот же алгоритм с "абстракциями" на C# будет выполняться за 0.5 сек. Это реальность.
У меня вот нынешний проц на компе — Core2Duo E8500
Предыдущий — P4 Prescott 3.2 HT
Представляешь какая между ними разница по производительности?
А стоимость производства снижается с каждым годом. Процессоры становится меньше, холоднее, мощнее. На дешевых мобильниках теперь идут игры, о которых раньше мы на компах могли только мечтать. Это тенденция, разве нет?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Чудес на свете не бывает.
Тоже мне, бином Ньютона.
Ускоряем код в 25 раз:
using System;
using System.Linq;
namespace linqbench
{
public static class SumHelper
{
// Sum для uint в стандартной библиотеке нет.public static uint Sum(this uint[] items)
{
var result = 0U;
for (int i = 0; i < items.Length; i++) result += items[i];
return result;
}
}
class Program
{
static void Main()
{
var matrix = new uint[128000, 1024];
var notParallel = from x in Enumerable.Range(0, matrix.GetLength(0) - 1)
select Enumerable.Range(0, matrix.GetLength(1) - 1).Sum(y => matrix[x, y]);
notParallel.ToArray(); //Чтобы выполнился JITvar matrix2 = new uint[128000][];
for (int i = 0; i < matrix2.Length; i++) matrix2[i] = new uint[1024];
var notparallel2 = from col in matrix2
select col.Sum();
notparallel2.ToArray();
var sw = new System.Diagnostics.Stopwatch();
sw.Start();
notParallel.ToArray();
sw.Stop();
var time1 = sw.ElapsedMilliseconds;
sw.Reset();
sw.Start();
notparallel2.ToArray();
sw.Stop();
var time2 = sw.ElapsedMilliseconds;
Console.WriteLine("time1={0} time2={1}", time1, time2);
}
}
}
Parallel Extensions у меня нет, но легко видеть, что легкость распараллеливания никуда не девается.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Pzz, Вы писали:
Pzz>А вот внутри самих алгоритмов if'ы и while'ы — вполне себе адекватный инструмент. Во всяком случае, все классические алгоритмы описаны в литературе именно в этих терминах.
Ай, неправда Ваша, уважаемый. if и while — ересь бесовская, для лохов, реальные пацаны и девчонки пишут на ассемблере, который есть самый адекватный инструмент. Во всяком случае, все самые классические алгоритмы описаны в самом классическом трехтомнике Кнуте не именно в терминах if-ов, а на ассемблере выдуманной им угребищной машины (открываем ветхий завет, и приобщаемся к истинной, ортодоксальной вере).
ЗЫ: Удивительно дурацкие флеймы пошли. Как на подбор. Кошмар просто. Казалось бы, причем здесь пропаганда Немерле?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Можно ссылку на суперкомпилятор для C#?
Ccылку на джаву дали. ВВ>Честно, не вижу много смысла муссировать рассуждения типа "теоретически возможно написать такой компилятор, который заоптимизирует все насмерть".
В таком случае, нужно отказаться от муссирования рассуждений типа "теоретически программист может вручную на ассемблере заоптимизировать всё насмерть" ВВ>Когда напишут — тогда и поговорим. А пока все абстракции — реализуемые средствами языков на .NET — о которых здесь и речь неизбежно несут оверхед.
Вот-вот. Когда напишет — тогда и поговорим. А пока на ассемблере воспроизвести банальную ASP.NET страничку, которая обращается к базе, веб-сервису и локальной файлухе — совершенно нереально. Я имею в виду — со сравнимой с ASP.NET эффективностью: то есть везде IO Completion Ports, тред пул по максимуму и т.п.
А пока все эти суперомтизации — реализуемые трюками с регистрами, SSE, и переупорядочиванием команд — о которых здесь и речь неизбежно несут оверхед в стоимости разработки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Я-то в оригинальном своем примере GetPixel суммировал, там все равно, как суммировать, время, на GetPixel требуемое, все перекроет. А ты за память взялся. И расположил ты эту матрицу по строкам, как все сейчас делают. А вот доступ к ней оставил по столбцам, что в таком случае лучше не делать. Оптимзатору компилятора это нравится не более, чем моему коту, да и доступ к памяти тут тоже не ахти. G>Не я писал этот цикл.
Но я-то его писал для других целей. Не могу же я отвечать за использование моего цикла в иной ситуации.
PD>>Кроме того, сравнивать значения, полученные по GetTickCount, при столь малых величинах, не очень корректно. У нее точность порядка 15 мсек, так что 60 и 70 — это одно и то же в пределах ошибки. Поэтому я увеличил G>Не я придумал использовть GetTickCount.
Да, но я ее использовал там, где время было 1500-2000 мсек
PD>>В общем, ты выбрал наихудший способ из всех возможных . G>Вообще-то не я выбрал, а ты Я просто GetPixel заменил назначение из матрицы.
Нет. Я выбрал не для матрицы, а для окна. Я за твой перенос этого на матрицу в ОП отвечать не намерен!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Я-то в оригинальном своем примере GetPixel суммировал, там все равно, как суммировать, время, на GetPixel требуемое, все перекроет. А ты за память взялся. И расположил ты эту матрицу по строкам, как все сейчас делают. А вот доступ к ней оставил по столбцам, что в таком случае лучше не делать. Оптимзатору компилятора это нравится не более, чем моему коту, да и доступ к памяти тут тоже не ахти. G>>Не я писал этот цикл.
PD>Но я-то его писал для других целей. Не могу же я отвечать за использование моего цикла в иной ситуации.
Какой иной ситуации. Ситуация та же — суммирование массива по столбцам. Только способ получения массива другой.
Вообще изначально код ущербный был. Надо получить весь массив пикселей, а потом сумировать вместо GetPixel на каждой итерации.
PD>>>Кроме того, сравнивать значения, полученные по GetTickCount, при столь малых величинах, не очень корректно. У нее точность порядка 15 мсек, так что 60 и 70 — это одно и то же в пределах ошибки. Поэтому я увеличил G>>Не я придумал использовть GetTickCount.
PD>Да, но я ее использовал там, где время было 1500-2000 мсек
Ну сегодня это 1500 мс, а послезавтра 15 мс.
PD>>>В общем, ты выбрал наихудший способ из всех возможных . G>>Вообще-то не я выбрал, а ты Я просто GetPixel заменил назначение из матрицы.
PD>Нет. Я выбрал не для матрицы, а для окна. Я за твой перенос этого на матрицу в ОП отвечать не намерен!
>Мы здесь, еще раз напоминаю, обсуждаем именно конструкции языка, и ничто иное. Обойтись без LINQ для демонстрации возможностей ФП на шарпе нельзя в принципе, обойтись без Win32 для демонстрации того, что LINQ ничего не дает можно, и даже нужно.
Согласен. Я вполне могу убрать оттуда и окно, и GetPixel, а просто предложить просуммировать столбцы некоего двумерного массива, каким-то образом заданного. Правда, чтобы время померить, придется либо в цикл это вставить, либо уж очень большой массив использовать. Впрочем, чтобы IT-ские проценты сравнить в AsParallel и без, то же придется сделать. Но все же никак не пойму — чего ты к пустякам придираешься ? Ну какое отношение к распараллеливанию имеет вопрос откуда и как брать эту матрицу ?
Кто же это писал???
PD>А резюме простое — истина конкретна
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Чудес на свете не бывает.
K>Тоже мне, бином Ньютона.
Все правильно. Ты сделал проход по смежным адресам, по строкам, иными словами, поэтому быстро. А если надо по столбцам еще (а кстати, требовалось именно по столбцам) — что напишешь ?
K> var matrix2 = new uint[128000][]; K> for (int i = 0; i < matrix2.Length; i++) matrix2[i] = new uint[1024]; K> var notparallel2 = from col in matrix2 K> select col.Sum(); K> notparallel2.ToArray();
Кстати, почему ты считаешь, что здесь именно колонка суммируется ? ИМХО все же в массиве первый индекс — номер строки, а второй — колонки, так что у теяб массив из 128000 строк и 1024 колонок.
Можешь изменить так, чтобы получился не массив из 128000 элементов (сумм строк) , а из 1024 элементов — сумм столбцов ? Условие — расположение массива не менять!
Я-то смогу, потому что в любом случае пойду по смежным адресам — хоть при суммировании по строкам (это вообще просто), хоть по столбцам — см. мой пример в этой ветке, на который ты ответил.
Вот тебе пример на всякий случай. Здесь и суммы по строкам, и по столбцам.
#include"stdafx.h"#include"windows.h"int _tmain(int argc, _TCHAR* argv[])
{
DWORD dwTimeStart, dwTimeEnd;
unsigned rows = 128000, cols = 1024;
unsigned** p = new unsigned *[rows];
for (unsigned i = 0; i < rows; i++)
p[i] = new unsigned [cols];
// сорри, но мне нули никто не занесетfor (unsigned i = 0; i < rows; i++)
for (unsigned j = 0; j < cols; j++)
p[i][j] = i;
unsigned* colSum = new unsigned[cols];
unsigned* rowSum = new unsigned[rows];
// суммирую по столбцам
dwTimeStart = GetTickCount();
for (unsigned i = 0; i < cols; i++)
colSum[i] = 0;
for (unsigned i = 0; i < rows; i++) // а пойду по строкам во внешнем циклеfor (unsigned j = 0; j < cols; j++)
colSum[j] += p[i][j];
dwTimeEnd = GetTickCount();
printf("%d\n", dwTimeEnd - dwTimeStart);
for ( int i = 0; i < cols; i++)
printf("%d ", colSum[i]);
printf("\n");
// суммирую по строкам
dwTimeStart = GetTickCount();
for (unsigned i = 0; i < rows; i++) // тоже пойду по строкам во внешнем цикле
{
unsigned s = 0;
for (unsigned j = 0; j < cols; j++)
s += p[i][j];
rowSum[i] = s;
}
dwTimeEnd = GetTickCount();
printf("%d\n", dwTimeEnd - dwTimeStart);
for ( int i = 0; i < rows; i++)
printf("%d ", rowSum[i]);
printf("\n");
for (unsigned i = 0; i < rows; i++)
delete p[i];
delete [] p;
delete []colSum;
delete [] rowSum;
return 0;
}
P.S. Переполнения при суммировании игнорируются. Я не поставил __int64 для сумм, чтобы не давать повода для еще одного флейма
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Мне вот непонятно, что за задача такая — помножение матриц. И, думаю, не только мне. Для чего/для кого она делается?
Не обижайся на то, что я сейчас скажу, ладно ? Я вовсе не хочу ни тебя, ни кого-то еще обидеть. Я с уважением отношусь к любым задачам.
В этом твоем ответе — суть проблемы. Тебе и другим — действительно непонятно. В задачах бизнеса (как я их определил) — это действительно не нужно. Если речь идет о создании сайта — это скорее всего не нужно. Если речь идет о системе управления заводом — может быть, тоже. И т.д.А поскольку большинство этим бизнес-задачами и занимается, то ему (большинству) это действительно непонятно. Оно как-то подсознательно уверено, что то, чем они занимаются — и есть единственно верное программирование, а то, что ему не нужно — вообще не нужно.
О чисто научных задачах я говорить не буду. То. что там оно нужно — думаю, спорить не будешь, но об этих задачах не говорим сейчас.
Вернемся к бизнесу. Ну а если это не сайт и не АСУ (не к ночи будь помянута). О своих нынешних делах рассказывать не буду, а вот о том. что делал лет 10 назад — расскажу. А была это задача натягивания некоей текстуры на фотографию человека. Вот стоит он, одет в голубую рубашку, а еще ткань есть, клетчатая. И надо эту ткань на его рубашку наложить. Чтобы складки там остались, тени и т.д, но только чтобы он был не в голубом, а в клетчатом. Не помню, было ли там перемножение матриц, но, в общем, всяких алгоритмов там хватало.
Это задача бизнеса ? Еще как — заказчик — некая фирма, которая эти рубашки шьет и хочет моделировать процесс — натянуть новый материал и посмотреть, что получится. Без человека — модели.
Другая задача, в которой я участвовал, включала в себя обширный регрессионный анализ для предсказания в экономике... вот чего — не скажу, NDA. Там линейная алгебра в чистом виде и перемножений матриц сколько угодно.
ВВ>Математика, исследования, обучение студентов — это все понятно, тут базара нет ВВ>Но мы ведь говорили о промышленном программировании, разве нет? В противном случае вообще непонятно к чем тут проценты "распространенности" сравнивать — 90 там на 10 или 80 на 20. Собственно говоря, непонятно что мы вообще сравниваем.
Ну вот я тебе привел пару задач вполне промышленного программирования. И то, чем я сейчас занимаюсь, и тот проект, в котором я несколько лет участвовал — тоже промышленное программирование, поверь. И еще какое промышленное
ВВ>А я представляю. Именно поэтому асм еще не умер. Понятно, что до сих пор есть железки растираживанные сотнями тысяч экземпляров, на которых ну никак дотнет не встанет, и асм чуть ли единственное решение.
За милую душу он туда встанет. 4-ядерный процессор с 4 Гб — туда что хочешь встанет (это машина заказчика, у меня хуже). Но вот работать все это будет с такой скоростью, что меня просто уволят
Про свою задачу не скажу, а сделаю имитацию. Вот мы тут сложение матриц вдоль и поперек обсуждали чуть выше. Ну так вот — матриц таких 6 штук, одна входная, другая выходная, 4 промежуточных. Размеры их примерно так 5000 на 5000. А время на обработку дается 200 мсек. И там немного сложнее, чем суммирование по строкам или столбцам. Теперь считаем. 5000 на 5000 — 25 млн. элементов на матрицу. Их надо хотя бы заполнить, а матриц 5 (кроме входной), итого 125 млн. элементов. И действия совершить. А тактовая частота всего лишь 3 Ггц (3 млрд в сек) , а команды за один такт не все выполняются, а времени всего 200 мсек. Вот и все.
ВВ>Но неужели ты считаешь, что через 5-10 лет эти железки не изменятся кардинально?
ВВ>Ты представляешь скорость с которой железо развивается? Сегодня у тебя на старом компьютере твой алгоритм выполняется за 2 сек. на асме, завтра на новом компьютере тот же алгоритм с "абстракциями" на C# будет выполняться за 0.5 сек. Это реальность.
Во-первых, если я его не сделаю сейчас, то меня сейчас и уволят, не дожидаясь, когда с абстракциями будет 0.5 сек. Впрочем, за 0.5 сек уволят тоже сейчас, хоть с абстракциями, хоть без И обратно меня когда-нибудь не возьмут, сколько бы я им потом не говорил про абстракции.
Во-вторых, аппетит приходит во время еды. 200 мсек я еще не сделал, но 400 сделал, а у меня еще SSE2 есть, на 4-кратное ускорение я не надеюсь, но раза в 2 хочу. А заказчик пока что, увидев эти 400, написал мне, что он хотел бы уже не 200, а 20 мсек и предлагает попробовать здесь CUDA. Вот такие вот дела.
ВВ>У меня вот нынешний проц на компе — Core2Duo E8500 ВВ>Предыдущий — P4 Prescott 3.2 HT ВВ>Представляешь какая между ними разница по производительности? ВВ>А стоимость производства снижается с каждым годом. Процессоры становится меньше, холоднее, мощнее. На дешевых мобильниках теперь идут игры, о которых раньше мы на компах могли только мечтать. Это тенденция, разве нет?
Это тема отдельного флейма, не хочу его начинать, скажу лишь, что я в этом совсем не уверен. Железо становится лучше, да, но вот софт все больше и больше тормозит. Тебя скорость работы XP или Vista не раздражает ? Меня даже время их загрузки раздражает, что они там, черт побери, почти полминуты делают ? А ведь у процессора миллиарды операций в секунду. Миллиарды!
Здравствуйте, Pavel Dvorkin, Вы писали:
ВВ>>Мне вот непонятно, что за задача такая — помножение матриц. И, думаю, не только мне. Для чего/для кого она делается? PD>Не обижайся на то, что я сейчас скажу, ладно ? Я вовсе не хочу ни тебя, ни кого-то еще обидеть. Я с уважением отношусь к любым задачам. PD>В этом твоем ответе — суть проблемы. Тебе и другим — действительно непонятно. В задачах бизнеса (как я их определил) — это действительно не нужно. Если речь идет о создании сайта — это скорее всего не нужно. Если речь идет о системе управления заводом — может быть, тоже. И т.д.А поскольку большинство этим бизнес-задачами и занимается, то ему (большинству) это действительно непонятно. Оно как-то подсознательно уверено, что то, чем они занимаются — и есть единственно верное программирование, а то, что ему не нужно — вообще не нужно. PD>О чисто научных задачах я говорить не буду. То. что там оно нужно — думаю, спорить не будешь, но об этих задачах не говорим сейчас.
PD>Вернемся к бизнесу. Ну а если это не сайт и не АСУ (не к ночи будь помянута). О своих нынешних делах рассказывать не буду, а вот о том. что делал лет 10 назад — расскажу. А была это задача натягивания некоей текстуры на фотографию человека.
Вот в последнем предложении описана бизнес-задача.
А перемножение матриц — это не бизнес задача, это кусочек ее решения. Отдельная техническая задача, так сказать
Заказчику же не особо важно, как технически решается его задача.
И оппоненты тебе пытаются сказать, что задачи надо рассматривать именно глобально, а не только в отдельных деталях. Может быть можно провести оптимизацию где-то выше, чтобы уменьшить количество перемножений матриц.
Я ведь тоже могу рассказать, какая это жуткая задача строить веб страницы — у меня сотни запросов в секунду, на каждый запрос надо подготовить данные по 20000 сущностей, а их все надо взять из базы, а для этого мне надо 200 запросов, а потом все эти данные обработать непростым алгоритмом ( 300 мс на каждую сущность) и все это нужно уложиться в полсекунды для каждого пользователя (которых тысячи). Это же уму непостижимо какая сложная вычислительная задача!!!
А потом рассказать, как я жутко оптимизирую алгоритм, и он уже не 300мс тратит, а всего 50мс (но 20000 объектов —
это все равно слишком долго обрабатывается). Ах, какие стали ужасные неэффективные средства.
Только если посмотреть по ограничениям самой задачи, то получается, что их можно закешировать в уже обработанном виде и вуаля, уложились в полсекунды на запрос.
И самая главная техническая (не бизнес!!!!) задача внезапно преобразуется в совершенно другую — вместо проблемы оптимизации алгоритма встает проблема правильности обновления и синхронизации кеша. Это тоже задача, и она тоже требует серьезного решения. Но другими средствами.
А вот бизнес-задача остается при этом той же самой.
Ты часто путаешь технические задачи и отдельные детали решения с собственно бизнес-задачами.
Да, бывают бизнес-задачи, где все упрется в один алгоритм и нет никаких способов решить бизнес-задачу, кроме как заоптимизировать этот алгоритм по самое немогу.
Но бывают и бизнес-задачи, где все упирается в один алгоритм, но все же есть способы решить бизнес-задачу, отойдя от оптимизации собственно прямого выполения алгоритма (например, дополнительно предобрпботав входные данные или закешировав частичные решения).
А бывают и бизнес-задачи, где все, кажется, упирается в один алгоритм, а на самом деле можно решить и несколькими другими, более или менее подходящими в разных условиях. И решение, отличное в одних случаях (скажем, один слабый компьютер) может оказаться плохоим в других (скажем, кластер мощных компьютеров)
Все.
Это я просто про разницу между "бизнес-" и "вообще-" задачами высказался, более ничего. Про твои задачи я ничего не знаю.
Но не стоит считать других глупее себя, даже если они пишут веб-приложения для всякого бизнеса.
Мы, на самом деле, многое понимаем.
Да еще и высказать можем
На самом деле мне и правда непонятно. Вот сегодня заказчик хочет чтобы у тебя было за 200 мс, завтра он передумал и хочет за 20 мс — т.е. так ни с того с сего требования по производительности изменились на порядок А что в действительности-то заказчику нужно? Это вообще похоже на какие-то упражнения для ума.
Ты вот сам пишешь — десять лет назад занимался "текстурированием" на асме. Сейчас есть куча движков написанных на С# — да, это конечно не мейн-стрим подход (пока) — но почему спустя еще 10 лет эта задача не должна выполняться на дотнете без всяких "но"? Я вот правда не вижу причин
Тезис "в перспективе любую задачу можно решить на ЯВУ" возникает не потому что все так ненавидят асм, а потому что непонятны те самые таинственные задачи, для которых он будет нужен всегда — ведь это основной тезис, не так ли? что асм никогда не умрет? Да ты и сам тумана напускаешь.
Помножение матриц — да, для меня это не задача. У меня мозг по-другому устроен И мне так кажется, что многие думают примерно также.
Здесь речь в первую очередь о мейнстриме. И тенденции мейнстрима у меня лично сомнений не вызывают. Код становится все более высокоуровневым. Я не удивлюсь, если через -надцать лет C# будет восприниматься как низкоуровневое средство разработки, а большинство программистов будут какие-нибудь UML-и компилить. И при этом доказывать "ветеранам" вроде меня, что C# уже почти мертв, а UML 6.0 — это видите ли супер-уровень абстракции, благодаря которому программы проще оптимизировать.
), а ты их пытаешься убедить, что "существуют задачи, для решения которых использование высокоуровневых средств... неэффективно и нецелесообразно". Как на фиг высокоуровневые средства, у нас сплошной ХМЛ, блин 
