Здравствуйте, IT, Вы писали:
IT>Здравствуйте, AndrewVK, Вы писали:
AVK>>На самом деле все печальнее. Хоть винды и не RTOS, но большое количество рилтаймовых задач на ней вполне решаются. А вот с .NET/Java этих задач значительно меньше. Главный виновник — GC. Из-за него на этих платформах реализуемы только системы, время гарантированного отклика которых измеряется десяками секунд.
IT>Десятками? А ты не пробовал вместо XT, хоты бы пентиум поставить?
А при чем тут машина. Все зависит от реализации сборщика мусора. Можно написать и такой, который за все время работы программы ни разу не вызовется по неизветсным причинам. В том то и фишка, что ты практически не управляешь ресурсами. Память освобождается не тогда, когда тебе это надо, а тогда, когда это посчитает нужным сделать машина — т.е. гарантии никакой. Для систем реального времени это весьма существенное ограничение — они то в большенстве своем работают с весьма конкретными временными параметрами.
Здравствуйте, Serginio1, Вы писали:
S> Наврядл и такой язык вообще нужен, т.к. приведет к большей сложности и ненужного в большинстве задач функционала,
Язык? Смотри глубже. Платформа. .NET. Вот там должен быть функционал. Тогда никакого усложения не должно быть.
И ты уже сможешь его или использовать, или нет, из-под конкретного языка. Далее, что если из-под одного языка это легче написать, чем из-под другого? Тогда нужно повысить (усреднить) уровень абстракции. Получили две равноправные языковые реализации. Сокротив коэфициенты, мы получили в итоге наш язык.
S> а вот использование вставок (аля asm) было бы очень даже привлекательно.
Здравствуйте, TK, Вы писали:
>> Система которая гарантированно обрабатывает все поступившие запросы. TK>Наверное все-таки не гарантированно, а за гарантированное время.
Технически да, но пинимание невеное. Делается так. Я знаю что по тем или иным причинам сообщения не будут приходить чаще чем 20 раз в секунду. Скажем это частота обновления показаний датчика. Причём это не средняя частота, а максимум. Значит я делаю обработчик который работает не дольше чем 0.05 сек. В этом смысле да, за гарантированное время
>>
TK>Сообщение никто не проглотит.
Что значит не проглотит? Очередь сообщений не резиновая.
TK>Другое дело, что таже java не может гарантировать, что сообщение о превышении температуры будет доставлено оператору например за 1сек максимум.
Здравствуйте, TK, Вы писали:
TK>А для чего? Возможное падение производительности процессора на 10% это существенный факт?
Если ты считаешь сумму от 1 до 100 то может и 10%, а ты расчитай электромагнитное поле вокруг антенны. Оно кстати меняется во времени. У меня тут знакомые считают так там оптимизации идут жуткие. Разница с Нетом в разы. А обсчёт иногда идёт несколько суток на 2-х процессорной машине.
TK>Да и потом — .NET широкая это платформа, а не один конкретный язык со всеми его недостатками.
Безусловно. Обсуждаем недостатки CLR и его использования, ок? Я пока вроде слова Шарп не говорил.
TK>А факт/не факт — с тем-же успехом, можно сказать, что вычислительные задачи однозначно не для AMD
Ну смотря какой AMD Но вобщем ,если взять те что были без SSE2, то да.
Здравствуйте, mikа, Вы писали:
A>>Спрашивается, зачем переносить на .Net код который не будет использовать возможностей .Net? M>Из крайности в крайноисть. Узкие места вычислений, на native, не узкие — на safe. Все просто.
Здравствуйте, adontz, Вы писали:
M>>Из крайности в крайноисть. Узкие места вычислений, на native, не узкие — на safe. Все просто.
A>Так там сплошное узкое место!
А ты zlib будешь использовать отдельно или таки встроешь в свою программу?
Здравствуйте, adontz, Вы писали: A>Если ты считаешь сумму от 1 до 100 то может и 10%, а ты расчитай электромагнитное поле вокруг антенны. Оно кстати меняется во времени. У меня тут знакомые считают так там оптимизации идут жуткие. Разница с Нетом в разы. А обсчёт иногда идёт несколько суток на 2-х процессорной машине.
Ну двухпроцессорные машины разные бывают, тем более что определенных задач и процессоры нужны другие.
Но Это касается очень специфичных задач. Например наш Эльбрус, но тенденция процессостроения идет к многоядерной и стековой архитектуре (IL использует виртуальный стековый процессор). Вообще то Net весьма молод и пока является надстройкой. Всему свое время.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, TK, Вы писали:
TK>>А для чего? Возможное падение производительности процессора на 10% это существенный факт?
A>Если ты считаешь сумму от 1 до 100 то может и 10%, а ты расчитай электромагнитное поле вокруг антенны. Оно кстати меняется во времени. У меня тут знакомые считают так там оптимизации идут жуткие. Разница с Нетом в разы. А обсчёт иногда идёт несколько суток на 2-х процессорной машине.
откуда они знают, что разница с .НЕТ в разы? Они что, и на НЕТе написали этот обсчет (который только считает неск суток, а сколько же его писать надо )
Здравствуйте, oRover, Вы писали:
R>откуда они знают, что разница с .НЕТ в разы? Они что, и на НЕТе написали этот обсчет (который только считает неск суток, а сколько же его писать надо )
Сутки считается потому что данных много, и детализация большая оченть, сами алгоритмы относиленьно простые.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Nick Notabene, Вы писали:
NN>>1)Критичных к скорости выполнения
S> Самый смех, что даже если бы это было так, на данном этапе это не представляет особой важности тем более когда в уже в 1.2 есть дженерики. Даже при увеличении скорости за счет алгоритмов в 2-4 раза это никому не нужно, т.к. технологичность и унификация на первом месте (хорошо это или плохо не мне судить) NN>>2)Оперирующих с большими блоками ( 50-100 Мб и больше) данных S> Не совсем так, при работе с валуе типами это не имеет значения, другое дело работа с большим количеством объектов http://www.rsdn.ru/Forum/Message.aspx?mid=415352&only=1
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, oRover, Вы писали:
R>>откуда они знают, что разница с .НЕТ в разы? Они что, и на НЕТе написали этот обсчет (который только считает неск суток, а сколько же его писать надо )
A>Сутки считается потому что данных много, и детализация большая оченть, сами алгоритмы относиленьно простые.
D_T>а какже всякие там 3D studio MAX,Maya, Photoshop, Illustrator, AutoCAD ? D_T>они от перехода на Net только проиграют
Там, как мне кажется, 90% кода — это НЕ РАСЧЕТНЫЕ задачи. И эти 90% гораздо лучше делать на удобном, надежном, пусть не таком быстром средстве разработки.
А остальные 10% — это DirectX/OpenGL и свои расчетные дела, которые по любому оптимизируют небось по самое нехочу — ну и пусть остаются на асме.
Вау !
Не ожидал такого оживленного трепалова по такой избитой тематике
В общем-то, все аргументы, которые можно привести, тут уже привели, как с одной, так и с другой стороны.
Собственно, сама тема навеяна одой Михалика ( если не ошибаюсь), что-то вроде:
если вам надо текстовый редактор то вам нужен дотнет,
если вам надо приложение БД, то вам нужен дотнет,
если вам надо формочку, то вам нужен дотнет,
если вам надо тонкую талию и высокую грудь, то вам нужен дотнет
и т.д.
2Igor Trofimov: как уже было справедливо сказано, и архивирование, и кодирование/декодирование,
и обработка растровой графики безусловно являются приложениями, критичными ко времени.
Если вы считаете иначе, попробуйте перекодировать несколько ваших любимых фильмов,
или обработать несколько растровых изображений для печати формата А3 — не такая уж и экстремальная
задача, согласитесть. И падение производительности на 10% совсем не ерунда — за две рабочих недели
у вас элементарно набежит еще один рабочий день, который вы не успели...
Почему дотнет работает медленно с большими блоками (больше 50 Мб) — я не знаю.
Предполагаю, что тут как-то замешан GC — больше вроде некому
Если использование хипов с блоками однотипных данных в native code programming позволяет существенно ускроить работу, то под
.Нет такого не наблюдается — только управлением хипами с использованием win32 api функций, что не есть
гуд — какой тогда смысл в дотнет ?
Это же в общем касается и MC++. Вообще пародоксальный гибрид. Нужен только в том случае,
если вы позарез хотите использовать готовые библиотеки от MS. Если вы поработали на С++
больше трех лет, у вас уже наверняка есть библиотеки, наиболее подходящие для ваших задач, и
как показывает практика, их качество не хуже, а зачастую лучше аналогичных от MS. Возьмите
boost или loki. Про "безопасность и скорость разработки" тут говорить не стоит по вполне понятным
причинам.
iT>Тоже не понимаю. Разве в native C++ выражение 1.123/3.321 даст результат отличный от результата этого же выражения в
managed C++?
Нет, тот же. И время вычисления будет одинаково никаким — это константное выражение.
А вот a = 1.123 b = 3.321; c = a/b; даст одинаковый результат, но за разное время.
2Serginio1 — не могу с вами согласится, что JIT компилятор ( для .Net Framework v 1.1 и v 1.2) делает
"оооочень хорошую" оптимизацию под конкретный процессор. Мог бы, но не делает.
Я думаю, это тоже маркетинг. Люди должны покупать новые мощные компьютеры, чтобы ставить на них новые модщные операционные
системы, для которых нужны более мощные компьютеры, для которых нужны более новые операционные системы et cetera...
Для сравнения — попробуйте посчитать двумерное преобразование Фурье для достаточно большой матрицы, например 10 000 х 10 000 double значений
с использованием С# и Intel C++ v.6. А это достаточно простой тест, и нифига не синтетический, и в реальной
жизни встречается часто, причем в разных областях обработки. Тут вам и работа с достаточно большим блоком памяти.
2oRover — SOAP — это как-то связано с мылом ??? )
А если серьезно — траффик действительно растет на 10-15%. Я не разбирался подробно. Но SOAP я не использую.
Ясен перец, что после объявления .Net платформой будущего, выбора у Win- программистов в общем-то не осталось —
так или иначе, все будут там или вне бизнеса. Просто не надо делать из .Net панацею.
А вообще-то, раньше выхода .Net Framework v2.0 SP3 делать на нем коробочные программы глупо.
Как показывает практика У меня перед глазами лежит два дотнет прилолжения — одно кривее другого, и за оба хотят
деньги. Гыгы.
2All Прошу прощения за невольный флеймгенератор. Философией тут и не пахнет.
Интуитивно понятный интерфейс — это интерфейс, для работы с которым нужна недюжинная интуиция...
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, AVM, Вы писали:
AVM>>Если мне не изменяет память в native С\С++ исходный код компилируется в объектные модули(.obj, .o и тд ), которые содержат, в том числе, процессорные команды. Потом линкером объектные модули и библиотеки собираются в исполняемый модуль (exe, elf и тд). В общих чертах так, детали я опускаю. AVM>>В NET программа написанная на С++ (или на другом поддерживаемом языке) собирается по другому, исходник компилируется в байт-код (MSIL) и потом полученный байт код выполняется под CLR. S>Нет. Перед выполнением код компилируется в процессорные команды. При этом они очень похожи на те, которые попадают в "обычный" exe файл.
Когда я писал "потом полученный байт код выполняется под CLR." Именно это и подразумевалось. Что такое just-in-time я немного представляю
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, AVM, Вы писали:
AVM>>Я могу допустить что GUI в обоих cлучаях будет работать одинаково, но неужели не будет различий, и потери производительности во втором случае, при работе с памятью или при вычислительных операциях ?
TK>Как показывает практика — различие в производительности от десятков до единиц процентов.
Это для GUI или для вычислений/работе с памятью ?
TK>также не стоит забывать, что runtime это динамичная среда — код генерируется в расчете на текущий процессор, а не на общий знаменатель, как это может быть для native c++. Плюс использование различных технологий профилирования (т.е. в процессе работы программы снимаются различные показатели скорости выполнения и критические участки могут быть аггрессивно оптимизированы) также позволяет поднять скорость работы уже запущенной программы (понятно, что для обычного native C++ это просто не доступно). StarJIT
Спасибо за ссылку.
AVM>>- программы написанные на интерпритируемых (скриптовых) языках (JScript, VBScript, php) при переносе на NET должны выиграть в производительности, за это приходится платить дополнительной "громоздкостью" среды в которой они выполняются.
TK>Громозкость среды — это ~на порядок. Плюс не стоит забывать, что среда может быть "предустановленна"
Причем желательно чтобы "предустановленна" аппаратно. Java за 8 лет существования пока не получила java-процессор, полностью поддерживающий java- байт-код (или я отстал от жизни ? ).
Если появится процессор полностью поддерживающий MSIL (и ему для работы не нужна будет WinOC ) — это будет просто замечательно.
AVM>>- программы на native С++ будут выигрывать в компактности и быстродействии у программ написанных на С++.NET.
TK>В компактности native код будет сильно проигрывать managed приложениям. во первых это связано с тем, что в .NET уже есть богатая библиотека классов, а во вторых байт код банально компактнее, чем аналогичный native.
я не про компактность кода говорю, а про компактность программа+среда(в которой программа выполняется)
AVM>>Стоит ли овчинка (поддержка множества языков) выделки ? Поживем увидим.....
TK>учитывая, что на данный момент еще не создали язык который покрывает 100% требований, можно считать — стоит.
Неточно выразился, поэтому ты видимо меня не совсем понял, переформулирую:
Стоит ли овчинка (поддержка множества существующих языков в NET) выделки ?
По прогнозам наибольшую популярность из всех языков (поддерживаемых в NET) получат VB.NET и С#.
Питон, перл, j# в NET это IMHO маркетинговый ход, что бы новая среда завоевала бОльшую популярность.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, AVM, Вы писали:
AVM>>Если мне не изменяет память в native С\С++ исходный код компилируется в объектные модули(.obj, .o и тд ), которые содержат, в том числе, процессорные команды. Потом линкером объектные модули и библиотеки собираются в исполняемый модуль (exe, elf и тд). В общих чертах так, детали я опускаю. AVM>>В NET программа написанная на С++ (или на другом поддерживаемом языке) собирается по другому, исходник компилируется в байт-код (MSIL) и потом полученный байт код выполняется под CLR. AVM>>Я могу допустить что GUI в обоих cлучаях будет работать одинаково, но неужели не будет различий, и потери производительности во втором случае, при работе с памятью или при вычислительных операциях ?
L>В нетовских сборках может лежать не только ил, но и нативный код.
Что ты подразумеваешь под "нетовской сборкой"? И очень ли она нужна для выполнения нативного кода.
IMHO наоборот, пока нативный код нужен для более оптимальной работы "нетовской сборки".
AVM>>IMHO AVM>>- программы написанные на интерпритируемых (скриптовых) языках (JScript, VBScript, php) при переносе на NET должны выиграть в производительности, за это приходится платить дополнительной "громоздкостью" среды в которой они выполняются.
L>Благодаря чему должны выиграть в производительности интерпритируемые языки ?
Интерпретируемые языки должны выиграть за счет наличия JIT.
Здравствуйте, AVM, Вы писали:
L>>Благодаря чему должны выиграть в производительности интерпритируемые языки ? AVM>Интерпретируемые языки должны выиграть за счет наличия JIT.
Интерпретируемые языки -- это языки которые интерпретируются (не компилируются). Им jit совершенно не в кассу.
Здравствуйте, Nick Notabene, Вы писали:
NN>Это же в общем касается и MC++. Вообще пародоксальный гибрид. Нужен только в том случае, NN>если вы позарез хотите использовать готовые библиотеки от MS. Если вы поработали на С++ NN>больше трех лет, у вас уже наверняка есть библиотеки, наиболее подходящие для ваших задач, и NN>как показывает практика, их качество не хуже, а зачастую лучше аналогичных от MS.
Ты опять не понял главного. Lock и boost это конечно хорошо, но это всего лишь lock и boost. Ничего больше. Улавливаешь?
NN>2oRover — SOAP — это как-то связано с мылом ??? ) NN>А если серьезно — траффик действительно растет на 10-15%.
Мда. И как ты это проверял? Можешь привести логи прокси-сервера?
NN>Ясен перец, что после объявления .Net платформой будущего, выбора у Win- программистов в общем-то не осталось — NN>так или иначе, все будут там или вне бизнеса. Просто не надо делать из .Net панацею.
Ее воообщем то делаете вы, спрашивая где ее место и где ее не место.
NN>А вообще-то, раньше выхода .Net Framework v2.0 SP3 делать на нем коробочные программы глупо.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, AVM, Вы писали:
L>>>Благодаря чему должны выиграть в производительности интерпритируемые языки ? AVM>>Интерпретируемые языки должны выиграть за счет наличия JIT.
L>Интерпретируемые языки -- это языки которые интерпретируются (не компилируются). Им jit совершенно не в кассу.
Но вобщем ,если взять те что были без SSE2, то да.
)
)
