Музыка в С++

[Shtirliz]

Сообщение от Spectator

Это конкретный вызов. Функции из DirectX, аналог строки кода из C++, какая инициализация тебе нужна?

гыыыы, ну приведите тогда точный аналог этого кода на C или C++.

Сообщение от Spectator

Все так же абсолютно - через простые переменные или структуры по ссылке.

Ага, ага, особенно работа со строками :-*, например.

[Spectator]

lpDDSBack->Blt();

Как параметры передавать (чтобы тебе не пришло в голову придраться к тому что Blt требует параметры) я уже говорил. Так же, через push'и

[Shtirliz]

Сравниваем:

Сообщение от Spectator

lpDDSBack->Blt();

и

Сообщение от Spectator

mov eax,[lpDDSBack] ; the pointer to the object instance
push eax ; param hidden by C++

mov eax,[eax] ; get vtable address
call [eax + DDS_Blt] ; call the Blt method

И между тем, что вы, Spectator, игнорируете то, что этот код лишен смысла, потому что не определены ни lpDDSBack, ни DDS_Blt

[Spectator]

Сообщение от Shtirliz

Сравниваем:

и

И между тем, что вы, Spectator, игнорируете то, что этот код лишен смысла, потому что не определены ни lpDDSBack, ни DDS_Blt

И в том и в другом куске кода они РАВНО НЕ определены. Поскольку это ОДНА СТРОКА СИШНОГО КОДА, в качестве примера того что ничего сверхужасного там нет.

Сообщение от Spectator

О ужас, здесь даже идет работа с ООП. И вызов иксовой функции. И целых четыре строки кода.

[Shtirliz]

Сообщение от Spectator

И в том и в другом куске кода они РАВНО НЕ определены. Поскольку это ОДНА СТРОКА СИШНОГО КОДА, в качестве примера того что ничего сверхужасного там нет.

Вот только из кода видно, что в данном случае вызывается метод Blt объекта класса lpDDSBack, а из кода на ассемблере видно, что вызывается неведомая фигня по неведомому смещению...
И при том, что в производительности такой код нисколько не выигрывает, он в 4! раза больше и практически не понятен без коментариев.

[Spectator]

Сообщение от Shtirliz

Вот только из кода видно, что в данном случае вызывается метод Blt объекта класса lpDDSBack, а из кода на ассемблере видно, что вызывается неведомая фигня по неведомому смещению...
И при том, что в производительности такой код нисколько не выигрывает, он в 4! раза больше и практически не понятен без коментариев.

Ясен пень что не выиграет))) Поскольку приведенная мною сишная строка при компиляции превратится именно в такую конструкию на ассемблере.
Идем дальше вверх - с чего мы начали изначально разговор.

Мои слова

Ты путаешь развитие ОС и язык программирования. WinAPI, вместе со всеми виндовыми драйверами прекрасно эксплуатируется и из программы на ассемблере. Вот тебе и все итоги.

Никаких особенных танцев с бубном в ассемблерном коде устраивать не надо - все работает через те же механизмы - WinAPI, DirectX и с СУБД можно запросто работать, и все что хочешь можно, то же что и на C++, к примеру.
И мы приходим к следующему тезису - если скорость работы какого-либо алгоритма (заметь, не программы, поскольку есть такая замечательная вещь как встроенный ассемблер) или части этого алгоритма важнее скорости написания этого алгоритма (т.е. писать 1 либо 2, но даже 30% прирост скорости не помешает, а обычно это бывает гораздо больший прирост) то "компилировать" функции "вручную" выгодно и полезно.
На практике вполне реально добиться 1000% прироста по сравнению с самым лучшим оптимизирующим компилятором, или можно оптимизировать код на С++, поняв, после просмотра полученного кода, что именно привело к тормозам.

[Shtirliz]

Сообщение от Spectator

На практике вполне реально добиться 1000% прироста по сравнению с самым лучшим оптимизирующим компилятором

Пруф!!! Потому что это нереально если, конечно, не включать криворукость в C.

[Hopkroft]

Сообщение от Spectator

Ты путаешь развитие ОС и язык программирования. WinAPI, вместе со всеми виндовыми драйверами прекрасно эксплуатируется и из программы на ассемблере. Вот тебе и все итоги.

Это что я путаю? Я писал что благодаря этим "абстракциям" жить стало легче. Конечно были подобные абстракции и ДОСа, но он как-то закончился
Зри в корень, как говориться!

Сообщение от Spectator

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

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

Кстати, 1000% чего? Что это за мифический коэффициент?

[Spectator]

Сообщение от Shtirliz

Пруф!!! Потому что это нереально если, конечно, не включать криворукость в C.

Почитай про кэш. Кэш для данных и кэш для кода
Ну, собственно, вот
http://ru.wikipedia.org/wiki/Кэш_процессора
Так вот, на асме, путем небольшого шаманства и контроля ты можешь добиться (и - что важнее гарантировать вне зависимости от настроек компилятора и прочих внешних параметров) что у тебя и код и данные будут выровнены по границе страниц памяти (ну, на это современные компиляторы способны вполне - но, как я уже говорил, знать ассемблер надо уже для того чтобы понимать как работает компилятор до мелочей, и понимать зачем нужны какие настройки и на что они повлияют в итоговом коде).
Важнее понимать как работакт кэш кода. И оптимизировать функции под этот самый кэш. Поскольку это за тебя компилятор при всем желании не сделает, и при изменении настроек или малейшем изменении код вылезет за пределы кэша и всё. Ты не определишь и не поймешь даже что произошло.
Для всего этого нужно хотя бы ЗНАТЬ ассемблер и понимать архитектуру процессора.

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

И еще насчет сложности разработки на асме. Это крайне преувеличено. Его надо
а) один раз изучить, один раз
б) применять следующим образом - скопировать при отладке код, который создал компилятор, превратить его в ассемблерную вставку, изучить на предмет мест где компилятор слажал, исправить эти места.

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

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

Как то так (с)

[Spectator]

Сообщение от Hopkroft

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

Кстати, 1000% чего? Что это за мифический коэффициент?

Каши в твоей голове "дружочек"

[Shtirliz]

Spectator, все это голословные домыслы. Я даже намекну как может выглядеть пруф. Берем алгоритм, одну реализацию делаем на С, другую - на Асм, сравниваем скорость выполнения потом, а все остальное - это сферическое в вакууме.

[Spectator]

Сообщение от Shtirliz

Spectator, все это голословные домыслы. Я даже намекну как может выглядеть пруф. Берем алгоритм, одну реализацию делаем на С, другую - на Асм, сравниваем скорость выполнения потом, а все остальное - это сферическое в вакууме.

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

[Shtirliz]

Сообщение от Spectator

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

Бгыы... ну тогда давайте, в студию, что это была за задача.

[Hopkroft]

Сообщение от Spectator

Каши в твоей голове "дружочек"

Т.е. ты не знаешь какую именно характеристику ты будешь оптимизировать?

Сообщение от Spectator

Но на асме гибкость способов оптимизации гораздо выше.

Ты тут холивар пытаешься развести по типу, C VS ASM?

Сообщение от Spectator

Оптимизация - это не взяли и написали, это процесс, по времени стремящийся к бесконечности, можно двадцать строчек кода на С всю жизнь оптимизировать, теоретически.

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

Сообщение от Spectator

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

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

Сообщение от Spectator

Там в ход шло всё, малейший выигрыш скорости в любом участке цикла приводил к серьезному увеличению общей скорости, поскольку на решение зависит от количества входных данных полиномиально и математически изменить алгоритм невозможно в рамках существующей научной мысли.

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

На практике если программа будет запускаться один-два раза, то проще подождать пока она считает. Если будет использоваться часто, покупают хорошее железо Хочешь сказать что 3D Max есть в сверх оптимизированном варианте для слабых компьютеров где нужно считать сложные сцены?
Или Гидрометеоцентр использует суперкомпьютеры для своих вычислений просто потому-что им так хочеться. Написал бы ихним админам и программистам про свою оптимизацию на асме.

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

Все гениальное просто(с)

[Hopkroft]

Может в отдельную тему вынести вопросы по оптимизации. А то какая-то совсем не музыкальная тема начинается.

[Spectator]

Сообщение от Shtirliz

Бгыы... ну тогда давайте, в студию, что это была за задача.

На входе - геометрия всех фигур (коих может быть порядка тысячи запросто) на выходе - укладка их на листах (заранее заданных размеров, в идеале - неравной формы, т.е. не обязательно одинаковой ширины / высоты, а то и вообще больших обрезков с заданной координатами геометрией).
На выходе - конкретный ход плазменного резака с точными координатами, для каждого листа, с оптимизацией
а) количества листов
б) площади размеров боковых отходов листов (т.е. ширина * высоту отходов должна стремиться к максимуму, при том что общее количество листов должно стремиться к минимуму, последнее приоритетно). Между любыми двумя точками вырезаемых фигур должно быть конкретное растояние (минимальное).
в) общего пути хода резака с минимизацией углов поворота, подъемов и опусканий (это влияет на скорость процесса резки)

[Spectator]

Hopkroft, твой героический высер я комментировать целиком не буду.

Ограничусь этим.

Сообщение от Hopkroft

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

Практика бывает крайне разной. Например - рендер сцены в трехмерных играх 25 раз в секунду.

[Hopkroft]

Сообщение от Spectator

Практика бывает крайне разной. Например - рендер сцены в трехмерных играх 25 раз в секунду.

Разные требования потому-что к задаче чудик Например тот-же Кармак в первом Quake использовал карту освещённости а не супер-асм алгоритм.
Так что у кого на что мозгов хватает. У кого-то 2 недели код оптимизировать с помощью ассемблера (и потом гнуть пальцы на форуме), а у кого-то придумать новый подход.

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

[Spectator]

Да, в последнем случае (я про игры) сегодня оптимизируют уже не на уровне даже CPU (и вариантов CPU - интел там или амд, а на уровне конкретных видеокарт с их шейдерами).
Я с шейдерами конкретно не очень знаком, но насколько мне хватило интереса - это, по сути, ассемблер для GPU (http://en.wikipedia.org/wiki/Graphics_processing_unit), процессоров, установленных в видеокартах.
Можно на досуге попрограммировать их на дельфях и задуматься о добром и вечном)))

[Spectator]

Сообщение от Hopkroft

Разные требования потому-что к задаче чудик

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

Сообщение от Hopkroft

Например тот-же Кармак в первом Quake использовал карту освещённости а не супер-асм алгоритм.

В смысле - карту освещености? Она сама по себе работала?

Дальнейший высер опустим, мне уже искренне поднадоело элементарные вещи разжевывать)))

[Hopkroft]

Сообщение от Spectator

Можно на досуге попрограммировать их на дельфях и задуматься о добром и вечном)))

Чем тебе Дельфи так понравились? В каждом посте о них упоминаешь. Человек который Delphi cоздал вроде как в MS над C# работает. Может тебе тоже на C# писать)

З.Ы.
К софтинке ты тоже приложил руку? Или просто русский аналог писал?

[Hopkroft]

Сообщение от Spectator

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

Вот ты интересный. Как школьниками людей называть так это он запросто. А как ему сказали так он обиделся Вот ты жук

Сообщение от Spectator

В смысле - карту освещености? Она сама по себе работала?

Quake_engine

Сообщение от Spectator

Дальнейший высер опустим, мне уже искренне поднадоело элементарные вещи разжевывать)))

Ну тебе же разжёвывали, вот и ты хоть раз бы потрудился.

[Spectator]

Сообщение от Hopkroft

Чем тебе Дельфи так понравились? В каждом посте о них упоминаешь. Человек который Delphi cоздал вроде как в MS над C# работает. Может тебе тоже на C# писать)

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

Сообщение от Hopkroft

З.Ы. К софтинке ты тоже приложил руку? Или просто русский аналог писал?

нет. и не приложил и не русский. в России вообще подобных продуктов очень мало. они распространены в сша, где их, наоборот, много.
По разным причинам - большая востребованность фиттингов и использование металла (в основном - жести) для их производства.
У нас пока эта промышленность развита сравнительно слабо.

[Hopkroft]

Сообщение от Spectator

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

Очень весомые аргументы.
Наверное как всегда некогда разжёвывать истинные причины?
Ну что-же это твоё мнение, так что пусть оно таким и останется.

[Shtirliz]

Сообщение от Spectator

На входе - геометрия всех фигур (коих может быть порядка тысячи запросто) на выходе - укладка их на листах (заранее заданных размеров, в идеале - неравной формы, т.е. не обязательно одинаковой ширины / высоты, а то и вообще больших обрезков с заданной координатами геометрией).
На выходе - конкретный ход плазменного резака с точными координатами, для каждого листа, с оптимизацией
а) количества листов
б) площади размеров боковых отходов листов (т.е. ширина * высоту отходов должна стремиться к максимуму, при том что общее количество листов должно стремиться к минимуму, последнее приоритетно). Между любыми двумя точками вырезаемых фигур должно быть конкретное растояние (минимальное).
в) общего пути хода резака с минимизацией углов поворота, подъемов и опусканий (это влияет на скорость процесса резки)

Господи, задача о плоском раскрое, вы хотите сказать, что там еще кто-то что-то оптимизирует? Да она еще в начале 2000-ых решалась за приемлемое время даже методом ветвей и границ без всяких ассемблеров для адекватного размера материалов и числа заготовок, там ассемблер мог быть нужен разве что пиписьками помериться, потому что оно и так больше 10 секунд считать не будет, даже если это на php реализовать. Плюс к этому, там же чистейшая числодробилка, которая любым адекватным оптимизирующим компилятором, во-первых, распараллеливается, а, во-вторых, заоптимизируется до идеала, я сомневаюсь, что один человек может справиться с оптимизацией числодробильни лучше, чем толпа инженеров Intel, программистов MS (или чей вы там компилятор использовали).

Сообщение от Spectator

Я с шейдерами конкретно не очень знаком, но насколько мне хватило интереса - это, по сути, ассемблер для GPU

Нет, GLSL и HLSL - это C подобные языки

Сообщение от Spectator

нет. и не приложил и не русский. в России вообще подобных продуктов очень мало. они распространены в сша, где их, наоборот, много.
По разным причинам - большая востребованность фиттингов и использование металла (в основном - жести) для их производства.
У нас пока эта промышленность развита сравнительно слабо.

ну нельзя же так с утра... Открою тебе страшную тайну, этого ПО везде вагон и то что ты написал умеют почти все CAD, начиная от AutoCAD и заканчивая наколеночным QCAD, так что очередная 1001 утилитка никому нафиг не нужна Но даже при этом, во всяких Воронежских Филиалах Санкт-Петербургского Института Водных Коммуникаций из года в год пытаются защитить диссеры по этой теме...

Сообщение от Hopkroft

Очень весомые аргументы.

Ну, видимо, стыдно писать, что после того как пришел студент третьекурсник и сделал за 8 часов в Delphi, то что Spectator 2 месяца нежно "оптимизировал" на ассемблере, его, Spectatorа, попросили проследовать на... Вот так и появилась ненависть ко всяким RAD
А, вообще, Hopkroft, глупо требовать обоснований постов от Spectatorа, он это не практикует, как говорится "за слова не отвечает"

[Hopkroft]

Сообщение от Spectator

Hopkroft, твой героический высер я комментировать целиком не буду.

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

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

Так где твои аргументы что это на практике не работает?

Или не хочешь сливать очередную тему.

З.Ы. В ссылке на твои рисунке есть софтина, где написано что она может использовать несколько ядер. Один из подходов для использования нескольких ядер, является распараллеливание задачи и создание многопоточных вычислений. У тебя же написано что ты работал с кэшем(в многоядерной архитектуре он вроде как у каждого ядра свой), каким именно кэшем ты работал. Может ты не том концентрировался. И нужно было использовать распараллеливание, как я тебе предлагал, и юзать многоядерные процы, как рекомендуют в описании программы.

Приводи нормальные аргументы, ты же программист блин

[Hopkroft]

Сообщение от Shtirliz

Ну, видимо, стыдно писать, что после того как пришел студент третьекурсник и сделал за 8 часов в Delphi, то что Spectator 2 месяца нежно "оптимизировал" на ассемблере, его, Spectatorа, попросили проследовать на... Вот так и появилась ненависть ко всяким RAD

У меня кстати было такое, правда я переделывал программу с FoxPro на Delphi И вместо 40 минут она считала за 2-3. Хотя никакого шаманства, технология доступа к dbf - ADO, чуть-чуть SQL и немного здравого смысла. Без всякого взрыва мозга.

Сообщение от Shtirliz

А, вообще, Hopkroft, глупо требовать обоснований постов от Spectatorа, он это не практикует, как говорится "за слова не отвечает"

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

[Spectator]

Сообщение от Shtirliz

Господи, задача о плоском раскрое, вы хотите сказать, что там еще кто-то что-то оптимизирует?

Ты не в теме. Оптимизируют не скорость поиска ЛЮБОГО раскроя, оптимизируют качество раскроя. Ты вообще читаешь ЧТО я пишу? Если да - видимо просто не понимаешь.

[Spectator]

Сообщение от Hopkroft

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

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

[Hopkroft]

Сообщение от Spectator

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

Я её читал. И чем-же приведённые методы тебе не подошли? К примеру ветвей и границ.
Ты смотрел рекомендуемые требования к буржуйской софтинке? там рекомендуют юзать хорошую аппаратку. Т.е. программист заложил возможность использования распараллеливания Видишь, кто-то это юзает.