Qt vs .NET

[Detonator]

закрывай, мне тоже надоело.

[panAlexey]

ясное дело->close();
Рекламы и восторгов я и по телеку насмотрюсь...

Прежде чем завершить тему, следует отметить и ряд ограничений C#. Одна область, для которой данный язык не предназначен - это критичный по времени или исключительно высокопроизводительный код - когда приходится заботиться о том, чтобы цикл занимал 1000 или 1050 тактов процессора, когда необходимо очищать ресурсы в течение миллисекунд после того, как отпадает потребность в них. Вероятно, C++ продолжает оставаться самым непревзойденным из высокоуровневых языков в этой области. C# недостает некоторых ключевых средств для построения наиболее высокопроизводительных приложений, включая возможность специфицировать встроенные функции и деструкторы, которые гарантированно запускаются в определенной точке кода. Однако пропорциональное отношение таких приложений к их общему числу чрезвычайно низко.

http://www.rsdn.ru/res/book/net/nagel3.0.xml
Чесно говоря мне этот .Net напоминает попытку мелкософта убежать от собственноручно разведенного невообразимого зоопарка и бардака в своих инструментах..
Смотреть там же, начиная с "Для чего подходит C#".

[Tonal]

Например замена свойства в особо узком месте на простое публичое поле или списка/итератора на обычный массив делают это место быстрее в разы.

>> Ужжос! Чем же занимается JIT?
В управляемом коде есть еще понятие безопасности, т.е. при доступе к коду она еще и проверяет имеет ли вызываемый выше по стеку код нужные права, не вызывает ли код из другой сборки приватный код этой сборки и т.д.

Неужели есть критичная разница по скорости что проверять на безопасность свойство или поле?
И мне казалось что JIT должен работать уже после всех проверок по безопасности.
Иначе он будет может сработать впустую - оптимизировать код, который не имеет права на выполнение.

Про сравнение функциональности:
XML .Net-а всего лишь обёртка к MS XML если я не ошибаюсь.
А MS XML - одна из самых продвинутых библиотек работы с XML - например с её обработчиком xslt я игрался ещё примерно лет 7-8 назад.
А в Qt xslt  только обещают.

Базы данных:
ADO.Net - развитие идей MS ADO.
Работа ведётся с Dataset который хранит в себе множество выборок и их связей.
Прозрачное сохранение/восстановление в/их xml,
После загрузки из базы может быть "отсоединён", передан по сети, изменён/дополнен, передан обратно и синхронизирован с базой.
При этом удалённая программа доже не знает о том, что работает не напрямую с сервером.

Ну и вообще, из .Net доступны и имеют свои обёртки все основные подсистемы винды.
Например .Net встроен в MS SQL, и можно писать сохранёнки и триггера на любом из его языков используя все доступные в .Net сервисы.

Короче, если не нужна кросплатформа и железо б.м. новое - то .Net довольно привлекательный выбор.

[Detonator]

> Неужели есть критичная разница по скорости что проверять на безопасность свойство или поле?
> И мне казалось что JIT должен работать уже после всех проверок по безопасности.

public поле это просто public, а public свойство это уже private метод, т.е. дополнительная проверка а имеет ли вызывающий код доступ к этому private.
При пересечении стеком вызова границ сборок происходит еще одна проверка,  напрмер используя в программе в цикле список List реализованный в основной библиотеке Framework'а будет постоянная проверка при каждом обращении к его методам, если предварительно скопировать все во временный массив, то проверок в цикле можно избежать.
Ктому же JIT к этому отношение не имеет, т.к. компилит в каждый момент только одну функцию не зная ничего о других. Ведь FIle.Open() может вызывать как код из интернета которому это запрещено, так и опосредством IsolatedStorage, через который это разрешено.

> XML .Net-а всего лишь обёртка к MS XML если я не ошибаюсь.

в .Net она полностью заново написана на C# и стала даже еще быстрее чем MS XML, быстрее я пока не встречал
Впрочем в Qt тоже появился аналогчиный нетовскому QXmlStreamReader

[Tonal]

> Неужели есть критичная разница по скорости что проверять на безопасность свойство или поле?
> И мне казалось что JIT должен работать уже после всех проверок по безопасности.
public поле это просто public, а public свойство это уже private метод, т.е. дополнительная проверка а имеет ли вызывающий код доступ к этому private.

В С++ проверки public и private доступов имеют место только на этапе компиляции.
На этапе выполнения никаких дополнительных проверок не происходит.
Ты уверен, что спецификаторы доступа как-то влияют на время выполнения?
Т.е. вызов public метода отличается от вызова private по скорости?
Или доступ к private полям из метода класса от доступа к public полям?

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

При пересечении стеком вызова границ сборок происходит еще одна проверка,  напрмер используя в программе в цикле список List реализованный в основной библиотеке Framework'а будет постоянная проверка при каждом обращении к его методам, если предварительно скопировать все во временный массив, то проверок в цикле можно избежать.

Пусть я что-то загрузил извне, проверил его доступы/разрешения.
Они что, могут поменяться после подгрузки динамически?
Какой смысл в таких постоянных проверках?

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

Ещё раз приведу ссылку на флейм: http://gzip.rsdn.ru/forum/message/3047193.aspx
Вроде защитники JIT-а утверждали что он может инлайнить и потом оптимизировать через границы сборок.
Врут?

Ведь FIle.Open() может вызывать как код из интернета которому это запрещено, так и опосредством IsolatedStorage, через который это разрешено.

Ну, это можно реализовать опять же глобальным для потока уровнем доступа.
Когда поток выполнения пересекает границы сборки меняется глобальный уровень доступа.
Который и проверяется в FIle.Open().
Т.е. опять же на скорость выполнения это не сильно влияет - проверки производятся в любом случае.
И уж всяко такие проверки гораздо быстрее чем сами операции с файлами.

> XML .Net-а всего лишь обёртка к MS XML если я не ошибаюсь.
в .Net она полностью заново написана на C# ... Впрочем в Qt тоже появился аналогчиный нетовскому QXmlStreamReader

Дествительно: http://support.microsoft.com/kb/815112
Вот: http://www.sql.ru/docs/AccessingData/index.shtml довольно интересная обзорная статья о базах и XML в .NET-е.
И QXmlStreamReader и .NET-овский XmlTextReader используют наиболее быструю на сегодня pull модель.
Но XmlTextReader - валидирующий а QXmlStreamReader нет. Т.е. если у тебя есть схема или DTD-шка для загружаемого XML-я, то XmlTextReader сообщит об её нарушении, а для QXmlStreamReader такую проверку нужно организовывать самостоятельно.

[Detonator]

> Ты уверен, что спецификаторы доступа как-то влияют на время выполнения?

Я не знаю насколько именно влияют, но то что проверки идут в рантайме это точно. Ведь на .NET используются и языки которые не проверяют типы/моификаторы доступа, да и хитрый IL-асемблерный код сгенерить на лету всегда можно - так вот вызов таким способом извне приватного метода объекта выдаст Exception. Этим он и отличается от C++, Delphi и прочих обычных языков где код имеет доступ куда только пожелает.

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

JIT автоматически инлайнит функции размером не более 32 байт кода, все что больше остаются обычным вызовом. А учитывая как много в исходниках .NET всяких проверок параметров  в теле функций они легко превышают этот рубеж.

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

Я не знаю почему проектировщики .NET выбрали другой метод проверок доступа, наверняка были причины.

> Пусть я что-то загрузил извне, проверил его доступы/разрешения.
> Они что, могут поменяться после подгрузки динамически?

Как ты можешь это проверить в момент загрузки? Как ты можешь быть уверен что код не поменяется по ходу выполнения, ведь код может подгружать новый код, даже на лету в памяти компилить и выполнять C# код можно, не гворя уже о простой прямой генерации нового IL кода.

> Вроде защитники JIT-а утверждали что он может инлайнить и потом оптимизировать через границы сборок.
> Врут?

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

В общем я делал тест, большой список объектов точка Point { double X,Y; }, в цикле значения координат точки увеличиваются на какое-то значение и точка пишется обратно в список,
- в первом случае X,Y свойства вида { get { return x; } set { x = value } } и точки хранятся в List<Point>,
- во втором случае X,Y просто публичные поля и точки хранятся в Point[].
В режиме Release со всеми включенными оптимизациями первый код дольше второго в 3-4 раза (из них в 1.5 раза медленнее это доступ к свойствам X,Y, в 2.5 раза медленнее доступ к индексатору List[]), в режиме Debug и отключенной оптимизации первый код дольше второго в 12 раз! С тех пор у меня все алгоритмы геометрии работают только с подобным типом точек и массивами.

[Tonal]

> Ты уверен, что спецификаторы доступа как-то влияют на время выполнения?
Я не знаю насколько именно влияют, но то что проверки идут в рантайме это точно. ...
Этим он и отличается от C++, Delphi и прочих обычных языков где код имеет доступ куда только пожелает.

В таком случае, это просто разные механизмы решающие разные задачи.
В C++, Delphi спецификаторы доступа - это просто помощь забывчивому кодеру, чтобы по нечайности не изменил чего не нужно и вообще не создавал дополнительной связанности.
Ежели полностью в себе уверен - можно всё на структурах писать - разницы не будет.
Понятно, что когда код работает этого всего уже не нужно.
А в .Net - это похоже один из механизм аутентификации - стало быть и применять его нужно не так и не для того.

> Пусть я что-то загрузил извне, проверил его доступы/разрешения.
> Они что, могут поменяться после подгрузки динамически?
Как ты можешь это проверить в момент загрузки? Как ты можешь быть уверен что код не поменяется по ходу выполнения, ведь код может подгружать новый код, даже на лету в памяти компилить и выполнять C# код можно, не гворя уже о простой прямой генерации нового IL кода.

Код создаётся/подгружается 1 раз. Его же нельзя после этого модифицировать.
Доступы ему назначаются 1 раз - зачем каждый то раз проверять?

В общем я делал тест, большой список объектов точка Point { double X,Y; }, в цикле значения координат точки увеличиваются на какое-то значение и точка пишется обратно в список,

Я довольно долго и плотно работал в проекте с векторной графикой.
Серьёзно бороться с производительность пришлось 3 раза:
1) Ещё для 486 пришлось написать перевод координат из мировой в оконную, т.к. багланд совсем не умеет оптимизировать плавающую точку и тупая реализация на асме его обгоняет.
2) Т.к. для багланда не было профилятора пришлось руками логировать код, чтобы доказать что тормозит не отрисовка а доступ к базе
3) Пришлось повозится с надписями - там пришлось кешировать каждый чих, правда до глифов таки не опустился.
Сейчас оно конечно вряд ли взлетит на 486, но везде, где Win95se ещё шевелиться работать вроде должно не зависимо от объёма данных
А ты говоришь, 1,5ггц, 512мб...

[Detonator]

> Доступы ему назначаются 1 раз

Доступы ты можешь запрашивать и изменять динамически из программы.

[ритт]

http://www.prog.org.ru/topic_7959_0.html
продолжим флэйм с учётом обновлённых фактов?

[Detonator]

А какие там факты появились, что то не пойму. Своя IDE появилась? Так сначала бы integration для VS до ума довели бы, а потом о своей IDE думали. Хотя возможно для MacOS/Linux эта IDE и важна.

[pastor]

Integration для VS ненужен

[Detonator]

Кому ненужен, линксоидам?

Is Qt Creator a replacement for Visual Studio?
Qt Creator is not a Visual Studio replacement, but instead a lightweight IDE designed specifically for cross-platform Qt development. We developed Qt Creator to provide our users with options. If a developer is comfortable with Visual Studio, we highly encourage them to continue using it. We will certainly continue to develop and improve our Visual Studio integration.

[ритт]

мне он и под вендой не нужен - я сейчас под мингвом пишу
а по удобству и возможностям Qt Creator уже постепенно приближается к студии...

[pastor]

Кому ненужен, линксоидам?

Это не есть обходимая вещь. Я пишу под вендой в студии, интегратор неюзал ниразу. А зачем он?

[Detonator]

а по удобству и возможностям Qt Creator уже постепенно приближается к студии...

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

Я пишу под вендой в студии, интегратор неюзал ниразу. А зачем он?

А низачем, глюкавый он. Но т.к. установил все таки пытаюсь изучить и приспособиться к нему. Чтобы потом тут не спрашивать "А зачем он?"