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

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

R>>Приятно, что ты хотя бы признаешь ограниченность своих взглядов...

IT>Странно слышать про ограниченность от человека никчего кроме про C++ слышать не желающего. Не правда ли? Я уже предлагал здесь одному перестать рассматривать мир через замочную скважину и просто открыть дверь. Могу посоветовать тоже самое и тебе. Может оказаться, что мир гораздо интереснее и разнообразнее, и не ограничен одними плюсами.

Там если до края мира дойти, будет ещё одна дверь. Это не мир, а просто другая комната.

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

IT>>Совершенно верно. Кривым инструментов можно сделать только кривое решение. Но потом можно его бесконечно выпрямлять, тратя на это тысячи человеко-лет.

VE>Ничего не понял. Так можно из дерьма конфетку слепить, получается? Или таки только дерьмо получится? Вы уж как-нибудь определитесь.

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

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

VE>Там если до края мира дойти, будет ещё одна дверь. Это не мир, а просто другая комната.

Ну-ка, ну-ка? Что у нас за той дверью?

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

PD>>А вот когда приходится решать задачи, в которых нужно от компьютера взять все, что он может (как твой рейтрейсер) — тогда все эти рассуждения летят к чертовой бабушке.
MC>Интересно, а как бы в этой задаче выглядел OCaml?
http://www.ffconsultancy.com/languages/ray_tracer/comparison.html

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

S>Видишь ли, в чем дело. В последний раз, когда я общался на аналогичные темы по поводу ограничений языка C++ насчет контроля над регистрами и прочей ерундой, я попросил адвоката low level показать мне, какой именно ассемблерный код он не может получить от компилятора плюсов.
S>Он показал. rep scansd, всё такое. Увы, его код исполнялся медленнее. Поэтому у меня есть обоснованные сомнения в том, что "твоя программа с lazy вычислениями" выполнялась бы быстрее, если бы ты мог перешить процессор.

А не мог бы ты ответить на такой вопрос. Есть в процессоре набор инструкций SSE (разные версии). C# компилятор их, насколько я знаю, не генерирует, C++ — тоже, но они доступны как intrinsic (==ассемблер, только без asm). Вопрос же такой — может ли и должен ли компилятор принять решение об их использовании и когда ?

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

PD>А не мог бы ты ответить на такой вопрос. Есть в процессоре набор инструкций SSE (разные версии). C# компилятор их, насколько я знаю, не генерирует, C++ — тоже,

С++ запросто генерирует.

PD>но они доступны как intrinsic (==ассемблер, только без asm). Вопрос же такой — может ли и должен ли компилятор принять решение об их использовании и когда ?

Для С++ достаточно задать ключик компилятора.

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

AVK>http://en.wikipedia.org/wiki/FPGA
Я в курсе. Насколько мне известно, перформанс у FPGA всё же не тот, что у мейнстрима.
Поэтому использование их "для оптимизации" мне показалось несколько бесполезным.
AVK>Вот только, как человек, который с ними лет 10 назад возился всерьез, могу заверить, что использовать сие без сложнейшего компилятора в хардвару (который сам по себе челендж на порядок покруче оптимизирующих компиляторов для VLIW, с чем, как показала практика, так особо и не справились пока) невозможно. Рассчитывать на то, что прикладной программист или даже разработчик компилятора ЯВУ будет этим заниматься сам — безумие.

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

PD>А не мог бы ты ответить на такой вопрос. Есть в процессоре набор инструкций SSE (разные версии). C# компилятор их, насколько я знаю, не генерирует, C++ — тоже, но они доступны как intrinsic (==ассемблер, только без asm). Вопрос же такой — может ли и должен ли компилятор принять решение об их использовании и когда ?
Смотря что мы понимаем под компилятором. Ну то есть если это компилятор в x86 код, то да, именно он должен принять это решение. Когда — в момент компиоляции, естественно. Поэтому нужно позаботиться о том, чтобы в этот момент компилятору было известно, какая версия SSE ему доступна.

Если мы говорим про компилятор C#->MSIL, то он естественно не может и не должен принимать такого решения. Потому, что в целевом языке никаких SSE нету.
Такое решение должен принимать компилятор MSIL->x86, в момент JIT-компиляции.

Mkizub считает, что это очень плохо — MSIL, как промежуточный уровень, не даёт C# компилятору доступа к SSE. Я считаю, что это бред — потому, что у JIT компилятора есть вся та же информация, что у C#, плюс еще и информация о целевой архитектуре. Поэтому он примет более правильное решение. Как раз благодаря тому, что MSIL такой весь бедный и невыразительный.

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

S>Если вспомнить реляционную алгебру, то отношение с N+M колонками можно трактовать как N-мерный разреженный массив с М-компонентными значениями.
S>Здесь N — размерность ключа, M — количество неключевых колонок.
S>Группировка выполняет операцию, аналогичную свертке тензора — она понижает размерность на произвольную величину.

Трактуй как хочешь. Результатом является линейный массив, а как он получается — не суть важно.

S>Я не передергиваю. Я говорю про уровни абстракции. Процессор предлагает удобный уровень абстракции по работе с числами.
S>Библиотека по работе с длинными числами — тоже. Тебе, как клиенту библиотеки, всё равно, как она там внутри работает — софтно или аппаратно.

Обсуждать не буду, как не имеющее к делу отношения.

PD>>Если бы мы могли работать с двумерными массивами как со скалярами — это оно и было бы.

PD>>Некий несуществующий язык

PD>>М = SELECT * FROM TABLE WHERE ROW > 0 && ROW < 10 && COLUMN > 0 && COLUMN < 10
S>Почему же несуществующий? Вполне себе существующий язык SQL — если только исправить синтаксические ошибки. Именно так всё и работает.

Тогда исправь и верни мне это окно. Только учти, что ROW и COLUMN — это не поля таблицы, а таблица БД должна содержать произвольно варьируемое сисло этих COLUMN.

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

F>Что мне нравится в твоем подходе — это отличное чувство предвидения. То есть слышишь слово "SSL2" — сразу очевидно — очень поможет перемножать матрицы. Слышишь слово — "Хаскель" — сразу очевидно, что для перемножения матриц — бесполезен.

Маленькое передергивание. Уточняю.

Слышу слово SSE2 , выясняю, что это такое (для этого много временине требуется, досточно введение почитать) и предполагаю, что это поможет быстрее перемножить матрицы. Слышу слово Хаскель , выясняю, что это такое и предполагаю, что это не поможет быстрее перемножить матрицы.

Разницу чувствуешь ?


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

Вот именно. Кстати, программа, с которой я работаю — исходный алгоритм написан на С++, но очень уж академически (и сделана в одном из университетов Германии). Именно поэтому мне удалось повысить ее быстродействие в 20 раз , а объем памяти уменьшить в 2 раза. Если бы ее профессионалы писали — ничего бы я не сделал.

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


FR>Для С++ достаточно задать ключик компилятора.

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

Кстати, у Intel C++ есть

parallel, Qparallel
Tells the auto-parallelizer to generate multithreaded code for loops that can be safely executed in parallel.

IDE Equivalent
Windows: Optimization > Parallelization


но я все же предпочту эти вещи делать сам

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

S>Mkizub считает, что это очень плохо — MSIL, как промежуточный уровень, не даёт C# компилятору доступа к SSE. Я считаю, что это бред — потому, что у JIT компилятора есть вся та же информация, что у C#, плюс еще и информация о целевой архитектуре. Поэтому он примет более правильное решение. Как раз благодаря тому, что MSIL такой весь бедный и невыразительный.

А ты уверен, что для корректного использования SSE будет достаточно поручить компилятору сделать такой выбор ? Информация у него есть, да, но все же MSIL как он есть сейчас не то чтобы очень SIMD ориентирован (или я не прав ?). Для успешного использования SSE , возможно, придется не полагаться на компилятор, а построить саму программу так, чтобы она делала за раз по 4 сложения, к примеру

for(i = 0; i < N; i++)
сложить a[i] и b[i]

for (i = 0, i < N; i+=4) // да еще и N должен быть кратен 4, иначе дел натворим
{
загрузить a[i].. a[i+3] в А
загрузить b[i].. b[i+3] в Б
сложить А и Б // А и Б — XMM регистры
}

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

PD>Кстати, у Intel C++ есть

PD>parallel, Qparallel
PD>Tells the auto-parallelizer to generate multithreaded code for loops that can be safely executed in parallel.

PD>IDE Equivalent
PD>Windows: Optimization > Parallelization


PD>но я все же предпочту эти вещи делать сам

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

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

PD>Трактуй как хочешь. Результатом является линейный массив, а как он получается — не суть важно.
Это заблуждение. Массивов в SQL вообще нет — потому что в нём нет операции взятия элемента по индексу. Да и вообще порядок элементов не определён, пока его не задашь при помощи order by.
По-видимому, некорректное восприятие и приводит к никорректным выводам про "понижение размерности".

S>>Я не передергиваю. Я говорю про уровни абстракции. Процессор предлагает удобный уровень абстракции по работе с числами.
S>>Библиотека по работе с длинными числами — тоже. Тебе, как клиенту библиотеки, всё равно, как она там внутри работает — софтно или аппаратно.

PD>Обсуждать не буду, как не имеющее к делу отношения.


PD>Тогда исправь и верни мне это окно. Только учти, что ROW и COLUMN — это не поля таблицы, а таблица БД должна содержать произвольно варьируемое сисло этих COLUMN.
Павел, ты опять подменяешь задачу неким решением. Зачем "таблица БД должна их содержать"?
Никому она ничего не должна. Более того, как мы уже выяснили, даже та часть запроса, которая про "строки с 0 по 10" — некорректна. Потому что в SQL у строк нет номеров. Как только ты превратишь ROW и СOLUMN в части составного ключа, как и подразумевает реляционная алгебра, задача сразу получит решение на SQL.

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

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

PD>>Трактуй как хочешь. Результатом является линейный массив, а как он получается — не суть важно.
S>Это заблуждение. Массивов в SQL вообще нет — потому что в нём нет операции взятия элемента по индексу. Да и вообще порядок элементов не определён, пока его не задашь при помощи order by.

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


PD>>Тогда исправь и верни мне это окно. Только учти, что ROW и COLUMN — это не поля таблицы, а таблица БД должна содержать произвольно варьируемое сисло этих COLUMN.
S>Павел, ты опять подменяешь задачу неким решением. Зачем "таблица БД должна их содержать"?
S>Никому она ничего не должна. Более того, как мы уже выяснили, даже та часть запроса, которая про "строки с 0 по 10" — некорректна. Потому что в SQL у строк нет номеров. Как только ты превратишь ROW и СOLUMN в части составного ключа, как и подразумевает реляционная алгебра, задача сразу получит решение на SQL.

Все, закроем эту часть. Ты просил показать понижение на 2 — я тебе показал, что я имею в виду под этим. Обсуждения того, где row и кто ключ — не будет.

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

PD>А ты уверен, что для корректного использования SSE будет достаточно поручить компилятору сделать такой выбор ?
Конечно уверен.
PD>Информация у него есть, да, но все же MSIL как он есть сейчас не то чтобы очень SIMD ориентирован (или я не прав ?).
По крайней мере, он не менее SIMD-ориентирован, чем С#. Это мы уже выясняли в топике про оптимизации "на уровне исходного кода".
PD>Для успешного использования SSE , возможно, придется не полагаться на компилятор, а построить саму программу так, чтобы она делала за раз по 4 сложения, к примеру

PD>for(i = 0; i < N; i++)
PD> сложить a[i] и b[i]

PD>for (i = 0, i < N; i+=4) // да еще и N должен быть кратен 4, иначе дел натворим
PD>{
PD> загрузить a[i].. a[i+3] в А
PD> загрузить b[i].. b[i+3] в Б
PD> сложить А и Б // А и Б — XMM регистры
PD>}
То есть ты думаешь, что вот это всё должен делать человек?
Я вот думаю, что это должен делать компилятор, при помощи двух эвристик:
1. Развертка цикла.
2. Объединение нескольких сложений, идущих подряд, в одну SSE-инструкцию.

remark,

R>Для меня язык не сильно принципиален, и будет 3 строчек кода или 7 тоже не особо интересует. Мне кажется, более важны более высокие и общие вещи — например, построение архитектуры на передачи неизменяемых объектов. И в чём тут проблемы у НЕ ФЯ я так и не понял.

Уж сколько раз твердили миру, что "Surely the most powerful stroke for software productivity, reliability, and simplicity has been the progressive use of high-level languages for programming" (один грамотный дядька).

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

PD>for(i = 0; i < N; i++)
PD> сложить a[i] и b[i]

Да вообще-то компиляторы и так умеют такие циклы векторизовать. Делается очень просто, сначала N/4 итераций по 4 сложения, потом остаток складываем как обычно.

Специально проверил на GCC — векторизует.

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

MC>Здравствуйте, remark, Вы писали:
MC>>>Писали когда-то (ну и сейчас еще по инерции), на PL/SQL, например, с использованием всяческих вещей, типа Oracle Forms, Oracle APEX и т.п. И продолжали бы, если бы Oracle не забросил эти технологии и не переключился на Java.
R>>Какое это имеет отношение к SQL? на Erlang тоже можно С-либу подгрузить и работать с разделяемой памятью.

MC>Прямое. Вы когда-нибудь работали с Oracle Forms, например? Полагаю, что нет, т.к. аналогия с erlang+C совершенно неуместна.

MC>Oracle Forms — это рантайм PL/SQL (чтобы запускать код на клиентской машине или сервере приложений — т.е. вне СУБД) плюс GUI (оконный или web), позволяющий работать с ним из PL/SQL (в частности, отображать результаты выборки из БД).

Как человек работающий с Oracle (и Forms в частности) со всей отвественностью заявляю:
PL/SQL никакого отношения к SQL не имеет

Но к слову надо заметить, что с введением MODEL SQL стал очень даже императивным
Надеюсь все-же что Mr.Cat на придет в голову писать на SQL что нибудь вроде биллинга

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

PD>SELECT * FROM table WHERE cond // Где тут цикл, куда он пропал ?
PD>for(int i = 0; i < table.size; i++)
PD> if(table[i].cond)
PD> result.Add(table[i];

PD>Конечно, SQL сервер отнюдь не обязательно устроит линейный просмотр , но идея от этого не изменится.

Изменится. Например для Join оптимизатор может выбрать по обстоятельствам Hash Join или Nested Loop
а программисту цикл придется очень нетривиально переписывать