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

Pzz>Скорее, в том случае gcc больше повезло с аллокацией регистров. Для
Pzz>нормальной реализации rc4 на x86 регистров чуть-чуть не хватает.

У MSVC7.1 действительно некоторые проблемы с крипто — там обычно нужно 8 регистров, а у x86 только 7 свободных. MSVC умудряется напихать лишних переменных в стеке Intel стабильно его обгоняет на таких задачах. В 8й версии ситуация заметно улучшилась.

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

G>Я вот, например, сейчас утверждаю: Intel C++ кардинально лучше текущей версии gcc в плане кодогенерации на платформе x86. В силу существенно более сложного кодогенератора — у него там полная модель интеловых процов внутри, которая почти все факторы учитывает,

Intel на самом деле заточен под IA-64, и x86 там наследует некоторые ограничения его архитектуры. Например, все переходы зачем-то выровнены по границе 4 байта. Имеет смысл выравнивать лишь на 16. Но в остльном GCC далеко до него.

G>с легкостью обходя в этом программиста на ассемблере.

Ни разу такого не видел. Или речь о сравнении новичка в ассемблере с профессионалом С++?

G>Да, я берусь утверждать, что вы не сможете обогнать IC++ при ручном кодировании на ассемблере на более-менее нетривиальном алгоритме — это за пределами человеческих возможностей. Хотите — проверьте сами .

Под нетривиальным алгоритмом что понимать?

gear nuke wrote:
> Я плохо знаю GCC, но для MSVC могу припомнить довольно много
> особенностей компилятора, влияющих на производимый код. Грубо говоря,
> можено что-то записать 2мя способами, в одном из них результат получится
> гарантированно лучше или хуже. Например, желательно писать const где
> только возможно, и компилятор скажет спасибо. В своих тестах я ничего не
> менял, но может быть, кто-то просто при написании оригинального варианта
> использовал заведомо узкие места GCC? Не будем считать такие действия
> умышленными, такое возщможно, или же GCC любой код одинаково хорошо
> компилирует?
Не знаю, я пользуюсь MSVC как первичным компилятором (а на GCC проверяю
портируемость). Вроде бы правила оптимизации примерно одинаковые.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Gaperton wrote:
>
> 1) Если у вас есть знакомые из компании Мирантис, советую связаться с
> ними и узнать, каким образом применение IC++ позволило им увеличить
> производительность симуляции процесса литографии на 20% (насколько я помню).
> 2) Потрудитесь сами взглянуть на тесты IC++. Их несложно найти в
> интернете — времени уйдет меньше, чем на выяснение степени моей
> наивности. Для вас, я вижу, последняя проблема имеет больший приоритет .

Я скажу отверждение, которое, вероятно, не смогу доказать: не стоит
слишком уж доверять популярным тестам.

Обратите внимание, я не спорю с тем, что Интеловский компилятор лучше,
чем gcc, знает особенности (Интеловских) x86. Я даже не буду спорить,
что в каких-то (возможно, во многих) случаях он порождает луший код.

Я лишь позволю себе напомнить, что
1) разговор начинался с MSVC, а теперь каким-то образом переехал на
Интеловский компилятор.
2) Мне очень не понравилась фраза, произнесенная Gaperton'ом, "А не
MSVC последней версии, у которого кодогенератор заметно качественнее".
Именно ее я и оспаривал, по причине ее спорности и бессодержательности
(что такое, "заметно качественнее"?). Так что я не очень понимаю, какое
к этому имеет отношение вопрос о том, кто круче выглядит на каких-то там
тестах, I++ или gcc.

> Pzz>Не забывайте, кстати, что x86'я архитектура, это не только Intel, но и
> Pzz>AMD. И вот на генерацию кода под AMD Интеловским ребятам было, мягко
> Pzz>говоря, наплевать.
>
>>> программиста на ассемблере. Да, я берусь утверждать, что вы не сможете
>>> обогнать IC++ при ручном кодировании на ассемблере на более-менее
>>> нетривиальном алгоритме — это за пределами человеческих возможностей.
>
> Pzz>А что, IC++ боги, что ли, писали? Если они смогли написать хороший
> Pzz>кодогенератор, то и я смогу руками сгенерировать хороший код.
>
> Флаг в руки. У вас или комбинация феноменальной памяти и великолепное
> знание нюансов устройства современного процессора, или это наглядная
> демонстрация наивности Вашего подхода. Да, в феноменальную память и
> умение предсказывать конвейерные и суперскалярные эффекты в уме я не верю.

Я не сказал, что это просто. Я сказал, что это возможно.

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

> G> Хотите — проверьте сами .
> Pzz> Не хочу.
>
> И это правильно. Мешки ворочать — тяжелая физическая работа, недостойная
> благородного дона. Давайте посмотрим, как с ний справляются другие

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

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

Gaperton wrote:
>
> НО ПОЧЕМУ INTEL COMPILER сделал более быстрый код. Давай-ка, IronPeter
> asm+source code, который сгенерировал Intel C.
> *Либо я ничего не понимаю, либо я вообще ничего не понимаю, либо и то и
> другое*, но короче моего asm-кода придумать просто нельзя.
>
> Касательно моей или вашей наивности, уважаемый Pzz — обратите внимание
> на выделение. Это полезно.

Что конкретно это доказывает?

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


V>Понятно, прикольно... Вся фишка в туплах, и мы может строить произвольные по размерности туплы, так?

V>Просто я рассмтаривал код на OCalm с т.з. своих некоторых давних познаний Лиспа и Пролог. Т.е. записи "[]" и "pivot::rest ->" трактовал весьма однозначно. Хе, тогда все еще прикольнее, если туплы могут иметь произвольную размерность. Наворотить можно нехило

Естественно. Причем, не стоит забывать о том, что все может быть перечисляемым.
Например:

(* вариант из пустого значения или трехэлементного тупла *)
type 'a list = Nil | Cons of 'a * 'a list * 'a list

Кроме того, это могут быть не только туплы, а рекорда, массивы, опять же списки или даже функции:

# type 'a test = Test of ('a -> 'a);;
type 'a test = Test of ('a -> 'a)
# let x = Test (fun x -> x * x);;
val x : int test = Test <fun>
(* и тут же *)
# match x with Test x -> x 5;;
- : int = 25

А если еще вспомнить, что недавно в окамле появились полиморфные варианты (!!warning — вынос мозга — автоматические расширяемые типы без декларации):

# let y = `Test2 (fun y -> y * y * y);;
val y : [> `Test2 of int -> int ] = `Test2 <fun>
# match y with `Test2 y -> y 100;;
- : int = 1000000

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

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

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

G>Либо я ничего не понимаю, либо я вообще ничего не понимаю, либо и то и другое, но короче моего asm-кода придумать просто нельзя.

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

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

>> C>А вот тут полностью не согласен. Производительность ОЧЕНЬ важна для
>> C>многих настольных приложений, игр. Ну и для самой ОС.
>> Для игр по большому счету — нет. ~80% кода современных игр написаны на
>> Lua (и еще ~10% на всяких Python, Javascript etc.) — а как у Луа со
>> скоростью, можете там же взглянуть
C>Ну да. Яркий пример — Civilization IV. Большая часть написана на Питоне
C>и жрет 2Гб памяти.

И к тому же, говорят, тормозит довольно сильно.

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

V>С++ — это универсальный язык, помимо прочего. Мне даже трудно определиться, что лучше: владение универсальным инструментом, или владение множеством узконаправленных, но идеально подходящих для конкретных случаев инструментов.

V>Достаточно много бенефитов у обоих подходов. Но у первого подхода все бенефиты скорее организационно-административного плана, как с технической т.з., так и с т.з. управления ресурсами (людскими)

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

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

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

G>>Я вот, например, сейчас утверждаю: Intel C++ кардинально лучше текущей версии gcc в плане кодогенерации на платформе x86. В силу существенно более сложного кодогенератора — у него там полная модель интеловых процов внутри, которая почти все факторы учитывает,

GN>Intel на самом деле заточен под IA-64, и x86 там наследует некоторые ограничения его архитектуры. Например, все переходы зачем-то выровнены по границе 4 байта. Имеет смысл выравнивать лишь на 16. Но в остльном GCC далеко до него.

G>>с легкостью обходя в этом программиста на ассемблере.

GN>Ни разу такого не видел. Или речь о сравнении новичка в ассемблере с профессионалом С++?

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

Хочешь посмотреть сам — почитай здесь — это весело и познавательно .
http://www.gamedev.ru/forum/?group=2&topic=537&page=6

G>>Да, я берусь утверждать, что вы не сможете обогнать IC++ при ручном кодировании на ассемблере на более-менее нетривиальном алгоритме — это за пределами человеческих возможностей. Хотите — проверьте сами .

GN>Под нетривиальным алгоритмом что понимать?

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

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

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

Pzz>Gaperton wrote:
>>
>> 1) Если у вас есть знакомые из компании Мирантис, советую связаться с
>> ними и узнать, каким образом применение IC++ позволило им увеличить
>> производительность симуляции процесса литографии на 20% (насколько я помню).
>> 2) Потрудитесь сами взглянуть на тесты IC++. Их несложно найти в
>> интернете — времени уйдет меньше, чем на выяснение степени моей
>> наивности. Для вас, я вижу, последняя проблема имеет больший приоритет .

Pzz>Я скажу отверждение, которое, вероятно, не смогу доказать: не стоит
Pzz>слишком уж доверять популярным тестам.

Правильно, к черту тесты SPEC, надо доверять непопулярным тестам, например тому странному тесту, на котором MSVC порвал OCaml.

Pzz>Я лишь позволю себе напомнить, что
Pzz> 1) разговор начинался с MSVC, а теперь каким-то образом переехал на
Pzz>Интеловский компилятор.
Батенька, так в приведенных мной материалах сравнивается все, о чем мы говорили. Там отчетливо видно, что gcc в целом хуже, чем MSVC 7.1, а он, в свою очередь, хуже IC++.

Pzz> 2) Мне очень не понравилась фраза, произнесенная Gaperton'ом, "А не
Pzz>MSVC последней версии, у которого кодогенератор заметно качественнее".
Pzz>Именно ее я и оспаривал, по причине ее спорности и бессодержательности
Pzz>(что такое, "заметно качественнее"?).
Загляните в материалы. Поймете, что такое заметно качественнее. У меня все четко, не проскочишь. По тем пунктам где я не прав, я признаю сам, что не прав. Например, я ошибся по поводу того, что ocamlopt использует gcc, и признал это сразу в первом ответе вам. Почему? Потому что прочитав ваш ответ, я не поленился проверить, так ли это на самом деле, и выяснил, что так. Так вот, учитывая такую мою привычку, и тот факт, что вы не смотре

Pzz>Так что я не очень понимаю, какое
Pzz>к этому имеет отношение вопрос о том, кто круче выглядит на каких-то там
Pzz>тестах, I++ или gcc.
Очень жаль, что вы не читаете мои ответы. Тесты не какие-то там, а SPEC. Почитайте, что такое SPEC. В тестах есть и MSVC и gcc, что относится к теме разговора. Почитайте материалы. Вообще странный подход — вы требуете от меня материалов, а сами их не даже не окрываете. Мсье не читатель, а писатель?

>> Флаг в руки. У вас или комбинация феноменальной памяти и великолепное
>> знание нюансов устройства современного процессора, или это наглядная
>> демонстрация наивности Вашего подхода. Да, в феноменальную память и
>> умение предсказывать конвейерные и суперскалярные эффекты в уме я не верю.

Pzz>Я не сказал, что это просто. Я сказал, что это возможно.
А я сказал, что это практически невозможно. Т.е. возможно только на словах, в теории.

Pzz>Вы утверждаете, что _я_ лично этого сделать не смогу. Я не понимаю, как
Pzz>Вы можете что-то утверждать про то, что я смогу, а что нет, если Вы меня
Pzz>в глаза-то не видели, и тем более никогда со мной не работали.

Элементарно, Ватсон. Есть задачи, с которыми компьютеры справляются лучше людей. Например, сколько целых чисел длиной в 100 цифр вы сможете сложить в уме за одну секунду? Так вот, несколько лет назад список таких задач пополнился — кодогенерация под современные процессоры, плюс игра в шахматы. Если это ущемляет ваше достоинство — извините, но жизнь есть жизнь. Например, я, совершенно не зная вас, могу утверждать, что вы проиграете в шахматы компьютеру BlueGene. Вас это тоже расстроит? Детский сад, короче.

>> G> Хотите — проверьте сами .
>> Pzz> Не хочу.
>>
>> И это правильно. Мешки ворочать — тяжелая физическая работа, недостойная
>> благородного дона. Давайте посмотрим, как с ний справляются другие

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

Ай-ай-ай. В таком случае, не надо, гхм, бросать слова на ветер. Раз уж вы вишли из детского возраста.

Pzz>Если Вы готовы заплатить мне денег за то, что я что-то перекодирую на
Pzz>ассемблере, я готов рассмотреть Ваше предложение, хотя и без особого
Pzz>удовольствия: я не любитель ассемблерного программирования.

Неужели вы считате, что мне настолько интересно убедить вас в том, что IC++ c легкостью обойдет вас при кодогенерации, чтобы я вам за это приплатил? Детский сад.

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

G>>>с легкостью обходя в этом программиста на ассемблере.

GN>>Ни разу такого не видел. Или речь о сравнении новичка в ассемблере с профессионалом С++?

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

Это как раз случай, о котором говорю я. Сравниение машинной и ручной трансляции С++ в asm. Однако, можно и просто на asm написать.

G>Хочешь посмотреть сам — почитай здесь — это весело и познавательно .
G>http://www.gamedev.ru/forum/?group=2&topic=537&page=6

попрошу IronPeter'а прописать в свойствах проекта " /FAs " (ну или что там в IntelCompiler), чтоб в asm вставлялся исходный код, а то я голый ассемблер не перевариваю.

с учетом моих узких знаний ассемблера...

Да, действительно — о чём я и говорил.

Мораль. Никакой ассемблер/IntelC не поможет, если нет знания архитектуры.

GN>>Под нетривиальным алгоритмом что понимать?

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

Понятно. Чисто теоретический предел возможностей мозга.

G>Второй фактор — IC++ гораздо больше "знает" о нюансах устройства проца, чем программист.

Ну да. Программист ведь сам не изучает это.

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

Все эти факторы визуально показывают соответствующие средства анализа. Которыми никто не запрещает пользоваться.

G>Пример алгоритма привести? Например — алгоритм Штрассена для умножения матриц, этого должно быть достаточно. Если этого будет мало — то возьмем обращение матриц, сделанное по принципу Штрассена.

Никогда не сталкивался с этим. Погуглил — пока не вижу каких-то подводных камней. Вот Вы, как программист на ассемблере, скажите — а какие там могут быть сложности? Я пока чижу лишь одну — времени может больше уйти на написание.

G>Ну, или решение систем линейных уравнений.

Довольно размытое направление...

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

GN>Все эти факторы визуально показывают соответствующие средства анализа. Которыми никто не запрещает пользоваться.
Как тут уже было показано, соответствующие средства анализа показывают далеко не все.
G>>Пример алгоритма привести? Например — алгоритм Штрассена для умножения матриц, этого должно быть достаточно. Если этого будет мало — то возьмем обращение матриц, сделанное по принципу Штрассена.

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

Кстати, соответствующие средства анализа почему-то предлагаются не вместо IC++, а в дополнение к нему. Это означает, что владелец IC++ начнет с очень хорошего таргет кода и станет его профилировать при помощи тех самых средств, в то время как хардкорный ассемблерщик все еще будет пытаться достичь точки А. К моменту, когда IC++ + VTune позволят добраться до точки Б, ассемблерщик рискует умереть от истощения.

Надо уже привыкать к мысли, что есть задачи, которые не стоит взваливать на хрупкие человеческие плечи. Ну вот например X29, самолет с обратной стреловидностью крыла, устойчив в полете примерно так же, как пущенная задом наперед стрела. Никакой летчик не сможет управлять им. Компьютер успевает сделать все необходимые расчеты и выдать управляюшие воздействия. Причем учитывает поступающие от летчика команды так, что создает иллюзию, будто именно человек управляет самолетом. Бессмысленно спорить с этим и говорить, что человек мог бы вести лучше. Ага, мог бы, если б ему хватило времени. Увы.

Здравствуйте, Sinclair,

GN>>Все эти факторы визуально показывают соответствующие средства анализа. Которыми никто не запрещает пользоваться.
S>Как тут уже было показано, соответствующие средства анализа показывают далеко не все.

Хм, VTune не показывает что происходит с инструкциями в pipeline CPU? а CodeAnalyst — показывает Больше в общем-то ничего и не нужно.

S>С точки зрения теории, можно добиваться произвольно хороших результатов за счет увеличения объема вложений. На практике, "скорость света" ограничена, т.е. некоторые теоретически достижимые результаты невоспроизводимы из-за превышения объема доступных инвестиций. Проще говоря, может не просто "времени больше уйти на написание", а "в 10000 раз больше времени уйти на написание".

С этим никогда не буду спорить.
Изначально, кстати, я сказал вот что (относительно теоретической скорости OCaml ) —

Теоретически, самый хороший язык — это ассемблер. Знаете как на нём всё быстро будет работать после ручной оптимизации? А если автоматическую прикрутить? Почему же на нём не пишут? Может быть, люди хотят синицу в руках сейчас, а не журавля в небе к старости?

Потом мне начали доказывать, что компиляторы С++ смогут лучше код сделать. Не смогут. Их используют, только потому, что время получения результата важнее самого результата.

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

S>Кстати, соответствующие средства анализа почему-то предлагаются не вместо IC++, а в дополнение к нему.

VTune смотрел очень давно — довольно бесполезный для оптимизации ассемблера инструмент, не показывал влияния команд друг на друга (зависимости по данным и т.п.). Он больше для выявления узких мест в С++ заточен. Для асма хорош CodeAnalyst, но он только под AMD

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

GN>>>Под нетривиальным алгоритмом что понимать?

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

GN>Понятно. Чисто теоретический предел возможностей мозга.

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

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

GN>Все эти факторы визуально показывают соответствующие средства анализа. Которыми никто не запрещает пользоваться.

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

G>>Пример алгоритма привести? Например — алгоритм Штрассена для умножения матриц, этого должно быть достаточно. Если этого будет мало — то возьмем обращение матриц, сделанное по принципу Штрассена.

GN>Никогда не сталкивался с этим. Погуглил — пока не вижу каких-то подводных камней. Вот Вы, как программист на ассемблере, скажите — а какие там могут быть сложности? Я пока чижу лишь одну — времени может больше уйти на написание.

"Больше времени" — не то слово. Время на получение результата такого же качества, как IC++ у вас будет расти быстрее, чем объем кода. И начиная с некоторого, небольшого размера кода — оно начнет скачком сремится к бесконечности. Я вам дал Штрассена как раз как пример потому, что программа умножения матриц методом Штрассена на порядок сложнее и длиннее таковой для обычного метода. На порядок — это не фигура речи, это означает раз в десять.

G>>Ну, или решение систем линейных уравнений.
GN>Довольно размытое направление...
Хорошо. Методом LU-разложения, а будет мало — вариант Штрассена этого метода. За то время, пока вы будете оптимизировать последнюю программу, интел успеет выпустить следующее поколение процессоров и версию компилятора. Что означает, что практически, т.е. на практике, невозможно оптимизировать программу лучше IC++ начиная с некоторого объема.

Ваша теоретическая возможность справиться с этой работой за 100 лет, как вы говорите, никому не интересна, и никто ее всерьез рассматривать не будет — всех интересует "то, что они могут использовать в работе." Тема, опять же — для меня очевидна, очевидна на самом деле и вам (я вам уже говорил, что ошибаются все? Ничего, это можно пережить), так что давайте прекратим тратить место на жестком диске сервера RSDN.

Gaperton wrote:
>
> GN>Понятно. Чисто теоретический предел возможностей мозга.
>
> Напротив, исключительно практический предел. Один из этих объективных
> пределов — объем т.н. оперативной памяти мозга. Никакая тренировка не
> позволит вам запоминать более 9 предметов, показанных одновременно не
> более чем на несколько секунд (исключаем жульничество вроде метода
> ассоциаций — он поззволит вам перечислить предметы но сведет на 0
> полезную функцию оперативной памяти). Примерно таким же образом, и
> примерно по этой самой причине вы на практике не сможете провести
> глобальную оптимизацию лучше компьютера с учетом всех эффектов сложного
> запутанного (сильно связного) куска кода сравнительно небольшого размера
> — по моим примерным оценкам это будет в районе до тысячи команд. Вы
> будете постоянно ошибаться.

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

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

Pzz>Gaperton wrote:
>>
>> GN>Понятно. Чисто теоретический предел возможностей мозга.
>>
>> Напротив, исключительно практический предел. Один из этих объективных
>> пределов — объем т.н. оперативной памяти мозга. Никакая тренировка не
>> позволит вам запоминать более 9 предметов, показанных одновременно не
>> более чем на несколько секунд (исключаем жульничество вроде метода
>> ассоциаций — он поззволит вам перечислить предметы но сведет на 0
>> полезную функцию оперативной памяти). Примерно таким же образом, и
>> примерно по этой самой причине вы на практике не сможете провести
>> глобальную оптимизацию лучше компьютера с учетом всех эффектов сложного
>> запутанного (сильно связного) куска кода сравнительно небольшого размера
>> — по моим примерным оценкам это будет в районе до тысячи команд. Вы
>> будете постоянно ошибаться.

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

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

Это будет очень познавательно, и будет неплохой иллюстраций к важному преимуществу компьютера над человеком — ему совсем не обязательно держать в поле внимания 7+-2 объекта, в отличии от человека. Именно поэтому человек компьютеру и проиграет — такое ему будет создать очень сложно.

Gaperton wrote:
>
> Видимо, вы плохо представляете себе, во что оптимизирующий компилятор
> превращает хорошо структурированную программу, написанную человеком
> разумным. Возьмите хотя бы MSVC 7.1, найдите алгоритм Штрассена,
> скомпилируйте его так, чтобы компилятор агрессивно инлайнил функции с
> максимальной оптимизацией, и посмотрите на результат. Вместо Штрассена
> подойдет другой нетривиальный численный метод из библиотек.

Хорошо быть теоретиком...

Нам (не мне лично, но в команде, в которой я работал) приходилось
разбираться с производительностью софтверной реализации таких
криптографических алгоритмов, как RC2, TKIP, AES-CCMP, Michael.

Компилятор был MSVC 7.1 для Форточек, и какой-то gcc для Линуха.

Во-первых, выяснилось, что gcc далеко не всегда проигрывает MSVC. Я был,
признаться, сильно удивлен, когда MSVC проиграл gcc'у на (если не
ошибаюсь) реализации RC4. И после этого перестал доверять тестам
компиляторов, и вообще всякому поверхностному сравнению компиляторов.

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

В среднем, компилятор гораздо лучше человека знает особенности
процессора. Но ручная аллокация регистров получается гораздо лучше. И
если компилятору банально не хватает регистров (а их на x86 очень мало),
то даже наивная ассемблерная реализация получается получше.

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

Pzz>Gaperton wrote:
>>
>> Видимо, вы плохо представляете себе, во что оптимизирующий компилятор
>> превращает хорошо структурированную программу, написанную человеком
>> разумным. Возьмите хотя бы MSVC 7.1, найдите алгоритм Штрассена,
>> скомпилируйте его так, чтобы компилятор агрессивно инлайнил функции с
>> максимальной оптимизацией, и посмотрите на результат. Вместо Штрассена
>> подойдет другой нетривиальный численный метод из библиотек.

Pzz>Хорошо быть теоретиком...
Ну что вы. Где мне, "теоретику", до глубоких практиков, в активе которых не написанный самим, а найденный в интернете ассемблерный листинг микротеста, который работал "очень заметно" лучше, чем какая-то MSVC-шная реализация, а все потому, что на эту задачу в x86 по любому не хватает регистров, а значит кодогенератор MSVC никак не может быть лучше gcc, а тесты SPEC, составленные из реальных прикладных задач — поверхностны. На такое у меня контраргументов нет, признаю свое поражение.

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

Gaperton wrote:
>
> Pzz>Хорошо быть теоретиком...
> Ну что вы. Где мне, "теоретику", до глубоких практиков, в активе которых
> не написанный самим, а /найденный в интернете /ассемблерный листинг
> микротеста, который работал "очень заметно" лучше, чем какая-то
> MSVC-шная реализация, а все потому, что на эту задачу в x86 по любому не
> хватает регистров, а значит кодогенератор MSVC никак не может быть лучше
> gcc, а тесты SPEC, составленные из реальных прикладных задач —
> поверхностны. На такое у меня контраргументов нет, признаю свое поражение.

Какой микротест, о чем Вы? Вам нужна быстрая реализация RC4. Что Вы
будете делать, напишете на C, и будете всем доказывать, что быстрее
невозможно?

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

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

> Хорошо, короче, быть практиком, хорошо. Желаю вам и дальше оставаться
> практиком, но к сожалению вынужден отказать в выделении денег на ручное
> ассемблерное кодирование. Видите-ли, у меня нет уверенности, что вы
> напишите ассемблерную программу сами — я боюсь, что вы опять скачаете ее
> из интернета.

А Вы за что платите, за решение проблемы, или за потраченное время?

Впрочем, денег у Вас все равно нет, так что ответ не важен