Высокий/низкий уровень, ручное/автоматическое управление

← →
Anatoly Podgoretsky © (2010-11-10 09:49) [40]

> TUser (10.11.2010 09:21:33) [33]

Это потому что он на delphimaster.ru не ходит, тут бы ему быстро мозги
прочистили, что на весь остаток жизни будет бояться Destroy

← →
Anatoly Podgoretsky © (2010-11-10 09:51) [41]

> Дмитрий Белькевич (10.11.2010 09:25:34) [34]

Это не у программиста круглые глаза, а у базы - ну ничего у вас запросики.

← →
Дмитрий Белькевич (2010-11-10 11:09) [42]

> Это не у программиста круглые глаза, а у базы - ну ничего
> у вас запросики.

Угу, ну и запросы у вас, сказала база данных и упала.

> сам, (стандарт Sql 2135года:) ) правильно построит запрос
> и в течении всего время эксплуатации на основе статистики
> наиболее правильно сам индексы наставит - база данных будет
> жива

Что мешает это сделать прямо сегодня? Что принципиально изменится через много лет?

← →
DiamondShark © (2010-11-10 11:14) [43]

> Берём MSVS и пишем динамическую библиотеку, которую компилируем
> в режиме сверхглубокой оптимизации. Потом дизассеблируем.
> И видим что? Офигенный по размеру код инициализации при
> входе в каждую функцию. При большом количестве вызовов функции
> избавление от этих лишних операций даёт существеннейшую
> выгоду в скорости работы.

"А она взяла селёдку и начала ейной мордой мене в харю тыкать".
Зачем вы мне микрософтовскими сями в харю тыкаете? Си над ассемблером выше уровнем чуть более, чем совсем никак.

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

Ручная оптимизация прологов функций? Ну, давайте прикинем, сколько на этом можно поиметь профита. Какое у вас там отношение объёма пролога к объёму тела? Один к десяти? Ну так это позорище, а не функция, она вообще инлайниться должна. Вот только из ДЛЛ функцию фиг заинлайнишь, потому что в ДЛЛ утеряна высокоуровневая информация о границах функций. Точки входа есть, а границ нету. Вообще, внутренний код ДЛЛ может быть перемешан как спагетти. Привет от Ассемблера, ага.
Какая же это, к свиням собачим, глубокая оптимизация, если возможность оптимизации В КОНТЕКСТЕ ИСПОЛЬЗОВАНИЯ утеряна безвозвратно?

Вернёмся к нашим прологам. В лучшем случае мы получаем 10% выигрыш ценой утери возможности более шлубокой оптимизации. Но если функции посерьёзнее, чем сотня машинных команд, то выигрыш от ручного опиливания напильником составит от процента до чуть менее, чем нифига.
Стоит оно того? Да ни разу!

Как бы оно могло быть при настоящем высокоуровневом подходе?
Модули представлены не в машинном коде, а в промежуточном представлении. Причём, это не байт-код какой-нибудь, а именно высокоуровневое представление графа алгоритма, с сохранением всей метаинформации, свйственной ЯВУ. Что-нибудь вроде такого:
http://moldovacc.md/acoulichev/th10497.pdf
(обратите внимание на год публикации).

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

Вот что такое высокий уровень. А мне тут сями тычут. Си, кстати, разрабатывались в расчёте на то, что из языка будет получаться приемлемого качества машкод БЕЗ ОПТИМИЗАЦИИ, и под одну конкретную систему команд -- PDP. Потому что машинки слабые были. Си -- бай дизайн язык неоптимизируемый, язык, который не смотря на свой примитивизм, снабжён излишествами, призванными ЗАСТАВИТЬ программиста маньячить с мозголомными конструкциями, для ручного запиливания программы в эффективный машкод.

← →
DiamondShark © (2010-11-10 11:20) [44]

> crux (09.11.10 23:50) [14]
> Я тут вот просто игриво намекаю на некоторые
> особенности языка без автоматического управления памятью.

Особенностью языка без автоматического управления памятью является необходимость создания over 9000 костылей, что нам и демонстрирует зоопарк наркоманских библиотек под некоторые особенные языки. В которых одного только стринга можно насчитать десатка полтора реализаций. При том, что без танцев с бубном ни одной нельзя пользоваться.

← →
Дмитрий Белькевич (2010-11-10 11:28) [45]

Начинать, как уже говорили, нужно с операционки.
Иначе все эти идеи выльются в очередную недооперационку-песочницу, типа жавы или дотнета.

← →
DiamondShark © (2010-11-10 11:37) [46]

> А низкий уровень нужен еще и для гибкости. Чем богаче язык
> высокого уровня, тем больше у него "закос" в определенную
> сторону. При этом "развернуть" его в другую сторону бывает
> очень трудно, или невозможно.

Это утверждение опровергается фактом существования систем программного обеспечения полного профиля (от бутлоадеара до прикладных сервисов), созданных с нуля и целиком на управляемых языках высокого уровня.
См. Проект "Lilith", Oberon System, Bluebottle, Active Oberon System

Вот что такое высокий уровень и гибкость.
http://www.rol.ru/news/it/press/cwm/19_98/pdp.htm
И на года, блин, смотрим! А то, блин, Жаба, блин, с дотнетом, блин, достижения...

← →
DiamondShark © (2010-11-10 11:42) [47]

> Дмитрий Белькевич (10.11.10 11:28) [45]
> Начинать, как уже говорили, нужно с операционки.

Всё значительно хуже. Начинать нужно с архитектуры.
http://www.rol.ru/news/it/press/cwm/19_98/pdp.htm
Одной из главных проблем неэффективной работы аппаратуры является разрыв между языком программирования и системой команд процессора. Именно это несоответствие и усиливало неприязнь Вирта к существовавшим архитектурам компьютеров, которые отравляли жизнь разработчикам компиляторов. Впечатления от увиденного в Xerox PARC не давали ему покоя. Вирта целиком захватила идея разработать и построить с нуля собственную компьютерную систему, которая состояла бы из аппаратной части, микрокода, компилятора, операционной системы и различных сервисных программ. Фундаментом ее должен был стать новый язык, который мог бы в максимальной степени задействовать возможности будущей станции. Этот язык должен быть компактным и в то же время универсальным, способным одинаково хорошо решать задачи и системного, и прикладного программирования.

Впрочем, начинать уже не нужно. Начало было в 1970-х (!).
Надо просто вытрясти из башки маркетоложескую хрень.

← →
Дмитрий Белькевич (2010-11-10 11:47) [48]

> а так ли уж сильно эта вставка ускоряет алгоритм? всё равно
> узким местом остаётся чтение/запись в память.

Померял - ровно в 4 раза, как и обещано. Да я когда реализацию писал, то видно было, что называется, невооруженным глазом, что разница существенная. Фпс сильно выше (я просто некоторое время в q3 резался, "фпсы" вижу с первых кадров :)).

← →
Дмитрий Белькевич (2010-11-10 11:49) [49]

> Всё значительно хуже. Начинать нужно с архитектуры.

Согласен. Но - мы же живём в реальном мире. Что уже сейчас сделаешь...

← →
RWolf © (2010-11-10 11:59) [50]

> Дмитрий Белькевич (10.11.10 11:47) [48]

вызов функции MinMax даёт большой оверхед.

← →
Дмитрий Белькевич (2010-11-10 12:07) [51]

> вызов функции MinMax даёт большой оверхед.

Извиняюсь, я не эту конкретно функцию мерял. Две реализации существует. Вторая - для 16-ти бит, там MinMax нету:

for i := 0 to BuffHigh do Img.FBuff16[i] := word(TempInt - ((ShiftMask.FBuff16[i] - ImageSlice.FBuff16[i]) * TempDbl2));

← →
Дмитрий Белькевич (2010-11-10 12:12) [52]

Эти куски существуют как раз для "досчёта" BuffHigh mod 4 и BuffHigh mod 8 для 8-ми и 16-ти битных данных. Лень было на ассемблере делать. Как раз тот случай - когда больше возни, чем выигрыша.

← →
Дмитрий Белькевич (2010-11-10 12:13) [53]

То есть - в жизни там for i := 0 to BuffHigh mod 4 do и for i := 0 to BuffHigh mod 8 do. Мерялось, конечно, без mod"а для чистоты эксперимента.

← →
crux (2010-11-10 12:14) [54]

DiamondShark © (10.11.10 11:20) [44]

>что нам и демонстрирует зоопарк наркоманских библиотек под некоторые особенные языки

Ну а некоторые не очень особенные языки просто не позволяют создавать такие библиотеки, даже наркоманские, поэтому приходится им довольствоваться, чем Создатель послал, в очередной раз применяя TStringList из преисподней для разбиения строк на токены и COM интерфейсы для подсчета ссылок.

DiamondShark © (10.11.10 11:37) [46]

>и целиком на управляемых языках высокого уровня.

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

← →
RWolf © (2010-11-10 12:15) [55]

> [51]

тогда странновато видеть 4-кратное ускорение; разве что если данные уже в кэше.

← →
euru © (2010-11-10 12:21) [56]

> Дмитрий Белькевич (09.11.10 23:03) [10]
> Когда машина научится автоматом превращать вот это:
> . . .
> Тогда я скажу, что ассемблер не нужен. А раньше - увы...

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

Код, содержащий ассемблерную вставку, не гарантирует наиболее эффективное выполнение для любого процессора, имеющего в своём наборе команд используемые во вставке команды (в том числе и для того процессора, для которого производилась эта оптимизация).

← →
Дмитрий Белькевич (2010-11-10 12:30) [57]

> тогда странновато видеть 4-кратное ускорение; разве что
> если данные уже в кэше.

BuffHigh - около 1 млн. То есть - там обсчитываются две 16-ти битные картинки объёмом по 2 мб, наружу отдаётся одна - объёмом 1 мб. Я не уверен, что это всё влазит в кэш.

← →
Дмитрий Белькевич (2010-11-10 12:31) [58]

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

Но софт-то как-то нужно писать и продавать, не?

← →
Дмитрий Белькевич (2010-11-10 12:31) [59]

>наружу отдаётся одна - объёмом 1 мб

Читать:

наружу отдаётся одна - объёмом 2 мб

← →
Дмитрий Белькевич (2010-11-10 12:37) [60]

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

Или ты думаешь, что завтра кто-то начнёт делать процессора, частично несовмстимые с интелом? Так никто не купит. Ну сделал Intel IA 64, много они их продали? И это - "целый" Интел!

← →
DiamondShark © (2010-11-10 12:39) [61]

> crux (10.11.10 12:14) [54]

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

Какие языки не позволяют создавать библиотеки? Модула не позволяет библиотеки создавать? Оберон? Жаба с шарпами не позволяют библиотеки создавать? Лисп с хаскелем не позволяют библиотеки создавать?
Какие "такие" библиотеки они не позволяют создать? Очередную стопицотую реализацию смартпоинтера, что-ли? А нафига собаке пятая нога?

В какой перёд ушла "индустрия" от Вирта, если только в 1995 (Жаба) и 2000 (нет) появились "индустриальные" воплощения отработанного в 60-70х (P-код, типобезопасные языки и менеджед-среда исполнения)?

Чего "нишево" в полном цикле разработки от ядра и драйверов до окошечек с прозрачностью и полного комплекта прикладных сервисов?

Чего вы бредите? Третий том страусного трупа на голову упал? Или корпоративных флэш-роликов обсмотрелись? Ну так приложите холодное, поспите.

← →
Дмитрий Белькевич (2010-11-10 12:41) [62]

Ну вот сделали. Всё круто. И где они сейчас?

"Эта архитектура, известная под названием Intel Architecture-64 (IA-64), полностью "порывает с прошлым". IA-64 не является как 64-разрядным расширением 32-разрядной архитектуры х86 компании Intel, так и переработкой 64-разрядной архитектуры PA-RISC компании HP. IA-64 представляет собой нечто абсолютно новое - передовую архитектуру, использующую длинные слова команд (long instruction words -- LIW), предикаты команд (instruction predication), устранение ветвлений (branch elimination), предварительную загрузку данных (speculative loading) и другие ухищрения для того, чтобы "извлечь больше параллелизма" из кода программ."

Увы - мы живём в реальном мире. И от витела, в текущем виде, фантастически сложно уйти. Даже самому винтелу.

← →
euru © (2010-11-10 12:43) [63]

> DiamondShark © (10.11.10 11:14) [43]
> Модули представлены не в машинном коде, а в промежуточном
> представлении. Причём, это не байт-код какой-нибудь, а именно
> высокоуровневое представление графа алгоритма, с сохранением
> всей метаинформации, свйственной ЯВУ.

Смахивает на .NET. Или нет?

← →
DiamondShark © (2010-11-10 12:45) [64]

> Или ты думаешь, что завтра кто-то начнёт делать процессора,
> частично несовмстимые с интелом? Так никто не купит.

Я вам открою страшную тайну: процессоров, "несовместимых с интелом", выпускается и продаётся огромное множество. В том числе и самим Интелом.

Вот, кстати, ещё один плюс высокоуровневого подхода: смена процессора сугубо до фонаря.

← →
DiamondShark © (2010-11-10 12:47) [65]

> Смахивает на .NET. Или нет?

Угу. Только на 15 лет раньше.

← →
Дмитрий Белькевич (2010-11-10 12:51) [66]

> Я вам открою страшную тайну: процессоров, "несовместимых
> с интелом", выпускается и продаётся огромное множество.
> В том числе и самим Интелом.

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

Мы же говорим про персоналки? Или нет? Даже эппл (из массового) - и тот не выдержал - на ител перешёл.

← →
DiamondShark © (2010-11-10 12:53) [67]

> и другие ухищрения для того, чтобы "извлечь больше параллелизма"
> из кода программ."

Вместо логичного решения рассматривать архитектуру и программирование как единую систему.
Это ж Вирт, семидесяты год... FFFUUUUUU!!!!!!!!
"Фигли думать! Трясти надо!"

← →
Дмитрий Белькевич (2010-11-10 12:54) [68]

> Угу. Только на 15 лет раньше.

Ну так всё не на ровном месте сделано. Многие алгоритмы и концепции придуманы были еще тогда, когда эвм (в современном виде) еще не было.

← →
crux (2010-11-10 12:56) [69]

DiamondShark © (10.11.10 12:39) [61]

>Какие языки не позволяют создавать библиотеки?

Вы, видимо, не понимаете, о чем речь. Как вы объясните, например то, что в Delphi, к примеру, нельзя создать тип делегата, который может делегировать и обычную функцию, и метод, и результат биндинга функцией bind, а в C++, например, можно, и при этом, при дизайне языка никто о таком вообще не помышлял?

>А нафига собаке пятая нога?

Я же рассказал зачем - для автоматизации процесса разработки, пожалуйста, читайте внимательнее.

>В какой перёд ушла "индустрия" от Вирта

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

>Чего "нишево" в полном цикле разработки от ядра и драйверов до окошечек с прозрачностью и полного комплекта прикладных сервисов?

Как раз в разработке полного комплекта прикладных сервисов и. Создавать еще раз, что успешно было создано и отработано уже в нескольких реализациях? Java не маялась такой маятой (хотя, маялась, но вовремя поняла, что не стоит) и таким образом выжила.

>Чего вы бредите?

Я несу светлый завет свободы от оков просвещенного консерватизма.

> Мы же говорим про персоналки?

Рабочих станций на том же ARM -- уже есть немало. И вроде бы собирается быть ещё больше.
Если в какой-нибудь Windows-2015 мелкомягкие решат совсем отказаться от поддержки х86, то эта рахитектура сдохнет за год.

> Даже эппл (из массового) - и тот не выдержал - на ител
> перешёл.

Эппл ваще не показатель. Вот ващщщще.

← →
Дмитрий Белькевич (2010-11-10 13:01) [71]

> > и другие ухищрения для того, чтобы "извлечь больше параллелизма"
> > из кода программ."

Кстати, в моём случае с mmx"ом, как раз параллелизм даёт такое увеличение. Ну, да я думаю, сами знаете.

← →
Дмитрий Белькевич (2010-11-10 13:04) [72]

> Рабочих станций на том же ARM -- уже есть немало

0.05 процентов? Или уже 0.5?

> Эппл ваще не показатель

Ага, 10% рынка.

> Если в какой-нибудь Windows-2015 мелкомягкие решат совсем
> отказаться от поддержки х86, то эта рахитектура сдохнет
> за год.

Не верно, если в какой-нибудь win 2015 мелкомягкие решат откзаться от поддержки x86, то сдохнут мелкомягкие.

← →
Дмитрий Белькевич (2010-11-10 13:06) [73]

Они-то от доса никак отказаться не могут. А ты говоришь - x86. Ну ну.

> DiamondShark (10.11.2010 13:00:10) [70]

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

12 © (10.11.10 08:57) [29]

> В будующем 99%% программистов не будет волновать реализация
> вообще.

а грамотность уже сейчас не волнует

> Anatoly Podgoretsky © (10.11.10 13:07) [74]
>
> > DiamondShark (10.11.2010 13:00:10) [70]
>
> Показатель, после стольких лет издевательства, битья в грудь
> - взять и перейти на то, что они называли гадостью.

Они по команде Джобса что угодно будут любить и что угодно гадостью называть :)

← →
Sapersky (2010-11-10 13:17) [78]

Дмитрий Белькевич (10.11.10 12:07) [51]

Подозреваю, что 4 раза - это "привет" от дельфийского компилятора.
Лень проверять, но там наверняка неоптимальное распределение переменных по регистрам, не соображает делать инкремент указателей и т.д.
Я учился оптимизировать в основном по FastLib, которая примечательна как раз весьма скромным использованием ассемблера, но при этом все паскалевские функции написаны в "ассемблерном" стиле, так, чтобы даже у самого, гхм, альтернативно одарённого компилятора не было возможности тупить. При этом паскалевский код всё же остаётся компактнее и читабельнее asm-a.

Говорят, что сишные компиляторы попродвинутее, в том числе и SIMD умеют применять. Intel C++ хвалят, например, хотя сам не пробовал.
Понятно, что для компиляции в SIMD нужно писать в том самом "ассемблерном" стиле, причём ещё более суровом из-за негибкости SIMD. Однако это всё-таки прогресс (теоретически) по сравнению с компилятором Дельфи, который нужно пинать, чтобы он обычный asm использовал мало-мальски прилично.
Хотя, конечно, против перехода на Си есть два существенных аргумента - Лень и Привычка :)

> Дмитрий Белькевич (10.11.10 13:04) [72]

Я точных процентов не знаю, но движуха есть.

← →
Дмитрий Белькевич (2010-11-10 13:26) [80]

> Подозреваю, что 4 раза - это "привет" от дельфийского компилятора.

Ну, как говориться, за что купил...

> Говорят, что сишные компиляторы попродвинутее, в том числе
> и SIMD умеют применять.

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

> Понятно, что для компиляции в SIMD нужно писать в том самом
> "ассемблерном" стиле, причём ещё более суровом из-за негибкости
> SIMD.

Ага, так и есть.

> Я точных процентов не знаю

А вот зря. Нет полноты картины.

> Хотя, конечно, против перехода на Си есть два существенных
> аргумента - Лень и Привычка :)

Да меня как-то и BASM не напрягает... Зачем еще C изучать, всё равно я на нём никогда не буду. Сильно нужно - найму кого. Что, бывает, и делаю.

Высокий/низкий уровень, ручное/автоматическое управление Найти похожие ветки