Типы данных

Вопросы программирования на Free Pascal, использования компилятора и утилит.

Модератор: Модераторы

Re: Типы данных

Сообщение Лекс Айрин » 23.12.2017 19:50:37

serbod писал(а):Объекты языка не тормозят, там самые тормоза только при выделении-освобождении мапяти.


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

Добавлено спустя 5 минут 14 секунд:
Cheb писал(а):Вот потому и тормозит, что примитивный, и кпд у него ниже плинтуса.
А не потому, что он - класс.


Не катит -- стандартный блокнот работает на порядки быстрее. И чем примитивнее код, тем быстрее он работает. Если, конечно, не использовать функции оптимизации поиска, но тут это не работает, т.к поиск/замена происходит линейно.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 4200
Зарегистрирован: 19.02.2013 16:54:51

Re: Типы данных

Сообщение vitaly_l » 24.12.2017 00:03:00

sign писал(а): 
GetMem(int64Ptr, 3 * SizeOf(Int64));
int64Ptr^ := 1;
  Inc(int64Ptr);
  int64Ptr^ := 22;
  Inc(int64Ptr);
  int64Ptr^ := 333;

Делайте лучше вот так:

SetLength(VInt64, 3);
  // Заполнение этих переменных значениями
  VInt64[0] :=   1;
  VInt64[1] :=  22;
  VInt64[2] := 333;


Почему SetLength лучше?
В смысле я понимаю что он удобнее, но почему лучше?
И что там крутого происходит с выделением памяти, нежели при GetMem?
Разве, SetLength, не делает "в тайне от программиста" GetMem?

И вообще, вот это (VInt64[0] :=   1; VInt64[1] :=  22; VInt64[2] := 333), у них загрузка значений, как работает в разжёванном виде?
Как вот эти хрени: [0], [1], [2] - превращаются в адреса памяти и как из них берётся содержимое, уж не через примитивный Inc() ли?

.
 
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3192
Зарегистрирован: 31.01.2012 16:41:41

Re: Типы данных

Сообщение Cheb » 24.12.2017 14:08:12

И чем примитивнее код, тем быстрее он работает.

Бред.
Прекращаю дискуссию.
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 619
Зарегистрирован: 06.06.2005 15:54:34

Re: Типы данных

Сообщение Лекс Айрин » 24.12.2017 20:03:19

Cheb писал(а):Бред.


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

И любое сильное ускорение современных программ это ее примитивизация, заключающаяся, например, в выкидывании лишнего кода.
Да просто переход на более примитивную базу может сильно ускорить программу. Сложность разработки, правда, сильно возрастет... но на это люди идут уже сейчас, когда требуется реалтайм система.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 4200
Зарегистрирован: 19.02.2013 16:54:51

Re: Типы данных

Сообщение vitaly_l » 24.12.2017 20:07:39

Лекс Айрин писал(а):Да ладно... еще ни один более "совершенный" код не работал быстрее

Ещё больший бред, нежели бред, который идентифицировал Cheb.
Это не дискуссия - это констатация.
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3192
Зарегистрирован: 31.01.2012 16:41:41

Re: Типы данных

Сообщение Лекс Айрин » 24.12.2017 20:26:19

vitaly_l писал(а):Ещё больший бред, нежели бред, который идентифицировал Cheb.


Это практика данная нам в ощущениях. Например, для очень скоростной работы у меня есть старичок VC. Более того, некоторые программы у меня специально стоят в довольно стареньких версиях. И не зря я написал "совершенный" в кавычках. Есть более современный код, а есть более вычищенный. Это две большие разницы! Так что переход от TMemo к более сложным компонентам должен замедлять скорость работы, но этого не наблюдается... Следовательно, код TMemo просто не отлажен. Т. к. обычно наблюдается обратная зависимость (обычно все глобальные поиски/замены я делаю в блокнотах, т. к. просто реально 500+ замен могут подвесить офисный текстовый процессор, а у меня были случаи и 4000+), то это показывает недостаток конкретной реализации компонента сделанной будто бы для галочки.
Причем, т.к. метод замены не менялся, то весь остальной код тяжело считать "слабым звеном".
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 4200
Зарегистрирован: 19.02.2013 16:54:51

Re: Типы данных

Сообщение zub » 24.12.2017 21:51:45

Лекс Айрин, vitaly_l вы любой топик превращаете в бред. хорэ уже
zub
долгожитель
 
Сообщения: 2305
Зарегистрирован: 14.11.2005 23:51:26

Re: Типы данных

Сообщение Mirage » 13.02.2018 00:54:38

Cheb писал(а):Чёзабред, наследуешь от IUnknown, делая всё ручками, или от TInterfacedObject, где всё уже сделано за нас - и класс становится со счётчиком ссылок, автоудаляющийся при присваивании nil последней ссылке на него.


Не зависит семантика классовых ссылок от того, от чего там унаследован класс. Или где такое в документации написано?
Mirage
энтузиаст
 
Сообщения: 763
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

Re: Типы данных

Сообщение MylnikovDm » 13.02.2018 09:43:39

И вообще, вот это (VInt64[0] := 1; VInt64[1] := 22; VInt64[2] := 333), у них загрузка значений, как работает в разжёванном виде?
Как вот эти хрени: [0], [1], [2] - превращаются в адреса памяти и как из них берётся содержимое, уж не через примитивный Inc() ли?

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

У первого варианта могут быть дополнительные задержки, если после каждого inc результат будет сохранятся обратно в память, как оно, вообще-то, написано. Умеет ли оптимизатор компилятора FreePascal определять, что данное значение потом не используется и его можно не сохранять в память, это надо проверять.

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

А вообще, было бы интересно посмотреть, что там в обои случаях получается "в разжёванном виде"...
MylnikovDm
новенький
 
Сообщения: 76
Зарегистрирован: 15.02.2007 21:26:10
Откуда: Челябинск

Пред.

Вернуться в Free Pascal Compiler

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 6

Рейтинг@Mail.ru