Здравствуйте, D. Mon, Вы писали:
DM>классы для работы с SIMD
Не знаю насчет остального — но для SIMD можно использовать либо интринсики gcc, либо хинты для авто-векторизации. Да, непортабельно, но раз уж начали оптимизировать с применением SIMD — оно скорее всего и так уже непортабельно :)
Здравствуйте, Abyx, Вы писали:
A>пример — это статика vs динамика, например компиляторы С++ обычно инлайнят вызовы Сallable типов, а компиляторы обычно Си не инлайнят вызовы через указатель на функцию.
gcc обычно таки инлайнит даже при вызове через указатель, если он может определить откуда этот указатель пришел.
Легко проверить, объявив функцию как inline и скомпилировав с -Winline.
Здравствуйте, SilentNoise, Вы писали:
SN>Здравствуйте, D. Mon, Вы писали:
DM>>классы для работы с SIMD
SN>Не знаю насчет остального — но для SIMD можно использовать либо интринсики gcc, либо хинты для авто-векторизации. Да, непортабельно, но раз уж начали оптимизировать с применением SIMD — оно скорее всего и так уже непортабельно
Это все используется, но с C++ гораздо удобнее, чем с обычным с, где надо либо в рантайме решать что тебе надо, либо в режиме компиляции вручную следить что ты компиляешь.
Здравствуйте, dеnisko, Вы писали:
D>Это все используется, но с C++ гораздо удобнее, чем с обычным с, где надо либо в рантайме решать что тебе надо, либо в режиме компиляции вручную следить что ты компиляешь.
Это само собой, а на более других языках, возможно, еще удобнее чем в С++ :) Но речь то об оптимизациях.
Здравствуйте, D. Mon, Вы писали:
DM>Штуки, приходящие на ум: DM>rvalue references, move constructors, return value optimization, классы для работы с SIMD. Что из этого есть в голом Си? Я не в курсе как-то.
Ну, там всё это просто придётся фигачить врукопашную.
Здравствуйте, Ops, Вы писали:
Ops>Зачем? Если бы не было RAII, исключения в плюсах нахрен бы никому не сдались, были бы те же коды возврата.
Здрасте!
Банальный пример: return из середины функции, где по дороге нахапано ресурсов которые надо освобождать.
С RAII я просто пишу return — и всё освободится само.
Когда пишу на С мне RAII очень сильно не хватает.
Здравствуйте, Трололоша, Вы писали:
Т>Когда пишу на С мне RAII очень сильно не хватает.
Можно наколбасить подобие пулов ресурсов как в APR. Сильно выручает, +region-based memory allocation.
Здравствуйте, Трололоша, Вы писали:
Т>Здрасте! Т>Банальный пример: return из середины функции, где по дороге нахапано ресурсов которые надо освобождать. Т>С RAII я просто пишу return — и всё освободится само. Т>Когда пишу на С мне RAII очень сильно не хватает.
И? Я про то, что без RAII нет смысла для обработки ошибок что-то делать на sj/lj, потому что без него и исключения будут неудобны.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, SilentNoise, Вы писали:
SN>Здравствуйте, dеnisko, Вы писали:
D>>Это все используется, но с C++ гораздо удобнее, чем с обычным с, где надо либо в рантайме решать что тебе надо, либо в режиме компиляции вручную следить что ты компиляешь.
SN>Это само собой, а на более других языках, возможно, еще удобнее чем в С++ Но речь то об оптимизациях.
Ты получаешь не меньшую скорость при гораздо большем удобстве, по-моему это и есть самая оптимизабельная оптимизация. Ну для примера, вот у тебя есть задача реализовать свертку на интринсиках для 1,2,4 байтовых целых, приведи решение на с, увидишь что иметься для поддержания целостности программы придется очень много.
Здравствуйте, SilentNoise, Вы писали:
Т>>Когда пишу на С мне RAII очень сильно не хватает. SN>Можно наколбасить подобие пулов ресурсов как в APR. Сильно выручает, +region-based memory allocation.
Мне не тока для memory, мне ещё для всякого рода handles и для структур.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Abyx, Вы писали:
A>>не было бы RAII — был бы finally или on error и те же самые исключения
Ops>Это что же, весь стек вызовов оборачивать? Ужоснах.
нет, надо оборачивать только куски где надо освободить ресурс.
никогда чтоли не видели языков с finally? или __finally в том же Си
Здравствуйте, Abyx, Вы писали:
Ops>>Это что же, весь стек вызовов оборачивать? Ужоснах.
A>нет, надо оборачивать только куски где надо освободить ресурс. A>никогда чтоли не видели языков с finally? или __finally в том же Си
Так с RAII об этом вообще думать не нужно, если в какой-то функции нас не интересуют исключения вызываемой, то никакую дополнительную обработку писать не надо, а обработают, если надо, уровнем выше. Ну и вложенные try...finally, когда ресурсов несколько, тоже не добавляют удобства и читаемости. ИМХО, исключения без RAII очень неудобны.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Трололоша, Вы писали:
Ops>>Зачем? Если бы не было RAII, исключения в плюсах нахрен бы никому не сдались, были бы те же коды возврата. Т>Здрасте! Т>Банальный пример: return из середины функции, где по дороге нахапано ресурсов которые надо освобождать. Т>С RAII я просто пишу return — и всё освободится само. Т>Когда пишу на С мне RAII очень сильно не хватает.
и при чём тут оптимизация и исключения?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ops, Вы писали:
A>>не было бы RAII — был бы finally или on error и те же самые исключения Ops>Это что же, весь стек вызовов оборачивать? Ужоснах.
ну в Java/C# нет RAII — там ёжики грызут кактус в виде finaly, using, try with resources, или как их там.
мне их жалко, честно
Здравствуйте, dilmah, Вы писали:
ХГ>>Первое, что в голову приходит — это сортировка. Ну и вообще шаблоны + встраивание пользовательского предиката в C++ vs. функция + коллбэк в C. D>в некоторых производительных библиотеках на С сортировку делали макросами
делали.. я ещё видел так делали red-black tree's. да и думаю много ещё чего делали.
но вот сделать на макросах несколько уровней такой абстракции будет на порядки тяжелей чем на C++.
Вот та же сортировка — что получится на макросах если попытаться абстрагироваться одновременно от последовательности (то есть не тупо массивы), от типа элемента контейнера, и от функции сравнения? уже не сладко, а вот добавь ещё пару уровней абстракции, будет ещё веселей.
Когда в C++ эти абстракции естественны + отлично оптимизируются. Вот например, посмотри на ассемблерный код цикла с итераторами. все эти вызовы "функций" ctor, copy ctor, dtor, operator++, operator+=, operator*, operator!= транслируются в отдельные ассемблерные инструкции, а то и убиваются вовсе.