ООП как лучше, и почему так.

[optimist32]

ГУРУ ПОМОГИТЕ РАЗОБРАТЬСЯ
Написал классическую прогу по перебору с возвратом, на примере игры "Ход конём". Понял, что управляемый код не для таких программ, где важен каждый такт процессора.
Вариант 1:
Можно сказать без ООП.
Описал глобальные переменные. Написал функцию перебора.
глобальные данные...
Perebor();
В обоих случаях функция "висячая", тоесть работает по типу
while(true)
{
//тут перебор идет, используя только наши данные
}

Вызываем фун-цию получаем 10.5 миллионов в секунду.
Вариан 2:
С ООП.
Создал класс Desk. Описал те же данные, но внутри класса Desk.
Создал метод перебора. Потом делаю так.
Desk desk = new Desk(6,6);
desk.Perebor(minMove);
Perebor - начинает работать с полями своего класса, получаем скорость
уже 6 миллионов в секунду

Заглянул в ассемблерский код, увидел там следущее(см. картинку во вложении)

Тоесть присутствуют лишние mov, чтобы указать на this нашего класса Desk. Это для нас является расточительной роскошью.
Внимание вопрос. Как используя подход ООП, создать быстрый и красивый код в критических приложениях?

Вот фун-ция перебора, хотя это не важно, тут вопрос только организации данных, полагаю.

1. 
   while (true)
               {
   				p_tmp = p_activeCell->p_Neighbour[ p_activeCell->current_index];//index];
   				if (p_tmp->cell_value == 0) // если сосед свободен,
                   {
   					p_activeCell->current_index++;
                       currentValue++;
                       last[currentValue] = p_activeCell;// запомним в памяти ячейку из которой уходим
   					p_tmp->cell_value = currentValue;
   					p_activeCell = p_tmp;
                       isPozitive_lastMove = true;
   			    }
                   else //если сосед не свободен
                   {
                       //пытаемся наити сдедующиего свободного соседа этой ячейки
   					p_activeCell->current_index++;
   					while (p_activeCell->current_index == p_activeCell->count_Neighbour) 
                       {
   						//то возможно это тупик      
   						if (isPozitive_lastMove) //если прошлое движение было вперед, а щас мы отступаем - то тупик
   						{
   							total++;//   if (total == 2) {}
   							////      Stats_table[CurrentValue]++;
   						    if(total % tot_MIL_local == 0)
   								std::cout << total << std::endl;
   							
   						}
                           // до отступления обновим возможные ходы в ячейке из которой уходим
   					    p_activeCell->current_index = 0;
                           // трем значение в ячейке при отступлении
   					    p_activeCell->cell_value = 0;
                           isPozitive_lastMove = false;
   					    p_activeCell = last[currentValue] ;
                           if (--currentValue == 0 )//если вернулись в нулевый ход - значит перебрали всё
   						   return total;
                       }
   
                   }
               }

[optimist32]

есть тут специалисты или этот форум мертвый

[counter]

>>но 5 тактов и 7 тактов

наверное это связано с образованием неявного указателя (this) внутри объекта на самого себя и поэтому ничего с этим не поделаеш?...

а как с оптимизацией алгоритма перебора? или объявления членов статиками, чтоб не вызывался this?

ps. возможно я не прав...

[m0nax]

я совсем не гуру, но разве может ООП версия работать так же быстро хотя бы теоретически?
ООП ведь придуман не для оптимизации, а для удобства и ясности кода, при небольших потерях скорости

[optimist32]

Сообщение от counter

>>но 5 тактов и 7 тактов

наверное это связано с образованием неявного указателя (this) внутри объекта на самого себя и поэтому ничего с этим не поделаеш?...

а как с оптимизацией алгоритма перебора? или объявления членов статиками, чтоб не вызывался this?

ps. возможно я не прав...

Спасибо, что четко поняли тему. Да это связанно как раз с этим this->
Получается только один выход, который я вижу. Создать локальные объекты-прокси внутри метода на его входе, а на выходе из него, скопировать
в реальные поля класса... Иначе сложно придумать что-то. Как Вам идея такая?

Дополнительный вопрос по теме. Почему компилятор не вставляет вместо конструкции

адресс =
this->class1->class2->class3->value

реальный адресс ячейки
move ecx, dword ptr[ адресс ]

а компилирует так

move eax, [this]
move edx, [eax + смещение_1]
move ecx, [edx + смещение_2]

и тока теперь в ecx у нас адрес!!!!!

PS: давайте посоревнуемся в оптимизации, я неуверен что даже весь отдел microsoft врядли улучшат этот код, хотябы на 1%
Эту версию можно смело засовывать в любые задачи по перебору...

Сообщение от m0nax

я совсем не гуру, но разве может ООП версия работать так же быстро хотя бы теоретически?
ООП ведь придуман не для оптимизации, а для удобства и ясности кода, при небольших потерях скорости

ООП - это всё современное корпоративное программирование. Врядли оно хоть сколько-нибудь ущербно

[Пепел Феникса]

в С++ не думаю что есть потери.

[MasterGH]

Если гнаться за скоростью выполнения, то ни какого ООП - писать надо на С технологией CUDA. А также, скорее всего, с ассемблерными вставками.