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

=A=L=X=!! молодец

Нет. Я не смогу
тихо смириться с этой правдой.
доле покориться...нет

....
Ты держись. Не отпускай.
Моё сердце у тебя в руках.
Ты один я тебе клянусь.
Лучик мой любимый С++.

Свет озарил мою больную душу...
Нет!
автосборкой разум    неееее нарушу
Бред!
Полночный берд в дотнете, яве и дельфях
О сиплюсплюс тебя не смею я предааать!

ИПавлов

Вот здесь больше: http://www.gamedev.ru/flame/forum/?id=138123

laMer007
Вот это у тебя баттхерт, чувак. Может, ты сравнишь свой окамл с плюсами в других тестах? ;)
Тебе никто не говорил, что СТЛ не является быстрой библиотекой? Значит, я буду первым.
А о великом и ужасном c++ amp ты слыхал?
Ну и самая гениальная мысль: "Не нравятся плюсы - не пиши на них" ;)

StiX
> c++ amp
А причем здесь С++, ставленник майкрософта? В стандарте С++ это виндового кривого инородного для С++ втиснутого через кучу костылей на данный момент непереносимого расширения языка С++ нет.

Как вы понимаете, кучи шаблонов

template<const int ItemCount>
void squareArray (int (&dest)[ItemCount], int (&source)[ItemCount])

для написания кода для фиксированных массивов, не использование итераторов и указателей, использование самих фиксированных массивов. Это все приходится делать (грысть кактус C++), тк нет настоящих динамических массивов на уровне языка, которые позволяли бы проводить нужные оптимизации компилятору.

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

В С++ с его стандартной библиотекой основанной на итераторах весьма проблематично не использовать итераторы и поэтому это чревато написанием кучи велосипедов, дублирующих стандартную библиотеку.

И так быстрыми конструкциями в современным языке C++ являются статические массивы int a[100500] и индексный доступ, а не указательный\итераторный доступ к ним, тк это позволяет проводить компиляторам современные оптимизации.

Тут упомянули OpenMP как панацея, но в стандарт языка он не входит. Имеет инородный синтаксис. Он позволяет только ручную параллелизацию (а не автоматическую параллелизацию и векторизацию или оптимизацию). Не во всех компиляторах реализован. Имеет много потенциальных мест для новых ошибок, не выявляемых на этапе компиляции.

Сейчас C++ всё больше похож на качающуюся лодку с наваленной тяжелой кучей костылей до предела. Костыли продожают наваливаться с завидной регулярностью: появление нового стандарта C++11, костыли от майкрософт: C++/CLI, C++/CX, C++AMP. Все эти большие расширения и диалекты языка C++, каждый из которых тянет в свою сторону. Они только раскачивают заваленную до предела костылями легаси лодку C++ и заваливают новыми костылями ещё более тяжёлыми и фундаментальными. Лодка С++ уже накренилась. Ждать осталось недолго...

StiX
> Ну и самая гениальная мысль: "Не нравятся плюсы - не пиши на них" ;)
Ага. Изучай D И потом хрен найдешь себе работу.
Отличный совет!

laMer007
Проблема STL-я в том, что он был написан на все случаи жизни, за универсальность приходится платить скоростью и сложностью интерфейсов.

laMer007
> В С++ с его стандартной библиотекой основанной на итераторах весьма
> проблематично не использовать итераторы и поэтому это чревато написанием кучи
> велосипедов, дублирующих стандартную библиотеку.

эх, вы батенька не видели C++ до stl эпохи... жаль, потеряли много прекрасных моментов :)

innuendo
> эх, вы батенька не видели C++ до stl эпохи... жаль, потеряли много прекрасных моментов :)
Это почти любой видел, тк начинают большинство обычно учиться с Си конструкций, а потом с конструкций языка С++, написав кучу велоспедов, а только потом берутся за стл.

innuendo
"C++ без STL это не С++" - не твои слова случайно?

nes
> "C++ без STL это не С++" - не твои слова случайно?
Да не в СТЛ основная беда, а в неправильно спроектированном языке, не рассчитанном на современные требования аппаратного обеспечения и оптимизации под них.

nes
> "C++ без STL это не С++" - не твои слова случайно?

неа :)

laMer007
О ужос! Неужели все так страшно?! Не думал что в с++ есть такие проблемы... Всегда везде говорили, что он мощный и самый быстрый...
ладно... кидаюсь проверять, беру все свои компили: ну а у меня правда только FPC, Delphi6, G++, VC++, GCC, ну яву решил не трогать... питон есть,
но в его тесте смысла мало...
Итак, начнем.
Пройдем простой тест, который указал laMer007

for(int i=0;i<csize;i++)  dst[i] = src[i]*src[i];

Взял лазарь, набрал код:

{$Define PtrArr}
{$ifdef PtrArr}
type Iarr = array[word] of longint;
     IntArr = ^IArr;
{$else}
type IntArr = array of longint;
{$endif}
const csize = 2000500;

procedure Test(src,dst:IntArr);
var i:integer;
begin
 for i:=0 to csize-1 do
  dst[i]:=src[i]*src[i];
end;

var Time:cardinal;
    a,b:IntArr;
    i:integer;

begin
 //выделение памяти
 for i:=0 to csize-1 do
  a[i]:=i*2+1;
 Time:=TimeGetTime();
 Test(a,b);
 Time:=TimeGetTime()-Time;
 writeln(time);
 //удаление памяти
end.

{$Define PtrArr} - т.е. с использованием простых указателей либо динамического массива (если не объявлен).
Поставил полную оптимизацию О3.
Тест: с дин массивами - 10мс, указатели - 12мс.
Беру Делфи6, ставлю оптимизацию. FastMM не подключал.
тот же самый код.
Тест: дин массивы - 8мс, указатели - 9.

Ладно, идем дальше.
Беру CodeLite. Пишу код:

#define csize 2000500

void Test(int *src, int *dst)
{
  for(int i=0;i<csize;i++)
    dst[i] = src[i]*src[i];
}

int main(int argc, char **argv)
{  
  int *a = (int*)malloc(csize*sizeof(int));//new int[csize];
  int *b = (int*)malloc(csize*sizeof(int));//new int[csize];
  for(int i=0;i<csize;i++)
    a[i] = i*2+1;
  unsigned long time = timeGetTime();
  Test(a,b);
  time = timeGetTime() - time;
  //std::cout << time;
  printf("%u",time);
  getch();
  return 0;
}

Сборка релиз. Компиль г++.
Тест - 26мс.
Ну ладно, захожу в настройки, вместо -О2 ставлю -О3.
Тест - 24мс.
Ладно, каюсь, не поставил -fopenmp (по-идее оптимизирует, хотя я не уверен...). Ставлю.
Тест - 24мс.
ЧЁ?! О_о КАК?! ПОЧЕМУ?!
Поставил компилятор VC++.
Тест - 24мс.
/навтыке.../

Хорошо, говорю, запускаю громозкую студиё. Ожидаю все загрузки... создаю проект, пишу тот же код...
Зборка релиз.
Тест - 15мс. Фух это уже лучше... Но все равно мало.
Залазю в настройки ставлю полную оптимизацию по скорости всего чего можно...
Тест - 10мс.  (это самый лучший, иногда рандоможно выскакивало 11-12).

Теперь гцц в кодлайте. (тот же код, но с поправками на си). Тест - 26мс.

Чтож вроде нормально... Я понял, что МинГВ со своим г++ - аццтой...
И все-таки, почему чуть больше даже у той же студии? Может у меня проц плохой? Или дело в точности timeGetTime?
Простите если вдруг случайно начну холивар...

Итак, увеличил размер до 10050000. (чтобы проще была лучше точность измерений).
G++ - лучший 127, худший 135.
VC++ - л 52мс, х 73мс.
Delphi - л 49мс, х69мс. С динамическими массивами: л 41мс, х 43мс.
FPC - указатели: л 52мс, х 65мс; дин массивы: л 48мс, х 52мс.

П.С. пичаль какая-то.