В чем разница между многомерным массивом и массивом массивов в C#?

Это могло быть упомянуто в приведенных выше ответах, но не явно: с зубчатым массивом вы можете использовать array[row] для ссылки на всю строку данных, но это не разрешено для массивов multi-d.

Я разбираю файлы .il, созданные ildasm, для создания базы данных сборок, классов, методов и хранимых процедур для использования при преобразовании. Я наткнулся на следующее, что сломало мой разбор.

.method private hidebysig instance uint32[0...,0...] 
        GenerateWorkingKey(uint8[] key,
                           bool forEncryption) cil managed

В книге Expert .NET 2.0 IL Assembler, написанной Сержем Лидином, Apress, опубликованной в 2006 г., объясняется глава 8, Примитивные типы и подписи, стр. 149–150.

<type>[] называется вектором <type>,

<type>[<bounds> [<bounds>**] ] называется массивом <type>

** средства могут повторяться, [ ] средства необязательны.

Примеры: Пусть <type> = int32 .

1) int32[...,...] представляет собой двумерный массив неопределенных нижних границ и размеров

2) int32[2...5] представляет собой одномерный массив нижней границы 2 и размера 4.

3) int32[0...,0...] представляет собой двумерный массив нижних границ 0 и неопределенного размера.

Том

В дополнение к другим ответам обратите внимание, что многомерный массив выделяется как один большой кусок массива в куче. Это имеет некоторые последствия:

1. Некоторые многомерные массивы будут размещены в куче больших объектов (LOH), где в противном случае не было бы их эквивалентов с зубчатыми массивами.
2. GC потребуется найти один непрерывный свободный блок памяти для выделения многомерного массива, тогда как зубчатый массив может заполнить пробелы, вызванные фрагментацией кучи ... обычно это не проблема в .NET из-за сжатия , но LOH не уплотняется по умолчанию (вы должны просить об этом, и вы должны спрашивать каждый раз, когда вы этого хотите).
3. Вы хотите , чтобы посмотреть в <gcAllowVeryLargeObjects>для многомерных массивов , как до того , как проблема будет когда - либо, если вы только когда - либо использовать неровные массивы.

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

Поиск значения jagged[3][6] в зубчатом массиве var jagged = new int[10][5] работает следующим образом: найдите элемент с индексом 3 (который является массивом) и найдите элемент с индексом 6 в этом массиве (который является значением). В этом случае для каждого измерения выполняется дополнительный поиск (это дорогостоящий шаблон доступа к памяти).

Многомерный массив размещается в памяти линейно, фактическое значение находится путем умножения индексов. Однако, учитывая массив var mult = new int[10,30], то Length свойство этого многомерного массива возвращает общее число элементов , то есть 10 * 30 = 300.

Rank Свойство зубчатым массива всегда 1, но многомерный массив может иметь любой ранг. Для GetLength получения длины каждого измерения можно использовать метод любого массива. Для многомерного массива в этом примере mult.GetLength(1) возвращается 30.

Индексирование многомерного массива происходит быстрее. например, учитывая многомерный массив в этом примере mult[1,7] = 30 * 1 + 7 = 37, получите элемент с этим индексом 37. Это лучший шаблон доступа к памяти, потому что задействована только одна ячейка памяти, которая является базовым адресом массива.

Следовательно, многомерный массив выделяет непрерывный блок памяти, в то время как зубчатый массив не обязательно должен быть квадратным, например jagged[1].Length, не должен быть равным jagged[2].Length, что верно для любого многомерного массива.

Представление

С точки зрения производительности многомерные массивы должны быть быстрее. Намного быстрее, но из-за очень плохой реализации CLR это не так.

 23.084  16.634  15.215  15.489  14.407  13.691  14.695  14.398  14.551  14.252 
 25.782  27.484  25.711  20.844  19.607  20.349  25.861  26.214  19.677  20.171 
  5.050   5.085   6.412   5.225   5.100   5.751   6.650   5.222   6.770   5.305 

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

В окнах тайминги зубчатых массивов намного лучше, примерно так же, как моя собственная интерпретация того, как должен выглядеть многомерный массив, см. 'Single ()'. К сожалению, JIT-компилятор Windows действительно глуп, и это, к сожалению, затрудняет обсуждение производительности, слишком много несоответствий.

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

  8.438   2.004   8.439   4.362   4.936   4.533   4.751   4.776   4.635   5.864
  7.414  13.196  11.940  11.832  11.675  11.811  11.812  12.964  11.885  11.751
 11.355  10.788  10.527  10.541  10.745  10.723  10.651  10.930  10.639  10.595

Исходный код:

using System;
using System.Diagnostics;
static class ArrayPref
{
    const string Format = "{0,7:0.000} ";
    static void Main()
    {
        Jagged();
        Multi();
        Single();
    }

    static void Jagged()
    {
        const int dim = 100;
        for(var passes = 0; passes < 10; passes++)
        {
            var timer = new Stopwatch();
            timer.Start();
            var jagged = new int[dim][][];
            for(var i = 0; i < dim; i++)
            {
                jagged[i] = new int[dim][];
                for(var j = 0; j < dim; j++)
                {
                    jagged[i][j] = new int[dim];
                    for(var k = 0; k < dim; k++)
                    {
                        jagged[i][j][k] = i * j * k;
                    }
                }
            }
            timer.Stop();
            Console.Write(Format,
                (double)timer.ElapsedTicks/TimeSpan.TicksPerMillisecond);
        }
        Console.WriteLine();
    }

    static void Multi()
    {
        const int dim = 100;
        for(var passes = 0; passes < 10; passes++)
        {
            var timer = new Stopwatch();
            timer.Start();
            var multi = new int[dim,dim,dim];
            for(var i = 0; i < dim; i++)
            {
                for(var j = 0; j < dim; j++)
                {
                    for(var k = 0; k < dim; k++)
                    {
                        multi[i,j,k] = i * j * k;
                    }
                }
            }
            timer.Stop();
            Console.Write(Format,
                (double)timer.ElapsedTicks/TimeSpan.TicksPerMillisecond);
        }
        Console.WriteLine();
    }

    static void Single()
    {
        const int dim = 100;
        for(var passes = 0; passes < 10; passes++)
        {
            var timer = new Stopwatch();
            timer.Start();
            var single = new int[dim*dim*dim];
            for(var i = 0; i < dim; i++)
            {
                for(var j = 0; j < dim; j++)
                {
                    for(var k = 0; k < dim; k++)
                    {
                        single[i*dim*dim+j*dim+k] = i * j * k;
                    }
                }
            }
            timer.Stop();
            Console.Write(Format,
                (double)timer.ElapsedTicks/TimeSpan.TicksPerMillisecond);
        }
        Console.WriteLine();
    }
}

Проще говоря, многомерные массивы похожи на таблицу в СУБД.
Array of Array (зубчатый массив) позволяет каждому элементу содержать другой массив того же типа переменной длины.

Итак, если вы уверены, что структура данных выглядит как таблица (фиксированные строки / столбцы), вы можете использовать многомерный массив. Зубчатый массив - это фиксированные элементы, и каждый элемент может содержать массив переменной длины.

Например, псевдокод:

int[,] data = new int[2,2];
data[0,0] = 1;
data[0,1] = 2;
data[1,0] = 3;
data[1,1] = 4;

Представьте, что это таблица 2x2:

1 | 2
3 | 4

int[][] jagged = new int[3][]; 
jagged[0] = new int[4] {  1,  2,  3,  4 }; 
jagged[1] = new int[2] { 11, 12 }; 
jagged[2] = new int[3] { 21, 22, 23 }; 

Подумайте об этом как о каждой строке с переменным количеством столбцов:

 1 |  2 |  3 | 4
11 | 12
21 | 22 | 23

Многомерные массивы представляют собой (n-1) -размерные матрицы.

Так int[,] square = new int[2,2] квадратная матрица 2x2, int[,,] cube = new int [3,3,3] это куб - квадратная матрица 3x3. Пропорциональности не требуется.

Неровные массивы - это просто массив массивов - массив, в котором каждая ячейка содержит массив.

Итак, MDA пропорциональны, а JD - нет! Каждая ячейка может содержать массив произвольной длины!

Предисловие: этот комментарий предназначен для ответа на ответ, предоставленный okutane , но из-за глупой системы репутации SO я не могу опубликовать его там, где он принадлежит.

Ваше утверждение, что один из них медленнее другого из-за вызовов методов, неверно. Один медленнее другого из-за более сложных алгоритмов проверки границ. В этом легко убедиться, посмотрев не на IL, а на скомпилированную сборку. Например, в моей установке 4.5 доступ к элементу (через указатель в edx), хранящемуся в двумерном массиве, на который указывает ecx, с индексами, хранящимися в eax и edx, выглядит так:

sub eax,[ecx+10]
cmp eax,[ecx+08]
jae oops //jump to throw out of bounds exception
sub edx,[ecx+14]
cmp edx,[ecx+0C]
jae oops //jump to throw out of bounds exception
imul eax,[ecx+0C]
add eax,edx
lea edx,[ecx+eax*4+18]

Здесь вы можете видеть, что нет накладных расходов на вызовы методов. Проверка границ просто очень запутанная благодаря возможности ненулевых индексов, что является функциональностью, недоступной для зубчатых массивов. Если мы удалим sub, cmp и jmps для ненулевых случаев, код в значительной степени преобразуется в (x*y_max+y)*sizeof(ptr)+sizeof(array_header) . Этот расчет примерно такой же быстрый (одно умножение может быть заменено сдвигом, поскольку именно по этой причине мы выбираем байты для измерения степеней двух битов), как и все остальное для произвольного доступа к элементу.

Еще одна сложность заключается в том, что во многих случаях современный компилятор оптимизирует проверку вложенных границ для доступа к элементам во время итерации по одномерному массиву. Результатом является код, который просто перемещает указатель индекса по непрерывной памяти массива. Простая итерация по многомерным массивам обычно включает дополнительный уровень вложенной логики, поэтому компилятор с меньшей вероятностью оптимизирует операцию. Таким образом, даже несмотря на то, что накладные расходы на проверку границ при доступе к одному элементу амортизируются до постоянной времени выполнения в отношении размеров и размеров массива, простой тестовый пример для измерения разницы может занять во много раз больше времени для выполнения.

Я хотел бы обновить это, потому что в .NET Core многомерные массивы быстрее, чем массивы с зазубринами . Я выполнил тесты Джона Лейдегрена, и это результаты предварительного просмотра .NET Core 2.0. Я увеличил значение измерения, чтобы сделать любые возможные влияния фоновых приложений менее заметными.

Debug (code optimalization disabled)
Running jagged 
187.232 200.585 219.927 227.765 225.334 222.745 224.036 222.396 219.912 222.737 

Running multi-dimensional  
130.732 151.398 131.763 129.740 129.572 159.948 145.464 131.930 133.117 129.342 

Running single-dimensional  
 91.153 145.657 111.974  96.436 100.015  97.640  94.581 139.658 108.326  92.931 


Release (code optimalization enabled)
Running jagged 
108.503 95.409 128.187 121.877 119.295 118.201 102.321 116.393 125.499 116.459 

Running multi-dimensional 
 62.292  60.627  60.611  60.883  61.167  60.923  62.083  60.932  61.444  62.974 

Running single-dimensional 
 34.974  33.901  34.088  34.659  34.064  34.735  34.919  34.694  35.006  34.796 

Посмотрел разборки и вот что нашел

jagged[i][j][k] = i * j * k; необходимо 34 инструкции для выполнения

multi[i, j, k] = i * j * k; необходимо 11 инструкций для выполнения

single[i * dim * dim + j * dim + k] = i * j * k; потребовалось 23 инструкции для выполнения

Я не смог определить, почему одномерные массивы все еще были быстрее многомерных, но я предполагаю, что это связано с некоторой оптимизацией, сделанной на процессоре.

Я подумал, что из будущего я присоединюсь к некоторым результатам производительности .NET 5, поскольку это будет платформа, которую все используют с этого момента.

Это те же тесты, которые использовал Джон Лейдегрен (в 2009 году).

Мои результаты (.NET 5.0.1):

  Debug:
  (Jagged)
  5.616   4.719   4.778   5.524   4.559   4.508   5.913   6.107   5.839   5.270
  
  (Multi)
  6.336   7.477   6.124   5.817   6.516   7.098   5.272   6.091  25.034   6.023
  
  (Single)
  4.688   3.494   4.425   6.176   4.472   4.347   4.976   4.754   3.591   4.403


  Release(code optimizations on):
  (Jagged)
  2.614   2.108   3.541   3.065   2.172   2.936   1.681   1.724   2.622   1.708

  (Multi)
  3.371   4.690   4.502   4.153   3.651   3.637   3.580   3.854   3.841   3.802

  (Single)
  1.934   2.102   2.246   2.061   1.941   1.900   2.172   2.103   1.911   1.911

Работает на 6-ядерной машине AMD Ryzen 1600 с тактовой частотой 3,7 ГГц.

Похоже, что соотношение производительности примерно такое же. Я бы сказал, если вы действительно сильно не оптимизируете, просто используйте многомерные массивы, поскольку синтаксис немного проще в использовании.