Это нормально?

← →
vpbar © (2007-10-03 21:11) [0]

Щас роюсь в исходниках (blackbox) и увидел там ЭТО
if ( TextSize.cx >= ( TaskWidth - taskIconSize - 6 ) ) { drawLeft = false; DrawText(); } else { drawLeft = true; DrawText(); }
Меня удивило. Ладно неоптимально - некоторые компиляторы С могут это оптимизировать. Но даже писать такое мне лично - лень.
Ведь так
drawLeft=TextSize.cx < ( TaskWidth - taskIconSize - 6 ); DrawText();
короче и понятней.
Итересно от чего возникают такие перлы? Лень думать. Или просто исторически при эволюции кода.
И как часто такое встречается в реальном коде? Мне такое впервый раз попалось. Я правда в основном код компонентов и примеров на Делфи читал и там ляпы если и были, то по-интеллектуальнее.

← →
Delphi User (2007-10-03 21:29) [1]

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

← →
tesseract © (2007-10-03 22:00) [2]

> И как часто такое встречается в реальном коде? Мне такое
> впервый раз попалось. Я правда в основном код компонентов
> и примеров на Делфи читал и там ляпы если и были, то по-
> интеллектуальнее.

Я иногда такое оставляю. На будущее - для рефакторинга и читать приятнее. Да и откуда ты знаешь насколько эффективен оптимизатор Delphi ?

← →
homm © (2007-10-03 22:04) [3]

> Да и откуда ты знаешь насколько эффективен оптимизатор Delphi?

Оптимизатор дельфи эффективен на столько, что сразу за последней закрывающей скобкой в первой строке и перед «else» выдаст ошибку компиляции, т.к. межжду ними пусто :)

← →
tesseract © (2007-10-03 22:06) [4]

> Оптимизатор дельфи эффективен на столько, что сразу за последней
> закрывающей скобкой в первой строке и перед «else» выдаст
> ошибку компиляции, т.к. межжду ними пусто :)

Там ещё then не хватает, я заметил.

← →
homm © (2007-10-03 22:08) [5]

> [4] tesseract © (03.10.07 22:06)
> Там ещё then не хватает, я заметил.

Естественно, пусто = не хватает :)

← →
vpbar © (2007-10-03 22:13) [6]

>>tesseract © (03.10.07 22:00) [2]
if (barIcons && IconHop) { GetTextExtentPoint32(DBuffer, TaskName, strlen(TaskName), &TextSize); if ( TextSize.cx >= ( TaskWidth - taskIconSize - 6 ) ) { drawLeft = false; DrawText(); } else { drawLeft = true; DrawText(); } } else { DrawText(); } приятнее читать чем это???
if (barIcons && IconHop) { GetTextExtentPoint32(DBuffer, TaskName, strlen(TaskName), &TextSize); drawLeft=TextSize.cx < ( TaskWidth - taskIconSize - 6 ); }; DrawText();
Нуу. В первом случае придется подумать что DrawText() вызывается в любом случае. А во втором все понятнее, по моему.
>>Да и откуда ты знаешь насколько эффективен оптимизатор Delphi ?
Код смотрел который он генерит. В отношении эффективности оптимизатора Делфи в данном случае сиильно проигрывает тому же Visual C.
ЗЫ. А на будующее я тчательнее планирую интерфейсы и не оставляю ничего лишнего.
ЗЗЫ Ну почему в С++ нет аналога делфийского with...

← →
DVM © (2007-10-03 22:15) [7]

> Ну почему в С++ нет аналога делфийского with...

там и без него своих граблей полно

← →
vpbar © (2007-10-03 22:16) [8]

>>DVM © (03.10.07 22:15) [7]
Эт точно.
>>[3],[4]
Могу переписать пример на Делфи. Все равно от этого суть не изменится, только букв прибавится.

← →
tesseract © (2007-10-03 22:17) [9]

> В отношении эффективности оптимизатора Делфи в данном случае
> сиильно проигрывает тому же Visual C.

RSDN приводил совершенно другие результаты.

> Нуу. В первом случае придется подумать что DrawText() вызывается
> в любом случае. А во втором все понятнее, по моему.

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

> ЗЗЫ Ну почему в С++ нет аналога делфийского with...

ЗЗЫ Ну почему в Delphi такой гемор с boolean....

> ЗЫ. А на будующее я тчательнее планирую интерфейсы и не
> оставляю ничего лишнего.

Маладой ещё. Один и тот же код можно в 50 проектах использовать, с мелочными варияциями.

← →
vpbar © (2007-10-03 22:34) [10]

>>tesseract © (03.10.07 22:17) [9]
>>RSDN приводил совершенно другие результаты.
Даа? А я там наоборот видел. Давай приведем ссылки .

>>нет, первый понятнее. Там алгоритм яснее - это запросто может быть закладка на добавление алгоритма. Ну или генератор такое выдал :-)
Кому как. (В смысле спорить не буду, но останусь при своем месте). Про генератор я тоже подумал - ему позволено такое выдавать. :)

>>Маладой ещё. Один и тот же код можно в 50 проектах использовать, с мелочными варияциями.
Ну не намного воложе тебя, но видимо метод Copy-Paste еще не достаточно освоил :)

← →
vpbar © (2007-10-03 22:40) [11]

Вот сравнение эффективности компиляторов http://www.rsdn.ru/summary/590.xml
В основном Делфи отстает от C

← →
DVM © (2007-10-03 22:43) [12]

Только вот Делфи компилирует за считанные секунды то, что С может компилировать час.

← →
sdubaruhnul (2007-10-03 22:46) [13]

Код:

drawLeft=TextSize.cx < ( TaskWidth - taskIconSize - 6 ); DrawText();

намекает, что развитие этой программы остановилось.

← →
celades © (2007-10-03 22:49) [14]

> Только вот Делфи компилирует за считанные секунды то, что
> С может компилировать час.
>

пользователю время компиляции безралично.

← →
vpbar © (2007-10-03 22:54) [15]

>>DVM © (03.10.07 22:43) [12]
Нуу не настолько медленее, но да. Но по моему лучше час подождать при компиляции, но получить более качественный код.
>>sdubaruhnul (03.10.07 22:46) [13]
Да. Видимо та этажерка условий что я приводил - намек на то что программе еще развиваться и развиваться.

Перефразирую анек, вспомнилось :)
"Недоделанный код - это еще ничего. Главное детей доделывайте. А то этот круг не разорвать."

← →
DVM © (2007-10-03 23:00) [16]

> пользователю время компиляции безралично.

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

> Но по моему лучше час подождать при компиляции, но получить
> более качественный код.

Иногда этого часа нет. Да и бывает не час, а всю ночь компилируется.

← →
tesseract © (2007-10-03 23:10) [17]

> В основном Делфи отстает от C

Ты сказал "значительно".

← →
homm © (2007-10-03 23:11) [18]

> [16] DVM © (03.10.07 23:00)
> > пользователю время компиляции безралично.
>
> ему также безразлично, что какой то кусок программы будет
> выполняться 100 или 200 микросекунд.

Зато ему важна скорость написания программы, в которую входит и времяна копиляцию, помноженная на несколько сотен

← →
tesseract © (2007-10-03 23:25) [19]

> Зато ему важна скорость написания программы,

Ну delphi тут без конкуренции практически....

← →
DVM © (2007-10-03 23:32) [20]

> Ну delphi тут без конкуренции практически....

C# + MSVS ему конкурент, причем сильный.

← →
homm © (2007-10-03 23:34) [21]

> [20] DVM © (03.10.07 23:32)
> C# + MSVS ему конкурент, причем сильный.

Вот и скажи, как в нем пути настроить :)
http://delphimaster.net/view/15-1191439038/

← →
DVM © (2007-10-03 23:44) [22]

> Вот и скажи, как в нем пути настроить :)

Для MSVS2005:

Tools - Options - Projects and Solutions - VC++ Directories - Show Directories For (выбираешь нужное ниже добавляешь папки)

← →
antonn © (2007-10-03 23:46) [23]

> Иногда этого часа нет. Да и бывает не час, а всю ночь компилируется.

серьезно, что ли?

← →
DVM © (2007-10-03 23:49) [24]

> серьезно, что ли?

Да, а что удивительного? Большой проект может и больше компилироваться со всеми зависимостями.

← →
antonn © (2007-10-03 23:55) [25]

ну большой проект понятие относительное. Я так подумал, что где дельфи компилит за считаные секундны там С может ночь гонять :)

← →
homm © (2007-10-04 00:14) [26]

> [22] DVM © (03.10.07 23:44)

Спасибо :)

← →
Zeqfreed © (2007-10-04 05:36) [27]

> DVM © (03.10.07 23:49) [24]

Проблем особых нет. 4 ядра, 8 Гб оперативки — 15 мин. компиляция сложного проекта :) Для ежедневных билдов самое оно, зато люди отвыкают от метода разработки «написал строку - запустил - посмотрел не сломалось ли».

← →
DVM © (2007-10-04 07:13) [28]

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

это да, у самого такая привычка

← →
KSergey © (2007-10-04 09:11) [29]

> Zeqfreed © (04.10.07 05:36) [27]
> 15 мин.
> Для ежедневных билдов самое оно

Ну... вообще-то и 8 часов проект собирался для ежедневных билдов - проблем не было. Главное за ночь успевать :)

← →
Игорь Шевченко © (2007-10-04 09:31) [30]

DVM © (03.10.07 22:15) [7]

> там и без него своих граблей полно

Не больше чем в Паскале

← →
pasha_golub © (2007-10-04 09:54) [31]

> vpbar © (03.10.07 22:40) [11]
>
> Вот сравнение эффективности компиляторов http://www.rsdn.
> ru/summary/590.xml
> В основном Делфи отстает от C

Цитату можно мне в лицо? А то я дурень даже и близко сравнения компиляторов Д и С не вижу.

← →
vpbar © (2007-10-04 10:22) [32]

>>pasha_golub © (04.10.07 09:54) [31]
Ниже приведены их результаты и результаты выполнения нашего нового Float-теста.
Float-тест Компилятор Время VC7 1.62 bcc 2.55 C# 3.14 gcc 3.43 Delphi6 3.72 vc6 4.75 bcb 5.47 Java 5.73 Intel C++ 7.34 VB6 13.28

Таблица 1. Результаты нового Float-теста.

Расклад сил в новом тесте кардинально изменился. Лидером на сей раз стал VC7. Второе место, и это можно считать сенсацией, занял bcc. Он традиционно отставал во всех тестах (в том числе и в первом Float-тесте), но в новом тесте вырвался на вторую позицию, причем с очень недурным результатом. На третьем месте – C#. Интересно, что в этом тесте он показал лучший результат, если не производилась прекомпиляция утилитой ngen! Мы произвели отдельное тестирование с и без использования этой утилиты, а также привели результаты, полученные на бете 2 (с ngen). Эти результаты можно увидеть в таблице 3. В любом случае столь высокий показатель «управляемого» компилятора говорит о большом потенциале платформы .Net, да и управляемых платформ (вроде Java) в целом.

← →
tesseract © (2007-10-04 10:31) [33]

> vpbar © (04.10.07 10:22) [32]

Некропостер, да и с float в RAD-ах можно обойтись.

← →
vpbar © (2007-10-04 10:31) [34]

>>tesseract © (03.10.07 23:10) [17]
>>Ты сказал "значительно".
И где я это сказал?
Или ты имел ввиду это " В отношении эффективности оптимизатора Делфи в данном случае сиильно проигрывает тому же Visual C."
Но в этой строчке только то что написано. В данном (см[0]) случае оптимизатор делфи хуже чем Visual C. А именно, делфи не вынес общее код. Хотя можно было.
В других случаях делфи не сильно проигрывает, а иногда выигрывает, например, при работе с памятью. Но это заслуга не оптимизатора, а его менеждера памяти.
ЗЫ. Будет время сделаю сравнение кода генерируемого Delphi7, TurboDelphi, Visual Studio 2005 и MinGW.

ЗЗЫ Во как, стоило привести код на С++ сразу началось обсуждение кто лучше. Хотя язык к в данном вопросе значения мало имеет, ИМХО.

← →
jack128_ (2007-10-04 10:32) [35]

> А то я дурень даже и близко сравнения компиляторов Д и С
> не вижу.

не только с и д, но и джава и vb
http://www.rsdn.ru/article/devtools/perftest.xml

← →
DVM © (2007-10-04 10:54) [36]

> Игорь Шевченко © (04.10.07 09:31) [30]
> DVM © (03.10.07 22:15) [7]
>
>
> > там и без него своих граблей полно
>
>
> Не больше чем в Паскале

А кто то сказал, что их там больше?

> А кто то сказал, что их там больше?

С++ по граблям лидирует однозначно, С - на втором месте, pascal не в 10-ке :-)

← →
Sandman31 (2007-10-04 11:17) [38]

jack128_ (04.10.07 10:32) [35]

Автор обзора совершенно не разбирается в java.

Для оптимизации теста в Java к классу был применен модификатор final. По умолчанию все методы в Java являются виртуальными.

...
Как бы то ни было, большинство программистов вообще не воспринимает всерьез ни Java, ни C#. Какие же доводы они приводят? Первый – эти языки (и сами платформы) значительно уступают «родному» коду в производительности. Второй – такие языки не универсальны, и с их помощью можно решать очень ограниченный круг задач.

Даешь программирование на ассемблере! :)

> Sandman31 (04.10.07 11:17) [38]
Но ведь в Java действительно обычные методы являются по умолчанию виртуальными.

> vpbar © (04.10.07 10:22) [32]

> Ниже приведены их результаты и результаты выполнения нашего
> нового Float-теста.

Так вопрос об оптимизаторе поднимался. Кроме float есть весомые аргументы?

> jack128_ (04.10.07 10:32) [35]
>
> http://www.rsdn.ru/article/devtools/perftest.xml

Жень по ссылке твоей:

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

← →
Sandman31 (2007-10-04 12:22) [41]

euru © (04.10.07 11:48) [39]

В java нет невиртуальных методов, то есть адрес даже final-метода определяется по таблице методов. Да и как иначе, ведь final-метод может быть изменен в новой версии класса и использоваться другим классом, использоваться рефлекшн и т.д. Так что единственная оптимизация - подстановка тела метода вместо вызова private final, тогда вообще нет никакого метода.

> Sandman31 (04.10.07 12:22) [41]

Java Language Specification

8.4.3.3 final Methods

A method can be declared final to prevent subclasses from overriding or hiding it. It is a compile-time error to attempt to override or hide a final method.

. . .

At run time, a machine-code generator or optimizer can "inline" the body of a final method, replacing an invocation of the method with the code in its body.

← →
Sandman31 (2007-10-04 14:22) [43]

euru © (04.10.07 14:07) [42]

Я об этом и говорил.

Contrary to the implication of many tips, methods declared as final cannot be safely inlined by the compiler, because the method could have a non-final declaration at runtime. To see why, suppose the compiler looks at class A and subclass B, and sub-subclass C and sees a final method in A which it inlines into C. But then at runtime the versions loaded for A and B are different and the method is not final in A, and overridden in B. Then C uses the incorrectly inlined version. This was a bug in some of the early compilers when used with the -O option. So tips suggesting using final and the -O option are not valid tips. On the other hand, final methods can be inlined after being loaded into the JVM, because at that point the JVM knows definitely that the method is final. So compilers that operate after class loading, such as JIT compilers, can take advantage of final methods. Consequently, methods declared final could have some performance benefit. Generally, I wouldn"t go out of my way to declare a method or class final purely for performance reasons. Only after you"ve definitely identified a performance problem is this even worth considering.

http://www.javaperformancetuning.com/tips/final.shtml

For Performance? Since a final method is only implemented in the declaring class, there is no need to dynamically dispatch a call to a final method, and static invocation can be used instead. The compiler can emit a direct call to the method, bypassing entirely the usual virtual method invocation procedure. Because of this, final methods are also candidates for inlining by a Just-In-Time compiler or a similar optimization tool. (Remember, private/static methods are already final, therefore always considered for this optimization.) Static invocation is faster than dynamic method lookup, leading to the widespread use of final methods as an optimization technique. But this "optimization" is next to useless in recent virtual machines: they are able to detect if a non-final method is overridden, and if not, use static invocation. Therefore, final should be used first and foremost for sofware engineering reasons, as discussed in the rest of this article.

http://renaud.waldura.com/doc/java/final-keyword.shtml#methods

> Sandman31 (04.10.07 14:22) [43]

Фразы

адрес даже final-метода определяется по таблице методов

и

there is no need to dynamically dispatch a call to a final method, and static invocation can be used instead

мне кажется, несколько противоречат друг другу.

← →
Sandman31 (2007-10-04 16:52) [45]

euru © (04.10.07 16:29) [44]

Static invocation в java означает, что не будет осуществляться поиск конкретного класса, метод которого будет вызван, потому что класс уже точно известен. Но поиск расположения кода метода по таблице методов всё равно будет, потому что на момент вызова точка входа в метод кода может быть неизвестен (очевидно в случае вызова метода любого другого класса, кроме собственного).
На java в принципе невозможно передать управление на N байт вниз, как в случае static invocation в C или Delphi.

← →
Sandman31 (2007-10-04 17:19) [46]

ИМХО налицо некоторая двусмысленность термина виртуальный.

Вот например:

class A { public void method() {} }
Является ли метод виртуальным? Несомненно.

class B extends A { public final void method() {} }
А теперь? А будет ли dynamic invocation из anotherMethod в случае:

class B extends A { public final void method() {} public void anotherMethod(){ ... method(); ... } }
у хорошей JVM не будет.

А в случае
A a = .. a.method()

Даже у хорошей JVM будет.

А будет ли dynamic invocation в случае

class C { void myMethod(){ B b = ... b.method(); } }

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

← →
Sandman31 (2007-10-04 17:29) [47]

А вообще похоже, что я неправ. Судя по http://www.research.ibm.com/journal/sj/391/suganuma.html
private и static методы действительно называют nonvirtual.

К вопросу об оптимизации.
Сравнение эффективности оптимизатора
Тестируемый код. Привожу варинт на делфи, на С++ код идентичен этому.
procedure TestIfThen; var flag: Boolean; j:integer; begin asm jmp @@end; db $AD,$CB,$EF,$10; @@end: end; QueryPerformanceCounter(TimeStart); for j := 0 to LoopCount do begin if j > 2 then begin if LoopCount > j * 2 then begin flag := false; res := (LoopCount + res) div divr; end else begin flag := true; res := (LoopCount + res) div divr; end; end else begin res := (LoopCount + res) div divr; end; end; if flag then res := res + LoopCount * t else res := res - LoopCount * t; QueryPerformanceCounter(TimeEnd); OutResult("TestIfThen"); asm jmp @@end; db $AD,$CB,$EF,$11; @@end: end; end; procedure Sampl(a,b:integer); begin res:=a+b; asm jmp @@end; db $AD,$CB,$EF,$12; @@end: end; end; procedure TestCall; var flag: Boolean; j:integer; begin asm jmp @@end; db $AD,$CB,$EF,$13; @@end: end; QueryPerformanceCounter(TimeStart); for j := 0 to LoopCount do begin if j > 2 then Sampl(divr*2+LoopCount*2,j+LoopCount) else Sampl(divr*2+LoopCount*2,j-LoopCount); end; QueryPerformanceCounter(TimeEnd); OutResult("TestCall"); asm jmp @@end; db $AD,$CB,$EF,$14; @@end: end; end; procedure TestCall2; var flag: Boolean; j:integer; r:TRect; begin asm jmp @@end; db $AD,$CB,$EF,$15; @@end: end; QueryPerformanceCounter(TimeStart); for j := 0 to LoopCount do begin if j > 2 then OffsetRect(r,divr*2+LoopCount*2,j+LoopCount) else OffsetRect(r,divr*2+LoopCount*2,j-LoopCount); end; QueryPerformanceCounter(TimeEnd); OutResult("TestCall2"); asm jmp @@end; db $AD,$CB,$EF,$16; @@end: end; end;
Список результатов. В скобках опции оптимизатора.
Delphi 7 (optimization)
TestIfThen Time: 26,6
TestCall Time: 16,5
TestCall2 Time: 9,7
****************************
Delphi 7 (no optimization)
TestIfThen Time: 26,9
TestCall Time: 9,7
TestCall2 Time: 21,7
****************************
Borland Developer Studio 2006 (optimization)
TestIfThen Time: 26,4
TestCall Time: 15,3
TestCall2 Time: 10,2
****************************
Borland Developer Studio 2006 (no optimization)
TestIfThen Time: 28,4
TestCall Time: 10,2
TestCall2 Time: 19,6
****************************
Microsoft Visual Studio 2005 (Maximize Speed (/O2))
TestIfThenTime: 2.7
TestCallTime: 4.5
TestCall2Time: 9.0
****************************
Microsoft Visual Studio 2005 (Disabled (/Od))
TestIfThenTime: 28.5
TestCallTime: 9.5
TestCall2Time: 11.8
****************************
MiniGW Studio 2.05 (Level3)
TestIfThenTime: 25.4
TestCallTime: 2.2
TestCall2Time: 8.7
****************************
MiniGW Studio 2.05 (None)
TestIfThenTime: 29.4
TestCallTime: 9.0
TestCall2Time: 13.0

Интересно что в Делфях неоптимизированный вариант TestCall работает быстрее.
Такая вот "оптимизация" в Делфях.
Лучшие результаты Visual Studio 2005 обусловлены тем, что ее
копмилятор выносит общие выражения из цикла.
Тесты конечно очень синтетические (хотя первая процедура по мотивам реального кода), но различие компиляторов показывают.

ЗЫ. Где-то встречал анализ методов оптимизации (вынос общего, развертка циклов, использование быстрых комманд) и наличия их в распростроненных компиляторах. Если найду - покажу иначе сам на досуге проанализирую и все равно покажу.

> Sandman31 (04.10.07 17:19) [46]
> А будет ли dynamic invocation в случае
> class
> {
> void myMethod(){
> B b = ...
> b.method();
> }
>
> Не знаю. C одной стороны ясно, что метод находится именно в классе B,
> но с другой стороны inline не сделать в принципе.

А почему нельзя в принципе? Ведь с точки зрения спецификации языка здесь, в отличие от примера, приведённого выше этого примера, однозначно вызовется метод класса В и никакой другой.

← →
Sandman31 (2007-10-05 11:03) [50]

euru © (05.10.07 10:50) [49]

А почему нельзя в принципе? Ведь с точки зрения спецификации языка здесь, в отличие от примера, приведённого выше этого примера, однозначно вызовется метод класса В и никакой другой.

Да, вызовется именно B.method. Но нет никакой гарантии, что в run-time класс B будет тот же самый, что и при компиляции класса C. Никто мне не мешает изменить класс B без перекомпиляции класса С, в котором он используется, при условии, что сигнатура методов класса B не поменяется.

← →
2463A7C8 (2007-10-07 22:12) [51]

Если же случалась большая беда — телепередачи показывали иногда катастрофы с
повозками или летательными аппаратами, — то немедленно собиралась толпа.

Это нормально? Найти похожие ветки