Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Редактирование движка
GAMEINATOR forums > S.T.A.L.K.E.R. > Мастерская: создание модов для S.T.A.L.K.E.R.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97
cjayho
QUOTE (Xottab_DUTY @ 04.05.2019, 02:54) *
QUOTE (cjayho @ 04.05.2019, 05:50) *
Вы мне объясните как работает инструкция которую я описал

Какой тип у переменной i?

Эта конструкция может делать целое ничего, а может делать что-то важное. Зависит от типа переменной и области видимости, где она объявлена. Но тела у этого цикла нет, да.


Вот объясните мне, глупому линуксоиду, что здесь происходит:

CODE
template <LPCSTR caBaseNames[]> class CAniFVector {
public:
    ANIM_VECTOR        A;

    IC    void        Load(CKinematicsAnimated *tpKinematics, LPCSTR caBaseName)
    {
        A.clear            ();
        string256        S;
        for (int j=0; caBaseNames[j]; ++j); // <-- вот тут
        A.resize        (j); // <-- и вот тут
        for (int i=0; i<j; ++i)  // <-- и тут
        {
            strconcat    (sizeof(S),S,caBaseName,caBaseNames[i]);
            A[i]        = tpKinematics->ID_Cycle_Safe(S);
#ifdef DEBUG
            if (A[i] && psAI_Flags.test(aiAnimation))
                Msg        ("* Loaded animation %s",S);
#endif
        }
    }
};


и заметьте что j больше нигде не обявлена кроме чудной конструкции кастрированного цикла for.
Что самое интересное, 2005 студия отлично это понимает. В отличие от 2017...2019.

И такое место в коде не одно, их десятки.
Молния в вакууме
Код
for (int j=0; caBaseNames[j]; ++j); // <-- вот тут

Ищется элемент массива который равен нулю, его индекс запоминается в j.

Код
A.resize        (j); // <-- и вот тут

Изменяется размер вектора на количесвто элементов которые не равны 0.

Код
for (int i=0; i<j; ++i)  // <-- и тут

А тут уже обрабатываются все элементы caBaseNames и результаты сохраняются в вектор A.

В старых компиляторах область видимости переменных объявленных в for была такая, как если бы они были объявлены прямо перед ним. То есть они видимы всему коду после for. В новых компиляторах такие переменные можно использовать только внутри for.
cjayho
QUOTE (Молния в вакууме @ 04.05.2019, 03:21) *
В старых компиляторах область видимости переменных объявленных в for была такая, как если бы они были объявлены прямо перед ним. То есть они видимы всему коду после for.


А можете показать стандарты где такое поведение документировано?
Как это переваривали компиляторы это вторично.

Зы. в коде полно моментов плана

for( i=0; i<4; i++) ну и так далее

где новые компиляторы ругаются что переменную i видят впервые.
iOrange
Цитата(cjayho @ 04.05.2019, 03:41) *
А можете показать стандарты где такое поведение документировано?

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

https://docs.microsoft.com/en-us/cpp/build/...pe?view=vs-2019
cjayho
QUOTE (iOrange @ 04.05.2019, 03:51) *
QUOTE (cjayho @ 04.05.2019, 03:41) *
А можете показать стандарты где такое поведение документировано?

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

https://docs.microsoft.com/en-us/cpp/build/...pe?view=vs-2019


Во, за это спасибо. Ато меня выше в теме так уверенно назвали неучем что я аж сам поверил.
Xottab_DUTY
Цитата(iOrange @ 04.05.2019, 06:51) *
Нет такого в стандарте, это было расширение компилятора msvc, которое не рекомендовалось к использованию (все вменяемые люди его отключали).

Его пришлось включить из-за того, что в C++ Builder это поведение было не отключаемым, а так как SDK был именно на этом компиляторе, пришлось и в студии это поведение включить.

P.S. но, может, я и ошибаюсь и, возможно, в билдере оно тоже отключаемо... Но я не нашёл там такого пункта! unsure.gif
cjayho
QUOTE (Xottab_DUTY @ 04.05.2019, 05:02) *
QUOTE (iOrange @ 04.05.2019, 06:51) *
Нет такого в стандарте, это было расширение компилятора msvc, которое не рекомендовалось к использованию (все вменяемые люди его отключали).

Его пришлось включить из-за того, что в C++ Builder это поведение было не отключаемым, а так как SDK был именно на этом компиляторе, пришлось и в студии это поведение включить.

P.S. но, может, я и ошибаюсь и, возможно, в билдере оно тоже отключаемо... Но я не нашёл там такого пункта! unsure.gif


а что билдер не поймет нормальное

CODE
int i;
for( i = 0; i < 5; ++i ){}


?

Я думаю причина проста - код писался в начале нулевых, когда мало кто думал о поддержке каких либо стандартов. Если даже в сайтостроении все сайты писались под интернет эксплорер 6, а пользователи других браузеров не учитывались, если у них чтото работало не так, то это их проблемы.
xrModder
Цитата(cjayho @ 04.05.2019, 09:38) *
а что билдер не поймет нормальное

Код
int i;
for( i = 0; i < 5; ++i ){}


?

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

Может:
Код
for(int i = 0; i < 5; ++i ){}
cjayho
QUOTE (xrModder @ 04.05.2019, 06:50) *
QUOTE (cjayho @ 04.05.2019, 09:38) *
а что билдер не поймет нормальное

CODE
int i;
for( i = 0; i < 5; ++i ){}


?

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

Может:
CODE
for(int i = 0; i < 5; ++i ){}



Нет, именно так как я написал. Почитайте тему выше, о доступности i за пределами for.

--------------

Мдэ, попытался скомпилять иксрей с флагом /Za и компилятор стал ругаться на winnt.h
Зашибись.
Хороший компилятор, который при включении соответствия стандартам с++ руается на собственный же хэдер...
Xottab_DUTY
cjayho, неправильно. winnt.h это хэдер WinAPI, но не MSVC. Да, они оба. конечно, творения Microsoft, но всё же надо немного разграничивать.. biggrin.gif
Молния в вакууме
Цитата(Xottab_DUTY @ 04.05.2019, 06:02) *
P.S. но, может, я и ошибаюсь и, возможно, в билдере оно тоже отключаемо... Но я не нашёл там такого пункта! unsure.gif

В шестом билдере такое поведение включается галочкой MFC Compatibility. В 2007 версии завезли отдельную галочку под это дело.

Вообще, эта фича из pre-standard C++, и есть чуть ли не в каждом первом компиляторе.
В GCC это опция -fno-for-scope. https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gc...s-Compatibility
В Open Watcom это опция -zf.

А кто первый начал я не знаю.
NanoBot-AMK
Кто нибудь пытался ТЧ,ЧН,ЗП компилировать GCC? Как это сделать? Я так понял, надо makefile сочинить? Что я, лично не умею. Но сам компилятор GCC мне нравится, правда файлы громоздкие получаются, но код как правило более быстрый для x86-32 чем с VS201*.
xrModder
Цитата(NanoBot-AMK @ 14.05.2019, 04:40) *
Кто нибудь пытался ТЧ,ЧН,ЗП компилировать GCC? Как это сделать? Я так понял, надо makefile сочинить? Что я, лично не умею. Но сам компилятор GCC мне нравится, правда файлы громоздкие получаются, но код как правило более быстрый для x86-32 чем с VS201*.

На Linux'е работаешь?
iOrange
Цитата(NanoBot-AMK @ 14.05.2019, 00:40) *
но код как правило более быстрый для x86-32 чем с VS201*

Спорно.

Ну и кстати - тогда уже стоит смотреть в сторону CLang - он моложе, перспективнее, и код генерит очень хороший.
У последних студий есть поддержка CLang из коробки, кстати.
Цитата(NanoBot-AMK @ 14.05.2019, 00:40) *
надо makefile сочинить?

Ну как минимум в этом репо (https://github.com/OpenXRay/xray-16) я вижу CMakeLists.txt, так что ничего сочинять не нужно.
Xottab_DUTY
Да, более того, OpenXRay не только компилируется под GCC, но и запускается на Линуксе wink.gif
Diesel
Цитата(Xottab_DUTY @ 14.05.2019, 22:48) *
но и запускается на Линуксе wink.gif

А кто сейчас Линукс использует? В чём сложность, разбить жёсткий диск и поставить палёную Винду - проблема прям?

У меня на 400Gb три системы уместилось, правда еще не разу ГТА5 не играл, из-за оставшихся 50gb свободного места.
iOrange
Цитата(Дизель @ 14.05.2019, 20:30) *
А кто сейчас Линукс использует?

Наверное есть спрос, раз Майкрософт так сильно старается

https://devblogs.microsoft.com/cppblog/linu...uild-and-debug/
Diesel
Цитата(iOrange @ 14.05.2019, 23:48) *
Цитата(Дизель @ 14.05.2019, 20:30) *
А кто сейчас Линукс использует?

Наверное есть спрос, раз Майкрософт так сильно старается

https://devblogs.microsoft.com/cppblog/linu...uild-and-debug/


Не верю, что виной наступление на пятки. Тут явный подвох. Зачем кормить конкурента?
Как говорят: -иди сюда милый, я буду убивать тебя нежно.

Видели что творит Гугл? Мазила с Яндексом то тупят как раз из-за конкуренции. Недавно где то видел в новостях, что америкосы стараются, по всем фронтам задушить в объятиях.
Modera
Цитата(Дизель @ 14.05.2019, 22:42) *
Не верю, что виной наступление на пятки. Тут явный подвох. Зачем кормить конкурента?
Как говорят: -иди сюда милый, я буду убивать тебя нежно.

Это все давно знают. https://ru.wikipedia.org/wiki/Embrace,_Exte..._and_Extinguish
iOrange
Цитата(Дизель @ 14.05.2019, 21:42) *
Зачем кормить конкурента?

Конкурент - очень громкое слово. Они не разу не конкуренты, ниши разные.

PS. Но это уже оффтоп. Извиняюсь.
Diesel
Цитата(iOrange @ 15.05.2019, 00:50) *
PS. Но это уже оффтоп. Извиняюсь.

Ну, да. BFG (модератора) не хватает.

А из CE3 можно в х-ray что нибудь украсть? Или там несовместимость 100%?

Охота воду такую же видеть в Сталкере, как в CE2-3
А физику можно хотя бы поменять?
NanoBot-AMK
Вопрос смены компилятора реально достаточно актуальный.
Вес установщика GCC 8.2.0 x86-32 = 86М
Вес установщика GCC 8.2.0 x86-32 = 106М
При этом x86-32 часто генерирует более оптимальный код. Интерес именно возможности оптимизации под конкретный процессор. Т.е. например у меня получается практически гениальный код - -march=athlon-xp
И ещё компиляторы типа gcc любят хороших программистов, а вот VS201* их просто ненавидят, т.е. M$ любят сранных говнокодеров которые очень хреново представляют работу современных процессоров.

Что такое плохой код, это код который потенциально выполняется медленно, медленней чем мог.
Например сортировка, раньше лидировала "Быстрая сортировка / Quicksort". А сейчас "Поразрядная сортировка / Radix sort".
Которая позволяет добиться очень высокой скорости на современных процессорах. Эээ порядка 100'000'000 двордов за 0.6 сек при 3 ГГц при хорошей оптимизацией на i7. При плохой, медленней в два три раза.

Что мне нужно во обще от XRay'я.
Онлайне до 500-1000 сложных объектов ака сталкеров при 50-60 FPS, в моделях 256 костей, в танках - гусеницы, это отдельные приатаченые объекты с полной физикой, можно из РПГ перебить гусеницу и она слетит с танка, если танк подчиняясь скрипты или командам ГГ продолжает движения, то реалистично начинает вращаться на месте. Сбитую гусеница можно захватить гравиприводом и она будет реалистично работать как артефакт "плёнка", да движок по дефолту многое поддерживает, ему надо помочь, чтобы он стал ещё быстрей и реалистичней.
Так, что ещё, что ещё? Ах да, реалистичная физика ударной волны, и сама физика детонации взрывных объектов. CExplosive. Вроде ерунда, но будучи правильно реализованной очень хорошо ложится на геймплей, в игре всегда есть что-то взорвать, разрушить для продолжения геймплея. Взрыв гранаты может вызвать детонацию взрывных объектов которые расположены в непосредственной близости, это вроде как уже реализовано, но работает довольно хреново.
Так, что ещё? Пока всё.
iOrange
Один я ничего не понял?
NanoBot-AMK
Самое главное танки без проблем преодолевали ЖД пути. У тебя застревали танки на путях? У меня застревали.
Это просто быстрое описания модернизации XRay'я что тут может быть непонятно. kozak.gif
ЗЫ
Да, описывал под хмелем, ну и что?
Diesel
Цитата(NanoBot-AMK @ 15.05.2019, 18:08) *
Самое главное танки без проблем преодолевали ЖД пути. У тебя застревали танки на путях? У меня застревали.
Это просто быстрое описания модернизации XRay'я что тут может быть непонятно. kozak.gif
ЗЫ
Да, описывал под хмелем, ну и что?

Какие танки в x-ray? Ты там кого нагородил? В гробу я видел такие танки, без движущихся гусениц.

Бросай пить.
Kontro-zzz
Цитата
В гробу я видел такие танки, без движущихся гусениц.

А ты на них не смотри, на гусеницы. biggrin.gif
iOrange
Цитата(NanoBot-AMK @ 15.05.2019, 01:26) *
сранных говнокодеров которые очень хреново представляют работу современных процессоров

А вы хорошо себе ее представляете? Очень сомневаюсь.
Современный процессор - это практически черный ящик, в котором ваши ассемблерные инструкции декодируются в наборы микроинструкций, которые выполняются в произволном порядке и результаты фиксятся по ходу дела.
Или до сих пор верите, что написанные вами ассемблерные инструкции выполняются в том порядке, в котором вы их записали?
ForserX
Товарищи танкисты, Дизель, NanoBot-AMK, вы надоели. Хотите 256 костей? Окей. Берите шейдер скина, там есть переменная с размером массива в 65*3. (Емнип) 65 костей. Умноженное на ротацию, размер и позицию. Дальше идут варианты скиннинга. Оттуда убирается 3 индекса, вроде бы под рут кость, емнип. По мимо этого, вам нужно увеличить в движке маску костей. Если же опять лень изучать, то возьмите vismask от KD87. Профит. Правленый SDK есть в ОГСР. Если же вас он не устраивает, я могу в MeshEditor окси вам заплатку сделать.

Идём дальше. GCC/Clang(aka llvm)/CMake и прочее. По тестам GCC по вероятным ошибкам проиграл остальным. На первом месте идёт кланг. НО! Не забывайте про Intel Compiler. Пока он превосходит в оптимизации остальные. К тому же, вам придется изрядно потратить нервы на шаблонах, ибо весь двиг точился под MSBuilder, плюс ещё потребуется портировать всё это дело под C++11/C++14. Если лень разбираться, то смотрим ветку Premissive в окси. Там я это почти закончил. Мб на днях добью
Цитата(NanoBot-AMK @ 15.05.2019, 02:26) *
При этом x86-32 часто генерирует более оптимальный код. Интерес именно возможности оптимизации под конкретный процессор.

Это лично у меня вызывает флешбеки с временами, когда код писался на ассемблере под конкретные процы. Хорош, а? Пишите нормальный CPUID и работайте с Intel intrinsics. Будем вам и SSE, AVX, AES, FMA, 3DNow! и прочее.

Сорри, сгорело, если где-то неправ, то можете закидать меня.
Diesel
Цитата(ForserX @ 15.05.2019, 21:08) *
Товарищи танкисты, Дизель, NanoBot-AMK, вы надоели. Хотите 256 костей? Окей. Берите шейдер скина, там есть переменная с размером массива в 65*3. (Емнип) 65 костей. Умноженное на ротацию, размер и позицию. Дальше идут варианты скиннинга. Оттуда убирается 3 индекса, вроде бы под рут кость, емнип. По мимо этого, вам нужно увеличить в движке маску костей. Если же опять лень изучать, то возьмите vismask от KD87. Профит. Правленый SDK есть в ОГСР. Если же вас он не устраивает, я могу в MeshEditor окси вам заплатку сделать.

Идём дальше. GCC/Clang(aka llvm)/CMake и прочее. По тестам GCC по вероятным ошибкам проиграл остальным. На первом месте идёт кланг. НО! Не забывайте про Intel Compiler. Пока он превосходит в оптимизации остальные. К тому же, вам придется изрядно потратить нервы на шаблонах, ибо весь двиг точился под MSBuilder, плюс ещё потребуется портировать всё это дело под C++11/C++14. Если лень разбираться, то смотрим ветку Premissive в окси. Там я это почти закончил. Мб на днях добью


Сложно и нерентабельно.
Предлагаю порыться в шейдерах намокания поверхностей от дождя. Там есть движение развёртки. Вот эту самую фичу надо перенести на динамику и сделать движение развертки туды-сюды и привязать скорость движения развертки хотя бы к трансмиссии техники.
ForserX
Цитата(Дизель @ 15.05.2019, 19:54) *
Сложно и нерентабельно.
Предлагаю порыться в шейдерах намокания поверхностей от дождя. Там есть движение развёртки. Вот эту самую фичу надо перенести на динамику и сделать движение развертки туды-сюды и привязать скорость движения развертки хотя бы к трансмиссии техники.

Займись! Костыльно, но может помочь.
macron
Цитата(Дизель @ 15.05.2019, 16:17) *
Какие танки в x-ray? Ты там кого нагородил? В гробу я видел такие танки, без движущихся гусениц.

Я seq-текстуркой делал движущиеся (без остановки) гусеницы. Если в движок добавить фишку/колбек мгновенной смены текстуры, то вообще по желанию будет стоять или двигаться вперед/назад.
Xottab_DUTY
Цитата(ForserX @ 15.05.2019, 21:08) *
Идём дальше. GCC/Clang(aka llvm)/CMake и прочее. По тестам GCC по вероятным ошибкам проиграл остальным. На первом месте идёт кланг. НО! Не забывайте про Intel Compiler. Пока он превосходит в оптимизации остальные. К тому же, вам придется изрядно потратить нервы на шаблонах, ибо весь двиг точился под MSBuilder, плюс ещё потребуется портировать всё это дело под C++11/C++14. Если лень разбираться, то смотрим ветку Premissive в окси.

Или основную ветку OpenXRay, где всё уже работает под GCC и CMake. cool.gif
NanoBot-AMK
С вами скучно. Все реальные программисты все в делах. Ну полная кататония. Все гениальные идеи приходят после хорошей синьки. это опасно, уже потеряно некоторое количество товарищей.
Я не призываю пить алкоголь, это вредно и опасно. Но всё таки....
Молния в вакууме
Цитата(Xottab_DUTY @ 16.05.2019, 00:10) *
Или основную ветку OpenXRay, где всё уже работает под GCC и CMake. cool.gif

Братан, а есть где-нибудь инструкция как заменить обычный луабинд на тот что используется в OpenXray? Я пару раз пробовал, но всё что-то не идёт. То functor не мог найти, потом нашел что-то и что-то там ещё вылезло.
Просто я тоже собираю GCC(MinGW), и обычный луабинд им собирается из рук вон плохо, больше 10 тысяч предупреждений.

PS Заглянул недавно в дискорд а там твои сообщения за сентябрь с вопросом как работает фс в Xray2. D= Это ещё актуально?
NanoBot-AMK
Ладно.
То есть GCC компилятор не является лучшим? Но он генерируется хороший код, Я ЖЕ ПРОВЕРЯЛ идаПРО, Я БЫ НЕ СМОГ ТАКОЙ БЫСТРЫЙ КОД СОЗДАТЬ. Чёто с капслоком намудрил ладно. Я имею ввиду что нужен максимально быстрый код, быстрей просто не бывает, что тут не понятно. z_crazy.gif
Молния в вакууме
NanoBot-AMK, GCC хороший компилятор.
По моему опыту чуть генерит код чуть медленее чем майкрософтовский. LE вместе с xrCDB собранным студией у меня генерировал аи-сетку быстрее чем с xrCDB собранным GCC, но там незначительно.
С другой стороны GCC не выкидывает фокусы в виде програм работающих не так как написано в исходниках при включении оптимизации, в отличии от.
Так что в целом GCC точно не хуже MSVC.

А самое главное он легально бесплатный, интеловский придётся пиратить.
RayTwitty
Цитата(NanoBot-AMK @ 16.05.2019, 00:25) *
Я имею ввиду что нужен максимально быстрый код, быстрей просто не бывает, что тут не понятно.

Ты конечно же мерил ФПС? Насколько быстрее с быстрым кодом?
iOrange
Цитата(NanoBot-AMK @ 15.05.2019, 23:25) *
Но он генерируется хороший код, Я ЖЕ ПРОВЕРЯЛ идаПРО, Я БЫ НЕ СМОГ ТАКОЙ БЫСТРЫЙ КОД СОЗДАТЬ

Дабы успокоить мое любопытство - не покажете ли сравнение? 2 небольших кусочка - один от MSVC, второй от GCC.
Буду очень благодарен.
Xottab_DUTY
Цитата(Молния в вакууме @ 16.05.2019, 02:22) *
Братан, а есть где-нибудь инструкция как заменить обычный луабинд на тот что используется в OpenXray?

Только коммиты nitrocaster'а, к сожалению.

Цитата(Молния в вакууме @ 16.05.2019, 02:22) *
PS Заглянул недавно в дискорд а там твои сообщения за сентябрь с вопросом как работает фс в Xray2. D= Это ещё актуально?

Я уже перестал её изучать, но, в целом, до сих пор актуально. Ибо там довольно интересная фс, может пригодится)
xrModder
Цитата(NanoBot-AMK @ 16.05.2019, 03:25) *
Ладно.
То есть GCC компилятор не является лучшим? Но он генерируется хороший код, Я ЖЕ ПРОВЕРЯЛ идаПРО, Я БЫ НЕ СМОГ ТАКОЙ БЫСТРЫЙ КОД СОЗДАТЬ. Чёто с капслоком намудрил ладно. Я имею ввиду что нужен максимально быстрый код, быстрей просто не бывает, что тут не понятно. z_crazy.gif

Переписать код на каком то языке ассемблера и собрать. Быстрее уже точно не будет.
iOrange
Цитата(xrModder @ 16.05.2019, 05:29) *
Быстрее уже точно не будет.

Откуда интересно пошло это распространенное заблуждение, что если написать код вручную на ассемблере - то это будет самый быстрый вариант?

Ну ладно 20 лет назад такое прокатывало - компиляторы были тупые, процессоры простые (не очень), а многоядерность только в датацентрах.
Но сегодня то?
ForserX
Кажись я начал топик на тему "Best of the Best C++ Compiler".
Ладно, вот вам результаты тестов. Выбираем на вкус и цвет, а вообще CLang в народ!
Цитата
Казалось бы, вывод о самом эффективном компиляторе напрашивается сам собой - это Borland Builder C++. Но не стоит спешить. Многие разработчики указывают на ошибки при формировании кода у Borland Builder (в частности, при использовании ссылок его поведение становится непредсказуемым). Кроме того, Borland Builder C++ явно наследует многое от Delphi (один модификатор вызова метода DYNAMIC чего стоит), в результате чего при компилировании абсолютно правильного С++ кода могут возникать ошибки (например, отсутствие множественного наследования для VCL-классов; а все потомки от TObject являются VCL-классами).

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

MSVC++ или Intel Compiler не имеют явно выраженных недостатков, так что их позиции примерно равны.

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

(предоставлено: http://citforum.ru/programming/C_comp/)
xrModder
Цитата(iOrange @ 16.05.2019, 10:07) *
Откуда интересно пошло это распространенное заблуждение, что если написать код вручную на ассемблере - то это будет самый быстрый вариант?

Ну ладно 20 лет назад такое прокатывало - компиляторы были тупые, процессоры простые (не очень), а многоядерность только в датацентрах.
Но сегодня то?

Не думаю что это заблуждение. Программы написанные на ассемблере всегда работают быстрее (Си-шные программы не в счёт). Зачем вставляют ассемблерные вставки в коде Си/С++? Но всё это при условии ассемблериста-задрота.
cjayho
QUOTE (NanoBot-AMK @ 15.05.2019, 01:26) *
Вес установщика GCC 8.2.0 x86-32 = 86М
Вес установщика GCC 8.2.0 x86-32 = 106М


эм.. unsure.gif

QUOTE (ForserX @ 15.05.2019, 18:08) *
Пишите нормальный CPUID и работайте с Intel intrinsics. Будем вам и SSE, AVX, AES, FMA, 3DNow! и прочее.


3DNow! уже не будет. технология давно объявлена устаревшей.

QUOTE (iOrange @ 16.05.2019, 06:07) *
QUOTE (xrModder @ 16.05.2019, 05:29) *
Быстрее уже точно не будет.

Откуда интересно пошло это распространенное заблуждение, что если написать код вручную на ассемблере - то это будет самый быстрый вариант?

Ну ладно 20 лет назад такое прокатывало - компиляторы были тупые, процессоры простые (не очень), а многоядерность только в датацентрах.
Но сегодня то?


Все кто имел дело с такими штуками, скажут что будет не самый быстрый вариант а самый повторяемый. Когда точно не нужно никакой отсебятины от компилятора. В тех местах кода где может наступить бутылочное горлышко, это наиболее актуально, потому что написанный на ассемблере код будет работать всегда одинаково, в отличие от сгенеренного компилятором (разные компиляторы, даже один и тот же но разных версий или с разными флагами компиляции, генерят сильно разный итоговый код).
Diesel
Пару палок дёгдя: не тем вы занимаетесь. Умничаете. Я вот нифига в этом не шарю, но пытаюсь методом тыка, что то сварганить. Нужны опыты от вас, а не таблица Менделеева.

Вертолёт (не скриптовый) изобретите, будет вам уважуха.
NanoBot-AMK
Ассемблер не всегда быстр. Для x86-32, x86-64 надо уметь программировать, это сложные архитектуры и лепить код под них не так просто. Да. К сожалению компиляторы не всегда делают хороший код, вот тогда и выигрывает ассемблер.
ForserX
Цитата(cjayho @ 16.05.2019, 16:19) *
3DNow! уже не будет. технология давно объявлена устаревшей.

Однако 3DNow!Ext имеется. (Я про свой проц). Единственное, что мне зашло из 3DNow!/3DNow!Ext - кеширование в L1.
Цитата(NanoBot-AMK @ 16.05.2019, 16:43) *
Ассемблер не всегда быстр. Для x86-32, x86-64 надо уметь программировать, это сложные архитектуры и лепить код под них не так просто. Да. К сожалению компиляторы не всегда делают хороший код, вот тогда и выигрывает ассемблер.

Ой, ну хорош, а? Сколько уже можно со своим ассемблером?! Я конечно понимаю А вот в наше время!!111!, но оно уже прошло.
Цитата(xrModder @ 16.05.2019, 12:51) *
Зачем вставляют ассемблерные вставки в коде Си/С++? Но всё это при условии ассемблериста-задрота.

Привет SSE линейке и ей подобным. Раньше такое делали через вставки. Сейчас это можно задать разными способами, к примеру:
Код
// Говорит компилятору какие функции менять на SSE аналоги
#pragma intrinsic(pow abs...)

// А Я ХОЧУ САМ ВЫЗВАТЬ
#include <tmmintrin.h>
__m64 as;
__m64 test = _mm_abs_pi16 (__m64 as)
atanda
Вижу топик обсуждаем.
Часто после вылета в нижнем левом углу экран появляется окошко "msctfime ui". С чем оно связано и в какую сторону копать?
ForserX
Цитата(Дизель @ 16.05.2019, 16:31) *
Пару палок дёгдя: не тем вы занимаетесь. Умничаете. Я вот нифига в этом не шарю, но пытаюсь методом тыка, что то сварганить. Нужны опыты от вас, а не таблица Менделеева.

Все мы с этого начинали. Я свой опыт высказал. Дальше дело ваше.

P.S. Я забил на это всё, т.к. было пару проблем с шейдерами, а HLSL мне учить лень (я про кости)

buffy, я такое видел один раз на Win8. Больше не сталкивался. Попробуй нагуглить, мб локальная проблема
cjayho
QUOTE (ForserX @ 16.05.2019, 22:32) *
Привет SSE линейке и ей подобным. Раньше такое делали через вставки. Сейчас это можно задать разными способами, к примеру:
CODE
// Говорит компилятору какие функции менять на SSE аналоги
#pragma intrinsic(pow abs...)

// А Я ХОЧУ САМ ВЫЗВАТЬ
#include <tmmintrin.h>
__m64 as;
__m64 test = _mm_abs_pi16 (__m64 as)


можно и с помощью openMP:

CODE
#pragma omp simd
for (i = 0; i < count; i++)
{
    a[i] = b[i] + 1;
}
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.