Вопрос по "промежуточному коду" .NET

← →
Alex Konshin © (2006-12-18 05:31) [40]

> Юрий Зотов © (18.12.06 03:02) [36]
> Запускаю Java-программу. Должна появиться простенькая экранная
> форма с таблицей, заполненной из локальной БД (примерно
> 100 записей, запрос простейший: SELECT * FROM TableName).
> Она и появляется, но... через полминуты. То же самое на
> Delphi - секунды.

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

Я не спорю, что потенциально Дельфи должно работать быстрее. Но сейчас не все определяется только скоростью. Если немало областей, в которых Java будет гораздо органичней и проще в использовании. Особенно это касается новомодных сетевых технологий, XML и т.п..

А уж надежность и возможности отладки Delphi win32 с Java ну никак не сравнить. Одна простая фича Java - печать стека вызовов с указанием строки кода - сохраняет массу времени при локализации проблемы. Да, я знаю, что можно с помощью JCL сделать нечто похожее, но это все равно непросто.

← →
Petr V. Abramov © (2006-12-18 05:49) [41]

> Alex Konshin © (18.12.06 05:31) [40]
> Юра, ты не поверишь, я и на Делфи могу написать программу, которая будет откликаться через полминуты.
меня хоть и не Юрой зовут, но выскажу мнение:
на дельфи надо еще повыеживаться, чтоб достичь такого результата (ну если не селектить гиговую таблицу. и если ПоДХОД не соблазняет так делать).
А на жабе человек с децилскими умственными способностями ПО УМОЛЧАНИЮ, т.е не выеживаясь, получил

>>SELECT * FROM TableName).
>> Она и появляется, но... через полминуты.
на уроках труда с школе это полезно, а далее...

← →
Petr V. Abramov © (2006-12-18 05:52) [42]

> Petr V. Abramov © (18.12.06 05:49) [41]
> жабе человек с децилскими умственными способностями
все же "НЕ" пропустил :)))

← →
iZEN © (2006-12-18 09:33) [43]

> Sergey Masloff (17.12.06 23:15) [31], Юрий Зотов © (18.12.06 03:02) [36]

1) Когда же вы перестанете пользоваться JRE version < 1.4, а?
Скажу по секрету: уже вышла Java 6.0. :)

2) Использование запроса SELECT * FROM TableName — признак непрофессионализма программиста независимо от ЯП, который он использует для написания приложений БД.

← →
vitv © (2006-12-18 10:09) [44]

> Скажите мне по секрету, какие аргументы Вы ему приводили
> в пользу Delphi, что этот самый "умный" дядя опустился до
> таких необоснованных аргументов в пользу VS?
>

Я просто его слушал, не спорил т.к. молодой ещё...

← →
Mystic © (2006-12-18 10:32) [45]

Мне кажется, тут спутаны вместе две малосвязаные проблемы. Во-первых, это низкоуровневая оптимизация. Эта задача со временем становится все более экзотичной, но там где она встречается, желателен полный контроль над генерируемым машинным кодом. Достичь этого в языках, где не используется промежуточный код, имхо, проще. Вторая проблема это потеря производительности при использовании универсальных библиотек/классов/framework-ов. Естественно, что универсальный код будет выполняться медленее специализированого. Так вот проблема больших framework-ов наблюдается в том, что из-за большого наслоения универсальных решений наблюдается часто потеря производительности (маляр Шлейхем), которая ощущается иногда и на современной технике. Низкоуровневой оптимизацией эту проблему никак не решить.

← →
VitV © (2006-12-18 10:41) [46]

> автор, ты кстати Троелсена книгу читаешь новую или старую?
>
> у него новая есть по 2 фреймворку вроде
>

Первую.

← →
iZEN © (2006-12-18 10:46) [47]

> Mystic © (18.12.06 10:32) [45]

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

Статически компилируемый нативный код эффективен только для одной конкретной архитектуры процессора с определённым набором инструкций (с SSE или без SSE, например) и размером кэша. Компилятор такого кода может делать предположения о платформе, на которой будет выполняться такой код — ключи оптимизации обычно подбираются специально и задаются в командной строке компилятора.

← →
KSergey © (2006-12-18 10:55) [48]

> iZEN © (18.12.06 10:46) [47]
> Статически компилируемый нативный код эффективен только
> для одной конкретной архитектуры процессора с определённым
> набором инструкций (с SSE или без SSE, например) и размером
> кэша. Компилятор такого кода может делать предположения
> о платформе, на которой будет выполняться такой код — ключи
> оптимизации обычно подбираются специально и задаются в командной
> строке компилятора.

Когда в некоей библиотеке делается упомянутое select * from t1, причем несколько раз - ввиду универсальности и многослойности (причем каждый слой - в общем-то весьма оптимальный) - то никакая оптимизация на уровне "с SSE или без SSE" уже не поможет :)
О чем, собственно, я было сказано Mystic ©.

← →
KSergey © (2006-12-18 10:57) [49]

К стати, в приведенной Eraser © (17.12.06 15:06) [3] картинке из Рихтера есть упоминание фортрана.
У меня есть вопрос: я не могу найти компилятор с фортрана для .NET. Отсюда вопрос: тов. Рихтер сказанул это для красного словца или я плохо ищу? Может кто видел?

← →
Mystic © (2006-12-18 11:41) [50]

> iZEN © (18.12.06 10:46) [47]

Попробовал, исходный код (C#) был такой:

const int N = 10; int[] A = new int[N]; for (int i = 0; i < N; ++i) A[i] = 2 * i;

В результате получилось:

const int N = 10; int[] A = new int[N]; 00000030 mov edx,0Ah 00000035 mov ecx,7915982Ah 0000003a call FFCB105C 0000003f mov dword ptr [ebp-40h],eax for (int i = 0; i < N; ++i) 00000042 xor edi,edi 00000044 nop 00000045 jmp 0000005D A[i] = 2 * i; 00000047 mov eax,edi 00000049 add eax,eax 0000004b mov edx,dword ptr [ebp-40h] 0000004e cmp edi,dword ptr [edx+4] 00000051 jb 00000058 00000053 call 793F3529 00000058 mov dword ptr [edx+edi*4+8],eax for (int i = 0; i < N; ++i) 0000005c inc edi 0000005d cmp edi,0Ah 00000060 setl al 00000063 movzx eax,al 00000066 mov ebx,eax 00000068 test ebx,ebx 0000006a jne 00000047

А вот оптимизированый вариант C++:

int const N = 10; int A[N]; for (int i=0; i<N; ++i) A[i] = 2*i; 00401004 xor esi,esi 00401006 mov dword ptr [esp+4],esi 0040100A mov dword ptr [esp+8],2 00401012 mov dword ptr [esp+0Ch],4 0040101A mov dword ptr [esp+10h],6 00401022 mov dword ptr [esp+14h],8 0040102A mov dword ptr [esp+18h],0Ah 00401032 mov dword ptr [esp+1Ch],0Ch 0040103A mov dword ptr [esp+20h],0Eh 00401042 mov dword ptr [esp+24h],10h 0040104A mov dword ptr [esp+28h],12h

← →
oxffff © (2006-12-18 12:02) [51]

Mystic © [50]

А что это за странный вызов?
00000053 call 793F3529

← →
Джо © (2006-12-18 12:11) [52]

> [50] Mystic

Ничего не скажешь, компилятор, действительно, «на высоте» :)

← →
Джо © (2006-12-18 12:12) [53]

> [52] Джо © (18.12.06 12:11)
> > [50] Mystic
>
> Ничего не скажешь, компилятор, действительно, «на высоте»
> :)

«Оптимизатор», сорри.

← →
Джо © (2006-12-18 12:16) [54]

Еще бы для полноты картины посмотреть код, генерируемый Java JIT.

← →
oxffff © (2006-12-18 12:23) [55]

> Джо © (18.12.06 12:12) [53]
> > [52] Джо © (18.12.06 12:11)
> > > [50] Mystic
> >
> > Ничего не скажешь, компилятор, действительно, «на высоте»
>
> > :)
>
> «Оптимизатор», сорри.

Так скоро появится COMPILER.NET
OPTIMIZER.NET

← →
Игорь Шевченко © (2006-12-18 12:32) [56]

Mystic © (18.12.06 11:41) [50]

> А вот оптимизированый вариант C++:

а на ассемблере еще быстрее можно. И что ?

← →
oxffff © (2006-12-18 12:39) [57]

> Игорь Шевченко © (18.12.06 12:32) [56]
> Mystic © (18.12.06 11:41) [50]
>
>
> > А вот оптимизированый вариант C++:
>
>
> а на ассемблере еще быстрее можно. И что ?

Быстрее этого. ОГО

00401004 xor esi,esi
00401006 mov dword ptr [esp+4],esi
0040100A mov dword ptr [esp+8],2
00401012 mov dword ptr [esp+0Ch],4
0040101A mov dword ptr [esp+10h],6
00401022 mov dword ptr [esp+14h],8
0040102A mov dword ptr [esp+18h],0Ah
00401032 mov dword ptr [esp+1Ch],0Ch
0040103A mov dword ptr [esp+20h],0Eh
00401042 mov dword ptr [esp+24h],10h
0040104A mov dword ptr [esp+28h],12h

Код пожалуйста

← →
Джо © (2006-12-18 12:39) [58]

> [56] Игорь Шевченко © (18.12.06 12:32)
> Mystic © (18.12.06 11:41) [50]
>
>
> > А вот оптимизированый вариант C++:
>
>
> а на ассемблере еще быстрее можно. И что ?

Да собственно тут, как мне показалось, иллюстрировалась «прекрасная» работа оптимизаторов JIT-compiler"ов и ничего более.

← →
MBo © (2006-12-18 12:49) [59]

>KSergey © (18.12.06 10:57) [49]
гугл по запросу fortran for dotNet выдал ссылки, в том числе на бесплатный компилятор F95, при желании встраиваемый в VS2005

← →
Юрий Зотов © (2006-12-18 12:58) [60]

Сэры, можно говорить что угодно, но если программа стартует полминуты и при этом в ней не заложено каких-то там особенных стартовых операций, кроме элементарной выборки сотни записей с десятком полей из одной таблицы локальной БД (что, как вы сами понимаете, происходит за секунду - то есть, полминуты уходит совсем на другое) - так вот говорить о скорости такой программы не приходится вообще.

Аналогичная Delphi-программа будет запускаться максимум пару секунд. Даже если она сделана новичком.

← →
Джо © (2006-12-18 13:01) [61]

> [60] Юрий Зотов © (18.12.06 12:58)
> Аналогичная Delphi-программа будет запускаться максимум
> пару секунд. Даже если она сделана новичком.

Недавно тут в «Начинающих» была ветка. У человека датамодуль несколько минут грузился.

← →
oxffff © (2006-12-18 13:07) [62]

> Юрий Зотов © (18.12.06 12:58) [60]
> Сэры, можно говорить что угодно, но если программа стартует
> полминуты и при этом в ней не заложено каких-то там особенных
> стартовых операций, кроме элементарной выборки сотни записей
> с десятком полей из одной таблицы локальной БД (что, как
> вы сами понимаете, происходит за секунду - то есть, полминуты
> уходит совсем на другое) - так вот говорить о скорости такой
> программы не приходится вообще.
>
> Аналогичная Delphi-программа будет запускаться максимум
> пару секунд. Даже если она сделана новичком.

А может Хейлсберг скрытый засланец Borland.

← →
Skier © (2006-12-18 13:10) [63]

> А может Хейлсберг скрытый засланец Borland.

Это же очевидно! :))

← →
Юрий Зотов © (2006-12-18 13:11) [64]

> Джо © (18.12.06 13:01) [61]

БД на пару гигов, аффигительный запрос и коннект через dialup - еще не то будет.

Ув. сэры. Поверьте, программу, о которой я говорю, я знаю ОЧЕНЬ хорошо. Изнутри. БД, с которой она работает, я тоже знаю ОЧЕНЬ хорошо. Тоже изнутри. И программа, и БД сделаны нормально, тормозов в них нет.

Тем не менее, тормоза налицо. И возникает вопрос - если они не из БД и не из программы, то откуда же они взялись?

И напрашивается ответ на сабж.

← →
KSergey © (2006-12-18 13:13) [65]

> MBo © (18.12.06 12:49) [59]
> гугл по запросу fortran for dotNet выдал ссылки, в том числе
> на бесплатный компилятор F95, при желании встраиваемый в
> VS2005

Сорри, я и правда плохо искал...

К стати, помнится кто-то как-то стпрашивал про передачу массивов промеж C++ (или Delphi?) и Fortran - так вот он и ответ :)

← →
Игорь Шевченко © (2006-12-18 13:21) [66]

oxffff © (18.12.06 12:39) [57]

> Код пожалуйста

1. Загрузить готовый массив констант
2. Использовать команды, оперирующие 64-битовыми значениями и пересылать по 64 бита за одну команду

← →
Anatoly Podgoretsky © (2006-12-18 13:49) [67]

> Джо (18.12.2006 13:01:01) [61]

То в яве будет два часа грузиться, если вообще сможет загрузиться.

← →
Anatoly Podgoretsky © (2006-12-18 13:49) [68]

> oxffff (18.12.2006 13:07:02) [62]

Почему скрытый, явный.

> Юрий Зотов © (18.12.06 13:11) [64]
> Тем не менее, тормоза налицо. И возникает вопрос - если
> они не из БД и не из программы, то откуда же они взялись?
> И напрашивается ответ на сабж.

Тем не менее, напрашиваются сопутствующие вопросы:
1) Что за программа;
2) Кто писал такую программу;
3) Какая версия JRE;
4) Аппаратная конфигурация компьютера, на котором запускалась программа.

Действительно, складывается ощущение, что "бутылочное горлышко" либо в JRE устаревшей версии, либо в недостатке памяти (непрерывный своп), либо в самой программе, либо в руках того, кто её писал.
Неплохо бы протестировать в том же ключе аналогичную .NET-программу.
Причём выполнять SQL-запрос с заполнением полей сетки нужно больше одного раза, так как на первом запуске проходит трансляция баткода в нативный код (та же компиляция) и оптимизация структур памяти, отводимых под данные запроса и буферы обмена.

> либо в JRE устаревшей версии,
а с каких это пор новые версии продуктов жрут меньше ресурсов? :)

О чем вообще спор? Быстрее, медленее...
Есть вещи, которые на Java (да и на C#) делаются легко и просто, а на Delphi еще надо долго попотеть, чтоб такое сделать и отладить, и то никогда не будешь уверен, что нигде не упустил чего-то.
Например, исполнение на удаленной машине.

Или давайте померяем скорость выполнения на платформе Sun Solaris, HPUX RISC2 или на мобильнике. Что, Delphi такого не умеет? А на Windows 64bit? Как, и тут нельзя? Так и запишем - на Delphi вообще нельзя написать работающую программу.

Это я юродствую. Но смысл, я надеюсь, вы уловили.
Надеюсь, моя квалификация как программиста Delphi сомнений не вызвает?

> iZEN (18.12.2006 14:28:09) [69]

> JRE устаревшей версии

Нравится мне этот подход у Явистов и Линуксоидов.

> Petr V. Abramov © (18.12.06 14:37) [70]
>
> > либо в JRE устаревшей версии,
> а с каких это пор новые версии продуктов жрут меньше ресурсов?
> :)

Кстати, факт - Java 6 жрет меньше ресурсов.

> Anatoly Podgoretsky © (18.12.06 14:51) [72]
> > iZEN (18.12.2006 14:28:09) [69]
> > JRE устаревшей версии
> Нравится мне этот подход у Явистов и Линуксоидов.

Согласен, после Windows и Delphi к этому трудно привыкнуть
:)

> Petr V. Abramov © (18.12.06 14:37) [70]
> > либо в JRE устаревшей версии,
> а с каких это пор новые версии продуктов жрут меньше ресурсов?
> :)

Их переписывают заново индусы2.

> Petr V. Abramov © (18.12.06 14:37) [70]
>
> > либо в JRE устаревшей версии,
> а с каких это пор новые версии продуктов жрут меньше ресурсов?
> :)

К Delphi и MSVS это явно не относится. :))

Кстати, нужно еще отдать должное разработчикам JDK: сохраняется совестимость снизу вверх. А вот проэкты Delphi приходится править при переходе от версии к версии.

> Игорь Шевченко © (18.12.06 13:21) [66]
> oxffff © (18.12.06 12:39) [57]
>
>
> > Код пожалуйста
>
>
> 1. Загрузить готовый массив констант
> 2. Использовать команды, оперирующие 64-битовыми значениями
> и пересылать по 64 бита за одну команду

Так 1 это и есть задача, которую надо оптимизировать.
Так что ваш вариант не подойдет.

> Alex Konshin (18.12.2006 14:53:14) [74]

Я не только про гиганстское количество версий, особенно тут убил MySql.
А сколько про подход, мол это старая версия, а вот новая и так постоянно.
Фиребирд и Интербейс тоже в этом замечены.

> Alex Konshin (18.12.2006 14:57:17) [77]

Не знаю как с JDK, но с Дельфи есть немного такое, правда с 5 по 2006 править не приходилось, работало сразу. Компоненты только стандартные

Вопрос по "промежуточному коду" .NET Найти похожие ветки