Перемножение матриц - конкурс для программистов

[Roman Voznyuk]

Zealint в сообщении #287216 писал(а):

Если бы я знал, то не заводил бы разговор.

Ну а с чего то же вы взяли что не работало. Может просто какие то библиотеки не удалось найти или обнаруживалась 64 битная версия вместо 32 или наоброт.

Zealint в сообщении #287216 писал(а):

Давайте проведём эксперимент? (если у Вас есть время).
Напишите код и скомпилируйте под своим линуксом. Я протестую под своим.

У вас какой нибудь boost стоит? А то его .so файлы больно много весят.

[Zealint]

Roman Voznyuk в сообщении #287218 писал(а):

Ну а с чего то же вы взяли что не работало. Может просто какие то библиотеки не удалось найти или обнаруживалась 64 битная версия вместо 32 или наоброт.

Ну вы меня совсем чайником представляете : ) Конечно все было нормально. На обеих системах стояли одни и те же вещи. То есть обе системы были голыми, на них потом поставили одинаковый g++ (скомпилировали, конечно). И все. Разрядность совпадала.

Roman Voznyuk в сообщении #287218 писал(а):

У вас какой нибудь boost стоит? А то его .so файлы больно много весят.

Нет, а вы сделайте так, чтобы не надо было подгружать эти .so. Ведь в виндоусе все нормально делается - один exe получается. Linux y меня голый.

Это тоже одна из проблем, из-за которой я отказался делать под Linux: я ведь заранее знал, что все начнут просить установить то или это. Представьте, что вы сдаете программу заказчику и ему "пофиг", что там у него в системе, лишь бы программа работала. Везде (на любом Linux'е) и всегда.

Конечно, если вы скажите какой boost поставить, я попробую.

-- Чт фев 11, 2010 19:41:14 --

Кстати, забыл сказать, у меня Ubuntu 64-битный. Подойдет?
Или ставить 32-битный?

[Xaositect]

Zealint в сообщении #287220 писал(а):

На обеих системах стояли одни и те же вещи. То есть обе системы были голыми, на них потом поставили одинаковый g++ (скомпилировали, конечно).

Это не значит, что стояли одни и те же вещи, вообще говоря.

[Zealint]

Xaositect в сообщении #287223 писал(а):

Это не значит, что стояли одни и те же вещи, вообще говоря.

Согласен. Но это и подтверждает то, о чем я говорю: где гарантия, что у меня будет работать то, что вы напишите? Нет такой гарантии. Я могу гарантировать только одно - я скачаю какую-то сборку (причем я не знаю, чья это сборка, так как их много всяких), поставлю и больше НИЧЕГО в ней не изменю. И конечно это уже не моя проблема, что в ней чего-то не хватает. Или я не прав?

[Roman Voznyuk]

Zealint в сообщении #287220 писал(а):

Кстати, забыл сказать, у меня Ubuntu 64-битный. Подойдет?
Или ставить 32-битный?

У меня тоже Убунту 64. Так что нормально. Как будет время приму участие С boost-ом разберусь тем более что uBLAS там "headers only".

[Ajabsandal]

Ed_Em в сообщении #287100 писал(а):

Если вам нужна только скорость, а особая точность не нужна, то лучше всего с поставленной задачей справятся видеокарты nVidia с их CUDA. Нужно лишь распараллелить стандартный алгоритм, хоть из того же GSL, чтобы равномерно нагрузить всю сотню-другую ядер процессоров видеокарты, а т.к. оперативной памяти у современных видеокарт предостаточно, можете перемножать хоть матрицы 10000х10000

Да согласен, CUDA рулит!
А мне, похоже, надо ждать долго с своим Mac OS "Snow Leopard". Да наверное и не дойдет до него дело то? Тем более с OPEN CL и видюхой RADEON-5850 на 2 Тф.

[Dongara]

Ajabsandal писал(а):

достанет = украдет?

Ханжество.

Ajabsandal писал(а):

У меня есть его фортрановские программы

У всех есть. Более того, могу сказать, что я с ним переписывался.

Ajabsandal писал(а):

Насчет тысяч строк ассемблера думаю он тоже, как и я, не согласился бы

За Донгару не надо говорить: действительно тысячи строк кода.
И вообще, судя по высказываниям автора этой темы, он имеет очень смутные представления о постановке задачи.

[Ed_Em]

Zealint в сообщении #287204 писал(а):

Кстати, тов. Ed_Em, функция gsl_matrix_mul_elements ( ..., ... ) выполняет произведение Адамара, а не произведение матриц в алгебраическом смысле. То есть ваши 2 секунды - это даже слишком долго для такой программы. У меня полторы получилось : ) Ой, тут тов. worm2 вам уже то же самое сказал, пока я это писал...

sorry, говорил же, что "на коленке" сделал, особо в документацию не вникал (я этот пакет использовал для расчета вейвлетов и выполнения Фурье, матричное умножение мне не нужно, т.к. свертка вычисляется простым поэлементным умножением). Сейчас глянул документацию GSL, похоже, с матрицами у нее туго: я метода перемножения двух матриц не нашел. Странно, конечно.

Цитата:

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

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

-- Пт фев 12, 2010 02:32:56 --

Zealint в сообщении #287220 писал(а):

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

В этих случаях обычно все зависимости упаковывают в один архив со своими исходниками и пишут общий make-файл. Ничего сложного.

[Dongara]

Ed_Em писал(а):

честно говоря, я не представляю, где может понадобиться выполнение матричного умножения столь больших матриц.

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

[Zealint]

Цитата:

У меня тоже Убунту 64. Так что нормально. Как будет время приму участие С boost-ом разберусь тем более что uBLAS там "headers only".

Отлично. Будем ждать...

Dongara в сообщении #287282 писал(а):

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

Тов. Dongara. Во-первых, я уже где-то у себя в правилах написал, что я чайник в вопросах линейной алгебры. Именно поэтому принимаю участие сам на равных условиях. О постановке задачи я имею полное представление. Я поставил её именно так, как мне нужно в моих научных исследованиях. Более того, ограничения здесь очень щадящие: в действительности приходится иметь дело с матрицами порядка до 10 000 тысяч и числа в них целые, примерно по 15 000 знаков каждое. Далее, заполнение такой матрицы происходит куда более долго (эти числа получаются путем чудовищных вычислений на кластере), чем ввод из файла, отнимающий (у одного из участников, не у меня) 2 секунды. Поэтому смутные представления о задаче не у меня, а у Вас. Я решаю ту задачу, которую нужно мне, вы можете только согласиться с постановкой либо не согласиться. Если бы речь шла, скажем, о вейвлет-преобразованиях, то и постановка была бы другой. Далее, вы все хвалитесь чьими-то крутыми исходниками. Я как раз и делаю конкурс, чтобы кто-нибудь этими крутыми исходниками воспользовался и победил бы. Поэтому я считаю, что прежде, чем начинать обвинять собеседника, нужно подумать. Вы теперь с этим согласны?

Далее, Вы пишите:

Цитата:

Но, честно говоря, угнетает неграмотная постановка задачи автором этой темы.

Здесь "неграмотная" придется пояснить. Хотя я догадываюсь: просто задача поставлена не так как вам нравится. Дело в том, что я ставлю задачу исходя из своих научных направлений. Если хотите, сделайте свой конкурс со свей задачей и я, кстати, приму в нем участие, если мне эта тема окажется близкой.

-- Пт фев 12, 2010 08:03:40 --

Должен признать, что BLAS оказался лучше, чем я сначала думал - один из участников поставил на нем рекорд. Придется у него выигрывать : ) Хотелось бы еще какие-нибудь пакеты сравнить, это же так интересно!

[Dongara]

Наилучший результат для 45 нм. процессора заранее предсказуем: примерно 95% от теоретически возможного результата (на 65 нм. процессоре для 32 битной ОС примерно 90%).

[Dongara]

А можно и за 100% зашкалить.

[Zealint]

Dongara в сообщении #287388 писал(а):

Наилучший результат для 45 нм. процессора заранее предсказуем: примерно 95% от теоретически возможного результата (на 65 нм. процессоре для 32 битной ОС примерно 90%).

Отлично. Вы можете посчитать этот самый результат для указанного в конкурсе компьютера?

[Dongara]

Zealint писал(а):

Dongara в сообщении #287388 писал(а):

Наилучший результат для 45 нм. процессора заранее предсказуем: примерно 95% от теоретически возможного результата (на 65 нм. процессоре для 32 битной ОС примерно 90%).

Отлично. Вы можете посчитать этот самый результат для указанного в конкурсе компьютера?

У меня нет времени на удовлетворение Ваших причуд. Просто я Вам указал, на какой результат необходимо ориентироваться.

[Chifu]

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