TK>> J# — дополнительные возможности от java библиотеки. TK>>
L>С java-библиотеками работать он все-таки не будет.
Java библиотека классов в рамках java 1.1 там присутствует.
(разумеется, что явовский байт код работать там не будет, и для использования в J# его надо специальным образом конвертировать)
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Lloyd, Вы писали:
TK>>>
TK>>> J# — дополнительные возможности от java библиотеки. TK>>>
L>>С java-библиотеками работать он все-таки не будет.
TK>Java библиотека классов в рамках java 1.1 там присутствует. TK>(разумеется, что явовский байт код работать там не будет, и для использования в J# его надо специальным образом конвертировать)
Жестко. Только вот java 1.1 не актуальна ужо года три-четыре как. И ан кой ляд нужно ваще портировать жабовский байт код в нетовский. Ваще лично мне кажется что Ж# — это мегагнилая идея. Отдает каким-то популизмом. Скоро будет того гляди Python#
G>Жестко. Только вот java 1.1 не актуальна ужо года три-четыре как. И ан кой ляд нужно ваще портировать жабовский байт код в нетовский. Ваще лично мне кажется что Ж# — это мегагнилая идея. Отдает каким-то популизмом. Скоро будет того гляди Python#
А какие проблемы — Python for .NET уже давно в разработке здесь например...
Здравствуйте, Glоbus, Вы писали:
TK>>Java библиотека классов в рамках java 1.1 там присутствует. TK>>(разумеется, что явовский байт код работать там не будет, и для использования в J# его надо специальным образом конвертировать)
G>Жестко. Только вот java 1.1 не актуальна ужо года три-четыре как.
В поставке с Windows идет именно эта версия. Многие использовать именно ее. также есть J++ для пользователей которого MS предлагает вариант миграции.
G>И ан кой ляд нужно ваще портировать жабовский байт код в нетовский. Ваще лично мне кажется что Ж# — это мегагнилая идея. Отдает каким-то популизмом. Скоро будет того гляди Python#
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, AVM, Вы писали:
AVM>>Правильно ли я понимаю что программа написанная на VC++, будет работать абсолютно так же, как и программа написанная на C++ под NET ? AVM>>Или в NET вообще нет поддержки C++ ?
TK>Поддержка С++ есть. Большинство программ написанных для C++ могут работать либо как обычно либо с минимальными переделками. На сайте MS есть рассказ про портирование Quake2 под .NET по описанию — это не заняло много времени.
Если мне не изменяет память в native С\С++ исходный код компилируется в объектные модули(.obj, .o и тд ), которые содержат, в том числе, процессорные команды. Потом линкером объектные модули и библиотеки собираются в исполняемый модуль (exe, elf и тд). В общих чертах так, детали я опускаю.
В NET программа написанная на С++ (или на другом поддерживаемом языке) собирается по другому, исходник компилируется в байт-код (MSIL) и потом полученный байт код выполняется под CLR.
Я могу допустить что GUI в обоих cлучаях будет работать одинаково, но неужели не будет различий, и потери производительности во втором случае, при работе с памятью или при вычислительных операциях ?
AVM>>Спрашиваю не для флейма, а что бы понять что реально дает поддержка в net множества ЯП.
TK>Каждый язык имеет свою нишу.
TK>
TK> VB.NET или JScript.NET удобны в случае использования позднего связывания (работа с Automation клиентами и т.п.). TK> С++ удобен для взаимодействия с native кодом — прозрачная работа с WinAPI вызовами. TK> J# — дополнительные возможности от java библиотеки. TK>
IMHO
— программы написанные на интерпритируемых (скриптовых) языках (JScript, VBScript, php) при переносе на NET должны выиграть в производительности, за это приходится платить дополнительной "громоздкостью" среды в которой они выполняются.
— программы на native С++ будут выигрывать в компактности и быстродействии у программ написанных на С++.NET.
— если сравнивать программы на java и j# — зависит от того кто лучше руелизует трансляцию/исполнение байт-кода.
Язык это же не просто синтаксис и семантика, это еще и среда к которой работает программа, написанная на этом языке.
Стоит ли овчинка (поддержка множества языков) выделки ? Поживем увидим.....
Здравствуйте, AVM, Вы писали:
AVM>Если мне не изменяет память в native С\С++ исходный код компилируется в объектные модули(.obj, .o и тд ), которые содержат, в том числе, процессорные команды. Потом линкером объектные модули и библиотеки собираются в исполняемый модуль (exe, elf и тд). В общих чертах так, детали я опускаю. AVM>В NET программа написанная на С++ (или на другом поддерживаемом языке) собирается по другому, исходник компилируется в байт-код (MSIL) и потом полученный байт код выполняется под CLR. AVM>Я могу допустить что GUI в обоих cлучаях будет работать одинаково, но неужели не будет различий, и потери производительности во втором случае, при работе с памятью или при вычислительных операциях ?
В нетовских сборках может лежать не только ил, но и нативный код.
AVM>IMHO AVM>- программы написанные на интерпритируемых (скриптовых) языках (JScript, VBScript, php) при переносе на NET должны выиграть в производительности, за это приходится платить дополнительной "громоздкостью" среды в которой они выполняются.
Благодаря чему должны выиграть в производительности интерпритируемые языки ?
AVM>- программы на native С++ будут выигрывать в компактности и быстродействии у программ написанных на С++.NET.
Здравствуйте, AVM, Вы писали:
AVM>Если мне не изменяет память в native С\С++ исходный код компилируется в объектные модули(.obj, .o и тд ), которые содержат, в том числе, процессорные команды. Потом линкером объектные модули и библиотеки собираются в исполняемый модуль (exe, elf и тд). В общих чертах так, детали я опускаю.
Теперь VC++ в OBJ может помещать код на промежуточном языке (IL). А инструкции процессора генерируются уже на этапе сборки. KeyWord: LTCG
AVM>В NET программа написанная на С++ (или на другом поддерживаемом языке) собирается по другому, исходник компилируется в байт-код (MSIL) и потом полученный байт код выполняется под CLR.
Полученный байт код сам по себе не выполняется. Перед выполнением он копилируется в инструкции конечного процессора. т.е. в финале мы все равно имеем инструкции процессора. и их эффективность зависит только он используемого компилятора (JIT)
AVM>Я могу допустить что GUI в обоих cлучаях будет работать одинаково, но неужели не будет различий, и потери производительности во втором случае, при работе с памятью или при вычислительных операциях ?
Как показывает практика — различие в производительности от десятков до единиц процентов. также не стоит забывать, что runtime это динамичная среда — код генерируется в расчете на текущий процессор, а не на общий знаменатель, как это может быть для native c++. Плюс использование различных технологий профилирования (т.е. в процессе работы программы снимаются различные показатели скорости выполнения и критические участки могут быть аггрессивно оптимизированы) также позволяет поднять скорость работы уже запущенной программы (понятно, что для обычного native C++ это просто не доступно). StarJIT
AVM>- программы написанные на интерпритируемых (скриптовых) языках (JScript, VBScript, php) при переносе на NET должны выиграть в производительности, за это приходится платить дополнительной "громоздкостью" среды в которой они выполняются.
Громозкость среды — это ~на порядок. Плюс не стоит забывать, что среда может быть "предустановленна"
AVM>- программы на native С++ будут выигрывать в компактности и быстродействии у программ написанных на С++.NET.
В компактности native код будет сильно проигрывать managed приложениям. во первых это связано с тем, что в .NET уже есть богатая библиотека классов, а во вторых байт код банально компактнее, чем аналогичный native.
AVM>Стоит ли овчинка (поддержка множества языков) выделки ? Поживем увидим.....
учитывая, что на данный момент еще не создали язык который покрывает 100% требований, можно считать — стоит.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
AVM>Если мне не изменяет память в native С\С++ исходный код компилируется в объектные модули(.obj, .o и тд ), которые содержат, в том числе, процессорные команды. Потом линкером объектные модули и библиотеки собираются в исполняемый модуль (exe, elf и тд). В общих чертах так, детали я опускаю. AVM>В NET программа написанная на С++ (или на другом поддерживаемом языке) собирается по другому, исходник компилируется в байт-код (MSIL) и потом полученный байт код выполняется под CLR.
Нет. Перед выполнением код компилируется в процессорные команды. При этом они очень похожи на те, которые попадают в "обычный" exe файл.
... << RSDN@Home 1.1.2 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, TK, Вы писали:
TK>Нет. Так-же как и Windows не является OS реального времени.
На самом деле все печальнее. Хоть винды и не RTOS, но большое количество рилтаймовых задач на ней вполне решаются. А вот с .NET/Java этих задач значительно меньше. Главный виновник — GC. Из-за него на этих платформах реализуемы только системы, время гарантированного отклика которых измеряется десяками секунд.
Здравствуйте, rmihael, Вы писали:
R>А чему же ещё там быть критичным? Если тот же 7zip переписать под дотНЕТ, то архивировать он станет здорово дольше.
Зачем переписывать? Пересобери под MC++. Думаю разница вряд ли будет больше 10%.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, IT, Вы писали:
IT>>Не забываем про MC++? Например, zlib переносится на MC++ на раз-два и работает так же быстро. При желании такие участки кода можно сразу компилировать в native-код, разницы не будет совсем никакой.
A>Спрашивается, зачем переносить на .Net код который не будет использовать возможностей .Net?
Из крайности в крайноисть. Узкие места вычислений, на native, не узкие — на safe. Все просто.
Самый смех, что даже если бы это было так, на данном этапе это не представляет особой важности тем более когда в уже в 1.2 есть дженерики. Даже при увеличении скорости за счет алгоритмов в 2-4 раза это никому не нужно, т.к. технологичность и унификация на первом месте (хорошо это или плохо не мне судить) NN>2)Оперирующих с большими блоками ( 50-100 Мб и больше) данных
Не совсем так, при работе с валуе типами это не имеет значения, другое дело работа с большим количеством объектов http://www.rsdn.ru/Forum/Message.aspx?mid=415352&only=1
где GC начинает подтормаживать. Выход работать с массивами валуе типов или создания своих хипов с валуе типами. NN>3)Принимающих/передающих эти блоки по коммуникациям с ограниченной пропускной способностью (траффик растет как на дрожжах, а за счет чего ??? )
За счет ручной сериализации тоже решается данная проблема, но могут возникать проблемы версионности. NN>4) Производящих обсчет данных с плавающей точкой, итерационными алгоритмами и n- методами
Работает очень быстро учитывая ооочень хорошую оптимизацию JIT компилятора с возможностью оптимизации под данный процессор.
Вот где нет Net места, то можно предположить для очень специфических задач с вылизыванием кода и применением Асма.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, oRover, Вы писали:
R>а если переписать на ассемблер обсчет задачи, которая написана на С++ и выполняется 2 месяца, то она будет выполняться полмесяца. Сколько денег экономим. А теперь если посчитать, сколько времени и денег обойдется написание нам этой задачи, то нет уж, лучше пусть считает 2 месяца
Не факт. Совсем не факт. Вычислительные программы писали на ассемблере вполне успешно и успели набить руку. Тем не менее, с приходом Фортрана, на него перешли очень быстро -- код, который генерировал компилятор, выполнялся быстрее ассемблерного. А С++ по скорости выполнения кода уже догнал Фортран, а в некоторых областях и перегнал.
ЗЫ. Я этих событий не застал, так что могу ошибаться. Но по словам людей, с которыми работаю, происходило всё именно так.
R>ЗЫ. Под .НЕТ есть С++.NET, тот же unfase код
Замечание дельное, готовлю ответ.
Здравствуйте, AVM, Вы писали:
AVM>Стоит ли овчинка (поддержка множества языков) выделки ? Поживем увидим.....
Точно стоит. Особенно, если появится поддержка функциональных (Haskell, Lisp) и логических (Prolog, Mercury) языков. А то сращивание их с алгоритмическими -- это такая головная боль...
Здравствуйте, TK, Вы писали:
AVM>>Стоит ли овчинка (поддержка множества языков) выделки ? Поживем увидим.....
TK>учитывая, что на данный момент еще не создали язык который покрывает 100% требований, можно считать — стоит.
Здравствуйте, AndrewVK, Вы писали:
AVK>На самом деле все печальнее. Хоть винды и не RTOS, но большое количество рилтаймовых задач на ней вполне решаются. А вот с .NET/Java этих задач значительно меньше. Главный виновник — GC. Из-за него на этих платформах реализуемы только системы, время гарантированного отклика которых измеряется десяками секунд.
Десятками? А ты не пробовал вместо XT, хоты бы пентиум поставить?
Если нам не помогут, то мы тоже никого не пощадим.
TK>>учитывая, что на данный момент еще не создали язык который покрывает 100% требований, можно считать — стоит.
M>Но стоит заметить, что к этому все стремится.
Наврядл и такой язык вообще нужен, т.к. приведет к большей сложности и ненужного в большинстве задач функционала, а вот использование вставок (аля asm) было бы очень даже привлекательно.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Glоbus, Вы писали:
TK>>>Java библиотека классов в рамках java 1.1 там присутствует. TK>>>(разумеется, что явовский байт код работать там не будет, и для использования в J# его надо специальным образом конвертировать)
G>>Жестко. Только вот java 1.1 не актуальна ужо года три-четыре как.
TK>В поставке с Windows идет именно эта версия. Многие использовать именно ее. также есть J++ для пользователей которого MS предлагает вариант миграции.
Эт конечно все клево, только вот остается вопрос. Я пишу на жабе. И вот черт меня дернул перейти на Ж# или Ж++. Что я вижу — ничего (практически) из того, что знаю применить нельзя. А так как я восновном как жаба-девелопер знаю ждк 1.2 и выше то возникает вопрос — кто и что пишут на Ж# и Ж++. До появления ждк 1.2 жаба была ваще очегь ущербным языком — на ждк 1.1 кроме убогого апплета или медленной консоли (ну или убогой гуевины) ничего и не напишешь. Вся сила пришла с ждк 1.2 — сервлетами, жсп и ж2ее. То есть на мой взгляд ж++ — это просто неудавшийся коньюнктурный шаг.
G>>И ан кой ляд нужно ваще портировать жабовский байт код в нетовский. Ваще лично мне кажется что Ж# — это мегагнилая идея. Отдает каким-то популизмом. Скоро будет того гляди Python#
TK>http://starship.python.net/crew/mhammond/dotnet/
еще один коньюнктурный шаг. И тоже как мне кажется тупиковый.
Если нам не помогут, то мы тоже никого не пощадим.
