умножение в 20 раз быстрее деления!

[gnoblin]

Math
• Add, subtract, multiply: a couple cycles
• Divide: 30-40 cycles

*0.5f в 20 раз быстрее чем /2

[Neodrop]

Блин... Не думал, что во столько
Возьму на перо.

[AndrewSt]

Блин где вы берете такие цифры.
Опять сделал тест не подтвердился.
Все зависит от типов данных который используешь.

div int: 0,002172112
mul int: 0,001509547
div float: 0,0030303
mul float: 0,004809499

Вот тестовый скрипт:

Код: Выделить всё

using UnityEngine;
using System.Collections;

public class TestMul : MonoBehaviour
{
   void Test()
   {
      {
         float k = 0;
         float startTime = Time.realtimeSinceStartup;
         for (int i = 0; i < 1000000; i++)
            k = i / 2;
         Debug.Log("div int: " + (Time.realtimeSinceStartup - startTime));
         float L = k;
      }
      {
         float k = 0;
         float startTime = Time.realtimeSinceStartup;
         for (int i = 0; i < 1000000; i++)
            k = i * 0.5f;
         Debug.Log("mul int: " + (Time.realtimeSinceStartup - startTime));
         float L = k;
      }
      {
         float k = 0;
         float startTime = Time.realtimeSinceStartup;
         for (float i = 0; i < 1000000; i++)
            k = i / 2;
         Debug.Log("div float: " + (Time.realtimeSinceStartup - startTime));
         float L = k;
      }
      {
         float k = 0;
         float startTime = Time.realtimeSinceStartup;
         for (float i = 0; i < 1000000; i++)
            k = i * 0.5f;
         Debug.Log("mul float: " + (Time.realtimeSinceStartup - startTime));
         float L = k;
      }


   }

   void FixedUpdate()
   {
      Test();
   }
}


В предыдущей (про делегаты) теме тест не подтвердил.
Может я тесты делаю не правильные?

[Neodrop]

Ага. Я же дал код. Разве у вас он дал другой результат?

[AndrewSt]

Где? Какой код?
Если вы про делегаты. То да. У меня другие результаты. Посмотрите мой пост.

[Neodrop]

Смотрел. Я привык верить собственным глазам и свой тест взял не с потолка.

[gnoblin]

Я всего лишь запостил кусок optimization guide от юнитеха, почему такие результаты дают тесты - хз .

[warr11r]

Про то ,что жэелательно использовать умножение, знал. Теперь буду знать, почему.
Но все равно странно, почему никто не оптимизировал деление, если оно настолько замедляет код.

[Neodrop]

Это вообще свойство .NET а деление - это умножение на дробное число. Так что оно вообще в принципе не особо нужно. Просто, вместо деления на 2.0 , умножайте число на 0.5

[Woolf]

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

И, кстати, разницы 0.8/2.0 или 0.8*0.5 не должно быть вообще никакой, если она есть, значит опять мелкомягкие что-то накрутили.

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

[gnoblin]

Не правда, вполне оправдано экономить.

В больших проектах (и особенно в ориентированных на слабые машины \ мобилки) по чуть-чуть добавляется отовсюду .

[Neodrop]

В MONO, который есть в Unity 3.0 этой проблемы нет. Там деление даже быстрее чем в дотнете, на сколько я помню. Но не тестил.

[sp00n]

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

Хы.. Ну вы прям... ой. Это актуально было при слабых FPU(387, 487, и т.д.), последние, как минимум, пять лет процессоры очень хорошо считают дробные числа приблизительно с той же скоростью, что и целые. Это было раз. Теперь два - насчет компиляторов (возьмем тот же С++) - включите оптимизацию и вы увидите, что в асмовском коде выражение типа int = float/2.0 будет заменено на бинарный сдвиг после приведения к int Оптимизация такого рода, имхо, нужна только для мобильных девайсов и всяких ембедед устройств. Хотя, с другой стороны, если есть привычка так писать - то это не мешает (например у меня такая привычка - на автомате использовать инты и сдвиги где только можно) работоспособности кода, единственное что - затрудняет прочтение этого кода человеком, не знающим о сдвигах.

[DbIMok]

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

мы говорим о мультиплатформенном инструменте. некоторые Android устройства не имеют аппаратного FPU.

[sp00n]

А юнити пока что нету релиза для андроид но, с приходом 3.0, конечно же будет. К тому же я писал:

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

Если же люди разрабатываю мультиплатформенные приложения с расчетом на тот же Андроид, то какбэ должны знать, что там и как. Да и не только Андроиды, возьмем к примеру Интел атом для нетбуков первой серии - это ж млин по архитектуре тот же Pentium 90 только на новой производственной технологии и с некоторыми дополнительными фичами - вот тут, например, нужна оптимизация операций с плавающей запятой. Хотя на те атомы больше стаят линукс, так как винда страшно глючит. Более поздние версии намного лучше и мой сервер, например, работающий с 1000 клиентами онлайн и переганяющий туда-сюда медиа-данные успешно работает на таком устройстве до сих пор:) При чем активно используя операции с плавающей запятой - я бы, может, и поменял на фиксированную арифметику, но глянув на спеки проца понял что выигрыш будет меньше 1%, не так как у более ранних версий. К чему это я - вот, кажись, ХТЦ выпустила новый андроид девайс с новым арм процессором - там спеки тоже весьма хорошие и фпу замечательный есть - появится у нас - скорее всего куплю Через год-два у 90% потенциальных обладателей андроидфона будет приличный фпу имхо.
оффтоп: хатю юнити под линух!!! ждемс хтмл5 и нэтив клиент от гугла