Войти
ПрограммированиеФорумОбщее

Что быстрее (2 стр)

Страницы: 1 2 3 410 Следующая »
#15
0:54, 20 июля 2009

Очень кстати симпатично откомментировано, поучительно.

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

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


#16
1:07, 20 июля 2009

А касательно оригинального поста:
inline bool CollisionCircleVsCircle(Object &object1, Object &object2)
{
}
должен вполне вменяемо отработать :)
Возьми в конце концов напиши разные варианты и замерь на допустим 100 млн тестовых выполнений функции. В релиз билде. И узнаешь что быстрее.

#17
1:15, 20 июля 2009

red noise
Там топик стартер явно подсказал 'try to make it faster'. Вот и try. Все ясно как белъй день - и уровень чайника того, и автора и цель написания.

#18
1:38, 20 июля 2009

OberMeister
> Где-то я читал что передавать отдельными переменными правильнее чем классами и
> структурами.
Чем отличается указатель/ссылка на класс/переменную/структуру? как они могут отличатся?? там только адрес передается... и помоему лучше передать 2 объекта, нежели 6 переменных или указателей на них... 0_о

Yamazaru
> Если не больше 2-3 [s][b]32-bit[/b][/s] [b]int[/b] input переменных, то оптимальнее передавать по
> отдельности, есть вероятность что они окажутся в регистрах или как immediate
> value. Если их больше, то ссылка или указатель на класс лучше. Это для IA32.
+1

#19
2:08, 20 июля 2009

Z
Такими "оптимизациями" невозможно добиться чего-то, кроме ухудшения читаемости и юзабельности кода. Посмотрел бы я на тесты производительности до и после "оптимизации", но самое главное горе-оптимизатор забыл - какая досада.
Что за ересь вообще пропагандируется в этом треде? Кэш, ветвление, инлайны, регистры - об этом всем позаботится компилятор гораздо лучше, чем сможете вы, даже потратив целый день на один вызов функции. Нужно оптимизировать сами алгоритмы, от оптимизации таких мелких деталей реализации весь цивилизованный мир уже давно отказался в пользу читаемости, поддерживаемости и универсальности. Вы застряли в 80-х годах.

#20
2:35, 20 июля 2009

kvakvs
По этой функции интреснее другой вопрос - а используется ли внутри sqrt? :)

#21
2:38, 20 июля 2009

red noise
> Кэш, ветвление, инлайны, регистры - об этом всем позаботится компилятор гораздо
> лучше, чем сможете вы, даже потратив целый день на один вызов функции
Извините, что банальничаю, но с въсотъ какого опъта ето говорится? Интересно узнать про цивилизованнъй мир, да.

#22
9:47, 20 июля 2009

Z
Цивилизованный мир уже постепенно забывает плюсы, как страшный сон :)

#23
10:04, 20 июля 2009

red noise
> Нужно оптимизировать сами алгоритмы
+1
Z
> Извините, что банальничаю, но с въсотъ какого опъта ето говорится? Интересно
> узнать про цивилизованнъй мир, да.
Оптимизировал я как-то физику для одного проекта. Там был хот поинт в подсчете тензора. Я долго извращался с микро-оптимизациями, вроде "Кэш, ветвление, инлайны, регистры", прирост в скорости был, но не значительный. Гораздо больше я выйграл поменяв порядок математических операций и избавившись от 2-3 лишних умножений на матрицу.
В 99% случаях надо оптимизировать алгоритмы, особенно, это касается геймдева.

#24
10:16, 20 июля 2009

Надо юзать MMX. Что-то вроде

;mm0 - x2|y2
;mm1 - x1|y1
mov     eax,[radius1]
psubsw  mm0,mm1          ;x3=x2-x1; y3=y2-y1
pmaddwd mm0,mm0          ;a=x3*x3+y3*y3
movd    edx,mm0
add     eax,[radius2]    ;b=radius1+radius2
emms
mul     eax              ;b=b*b
sub     eax,edx           
sar     eax,31
not     eax              ;return a<b;

P.S.
Да и лучше передавать 2 указателя вместо 6.

#25
10:25, 20 июля 2009

murder
Там все во флоатах

#26
11:16, 20 июля 2009

red noise
Видел на одной из бумажек слово PPU ?
Cell BE не станет прятать от тебя все радости кеш-миссов, бранчинга и т.д.
Да и основная его сила в куче 128-bit SIMD SPU, которым вот такой PC-like код просто рубит крылья.

#27
11:33, 20 июля 2009

какбэ и на х86 разница отлична измерима и будет не проценты и даже видимо не десятки процентов

#28
11:43, 20 июля 2009

Capcha
Я думаю копилятор должен сделать один и тот же код в обоих случаях...
Но второй код явно хуже изза указателей...

red noise
Согласен...

Реальный ботлнек всё равно будет упираться в какойнить филрейт или батчкост и всем будет накласть на ваши мини оптимизации, где вы выжали 0.1%... Это просто оптимизация ради оптимизации... Я не вижу ничего плохого в том, что код может работать чуть медленее, но при этом его читабельность выше в разы, за исключением очень критических участков, которые будут являться ботлнеками...

#29
11:57, 20 июля 2009

VirT
> В 99% случаях надо оптимизировать алгоритмы, особенно, это касается геймдева.
Ето труизм, он сам по себе мало чего дает.
Да, ето так - в данном случае первое предложение автора бъло именно поменять алгоритм, и не отсекать *одну* сферу, *одной* плоскостью.
Тупо преобразование кода из for_each sphere do for each plane do sphere->Test( plane ) в CullSpheres( spheres, frustum ), где осознано кулятся *несколько* сфер, *фрустумом*.

Страницы: 1 2 3 410 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.