Давно хотел задать вопрос, возможно, глупый. Как быстрее читать/писать массив: последовательно по элементам или случайным образом(не последовательно)? На сколько велика разница?
Ну, если делать последовательно через цикл for - убирается проверка индекса.
А приведите ка примеры алгоритмов непоследовательного чтения…
Проверил код и обалдел. Последовательное чтение даёт прирост скорости в 9 раз!Speed.cs (1,3 КБ) Компилятор - C# Shell на Android(Кстати, категорически рекомендую программу C# Shell(offline C# compiler). Она позволяет запускать на телефоне коды на C#, разрабатывать их и компилировать под Windows и всё это в офлайне.)
Я бы использовал System.Diagnostics.Stopwatch. Это, что могу сказать, после беглого просмотра. Позже - потом посмотрю.
Каким образом? Можно пример?
Сколько угодно. Тесты физической памяти (оперативной, дисковой и т.д.) содержат целый набор таких алгоритмов. Чтение всех четных, затем всех нечетных, чтение “бабочкой” - навстречу, когда первая-последняя, вторая - предпоследняя и т.д., случайное чтение (номер по датчику случайных чисел). Есть и другие, более мудреные последовательности чтения.
1 лайк
В моём случае это вызвано тем, что трёхмерный массив развёрнут в одномерный.
А если четырехмерный развернете, скорость возрастет еще в разы. Это настолько очевидно, что даже можно и не измерять. Вот только опыт этот нужно ставить с медленным носителем, потому что сейчас Вы ловите разницу от времени вычисления индекса, т.е. преобразования трехмерного индекса в порядковый номер, а это не совсем то, о чем говорилось первоначально. Кстати, это одна из причин, по которой Фортран разрешает обращаться к двухмерному массиву, как к одномерному. Там это называется “обобщенный индекс”.
Такое тоже есть, правда пока не использовалось.
В смысле? Индекс везде одинаково вычисляется.
Зато он сложнее в разы. Кстати, @Sun_Serega, индексы уже не используются явно. Я перешёл на указатели, так что о проверке можно забыть во всех случаях.
Фортран сложнее всяких С++ и C# ? Спасибо, повеселили. На нем с массивами работают, как с простыми переменными, - куда уж “сложнее”. Плюс там оптимизация, заложенная в компилятор изначально…
Можно подумать, это отменяет арифметику при вычислении нужного смещения. Программирование с помощью указателей - это ассемблер прошлого века. Хотите в нем жить и мыслить на этом уровне - Ваше право, конечно.
Нет, но отменяет проверку индексатора. Т. е. порядок чтения не определяет ничего, кроме загрузки данных в кэш процессора. Именно к этому я и веду.
Предложите замену.
А можно с этого места подробнее? Расскажите, пожалуйста, как это Вы управляете кэшем процессора из своей программы? 
Ну уж это Вы сами. Я предлагал, но Вам в одном языке то не нравится, в другом -это… На деле Вам просто не хочется учить какой-то другой язык, чтобы оторваться от мышления в стиле С/С++, потому что Вы его считаете эталоном всего и единственно правильным подходом к программированию. Оно же не даром говорят, что изучение языка С в качестве первого искривляет мышление на всю жизнь.
Но, тем не менее, это важный аспект языка программирования, который следует знать программистам. Так как не факт, что им не придется писать на таких языках, в которых это пригодится. Однако, если есть способ этого избежать и не потерять сильно в скорости, то пожалуйста. Лично я без арифметики указателей живу, используя ее в редких случаях, когда без этого никак, либо решение будет проигрывать по скорости.
Знать, что указатели есть на нижнем уровне работы с памятью - это знают все программисты. А вот считать, что если в языке они есть, то к ним нужно прибегать - совсем иное. Те, кто пишут на С/С++ в силу особенностей языка иначе просто не могут. Отсюда - соответствующий стиль.
Если нужно получить эффективное, быстро работающее приложение, использующее многомерные массивы - программист уходит писать на Фортран. Либо пишет на С, вынося мозг себе и окружающим, попутно жалуясь и проклиная все и всех подряд.
Да, согласен.
Вы очень не любите, когда другие упоминают C/C++/C# или другие языки, однако сами регулярно делаете это, причём ещё агрессивней, чем, скажем, я.
Прибегать надо к тому, что позволяет писать производительный код, а не тому, что характерно стилю ЯП.
Не думаю, что стоит начинать беседу на эту тему. Главная причина - засорение темы Помощь для начинающих. Однако, я с Вами согласен в этом вопросе.
1 лайк
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021