Почитал я тут всякой всячины на тему оптимизации кода

[sz]

Да еще на семинар сходил по оптимизации последних версий процессоров.
Однако, этот векторно-оптимизированный код невозможно читать, должен вам заметить.

Знаете, что я думаю.. Аналогия с SQL напрашивается. Всем известно, что работать с курсорами в SQL неэффективно. Что их надо трогать только если с select-ом ну никак уже не получается. Похоже, что мы приходим к той же самой ситуации с процессорами и циклами. Что Cи устарел и должен быть сделан Vector Query Language покрывающий работу с массивами. А циклы делать только тогда, когда через запрос - ну никак.

Наверное и стандартные решения уже есть? Интересная задачка. Сделать переносимый язык, или стандартную библиотеку для Си с такими запросами. У нас на фирме я знаю два отдела, которые этим занимаются, но судя по их документации, им до стандартизации еще очень далеко. Да и библиотекам их до емкости SQL - как до луны.

[vg]

Не очень понял, о чём ты... Если о запросах на "выборку" данных "подобно" SQL из небольших порций структурированных данных ( например, XML ), то XPath (http://www.w3.org/TR/xpath). Работает очень бытро. Занимает полстрочки в коде. Не знаю, что и делал бы без этого (вернее знаю, но надоело писать груды кода). Никаких циклов и переборов.

ПС. Если я не в тему - извини, пожалуйста. От неопытности моей не сразу понял, о чём постинг твой.

[Marmot]

Наверное и стандартные решения уже есть? Интересная задачка. Сделать переносимый язык, или стандартную библиотеку для Си с такими запросами. У нас на фирме я знаю два отдела, которые этим занимаются, но судя по их документации, им до стандартизации еще очень далеко. Да и библиотекам их до емкости SQL - как до луны.

Вот тут почитать про это можно: http://research.sun.com/projects/plrg/fortress0785.pdf
Посмотрим что у них получится...

Кстати, а нафига вам такой уровень оптимизации?

[Marmot]

ПС. Если я не в тему - извини, пожалуйста. От неопытности моей не сразу понял, о чём постинг твой.

Ага, в огороде бузина..

[sz]

Почитай, например, вот тут: http://en.wikipedia.org/wiki/Vector_processor

Я говорю о том, что писать оптимизированный код на Си (не говоря уже о других высокоуровневых языках) под процессоры поддерживающие SIMD (а это сейчас поддерживают практически все процессоры) - практически невозможно.

Вот и получается, что оптимальный язык выского уровня должен напоминать скорее SQL, чем пошаговый язык. Ну точнее, должен поддерживать и то, и то. Можно реализовать в качестве библиотеки на Си, но гибкости не будет. Нужен новый язык. Нового поколения.

[Marmot]

Почитай, например, вот тут: http://en.wikipedia.org/wiki/Vector_processor

Я говорю о том, что писать оптимизированный код на Си (не говоря уже о других высокоуровневых языках) под процессоры поддерживающие SIMD (а это сейчас поддерживают практически все процессоры) - практически невозможно.

Вот и получается, что оптимальный язык выского уровня должен напоминать скорее SQL, чем пошаговый язык. Ну точнее, должен поддерживать и то, и то. Можно реализовать в качестве библиотеки на Си, но гибкости не будет. Нужен новый язык. Нового поколения.

Не согласен, язык должен быть простым и интутивным прежде всего, и императивные языки в этом плане лучше всего.
А вот копмилятор должен быть очень умным.
В том же Fortress все циклы по умолчанию выполняются параллельно, и компилятор пытается это сделать наилучшим образом.
Честно гововоря мне больше нравятся massive-multicore CPUs ( http://en.wikipedia.org/wiki/UltraSPARC_T1 ) чем vector processors, хотя они во многом и похожи.

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

[vg]

Почитай, например, вот тут: http://en.wikipedia.org/wiki/Vector_processor

Я говорю о том, что писать оптимизированный код на Си (не говоря уже о других высокоуровневых языках) под процессоры поддерживающие SIMD (а это сейчас поддерживают практически все процессоры) - практически невозможно.

Вот и получается, что оптимальный язык выского уровня должен напоминать скорее SQL, чем пошаговый язык. Ну точнее, должен поддерживать и то, и то. Можно реализовать в качестве библиотеки на Си, но гибкости не будет. Нужен новый язык. Нового поколения.

Да, почитал. Интересно в принципе... Спасибо за разъянение.

Ещё наблюдение про оптимизацию, которое, конечно, не имеет отношения к топику. Если говорить не о C, а C++, вопрос об оптимизации может зачастую переносится в плоскость написания нормального, хорошо отлаженного кода (без особых багов и явных ляпсусов). Я видел, как профи переписывали неудачно написанные куски (хотя и работающие), добиваясь повышения быстродействия и снижения зарузки CPU в разы.

[ajkj3em]

Сделать переносимый язык, или стандартную библиотеку для Си с такими запросами.

я по-моему говорил уже как-то - работал с кренделем, который на
define'ах забабахал библиотеку эмуляции exceptions под ANSI C и
потом активно её использовал в софте для payment terminals .. до
сих пор наверняка где-то в verifone'овских pinpad'ах тикает

короче мораль, что на Си можно сделать что угодно, главное не
бояться дефайнов :)

[ajkj3em]

А векторные инструкции для singlecore это всё равно только для всяких игрушек полезно..

ну считай угадал с первого раза, зачем это Старине нужно :)

[Marmot]

А векторные инструкции для singlecore это всё равно только для всяких игрушек полезно..

ну считай угадал с первого раза, зачем это Старине нужно

А он теперь никак игрухи пишет?

[Ren]

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

Кто что про OpenMP думает?

[sz]

> А вот копмилятор должен быть очень умным

Слабо компилятору быть таким умным, чтобы запихнуть произвольный цикл в SIMD. Да еще сообразить, как обойтись минимумом бранчей, соптимизировать кеш и побить код на независимые куски. Подсказка нужна. Нужно рассказать компилятору, чего ты собственно хочешь добиться. А для этого лучше подходит язык запросов, а не процедурный.

> Честно гововоря мне больше нравятся massive-multicore CPUs (
> http://en.wikipedia.org/wiki/UltraSPARC_T1 ) чем vector processors,
> хотя они во многом и похожи.

Одно другому не мешает - перпендикулярные вещи.

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

Везде можно ручками соптимизнуть. Но когда пишешь код под 8 платформ (популярных игровых платформ нынче даже больше, но наш проект поддерживает только , начинаешь задумываться, а может обобщить как-то?

> А он теперь никак игрухи пишет?

EA

[sz]

> Вот тут почитать про это можно: http://research.sun.com/projects/plrg/fortress0785.pdf

Спасибо, почитал. Немного не то. Слишком много гоняются за "очеловечиванием" синтаксиса.

А я говорю о чисто практических вещах. Рассказать компилятору, как правильно оптимизировать.

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

[Groundhog]

"Я говорю о том, что писать оптимизированный код на Си (не говоря уже о других высокоуровневых языках) под процессоры поддерживающие SIMD (а это сейчас поддерживают практически все процессоры) - практически невозможно."
А вы попробуйте вместо ANSI C, gcc (GNU) C использовать. Это
позволит вам применять likely/unlikely в условных операторах
(главное их правильно расставить . Только за счет "подсказки" CPU какая ветвь наиболее вероятна можно 1000% выигрыш
получить в производительности. Инлине функции так-же производительности не уменьшают .

[sz]

> А вы попробуйте вместо ANSI C, gcc (GNU) C использовать. Это
> позволит вам применять likely/unlikely в условных операторах

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