profi_r
> у него плавность движения мячика была куда лучше

скорее всего это не из-за типа используемой арифметики

> Активно используется наследование и полиморфизм.
> События - указатели на функции типа OnClick и тп.

О!!! Ну да ладно, не будем об этом...

> Так что много окон опрашиваться не будут

И в самом начале ты тоже писал:

> Там эта самая функция будет вызываться раз 100 в секунду

Ну если порядок величин таков, то можно заметить, что 100МГц процессор будет успевать выполнить миллион тактов (а у многих, надо полагать, более быстрые процессоры). Даже при самой крутой оптимизации доля времени, затрачиваемого на эту операцию, в абсолютном исчислении вообще сколь-нибудь заметно не изменится. Так что это НЕ то узкое место, которое надо подкручивать... Как там писал Агнер Фог? "Некоторые тратят уйму времени, чтобы уменьшить время реакции своей программы на несколько миллисекунд, в то время как экран монитора обновляется 60 раз в секунду..."

S_T_A_S_
> Честно сказать, мне тоже окошки придется рисовать скоро...

Рекомендую сначала немного помедитировать над X Window (и тебе, profi_r, тоже). Такого расточительного способа, как ты описываешь, AFAIK, не использует даже микрософт.

Black_mirror

В данном случае также невредно было бы в очередной раз отметить, что при некоторых (обычно справедливых) предположениях, float-ы можно обрабатывать обычными целочисленными инструкциями.

profi_r
Shr заменять на rol нельзя. И fist там не нужен. Хотя у меня что с fist что с fst работает примерно одинаково: 20-25 тактов. Только никаких классов у меня нет. Поставь в начале функции бряк и нажми Alt+8 чтобы посмотреть что VC сгенерил.

captain cobalt
Про сто раз в секунду.
У меня FPS примерно 30-80, функция вызывается при движении курсора мышки. Есть одно общее окно - 1. Примено 3 дочерних +3. Уже 4 опроса 30*4=120.
Моя цель не оптимизировать программу в целом - это пригодится везде, где есть прямоугольные области.

А что за X Window можно поподробнее?

Black_mirror
У меня измеряется не выполнение асм кода, а именно вызов функции так что может быть и 25 тактов...

fist я просто забыл поменять обратно - она у меня сразу не заработала. Я думал из-за fst. Оказалось из-за стека.

rol Почему нельзя? Я тоже думал, что нельзя, а оказывается работает.

Я смотрел что генерит компилятор - то, что надо - код такой же как на асме.

profi_r
А операция деления? Ну ладно сдвиг на 8 вправо если я не ошибаюсь занимает по 2 такта на 1 бит. И это окупается?
Это окупается, если использовать эти координаты для обращения к памяти экрана, как к массиву. Тут даже могут быть почти "бесплатные" операции. Например если имеем массив из DWORDов, то 2 младшие бита у координаты X можно просто убирать ANDом.
А сравните пример Black_mirror и Maverickа по моей ссылке :)
Поэтому иногда проше и быстрее дублировать данные, чтобы избежать преобразования типов.

Активно используется наследование и полиморфизм
Ну я же писал, что у меня плохо с терминологией. Я понимаю: адрес, регистр, dword :)
Хотя попробую увязать...
Пусть есть массив 800*600 (или какой у вас экран) заполняем его указателями на функции типа OnClick. Это делается при рисовании окон. Потом просто читаем из этого массива, обращаясь к нему используя координаты мыши.
Если окон не много, то выигрыш сомнительный, а если много и они сложные - имеем пример оптимизации по скорости в ущерб памяти. К томуже можно будет окна не целиком перерисовывать.

Хотя, честно сказать, решение достаточно низкоуровневое.
Я не уверен, что это можно эффективно реализовать на HLL.

profi_r
> А что за X Window можно поподробнее?

:-)))))))))))))))) "оконная система для юниксов на базе сокетов..."

Ключевые слова: x11, XFree86
Для первого чтения: RFC1013: X Window System Protocol, version 11.

Рекомендуется ознакомиться даже если нет планов иметь отношения с юниксами.
Ибо классика...

captain cobalt
Чето лень искать. Хоть похожа на Windows? Если коротко. Я Windows дня 3 понять не мог - на юникс чето не тянет.

S_T_A_S_
А прикольный метод, тока объемный - я уже кое-что написал. Переделывать значит тоже, что и писать новую программу. Так что я пока на ректах оставлю.

captain cobalt

Можно, только интел это делать не рекомендует, грозясь что может формат изменить.

profi_r
У меня измеряется не выполнение асм кода, а именно вызов функции так что может быть и 25 тактов...

Попытайся замерить минимальное время выполнения этого кода. Думаю больше 100 тактов там получится не должно.

rol Почему нельзя? Я тоже думал, что нельзя, а оказывается работает.

Работать он будет только в том случае если дальше поставть and eax,1. А так в битах 1-31 будет всякий мусор.

captain cobalt
Начиная с какого процессора X window начала работать _быстро_?

Такого расточительного способа, как ты описываешь, AFAIK, не использует даже микрософт.
Я лучше над этим помедитирую :)
Я же не виндос собираюсь делать, а окошки для игрушки. Там скорость важна.
И такой "расточительный" способ очень хорошо работал на 3,5MHz 8bit CPU с 42Kb RAM.
А сейчас, учитывая объемы памяти? 1Mb - тьфу ;-)
Зато по скорости конкурентов я не вижу..
Самое сложное - правильный формат данных выбрать.


profi_r
Вам оптимизировать ничего не надо. Виндос задачи дольше переключает :)

Black_mirror
Я тоже удивился когда увидел, что мусора нет. Чертовщина какаято.

profi_r
rect dd -50.0,-50.0,100.0,100.0
pt dd 100.0,100.0
В результате в eax будет 40h если использовать fist и 900000h если использовать fst, что совершенно не правильно.

А как обстоят дела с минимальным временем выполнения?

Black_mirror
Я понял почему rol работает - из-за fist - я поменял на fst и работать перестало.

Измерил такты внутри функции 100-115 тактов. Но очень часто подскакивает до 1100. Не знаю почему наверное из-за аппаратных прерываний.

Вот так такты мерю

__asm
	{
		rdtsc
		mov TactCnt.LowPart, eax
	}
__asm
	{
		fld		mx
		fsub	x
		fst		a
		fsub	sx
		fistp	b
		fld		my
		fsub	y
		fst		c
		fsub	sy
		fistp	d
		mov		eax,a
		or		eax,c
		not		eax
		and		eax,b
		and		eax,d
		shr		eax,31
	}
	__asm
	{
		push eax
		rdtsc
		sub eax, TactCnt.LowPart
		mov TactCnt.LowPart, eax
		pop eax
	}
	return;

profi_r
Я понял почему rol работает - из-за fist - я поменял на fst и работать перестало.
Перестало потому что fistp тоже менять нужно, но в любом случае rol это не правильно. И fist тоже не правильно. Если сторона прямоугольника меньше 1 а точка находится внутри, то вариант с fist будет возвращать 0.

Самое что обидно это то что координаты экранные! Тоесть они не могут быть нецелыми и не могут быть меньше 0. Но на преобразование типов почемуто тратится много времени. Вот у С++ какой --.