The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В компиляторе G++ обеспечена поддержка C++17, opennews (?), 13-Янв-17, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


57. "В компиляторе G++ обеспечена поддержка C++17"  +/
Сообщение от Аноним (-), 13-Янв-17, 14:10 
Rust уже значительно обошел с++ по потенциалу оптимизации и безопасности кода, но по прежнему далеко отстает по библиотечной базе. Попытался тут перевести один свой C++ Qt проектик на Rust, понял сколько нужно с нуля реализовывать и забил.
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

70. "В компиляторе G++ обеспечена поддержка C++17"  +/
Сообщение от Антонимус (?), 13-Янв-17, 16:02 
>> Rust уже значительно обошел с++ по потенциалу оптимизации и безопасности кода

Давайте уже поймем, что ЛИБО оптимизация, ЛИБО безопасность.
>> Попытался тут перевести один свой C++ Qt проектик на Rust

Qt/C++ и C++ - весьма разные, вплоть до полной непохожести вещи.
>> понял сколько нужно с нуля реализовывать и забил

В смысле, с нуля Qt реализовывать?)

Ответить | Правка | Наверх | Cообщить модератору

104. "В компиляторе G++ обеспечена поддержка C++17"  +1 +/
Сообщение от Аноним (-), 13-Янв-17, 22:56 
Статический анализ, который обеспечивается в Rust'е, позволяет проверять код на безопасность, и одновременно, удивительным образом, производить оптимизации, которые в том же c++ произвести не возможно.  
Вот пример:
> void squareArrayWith100500Items (int* const dest, const int* const source)
> {
>   for (int i=0; i < 100500; ++i) {
>        dest[i] = source[i]*source[i];
>      }
>  }

C++\C, в отличии от нормальных языков, для данной функции не может провести часть оптимизаций и предрасчётов во время компиляции, не может векторизовать этот цикл, не может распараллелить его.
А всё почему?
А потому что не уверен перекрываются ли указатели dest и source. В C99 для этого ввели костыль в виде ключевого слова restrict. В языке просто нет понятия динамического массива, который бы более или менее гарантировал отсутствия перекрытий. Они эмулируются через указатели, которые не может нормально оптимизировать компилятор. И весь stl построен на указателях, оптимизация тоже не возможна.

Ответить | Правка | Наверх | Cообщить модератору

110. "В компиляторе G++ обеспечена поддержка C++17"  –1 +/
Сообщение от Аноним (-), 14-Янв-17, 02:51 
Для С++ существуют статические анализаторы, например http://clang-analyzer.llvm.org .

g++ векторизирует эту функцию, вот код сгенерированный для тела цикла:

// void square(int* const dest, const int* const source, size_t lenght)
//{
//  for (size_t i = 0; i < lenght; ++i)
//    dest[i] = source[i] * source[i];
//}

<square(int*, int const*, unsigned long)>:
               ...
start:
    movdqu (%rsi,%rax,1),%xmm1
    add    $0x1,%rcx
    movdqa %xmm1,%xmm2
    pmuludq %xmm1,%xmm2
    psrlq  $0x20,%xmm1
    pshufd $0x8,%xmm2,%xmm0
    pmuludq %xmm1,%xmm1
    pshufd $0x8,%xmm1,%xmm1
    punpckldq %xmm1,%xmm0
    movdqu %xmm0,(%rdi,%rax,1)
    add    $0x10,%rax
    cmp    %rcx,%r9
    ja     start
    ...

И распараллелить автоматически тоже может, см. OpenMP.

>> И весь stl построен на указателях, оптимизация тоже не возможна.

Ты или неуч или провокатор.

Ответить | Правка | Наверх | Cообщить модератору

121. "В компиляторе G++ обеспечена поддержка C++17"  +1 +/
Сообщение от Аноним (-), 14-Янв-17, 12:12 
OpenMP - не автоматические распараллеливание. Это костыль, созданный чтобы как-то поддержать с++ на плаву в многопоточивающемся мире. Он даже не входит в стандарт с++. Это отдельный стандарт для компиляторов.
> Ты или неуч или провокатор.

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

Ответить | Правка | Наверх | Cообщить модератору

111. "В компиляторе G++ обеспечена поддержка C++17"  –1 +/
Сообщение от Аноним (-), 14-Янв-17, 02:51 
Для С++ существуют статические анализаторы, например http://clang-analyzer.llvm.org .

g++ векторизирует эту функцию, вот код сгенерированный для тела цикла:

// void square(int* const dest, const int* const source, size_t lenght)
//{
//  for (size_t i = 0; i < lenght; ++i)
//    dest[i] = source[i] * source[i];
//}

<square(int*, int const*, unsigned long)>:
               ...
start:
    movdqu (%rsi,%rax,1),%xmm1
    add    $0x1,%rcx
    movdqa %xmm1,%xmm2
    pmuludq %xmm1,%xmm2
    psrlq  $0x20,%xmm1
    pshufd $0x8,%xmm2,%xmm0
    pmuludq %xmm1,%xmm1
    pshufd $0x8,%xmm1,%xmm1
    punpckldq %xmm1,%xmm0
    movdqu %xmm0,(%rdi,%rax,1)
    add    $0x10,%rax
    cmp    %rcx,%r9
    ja     start
    ...

И распараллелить автоматически тоже может, см. OpenMP.

>> И весь stl построен на указателях, оптимизация тоже не возможна.

Ты или неуч или провокатор.

Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

119. "В компиляторе G++ обеспечена поддержка C++17"  +/
Сообщение от freehckemail (ok), 14-Янв-17, 12:09 
> Давайте уже поймем, что ЛИБО оптимизация, ЛИБО безопасность.

Ну почему же. Бывает и так, что обе сразу, зависит лишь от того, с какой стороны глядишь. Вот, например, смотрит Racket-программист на OCaml, и понимает, что это +оптимизация, +безопасность.

Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

124. "В компиляторе G++ обеспечена поддержка C++17"  +/
Сообщение от Аноним (-), 14-Янв-17, 14:32 
То-то у меня периодически sks в режиме recon выпадает в сегфолт на ровном месте. Звизди больше.
Ответить | Правка | Наверх | Cообщить модератору

153. "В компиляторе G++ обеспечена поддержка C++17"  +/
Сообщение от iZEN (ok), 20-Апр-17, 20:19 
> Попытался тут перевести один свой C++ Qt проектик на Rust, понял сколько нужно с нуля реализовывать и забил.

Время компиляции и сборки Rust 1.16 сопоставимо с временем компиляции и сборки LLVM 3.9.
Qt - самый жирный фреймворк/набор C++ классов. Так, чтобы собрать какую-нибудь малюсенькую программку на Qt, нужно каждый раз разворачивать архив qt-everywhere-opensource-src-4.8.7.tar.gz размером 241 МБ, чего-то с ним делать и потом удалять ненужное, получая нужное (честное слово - как статую из скалы высекаешь). Вы же выбираете самое тормозное и жручее в квадратичной степени. Зачем так делать, не понимаю. Qt непопулярный фреймворк. Оконные приложения в основном пишутся/писались на Gtk2. Лично я настороженно отношусь к приложениям с Qt.

Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру