Чи ефективніше проводити перевірку діапазону, кидаючи uint, замість перевірки на від’ємні значення?

Я натрапив на цей фрагмент коду у вихідному коді списку .NET :

// Following trick can reduce the range check by one
if ((uint) index >= (uint)_size) {
  ThrowHelper.ThrowArgumentOutOfRangeException();
}

Мабуть, це ефективніше (?) Ніж if (index < 0 || index >= _size)

Мені цікаво, як обгрунтовувати цей фокус. Чи справді одна інструкція гілки дорожча за дві конверсії uint? Або відбувається якась інша оптимізація, яка зробить цей код швидшим, ніж додаткове числове порівняння?

Щоб звернутися до слона в кімнаті: так, це мікрооптимізація, ні, я не збираюся використовувати це скрізь у своєму коді - мені просто цікаво;)

З розділу I MS , розділ 12.1 (Підтримувані типи даних):

Підписані цілі типи (int8, int16, int32, int64 і рідний int) та відповідні цілі цілі без підпису (unsigned int8, unsigned int16, unsigned int32, unsigned int64 і native unsigned int) відрізняються лише тим, як біти цілого числа інтерпретуються. Для тих операцій, у яких ціле число без знака трактується інакше, ніж ціле число зі знаком (наприклад, у порівняннях чи арифметиці із переповненням), існують окремі інструкції щодо обробки цілого числа як беззнаку (наприклад, cgt.un та add.ovf.un).

Тобто перетворення з a intна a uintє лише питанням ведення бухгалтерії - відтепер, значення в стеку / в реєстрі, як відомо, є непідписаним int, а не int.

Отже, два перетворення повинні бути "безкоштовними" після того, як код буде JITted, і тоді можна буде виконати операцію порівняння без підпису.

Скажімо, маємо:

public void TestIndex1(int index)
{
  if(index < 0 || index >= _size)
    ThrowHelper.ThrowArgumentOutOfRangeException();
}
public void TestIndex2(int index)
{
  if((uint)index >= (uint)_size)
    ThrowHelper.ThrowArgumentOutOfRangeException();
}

Давайте скомпілюємо їх і подивимось на ILSpy:

.method public hidebysig 
    instance void TestIndex1 (
        int32 index
    ) cil managed 
{
    IL_0000: ldarg.1
    IL_0001: ldc.i4.0
    IL_0002: blt.s IL_000d
    IL_0004: ldarg.1
    IL_0005: ldarg.0
    IL_0006: ldfld int32 TempTest.TestClass::_size
    IL_000b: bge.s IL_0012
    IL_000d: call void TempTest.ThrowHelper::ThrowArgumentOutOfRangeException()
    IL_0012: ret
}

.method public hidebysig 
    instance void TestIndex2 (
        int32 index
    ) cil managed 
{
    IL_0000: ldarg.1
    IL_0001: ldarg.0
    IL_0002: ldfld int32 TempTest.TestClass::_size
    IL_0007: blt.un.s IL_000e
    IL_0009: call void TempTest.ThrowHelper::ThrowArgumentOutOfRangeException()
    IL_000e: ret
}

Легко помітити, що другий має менше коду, з однією гілкою менше.

На насправді, немає кидка на все, що є вибір , використовувати чи blt.sі bge.sчи використанняblt.s.un , де останній обробляє цілі числа , що передаються в якості знака в той час як колишні розглядає їх як підписані.

(Примітка для тих , хто не знайомий з КСС, так як це C # питання з КСС відповіді bge.s, blt.sі blt.s.unє «короткі» версії bge, bltі blt.unвідповідно. bltСОЗи два значення з стека і гілок , якщо перший менше , ніж другий , коли розглядаючи їх як підписані значення, покиblt.un виводить два значення стека та гілок, якщо перше менше, ніж друге, коли розглядає їх як беззнакові значення).

Це абсолютно мікро-вибір, але бувають випадки, коли мікро-опції варто зробити. Далі розглянемо, що з рештою коду в тілі методу це може означати різницю між чимось, що потрапляє всередину межі тремтіння для вкладання чи ні, і якщо вони заважають мати помічника для викидання винятків за межі діапазону, вони ймовірно, намагається забезпечити вбудовування, якщо це можливо, і додаткові 4 байти можуть все змінити.

Дійсно, цілком імовірно, що ця вбудована різниця буде набагато більшою угодою, ніж скорочення однієї гілки. Існує не так багато випадків, коли виходити з усіх шляхів, щоб переконатися, що вбудовування відбувається, того варте, але основний метод класу такого інтенсивного використання, List<T>який, безумовно, був би одним із них.

Зверніть увагу, що цей трюк не спрацює, якщо checkedзамість цього є ваш проект unchecked. У кращому випадку це буде повільніше (тому що кожен привід потрібно буде перевірити на переповнення) (або принаймні не швидше), в гіршому випадку ви отримаєте, OverflowExceptionякщо спробуєте передати -1 якindex (замість вашого винятку).

Якщо ви хочете написати це "правильно" і більш "напевно буде працювати", вам слід поставити

unchecked
{
    // test
}

навколо тесту.

Припускаючи _size, що це ціле число, приватне для списку іindex є аргументом для цієї функції, чию дійсність потрібно перевірити.

Припускаючи далі _size завжди> = 0.

Тоді початковий тест мав би бути:

if(index < 0 || index > size) throw exception

оптимізована версія

if((uint)index > (uint)_size) throw exception

має одне порівняння (на відміну від двох у попередньому прикладі.) Оскільки акторський склад просто переосмислює біти і робить >фактично непідписане порівняння, для нього не використовуються додаткові цикли процесора.

Чому це працює?

Результати прості / тривіальні, якщо індекс> = 0.

Якщо індекс <0, це (uint)indexперетворить його на дуже велике число:

Приклад: 0xFFFF дорівнює -1 як int, але 65535 як uint, таким чином

(uint)-1 > (uint)x 

завжди вірно, якщо xбуло позитивним.

Так, це ефективніше. JIT робить той самий трюк під час перевірки діапазону доступу до масиву .

Трансформація та міркування наступні:

i >= 0 && i < array.Lengthстає (uint)i < (uint)array.Lengthтому, array.Length <= int.MaxValueщо array.Lengthмає таке саме значення, як (uint)array.Length. Якщо iвиявляється негативним, тоді (uint)i > int.MaxValueперевірка не вдається.

Мабуть, у реальному житті це не швидше. Перевірте це: https://dotnetfiddle.net/lZKHmn

Виявляється, завдяки прогнозуванню гілок Intel та паралельному виконанню більш очевидний та читабельний код насправді працює швидше ...

Ось код:

using System;
using System.Diagnostics;

public class Program
{


    const int MAX_ITERATIONS = 10000000;
    const int MAX_SIZE = 1000;


    public static void Main()
    {

            var timer = new Stopwatch();


            Random rand = new Random();
            long InRange = 0;
            long OutOfRange = 0;

            timer.Start();
            for ( int i = 0; i < MAX_ITERATIONS; i++ ) {
                var x = rand.Next( MAX_SIZE * 2 ) - MAX_SIZE;
                if ( x < 0 || x > MAX_SIZE ) {
                    OutOfRange++;
                } else {
                    InRange++;
                }
            }
            timer.Stop();

            Console.WriteLine( "Comparision 1: " + InRange + "/" + OutOfRange + ", elapsed: " + timer.ElapsedMilliseconds + "ms" );


            rand = new Random();
            InRange = 0;
            OutOfRange = 0;

            timer.Reset();
            timer.Start();
            for ( int i = 0; i < MAX_ITERATIONS; i++ ) {
                var x = rand.Next( MAX_SIZE * 2 ) - MAX_SIZE;
                if ( (uint) x > (uint) MAX_SIZE ) {
                    OutOfRange++;
                } else {
                    InRange++;
                }
            }
            timer.Stop();

            Console.WriteLine( "Comparision 2: " + InRange + "/" + OutOfRange + ", elapsed: " + timer.ElapsedMilliseconds + "ms" );

    }
}

Досліджуючи це на процесорі Intel, я не виявив різниці в часі виконання, можливо, через кілька цілочисельних блоків виконання.

Але при виконанні цього на мікропроцесорі в реальному часі 16 МГц без передбачення гілок та цілочисельних блоків виконання не було помітних відмінностей.

1 мільйон ітерацій повільнішого коду зайняв 1761 мс

int slower(char *a, long i)
{
  if (i < 0 || i >= 10)
    return 0;

  return a[i];
}

На 1 мільйон ітерацій швидший код зайняв 1635 мс

int faster(char *a, long i)
{
  if ((unsigned int)i >= 10)
    return 0;
  return a[i];
}