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

← →
vitv © (2006-12-17 14:49) [0]

1.В книге Троелсена по С# есть глава в которой рассказывается о том, что все равно на каком языке вы пишите по НЕТ, главное то, что он "компилируется" в промежуточный код.Т.е. получается всё равно на чём писать?
2.И ещё. Один умный дядя мне доказывал, что exe-ник скомпилированый под VS быстрее чем Delphi-кий. Он прав или нет?

← →
Eraser © (2006-12-17 14:54) [1]

> [0] vitv © (17.12.06 14:49)

1. в книге Рихтера это описано лучше. В принципе - все равно. Но, imho, лучше на C#.
2. не прав.

← →
palva © (2006-12-17 15:01) [2]

> Т.е. получается всё равно на чём писать?
В некоторых NET языках реализованы не все возможности. Например, в Basic .NET отсутствуют некоторые типы данных, которые есть в C#

← →
Eraser © (2006-12-17 15:06) [3]

вот хорошая иллюстрация http://slil.ru/23588829 (78 КБ)

← →
vitv © (2006-12-17 15:24) [4]

> 1. в книге Рихтера это описано лучше. В принципе - все равно.
> Но, imho, лучше на C#.
> 2. не прав.

А как насчёт Delphi.net и С#.

← →
Eraser © (2006-12-17 15:30) [5]

> [4] vitv © (17.12.06 15:24)

> А как насчёт Delphi.net и С#.

там быстродействие в 99% случаев одинаковое будет.

← →
vitv © (2006-12-17 15:34) [6]

И возможностисреды разработки тоже?

← →
vitv © (2006-12-17 15:34) [7]

И возможности среды разработки тоже?

← →
Eraser © (2006-12-17 15:37) [8]

> [6] vitv © (17.12.06 15:34)

насчет IDE.. впринципе BDS2006 вполне мощная среда, но бывает глючит и поддерживает только NET1.1, по-этому мой выбор - VS2005.

← →
Gero © (2006-12-17 15:40) [9]

> [8] Eraser © (17.12.06 15:37)

Притом обе одинаково неудобны.

← →
Eraser © (2006-12-17 15:42) [10]

> [9] Gero © (17.12.06 15:40)

ну эт дело вкуса, мне VS удобна, если не считать отсутсвие некоторых фишек, которые в BDS есть.
и интерфейс BDS2006 нравится больше, чем 7, только вот падает часто :(

← →
Gero © (2006-12-17 15:46) [11]

> [10] Eraser © (17.12.06 15:42)
> и интерфейс BDS2006 нравится больше, чем 7, только вот падает
> часто

Мне в BDS из удобства только редактор кода больше нравится. Большинство из остального — шаг назад.
А вобще, самой удобной средой, что мне приходилось видеть, был TP7.

← →
VitV © (2006-12-17 15:47) [12]

> ну эт дело вкуса, мне VS удобна, если не считать отсутсвие
> некоторых фишек, которые в BDS есть.
> и интерфейс BDS2006 нравится больше, чем 7, только вот падает
> часто :(

Если не секрет:
в VS ты пишешь только под Нет или вин32?

← →
Eraser © (2006-12-17 15:51) [13]

> [11] Gero © (17.12.06 15:46)

> Мне в BDS из удобства только редактор кода больше нравится.

ну это бесспорно.

> Большинство из остального — шаг назад.

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

← →
Eraser © (2006-12-17 15:52) [14]

> [12] VitV © (17.12.06 15:47)

> в VS ты пишешь только под Нет или вин32?

только .net (C#), для win32 мой выбор - Делфи, и вряд ли он изменится в ближайшие несколько лет. уж очень удобное изобретение этот VCL )

← →
VitV © (2006-12-17 15:57) [15]

В
>
> только .net (C#), для win32 мой выбор - Делфи, и вряд ли
> он изменится в ближайшие несколько лет. уж очень удобное
> изобретение этот VCL )

Вот-вот...Я представляю, если бы VCL MS придумала. Точнее подход к разработке.

← →
Eraser © (2006-12-17 15:59) [16]

> [15] VitV © (17.12.06 15:57)

> если бы VCL MS придумала

так и придумала - .NET :)

← →
Piter © (2006-12-17 15:59) [17]

VitV © (17.12.06 15:57) [15]
представляю, если бы VCL MS придумала

а чего тут представлять. MFC.

← →
Piter © (2006-12-17 15:59) [18]

ну да, а потом на системном уровне уже - .NET :)

← →
default © (2006-12-17 17:48) [19]

> Один умный дядя мне доказывал, что exe-ник скомпилированый
> под VS быстрее чем Delphi-кий. Он прав или нет?

> 2. не прав.

вот цитата из Рихтера
не поленился я набрать её вручную
"Если ваши эксперименты покажут, что JIT-компилятор CLR не обеспечивает нужную производительность, можете использовать утилиту NGen.exe, поставляемую с .NET FrameWork SDK. NGen.exe компилирует весь IL-код некоторой сборки в процессорный и сохраняет результирующий код процессора в дисковом файле. При загрузке сборки в период выполнения CLR автоматически проверяет наличие предварительно скомпилированной версии сборки и, если она есть, загружает скомпилированный код, так что компиляция в период выполнения не производится"
если так сделать, да ещё учесть, что JIT-компилятор оптимизирует код под конретный процессор вполне может оказаться, что Delphi-коду придётся курить в сторонке

← →
default © (2006-12-17 17:52) [20]

блин ступил я
Delphi-код тоже можно так скомпилировать заранее...
ну да ладно, зато приведённая информация может кому-то будет интересной

← →
Celades © (2006-12-17 19:05) [21]

> > под VS быстрее чем Delphi-кий. Он прав или нет?

Может имелась ввиду компиляция в native-код? Тогда не всё так однозначно

← →
DrPass © (2006-12-17 20:21) [22]

Piter © (17.12.06 15:59) [17]
> а чего тут представлять. MFC

MFC и VCL совершенно разные вещи. Первая - просто набор полезных классов и макросов, причем сравнительно небольшой. Вторая - по сути, глобальный инструментарий для разработчика.

VitV © (17.12.06 15:57) [15]
> Я представляю, если бы VCL MS придумала. Точнее подход к
> разработке.

В принципе, она и придумала. Delphi делалась по принципу "как в Visual Basic, только лучше"

> Eraser © (17.12.06 15:59) [16]
> так и придумала - .NET :)

Не придумала, а гнусно скопировала лучшее из Delphi и Java :)

← →
Piter © (2006-12-17 20:26) [23]

DrPass © (17.12.06 20:21) [22]

а по-моему, VCL - это как раз тоже набор классов и функций. Разве нет? :)

← →
iZEN © (2006-12-17 20:37) [24]

> vitv © (17.12.06 14:49)
>
> 1.В книге Троелсена по С# есть глава в которой рассказывается
> о том, что все равно на каком языке вы пишите по НЕТ, главное
> то, что он "компилируется" в промежуточный код.Т.е. получается
> всё равно на чём писать?
> 2.И ещё. Один умный дядя мне доказывал, что exe-ник скомпилированый
> под VS быстрее чем Delphi-кий. Он прав или нет?

1. Не всё равно.
2. Прав. У Дельфи весьма посредственный оптимизатор кода.

← →
Sergey Masloff (2006-12-17 20:45) [25]

iZEN © (17.12.06 20:37) [24]
У жабы зато самый лучший. Только как запустишь приложение так и между нажатиями на кнопки курить можно ходить. А оптимизатор волшебный ;-)

← →
ProgRAMmer Dimonych © (2006-12-17 20:55) [26]

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

← →
default © (2006-12-17 20:56) [27]

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

← →
wl © (2006-12-17 20:58) [28]

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

← →
Думкин © (2006-12-17 21:05) [29]

> wl © (17.12.06 20:58) [28]

Если бы у бабушки, то она была бы дедушкой.

← →
iZEN © (2006-12-17 21:09) [30]

> wl © (17.12.06 20:58) [28]
>
> не надо сравнивать интерпретацию байткода java и выполнение
> машинных кодов. Вот если бы байткод на уровне процессора
> выполнялся, тогда другое дело

http://kano.net/javabench/data
Почму нет?

← →
Sergey Masloff (2006-12-17 23:15) [31]

iZEN © (17.12.06 21:09) [30]
Бенчи это хорошо. На реальных приложениях оно б работала как в бенчах.
А то на PIV 2.8 с гигом паямяти вообще не шевелится. Кнопочки по одной прорисовывает. Примеры - Oracle Reports, JDeveloper Studio, Discoverer...
Из наболевшего, так сказать.

← →
ANTPro © (2006-12-17 23:54) [32]

> [31] Sergey Masloff (17.12.06 23:15)

Дык, может "кривые руки"/лень программистоФФ?

← →
Petr V. Abramov © (2006-12-18 01:00) [33]

> ANTPro © (17.12.06 23:54) [32]
фактор индейцев конечно присутствует, но так сложилось, что вот я лично ни одного приложения ж не видел, которым пользоваться можно без мата.

← →
ANTPro © (2006-12-18 01:06) [34]

> [33] Petr V. Abramov © (18.12.06 01:00)

Вывод:
Все программеры на ж - индейцы. :)

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

> ANTPro © (18.12.06 01:06) [34]
> Все программеры на ж - индейцы. :)
в душе :)

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

Запускаю Java-программу. Должна появиться простенькая экранная форма с таблицей, заполненной из локальной БД (примерно 100 записей, запрос простейший: SELECT * FROM TableName).

Она и появляется, но... через полминуты. То же самое на Delphi - секунды.

← →
Petr V. Abramov © (2006-12-18 03:20) [37]

> Юрий Зотов © (18.12.06 03:02) [36]
не буди .... ну сам знаешь кого :)))))))

← →
Petr V. Abramov © (2006-12-18 03:37) [38]

> Юрий Зотов © (18.12.06 03:02) [36]
> Она и появляется, но... через полминуты.
прогрессивные технологии требуют аппаратных ресурсов. На жабе можно сделать много того, что нельзя сделать с использованием других технологий. А то, что можно, делается с меньшими затратами :)))

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

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

Юрий, как уже было сказано выше, это работа замечательного оптимизатора. Еще раз подчеркну — замечательного оптимизатора 8-)

← →
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]

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

← →
iZEN © (2006-12-18 14:28) [69]

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

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

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

← →
Petr V. Abramov © (2006-12-18 14:37) [70]

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

← →
Alex Konshin © (2006-12-18 14:49) [71]

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

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

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

← →
Anatoly Podgoretsky © (2006-12-18 14:51) [72]

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

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

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

← →
Alex Konshin © (2006-12-18 14:51) [73]

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

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

← →
Alex Konshin © (2006-12-18 14:53) [74]

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

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

← →
oxffff © (2006-12-18 14:53) [75]

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

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

← →
iZEN © (2006-12-18 14:53) [76]

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

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

← →
Alex Konshin © (2006-12-18 14:57) [77]

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

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

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

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

← →
Anatoly Podgoretsky © (2006-12-18 14:58) [79]

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

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

← →
Anatoly Podgoretsky © (2006-12-18 15:00) [80]

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

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

← →
Alex Konshin © (2006-12-18 15:06) [81]

> Anatoly Podgoretsky © (18.12.06 14:58) [79]
> > Alex Konshin (18.12.2006 14:53:14) [74]
> Я не только про гиганстское количество версий, особенно
> тут убил MySql.
> А сколько про подход, мол это старая версия, а вот новая
> и так постоянно.
> Фиребирд и Интербейс тоже в этом замечены.

А чего такого с Java? Мне до сих пор приходится иметь дело с проэктами для Java 1.3, 1.4 и никаких проблем. Совместимость очень хорошая. Можно быть увереным, что скомпилируется и будет работать.

← →
iZEN © (2006-12-18 15:06) [82]

> Anatoly Podgoretsky © (18.12.06 14:58) [79]
> Я не только про гиганстское количество версий, особенно
> тут убил MySql.
> А сколько про подход, мол это старая версия, а вот новая
> и так постоянно.

Так ведь улучшения в новых версиях JRE кардинальные, а не доли процентов!
Сравните: java 1.02 -> java 1.1 -> jre 1.2 -> jre 1.3 -> jre 1.4 -> jre 1.5 (5.0) -> jre 1.6 (6.0) — во всех случаях быстродействие JVM повышалось от 10%, а на некоторых весьма распространённых операциях до 200%(!), что было заметно явно.
В данном контексте это имеет первостепенное значение.

← →
Alex Konshin © (2006-12-18 15:09) [83]

Кстати, при большом желании из Java можно использовать нативный код (хотя бы через JNI), но это не приветствуется, т.к. теряется переносимость.

> Alex Konshin (18.12.2006 15:06:21) [81]

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

> Alex Konshin (18.12.2006 15:06:21) [81]

Ой извиняюсь перепутал автора.

> iZEN (18.12.2006 15:06:22) [82]

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

А то что версии должны выпускать без сомнения, но не так часто, вон Опера уже 10 версия, а совсем недавно была первая.

Ну нельзя такие гонки устраивать.

> iZEN © (18.12.06 14:28) [69]

Дружище, Вы полагаете, я начал что-то там ругать, не проверив все это сначала?

ОК, отвечаю.

1. Что за программа - обычная клиентская программа, работающая с БД. Использована связка Hibernate+Spring+Derby (в другой версии - MS SQL Server вместо Derby). Какие запросы генерит Hibernate - это проверялось. Вполне вероятно, что человек написал бы лучше, но и в сгенерированных запросах тормозов на полминуты не наблюдается.

2. Писал, среди прочих, и я тоже (в Eclipse 3.2). Естественно, никаким спецом в Jav"е я себя не считаю (наоборот), но, надеюсь, Вы не сомневаетесь, что потенциально тормозной код я отличу даже на малознакомом языке. Поэтому и утверждаю - тормозов на полминуты там нет. Тем более, что это проверялось и людьми, в Jav"e действительно опытными.

3. Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03). Последний раз обновлялась где-то пару месяцев назад.

4. Нормальная рабочая машина. Совсем не крутая, но и на ней сильных тормозов быть не должно. Celeron 2 GHz, RAM 768 Mb. Диск IDE, 5400 об/мин, файловая система NTFS. OS - W2K Pro.

5. Естественно, программа запускалась далеко не один, и далеко не сто один раз (как RCP, и с очисткой Workspace, и без нее). Естественно, я в курсе, что происходит при каждом первом запуске после очередной пересборки и говорю не о нем.

> Alex Konshin (18.12.2006 15:09:23) [83]

Это нигде не приветствуется, поскольку профанация идеи. Такое вроде С++ники устраивают в C++.NET

А когда напишут С++ на C#.
:)

Вот небольшая статья про Unsafe Java
http://www.wasm.ru/article.php?article=unsjav1

> [40] Alex Konshin © (18.12.06 05:31)
> Да, я знаю, что можно с помощью JCL сделать нечто похожее,
> но это все равно непросто.

Можно ссылку на JCL? А то гугл ссылки битые выдает :(

> Можно ссылку на JCL?

www.delphi_jedi.org

> [93] Eraser © (18.12.06 16:25)
> слышал, что в BDS похожее сделано именно с использованием
> кода jcl.

Что-то не заметно, хотя в BDS много всего :)

> [92] Игорь Шевченко © (18.12.06 16:23)

Пасиб. Как я там давно не был :)

[87]
Hibernate+Spring это, конечно, круто, на острие прогресса ORM и объектных хранилищ. Всё-таки серверная технология с большим оверхедом по памяти.
768МБ - это мало, когда делают полную выборку всех данных из таблицы - это ведь на каждую запись по объекту создаётся в Hibernate! Вопрос к допустимости конкретного решения, скорее, а не к быстродействию (если на Запорожец поставить движок от Мерса и говорить, что не тянет.).

[86]
Новая версия всегда лучше старой - это справедливо для приложений, за которые не требуют денег (иначе автор сгорел бы от стыда за свой продукт/потерял авторитет у партнёров). В мире коммерческого софта не всё так однозначно.

> iZEN © (18.12.06 15:06) [82]
>
> > Anatoly Podgoretsky © (18.12.06 14:58) [79]
> > Я не только про гиганстское количество версий, особенно
>
> > тут убил MySql.
> > А сколько про подход, мол это старая версия, а вот новая
>
> > и так постоянно.
>
> Так ведь улучшения в новых версиях JRE кардинальные, а не
> доли процентов!
> Сравните: java 1.02 -> java 1.1 -> jre 1.2 -> jre 1.3 ->
> jre 1.4 -> jre 1.5 (5.0) -> jre 1.6 (6.0) — во всех случаях
> быстродействие JVM повышалось от 10%, а на некоторых весьма
> распространённых операциях до 200%(!), что было заметно
> явно.
> В данном контексте это имеет первостепенное значение.

Вот это подход к делу.
Я думаю через лет 10 скорость станет, как у native x86.

> oxffff © (18.12.06 17:11) [98]
>
> Вот это подход к делу.
> Я думаю через лет 10 скорость станет, как у native x86.

Так уже баткод опережает по быстродействию нативный код. Ссылка на бенчмарки — выше.

Будут тормозить только неквалифицированные кодеры, неумеющие применять инструмент по делу.

iZEN © (18.12.06 17:27) [99]
Будут тормозить только неквалифицированные кодеры, неумеющие применять инструмент по делу.

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

> iZEN © (18.12.06 16:58) [96]

> 768МБ - это мало, когда делают полную выборку всех данных из таблицы -
> это ведь на каждую запись по объекту создаётся в Hibernate!

Как уже говорилось, в таблице порядка сотни записей. Это какого же размера должны быть объекты, чтобы 100 объектов сожрали память настолько, что 768 метров для W2K оказалось маловато и начался крутой свопинг? ИМХО, несерьезно.

Так что вопрос с Запорожцем и с Мерсом остается еще как открытым.

> Юрий Зотов © (18.12.06 18:31) [101]
>
> Как уже говорилось, в таблице порядка сотни записей. Это
> какого же размера должны быть объекты, чтобы 100 объектов
> сожрали память настолько, что 768 метров для W2K оказалось
> маловато и начался крутой свопинг? ИМХО, несерьезно.

Ага. Попался! Так всё-таки свопинг есть. ;)
Значит всё дело в руках того, кто писал приложение.

> iZEN © (18.12.06 18:50) [102]

???

Нет никакого свопинга, естественно. Неоткуда ему взяться. А тормоза - есть. В чем же дело?

Ответ, собственно, лежит на поверхности. Раз в нашем коде тормоза не наблюдаются, значит, они возникают в тех модулях, которые он использует (Hibernate и пр.). А их уж точно писали люди с далеко не с кривыми руками. Вот и выходит, что дело-таки не в руках, а в чем-то ином.

В чем же, как Вы думаете?
:о)

==========================

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

Как бы этого кое-кому ни хотелось.
:о)

> Юрий Зотов © (18.12.06 19:16) [103]
>
> Нет никакого свопинга, естественно. Неоткуда ему взяться.
> А тормоза - есть. В чем же дело?
>
> Ответ, собственно, лежит на поверхности. Раз в нашем коде
> тормоза не наблюдаются, значит, они возникают в тех модулях,
> которые он использует (Hibernate и пр.). А их уж точно
> писали люди с далеко не с кривыми руками. Вот и выходит,
> что дело-таки не в руках, а в чем-то ином.
>
> В чем же, как Вы думаете?
> :о)

Код профилировать пробовали? Нашли узкие места?

> iZEN © (18.12.06 19:39) [104]

Пока не до этого. На первом этапе заказчику важнее полнота функционала (что он сам и сказал), а за его качество будем бороться на втором.

Так что пока записали в TODO. Отпрофилируем - отпишусь.

PS
Но, опять-таки: профилирование позволит выявить узкие места, но не позволит сравнить скорость с реально нативным кодом.

> Юрий Зотов © (19.12.06 00:07) [105]
> Но, опять-таки: профилирование позволит выявить узкие места,
> но не позволит сравнить скорость с реально нативным кодом.

Конечно.
Зато вы узнаете, где собачка зарыта и есть ли в шкафу скелет.
(подсказка: в архитектуре)

> Юрий Зотов ©
> Код интерпретируемый (даже и байт-код - он все равно интерпретируемый) не может быть быстрее кода нативного в принципе.
оно конечно так. только не с разницей на 2 порядка. и тем более не с разницей, заметной "на глаз" и тем более не с разницей "с_перекуром/без_перекура"

> Hibernate+Spring+Derby
где-то в моих постах этой ветки было про индейцев. ИМХО, оттуда и растет.

P.S.
почему-то у меня на P4 2.6GHz 1G памяти работает немалая база Oracle + VS2005 + приложение (тестовое, изучаю VS) под VS-дебаггером. и без свопа, без тормозов... Может, потому, что .Net авторы Delphi делали???

> iZEN © (19.12.06 00:20) [106]

Если это плюха архитектуры, то наибольшие подозрения пока что вызывает использование lazy=false в дескрипторах для Hibernate. Там такого очень мало, но кое-где все-таки есть, и необходимость этого связана именно с архитектурой библиотеки классов. Впрочем, мы уже знаем, что и как надо в ней изменить, чтобы навсегда от этого подозрения избавиться, только руки пока не дошли.

Но речь в этой ветке ведь идет не о том, а о сравнении с нативным кодом. Там очень простая и маленькая по объему БД, поэтому, если бы программа писалась, например, на той же Delphi, то даже с полной загрузкой всех таблиц разом, это все равно заняло бы секунд 5 от силы. Но уж никак не полминуты.

Полминуты у нас когда-то стартовало огромное Delphi-приложение (exe весил 17 метров), которое при старте качало с удаленной базы (Interbase) очень и очень приличный объем данных, получаемых далеко не самыми простыми запросами. С тем что сейчас - даже и сравнивать нельзя, оно было на несколько порядков сложнее и объемнее (и по коду, и по данным). А грузилось те же полминуты.

Это все потому, что, блин, технологии ради технологий... Шоп былО...

> Eraser © (18.12.06 16:25) [93]
> > [91] ANTPro © (18.12.06 16:18)
>
> слышал, что в BDS похожее сделано именно с использованием
> кода jcl.

именно так.
они построение стека вызовов при исключении из jcl юзают.

Юрий Зотов, с уважением к вам отношусь, но по-моему вы перегибаете палку. Если бы Java пожизненно тормозила в 15 раз сильнее, чем натив-приложения (2 секунды и 30 секунд) - это бы означало ее смерть и НИКТО бы ее не использовал. Соответственно, минутые операции растягиваются на 15 минут, часовые на 15 часов и так далее. Это уже ОЧЕНЬ критично.

Поэтому одно из:

1) плохо реализовали
2) использовали средство в задачах, для которых оно не предусмотрено
3) выбрали пример, на котором видны все недостатки технологии (это можно придумать для любых средств)

Я не претендую ни на звание профи Delphi, ни тем более Java, исхожу из чисто человеческой логики. Если бы Java был настолько плох - это не было средство разработки в США номер 1. Думаю, факт.

Вряд ли таже кроссплатформенность оправдает ПЯТНАДЦАТИКРАТНОЕ замедление производительности. Ну 2-3 раза еще куда не шло, но не так. Поэтому, имхо, стоит искать косяки у себя.

← →
Sergey Masloff (2006-12-19 06:45) [112]

Piter © (19.12.06 03:11) [111]
>Если бы Java пожизненно тормозила в 15 раз сильнее, чем натив->приложения (2 секунды и 30 секунд) - это бы означало ее смерть и НИКТО >бы ее не использовал.
Если бы у бабушки были мужские первичные половые признаки, то она была бы дедушкой ;-)
А если бы эффективность/целесообразность технологии определяла ее использование в реальности то нас окружал бы совсем другой мир. К сожалению, в двух (и десяти) строчках не описать так что просто прими (или не принимай - мне все равно) как постулат - твои утверждения про смерть и критичность ложны. Имеется очень много других факторов.

мои пять копеек.
java таки тормознее, чем дельфи и даже чем net.

проверял в основном на gui приложениях. просто реализовал одну из экранных форм нашей системы (на дельфи) на java (swing) и на net.

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

Sergey Masloff (19.12.06 6:45) [112]
твои утверждения про смерть и критичность ложны. Имеется очень много других факторов

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

Если цитаты нет - то давай воспринимать слова так, как они сказаны. А я говорл про торможение в 15 раз во всех приложениях. Это наблюдается в java? Если да, если любое java приложение запущенное под винду работает в 15 раз медленнее, чем delphi - то я беру свои слова обратно и удаляюсь.

К

> Суслик © (19.12.06 09:47) [113]

мои копейки: Java 1.5 (и особенно Swing-приложения) заметно тормозят в FreeBSD 6.1. Хотя Sun JVM HotSpot собирал из портов (читай - исходников) с опциями оптимизации под мой CPU (AthlonXP).
Eclipse 3.1 (собрана из портов) тоже тормозит, но не так заметно как NetBeans 5.5.
Другая ситуация в WindowsXP: NetBeans 5.5 работает с той же скоростью (если не большей), как и Eclipse 3.1.

(Здесь: под скоростью подразумевается отклик интерфейса и элементов управления, компиляция происходит везде одинаково быстро).

> Суслик © (19.12.06 16:23) [116]
>
>
> > [115] iZEN © (19.12.06 13:26)
>
> ты это к чему? Не понял?

GUI — он разный. Не только на Windows, но и на других оп.системах.
Если Eclipse использует нативные вызовы к системным виджетам (внутри библиотеки SWT), то NetBeans "рисует" (внутри Swing) прямо на графическом контексте, предоставленном DirectDraw. И всё это очень субъективно, учитывая разную аппаратную конфигурацию машин. У кого-то элементарно не будет задействована 2D-акселерация — и всё, кирдык Swing"у, слайдшоу на P4 будет обеспечено.

> [117] iZEN © (19.12.06 16:57)
> GUI — он разный. Не только на Windows, но и на других оп.системах.
> Если Eclipse использует нативные вызовы к системным виджетам
> (внутри библиотеки SWT), то NetBeans "рисует" (внутри Swing)
> прямо на графическом контексте, предоставленном DirectDraw.
> И всё это очень субъективно, учитывая разную аппаратную
> конфигурацию машин. У кого-то элементарно не будет задействована
> 2D-акселерация — и всё, кирдык Swing"у, слайдшоу на P4 будет
> обеспечено.

Спасибо, хорошо объяснил.

Но вот какая штука. Пользователь на это самое GUI и смотрит. Ему действительно все равно с чем связаны тормоза.

> iZEN © (18.12.06 17:27) [99]
>
> > oxffff © (18.12.06 17:11) [98]
> >
> > Вот это подход к делу.
> > Я думаю через лет 10 скорость станет, как у native x86.
>
>
> Так уже баткод опережает по быстродействию нативный код.
> Ссылка на бенчмарки — выше.
>
> Будут тормозить только неквалифицированные кодеры, неумеющие
> применять инструмент по делу.

Бенчмарки это не показатель.
Любая косвенность это "нагрузка".
И чтобы там Рихтер не писал, несмотря на JIT компиляцию и другие ухищрения, код в целом исполняется медленее.
Да и вы сами подумайте, модификаций процессоров много (не берите поддержку SSE,SSE2 и т.д).
Возьмите размер кэша.
Что .NET будет на него обращать внимание. IMHO нет.

Вы все еще отбеливаете?
Тогда мы идем к вам.

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