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

← →
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), но это не приветствуется, т.к. теряется переносимость.

← →
Anatoly Podgoretsky © (2006-12-18 15:09) [84]

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

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

← →
Anatoly Podgoretsky © (2006-12-18 15:10) [85]

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

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

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

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

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

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

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

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

> 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, и без нее). Естественно, я в курсе, что происходит при каждом первом запуске после очередной пересборки и говорю не о нем.

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

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

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

← →
oxffff © (2006-12-18 15:53) [89]

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

← →
oxffff © (2006-12-18 15:56) [90]

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

← →
ANTPro © (2006-12-18 16:18) [91]

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

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

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

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

www.delphi_jedi.org

← →
Eraser © (2006-12-18 16:25) [93]

> [91] ANTPro © (18.12.06 16:18)

слышал, что в BDS похожее сделано именно с использованием кода jcl.

← →
ANTPro © (2006-12-18 16:31) [94]

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

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

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

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

← →
Eraser © (2006-12-18 16:47) [95]

> [94] ANTPro © (18.12.06 16:31)

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

← →
iZEN © (2006-12-18 16:58) [96]

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

← →
iZEN © (2006-12-18 17:06) [97]

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

← →
oxffff © (2006-12-18 17:11) [98]

> 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.

← →
iZEN © (2006-12-18 17:27) [99]

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

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

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

← →
Virgo_Style © (2006-12-18 18:08) [100]

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

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

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

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

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

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

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

← →
iZEN © (2006-12-18 18:50) [102]

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

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

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

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

???

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

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

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

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

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

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

← →
iZEN © (2006-12-18 19:39) [104]

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

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

← →
Юрий Зотов © (2006-12-19 00:07) [105]

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

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

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

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

← →
iZEN © (2006-12-19 00:20) [106]

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

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

← →
Petr V. Abramov © (2006-12-19 00:36) [107]

> Юрий Зотов ©
> Код интерпретируемый (даже и байт-код - он все равно интерпретируемый) не может быть быстрее кода нативного в принципе.
оно конечно так. только не с разницей на 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 Найти похожие ветки