Как вам такая идея насчет inline дерективы

← →
Училка (2010-12-06 20:51) [0]

Если компилятор встречает ключевое слово inline внутри тела функции,
то все функции в скобках интерпретируются так, как будто бы они были декларированы с ключевым словом inline.

Предлагаю так же ввести еще ключевое слово inlineoff,
которая для функций декларированных с inline дерективой ее отменяет.

function f1: integer; begin Result := 1; end; function f2: integer; begin Result := 1; end; function f3: integer; inline; begin Result := 1; end; ... begin // примеры с ключевым словом inline: v1 := inline( f1 + f2 ); v2 := inline( f1 ) + inline( f2 ); v3 := inline( f1 ) + f2; v4 := f1 + inline( f2 ); v5 := f1 + f2; ... // примеры с ключевым словом inlineoff: v6 := inlineOff( f3 ) + f1; ... // допустимы сложные вложения, например: v7 := inline( f1 + f2 + inlineoff( f3 ) ); v8 := inlineoff( f3 ) + inline( f1 + inline( f2 ) + inlineoff( f3 ) ); inline ( v9 := f1 + f2 + f3; ); ... end;

← →
TUser © (2010-12-06 21:14) [1]

А смысл? Ускорение от инлайн - ноль целых и столько же десятых.

← →
Училка (2010-12-06 21:36) [2]

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

← →
Училка (2010-12-06 21:41) [3]

К первому посту, насчет приоритетов, предлагаю такое правило:
- inline при декларации функции имеет наименьший приоритет
- самая вложенная директива имеет наибольший приоритет

← →
TUser © (2010-12-06 21:49) [4]

> Смысл есть использовать может быть в небольших функциях,
> код иногда генерируется немного оптимальней.

Какой смысл, если ускорения никакого?

← →
vuk © (2010-12-06 21:58) [5]

to Училка (06.12.10 21:36) [2]:

> Сейчас если функцию объявить как inline, то она потом уже
> везде inline.

Читайте доки, они рулез. Есть директива $INLINE.

← →
Училка (2010-12-06 21:59) [6]

Ну не совсем никакого, иногда все-таки можно добиться небольшого ускорения.
И потом, если заинлайнить большой блок именно таким способом, то возможно компилятору будет легче оптимизировать. Я надеюсь :)

← →
Игорь Шевченко © (2010-12-06 22:32) [7]

От inline есть ускорение. оптимизирует не комплятор, оптимизирует процессор.
другое дело, применять inline надо с умом. Вот тут чтение доки и пригодится.

← →
Ega23 © (2010-12-06 22:37) [8]

> Какой смысл, если ускорения никакого?

Ускорение - в экономии на вызове самой функции.
Но в данном конкретном случае оптимизатор должен сам всё выкинуть нафиг.

← →
DiamondShark © (2010-12-07 14:54) [9]

> Ускорение - в экономии на вызове самой функции.

Фигня. Ускорение за счёт увеличения локальности. Ну, там, эффективность кэша, все дела...

> Но в данном конкретном случае оптимизатор должен сам всё
> выкинуть нафиг.

+100500
Ручную оптимизацию фтопку.

← →
Ega23 © (2010-12-07 14:56) [10]

> Ручную оптимизацию фтопку.

не скажи.

← →
DiamondShark © (2010-12-07 15:02) [11]

> Ega23 © (07.12.10 14:56) [10]

Уже сказал, поздняк ;)

Ну а нафиг она нужна в ЯВУ? Предлагаешь кроме собственно языка курить внутреннюю организацию конкретной версии компилятора + целевой платформы? Дык, опухнешь. Первое вообще не документируется, а бинарно совместимых целевых платформ существует десятка полтора.
Смысл?

← →
Ega23 © (2010-12-07 15:13) [12]

> Ну а нафиг она нужна в ЯВУ?

procedure TForm2.DBGrid1DrawColumnCell(Sender: TObject; const Rect: TRect; DataCol: Integer; Column: TColumn; State: TGridDrawState); begin (Sender as TDBGrid).DataSource.DataSet.DisableControls; try (Sender as TDBGrid).DataSource.DataSet.First; while not (Sender as TDBGrid).DataSource.DataSet.Eof do begin if (Sender as TDBGrid).DataSource.DataSet.FieldByName("AAA").AsString = "AAA" then begin ...... end; end; finally (Sender as TDBGrid).DataSource.DataSet.EnableControls; end; end;

Совсем не нужна, ага. :)

← →
DiamondShark © (2010-12-07 15:29) [13]

> Ega23 © (07.12.10 15:13) [12]

В огороде бузина, в Киеве дядька.

← →
han_malign (2010-12-07 16:55) [14]

> Какой смысл, если ускорения никакого?

- ну-ну - бета-редукцию фтопку...
Скомпилируйте ZLib, или libav, или crypto++(ц-шные) с отключенным инлайнированием и посмотрите какое оно никакое...

← →
TUser © (2010-12-07 17:06) [15]

Реальное ускорение достигается выбором оптимального алгоритма. А всякие там inline, не inline, ну дадут они 0,1%. Ну, выбор языка еще 5% (а скорее 1%). Наверное, в программах для каких-то очень критических, риалтаймовых вещей, ступень ракетоносителя включать или на БАКе пучки двигать, оно может и важно. Но тогда - какой Делфи? асм в зубы и пишите оптимально.

Имхо, разумеется.

← →
TUser © (2010-12-07 17:12) [16]

Или вот есть - для любителей яву

http://www.cminusminus.org/

← →
Ega23 © (2010-12-07 17:17) [17]

> Реальное ускорение достигается выбором оптимального алгоритма.

function ReverseString(const Value: string): string; var i: Integer; begin Result := ""; for i := Length(Value) downto 1 do Result := Result + Value[i]; end; function ReverseString(const Value: string): string; var i: Integer; begin SetLength(Result, Length(Value)); for i := Length(Value) downto 1 do Result[i] := Value[i]; end;

← →
TUser © (2010-12-07 17:20) [18]

угу, именно это пример и иллюстрирует

Result[i] := Value[length(Value)-i+1];

← →
Ega23 © (2010-12-07 17:22) [19]

> Result[i] := Value[length(Value)-i+1];

Во-во, так даже круче.

Я, собссно, к чему: лучший оптимизатор - это мозги.

← →
Rouse_ © (2010-12-07 19:08) [20]

> TUser © (07.12.10 17:06) [15]
>
> Реальное ускорение достигается выбором оптимального алгоритма

Логично, но не всегда верно, на днях оптимизировал алгоритм округления вызываемый при редактировании ячейки таблицы несколько миллионов раз (среднее кол-во вызовов при редактировании более полутора миллионов итераций). Задача - оптимизировать округление числа типа Currency до двух после запятой.
Хоть заоптимизируйся, но иной алгоритм действий не придумаешь, метода составления документа придуманная не нами не позволяет - поэтому пришлось как обычно отказываться от потуг компилятора не желающего уходить от system.__llmod и переписать все нафиг с девизом "здравствуй FRNDINT" с нивелированием тысячной части на этапе округления.

← →
Rouse_ © (2010-12-07 19:24) [21]

А ну и по поводу прироста скорости.
Оригинальный алго выдавал 1.4 секунды на миллионе итераций, а переписанный на асме с использованием матсопроцессора 0.3 сек на том-же объеме.
Выводы делай сам.

← →
DiamondShark © (2010-12-07 19:35) [22]

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

Не то оптимизировали.

Метода не нами придумана :) Требуецо округлить - значит надо :)

> Rouse_ © (07.12.10 19:38) [23]

Получается парадоксальная ситуация.
Хорошие специалисты алгоритмисты разгребают чужое гуано. Да даже не разгребают, а так, лопушками прикрывают.

Что-то в этом есть фундаментально неправильное.

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

А без вызова полтора миллиона раз никак?

неа - иначе смета не сойдется :)

Сурово. Верится с трудом, но всякое бывает.

А весь расчёт сколько времени занимает.

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

оптимизаторы хреновы

лужа стерпит :)

Как вам такая идея насчет inline дерективы Найти похожие ветки