Как быстро скопировать массив в другой?

← →
Хыхы (2013-03-06 15:13) [0]

← →
Kerk © (2013-03-06 15:13) [1]

Move

← →
DVM © (2013-03-06 15:13) [2]

Move

← →
DevilDevil © (2013-03-06 15:21) [3]

статический
X := Y

динамический, копия ссылки
X := Y

динамический, уникальный
X := Copy(Y, 0, Length(Y)-1)

← →
DevilDevil © (2013-03-06 15:28) [4]

Ещё у меня есть такой код. На новых версиях не тестировал.

procedure CopyArray(const dest, source: pointer; const typeinfo: ptypeinfo; const count: integer); asm // если указан статический массив, то домножить count на общее количество элементов в массиве // а в typeinfo - базовый элемент // сделано это для того чтобы не вызывался Exception // по каким то причинам System.CopyArray не приспособлен под аргумент tkArray // наверное потому что System.CopyArray внутренняя функция и на этапе прекомпиляции всё грамотно просчитывается cmp byte ptr [ecx], tkArray jne @1 push eax push edx movzx edx, [ecx + TTypeInfo.Name] mov eax, [ecx + edx + 6] mov ecx, [ecx + edx + 10] mul count mov ecx, [ecx] mov count, eax pop edx pop eax @1: push dword ptr [ebp+8] call System.@CopyArray end;

фишка в том, чтобы скопировать несколько элементов (структур) из одного массива в другой, учитывая typeinfo рутину
в качестве typeinfo надо указывать typeinfo() элемента
если typeinfo() не берётся - то конечно Move + Count*sizeof(Item)

← →
Kerk © (2013-03-06 15:39) [5]

> DevilDevil © (06.03.13 15:28) [4]

Я вот не пойму. Нафига ты так упорно пишешь код, который не скомпилится даже в x64, не говоря уже о всяких модных платформах, которые в Delphi есть и скоро будут? :) И вообще тебе коллеги за использование асма без крайней необходимости руки линейкой еще не отбили? Нравится им это сопровождать? :)

← →
DevilDevil © (2013-03-06 16:00) [6]

> Kerk © (06.03.13 15:39) [5] > Я вот не пойму.

Я таких людей как ты называю "чёрно-белые" :)
Т.е. те, кто не привык в каждом решении видеть и плюсы, и минусы - кто делит мир на "чёрное" и "белое"

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

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

И получается, что хорошо и что плохо для кода - принципиально зависит от того, какой он. Хороший управляющий код - читабельный, логичный, багобезопасный, хорошо комментируемый, с перспективой роста. И плевать, сколько тактов выполняется управляющий код. Хороший ресурсоёмкий код - тот, который выполняется с максимальной производительностью. И плевать как он написан. С кучей дифайнов, на ассемблере или С++, хорошо он закомментирован или плохо. Главное - чтобы он работал быстро

Топикстартера интересует ресурсоёмкий код, а не управляющий. И требования к нему соответствующие

← →
Kerk © (2013-03-06 16:10) [7]

> DevilDevil © (06.03.13 16:00) [6]

Что, реально, если написать эту процедуру нормальным Delphi-кодом, она станет ощутимо более медленной? Сколько тактов процессора ты выигрываешь? Выигрываешь ли вообще? Сколько миллионов (миллиардов?) раз нужно вызвать твою процедуру, чтобы я заметил разницу на глаз?

Я вот так скажу.

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Но это ничего. Я тоже раньше такой был :)

← →
картман © (2013-03-06 16:15) [8]

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

И получается, что хорошо и что плохо для кода - принципиально зависит от того, какой он. Хороший управляющий код - читабельный, логичный, багобезопасный, хорошо комментируемый, с перспективой роста. И плевать, сколько тактов выполняется управляющий код. Хороший ресурсоёмкий код - тот, который выполняется с максимальной производительностью. И плевать как он написан. С кучей дифайнов, на ассемблере или С++, хорошо он закомментирован или плохо. Главное - чтобы он работал быстро

черно-белые, говоришь?))

← →
Kerk © (2013-03-06 16:23) [9]

> картман © (06.03.13 16:15) [8]

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

← →
DevilDevil © (2013-03-06 16:29) [10]

> Kerk © (06.03.13 16:10) [7]

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

по поводу "на глаз"... Всё меняется с ростом объёмов, которые обрабатывает ресурсоёмкий код. Для пользователя нет разницы, 1мск или 10мск. Но огромная разница между 1мин и 10мин. Кроме того на практике существуют подходы, реагирующие на объёмы не в геометрической прогрессии, а по экспоненте. То же перевыделение памяти. Недавно кстати выкладывал тест на запись текстового файла, и просто безбожно сливал TMemoryStream, который на паре килобайт показывает прекрасный результат

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

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

Ну и конечно я считаю жуткими непрофессионалами своего дела тех, кто не способен управляющий код писать логичным, структурированным и читабельным, а ресурсоёмкий код быстрым

← →
DevilDevil © (2013-03-06 16:31) [11]

> картман © (06.03.13 16:15) [8]

чёрно-белые - это люди, которые не способны взвешивать плюсы и минусы. от этого и страдают

← →
Kerk © (2013-03-06 16:37) [12]

Ну то есть ты не знаешь сколько ты выигрываешь написав ту процедуру на ассемблере. Оптимизация чисто "на глаз". Очень крутой подход, совсем не черно-белый :)

← →
Игорь Шевченко © (2013-03-06 16:51) [13]

http://www.gunsmoker.ru/2013/01/optimization-basics.html

← →
DevilDevil © (2013-03-06 16:54) [14]

> Kerk © (06.03.13 16:37) [12]

давай начнём с того что приведённый твой "код" в [1] очень даже может привести к Access Vialotion где-нибудь в неожиданном месте программы. И ты не знаешь, почему

и ты не знаешь, что лучше: сортированный массив, дерево (ты наверное не знаешь, что значит "самобалансирующееся") и хеш-массив. И совершенно точно не знаешь, как это реализовать с действительно хорошей скоростью

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

В целом, если код обрабатывает объёмы данных, если он потенциально ресурсоёмкий - сделай его быстрым, не прогадаешь - такая у меня философия. Ассемблер я использую по нескольким причинам. Во-первых, я им владею. Во-вторых, я специализируюсь на быстрых реализациях; и если существует перспектива создания универсальной библиотеки - лучше уж раз написать и больше не париться. В-третьих, иногда встречаются задачи, которые не реализуемы без ассемблера. Например некоторые части в CrystalLUA.

← →
DevilDevil © (2013-03-06 16:55) [15]

> Игорь Шевченко © (06.03.13 16:51) [13]
> http://www.gunsmoker.ru/2013/01/optimization-basics.html

read [10]

← →
Ega23 © (2013-03-06 17:03) [16]

ПАФОСПАФОСПАФОСПАФОС!!!

← →
DevilDevil © (2013-03-06 17:06) [17]

> Ega23 © (06.03.13 17:03) [16]

https://lh3.googleusercontent.com/-rWbDB61qQeE/ULbxJzb3qFI/AAAAAAAAE30/KL57A2JVWE0/s604/mantra_rossiyanina.jpg

← →
брат Птибурдукова (2013-03-06 17:09) [18]

пафосГлазамиХакера()™

← →
Kerk © (2013-03-06 17:09) [19]

> DevilDevil © (06.03.13 16:54) [14]

Добавь еще "ты совершенно точно не знаешь асма" и все, ты меня сделал! Возьми с полки пирожок :)

← →
Inovet © (2013-03-06 17:12) [20]

> [16] Ega23 © (06.03.13 17:03)
> ПАФОСПАФОСПАФОСПАФОС!!!

АПОФЕОЗАПОФЕОЗАПОФЕОЗАПОФЕОЗ!!!

← →
DevilDevil © (2013-03-06 17:13) [21]

> Kerk © (06.03.13 17:09) [19]

http://motivatory.ru/img/poster/e3c041ef94.jpg

← →
Kerk © (2013-03-06 17:14) [22]

Да прекрати уже истерику :)
Ты нереально крут, тут все это уже увидели, даже дебилы вроде меня.

← →
DevilDevil © (2013-03-06 17:16) [23]

очень хорошо, что ты это признаёшь

← →
Kerk © (2013-03-06 17:20) [24]

А знаешь что самое смешное? Ты так и не ответил на вопрос из [7] и [12]. Вместо этого ты свалился в тупую истерику. О многом говорит :) Если б тобой двигало что-то серьезнее твоих детсадовских принципов, ты бы легко ответил "вот на такой-то задаче я выигрываю полчаса" (например). Все бы посмотрели, покивали, убедились. Но нет же. Курам на смех.

← →
Ega23 © (2013-03-06 17:21) [25]

> DevilDevil © (06.03.13 17:06) [17]

Это ты вечерами читаешь?

← →
DVM © (2013-03-06 17:22) [26]

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

← →
брат Птибурдукова (2013-03-06 17:25) [27]

> DVM © (06.03.13 17:22) [26]
У Зубкова в книжке по асму сие очень доходчиво растолковано, да :-)

← →
DevilDevil © (2013-03-06 17:29) [28]

> Kerk © (06.03.13 17:20) [24]

нет, самое смешное, что я ответил - даже дважды. а ты не увидел
и ещё смешнее, что ты приятельское отношение к себе воспринимаешь как возможность самоутвердиться. причём в вопросе, в котором ты явно слаб

> Ega23 © (06.03.13 17:21) [25]

да. чтобы не походить на типичное форумное быдло

> DVM © (06.03.13 17:22) [26]

ну так на си производительность в разы бывает быстрее, чем на паскале - зависит от задачи. Только на си программы дольше компилируются, особенно на С++, язык менее удобный. Вот и получается дилема: быстрая разработка или быстрая работа программы. Я выбираю зототую середину: Delphi + оптимизация слабых мест. Ассемблер - это одна из оптимизаций. Которой я не брезгую

>По мне лучше улучшать алгоритмы на основном языке

+100500

Простой пример - умножение матриц.

Если делать в лоб, да хоть на асме:

procedure Mult_Head(const a,b: Matr; var c: Matr; n: integer);
var
i,j,k: integer;
cc: real;
begin
for i:=0 to n-1 do
for j:=0 to n-1 do begin
cc := 0.0;
for k:=0 to n-1 do cc := cc + a[i,k]*b[k,j];
c[i,j] := cc;
end;
end;

и учесть разное время доступа к строкам и столбцам путем транспонирования:

procedure Mult_Trans(var a,b,c: Matr; n: integer);
var
i,j,k: integer;
cc: real;
begin
for i:=0 to n-1 do
for j:=0 to i-1 do begin
cc := b[i,j]; b[i,j] := b[j,i]; b[j,i] := cc;
end;

for i:=0 to n-1 do
for j:=0 to n-1 do begin
cc := 0.0;
for k:=0 to n-1 do cc := cc + a[i,k]*b[j,k];
c[i,j] := cc;
end;
end;

то можем выиграть в 2-4 раза.

> DevilDevil © (06.03.13 17:29) [28]

Да я-то что, мне диагноз в этой ветке уже поставлен несколько раз.
Ты о себе беспокойся. Тяжело наверно быть Д"Артаньяном :)

> DevilDevil © (06.03.13 17:29) [28]

> ну так на си производительность в разы бывает быстрее, чем
> на паскале - зависит от задачи.

Это от компилятора в основном зависит, компиляторы си они тоже разные очень.

> Jeer © (06.03.13 17:30) [29]
> Простой пример - умножение матриц.

попробуй пожалуйста без ассемблера вызвать функцию System._CopyArray

> DVM © (06.03.13 17:34) [31]
> Это от компилятора в основном зависит, компиляторы си они тоже разные очень.

да ладно. Все пользуются майкрософтским (чтобы быстро компилировалось), gcc (бесплатно и сердито) или интеловским (понты + убер скорость)

> Kerk © (06.03.13 17:34) [30]

нет, не тяжело

> DevilDevil © (06.03.13 17:37) [33]
> нет, не тяжело

Ну вот и отлично, а то я волновался. Непризнанных гениев нужно беречь.

>попробуй пожалуйста без ассемблера вызвать функцию System._CopyArray

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

> DevilDevil © (06.03.13 17:37) [33]

> да ладно. Все пользуются майкрософтским (чтобы быстро компилировалось),
> gcc (бесплатно и сердито) или интеловским (понты + убер
> скорость)

Ну вот ты три уже назвал, прибавь еще от ембаркадеро/борланд компилятор си (многие используют), под MacOS еще свой компилятор, есть еще куча менее известных и все выдают разный код в плане быстродействия, но разница в среднем не в разы, так процентов 10-20. В этом же интервале и компилятор Delphi находится. Уж сколько сравнивали, никакого особенного отставания не было.

> Kerk © (06.03.13 17:44) [34]

говорят, всё познаётся в сравнении
на фоне неучей, которые не способны создать самобалансирующееся дерево - да, я гений

а вообще мне хватает заботящихся обо мне людей, так что не волнуйся
всё будет хорошо

> Jeer © (06.03.13 17:45) [35]
> Я дурью маюсь когда очень сильно приспичит, да и то - тыщу раз еще подумаю.

получается - ты не способен решить задачу, поставленную топикстартером
потому что правильно использовать CopyArray, а не Move, как посоветовали предшественники

> DVM © (06.03.13 17:48) [36]

я тусуюсь на gamedev.ru - там одни сипиписты
и к сожалению на всех проделанных тестах Delphi сильно сливает. В 2 раза в лучшем случае

На этой пафосной ноте дискуссию можно завершить

Как быстро скопировать массив в другой? Найти похожие ветки