Указатели вредят оптимизации C++ [ КРЕСТОПРОБЛЕМЫ C++ кококомпиляции ] (3 стр)

ExeLord
Дельфи всех уделал, причем старый Delphi6. Радость же!

kipar
Да, странно как-то... может это только у меня?)

Люди, кто-нить, проведите у себя такой тест...
может мне и сами ехешники выложить?

И вот раскрылся страшный заговор жидомассонов, теперь все резко начнут переходить на дельфи )

laMer007
Тараска, выжигаешь. Делфи, штоле, заточен под аппаратные нужды? Лисп?

ExeLord
>Компиль г++. -О3 -fopenmp
>Тест - 24мс.

>студиё
>Залазю в настройки ставлю полную оптимизацию по скорости всего чего можно...
>Тест - 11мс.

>Беру Делфи6
> Тест: дин массивы - 8мс, указатели - 9.

Это заговор, на самом деле все корпорации скрывают, что С++ тормозной язык и совершенно не подходит для оптимизации кода, тк язык спроектирован через заднее место. А скрывают они это потому, что сами пишут на других нормальных языках, а конкурентам впаривают мозг, чтобы те писали на непроизводительных языках, типа С++. К тому же написано уже очень много проектов и библиотек и не могут в одночасье переписать все это дело на нормальные языки. Ну и в принципе уже им просто стыдно С++ бросить, тк они очень долго впаривали ресурсы в бездонное дно /dev/null С++ и им стыдно признать свою ошибку, поэтому улыбаясь от безысходности потупив глаза в пол продолжают жрать свой кактус и говорить что на Короле великолепные платья. Но извольте... Король то голый!

ExeLord
> Да, странно как-то... может это только у меня?)
GCC из MinGW жутко тормознутый на любых тестах, сторонники оправдывают его тем, что там плохой менеджер памяти, мол в линуксе все будет ок. Правда здесь менеджер памяти не должен влиять.

Почему сливает визуал студия не знаю, но сливает она совсем на чуть-чуть. Как минимум это значит, что никакие SIMD и параллельные оптимизации в этом тесте не происходят.

Мы не успели до дедлайна,
Был нереальным срок такой.
И молодоо-ова программи-иста
Несут с распухшей головой...

забацайте код на Assembler-е, со всеми оптимизациями

begr
Мы успеели до дедлайна,
Не бывает опозданий.
И что там критики поют
Такими злыми голосами?

ExeLord

У timeGetTime квант времени близок к твоим результатам, увеличь объем теста раз в 10 хотя бы.

Опоздал. =)

Я сделал что-то не так? Я не вижу тут двух загрузок из src.

void test_OMG(int const * src, int * dst, size_t size)
{
    for (; size > 0; ++src, ++dst, --size)
    {
        *dst = *src * *src;
    }
}

int main()
{
    std::vector<int> src(5);
    std::vector<int> dst(5);

    src[0] = 1;
    src[1] = 2;
    src[2] = 3;
    src[3] = 4;
    src[4] = 5;

    test_OMG(src.data(), dst.data(), src.size());

    printf("%d %d %d\n", dst[0], dst[1], dst[2]);
}

PUBLIC  ?test_OMG@@YAXPBHPAHI@Z        ; test_OMG
; Function compile flags: /Ogtp
; File c:\users\du_hast\documents\visual studio 2010\projects\perf\test.cpp
;  COMDAT ?test_OMG@@YAXPBHPAHI@Z
_TEXT  SEGMENT
?test_OMG@@YAXPBHPAHI@Z PROC        ; test_OMG, COMDAT
; _src$ = edx
; _dst$ = eax
; _size$ = ecx

; 4    : {

  push  esi
  mov  esi, ecx

; 5    :     for (; size > 0; ++src, ++dst, --size)

  test  esi, esi
  je  SHORT $LN1@test_OMG
  sub  edx, eax
  npad  7
$LL3@test_OMG:

; 6    :     {
; 7    :         *dst = *src * *src;

  mov  ecx, DWORD PTR [edx+eax]
  imul  ecx, ecx
  mov  DWORD PTR [eax], ecx
  add  eax, 4
  dec  esi
  jne  SHORT $LL3@test_OMG
$LN1@test_OMG:
  pop  esi

; 8    :     }
; 9    : }

Nomad
> Тараска, выжигаешь. Делфи, штоле, заточен под аппаратные нужды? Лисп?
А между прочем, если бы за него взялись, то этой архитектуры языка (дельфи) больше шансов иметь лучшую автоматическую оптимизацию, чем у С++. В дельфи тоже есть свои проблемы, но об этом когда придёт Тарас.

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

kipar
С-:

du_hast
> Я не вижу тут двух загрузок из src.
Двух загрузок нет, но где наша многопоточность, где безумные инструкции умножающие числа по нескольку штук?

kipar
> GCC из MinGW жутко тормознутый на любых тестах, сторонники оправдывают его тем,
> что там плохой менеджер памяти, мол в линуксе все будет ок.
Да, в линукск все ок. На 10050000 показывает 25мс, что на С, что на С++.
Ща посмотрим fpc.