информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медСетевые кракеры и правда о деле ЛевинаСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / miscellaneous
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
@#$%ежъ 11.03.08 16:04  Число просмотров: 2229
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Тесты показывают, что managed код при нормальной VM даёт в
> среднем производительность 60-70% от нативного. Тупорылую

Пиздежъ

> работу двиганья байтиков большей частью может делать VM со
> своими примитивами. Т.е. реально может получиться и 95% ;-)

Пиздежъ.

> Т.е. нету "несколько порядков". Внимание! Это написано для
> чистых интерпретирующих байт-код VM!

Пиздежъ

> > Кроссплатформенность - миф. И об этом я уже писал.
> Это не миф. Это кривая реализация или от M$, или от
> создателей Mono.
> Есть более интересные примеры. Браузер Opera Mini, к
> примеру, который работает на всех телефонах, где есть жаба
> + необходимые жабарасширения + память.

Та же самая Opera Mobile работает под всеми смартфонами/коммуникаторами вообще. И в тыщу раз быстрее. Да и "большая" опера тоже работает на туевой хуче разных платформ и не жужжит. Кросплатформенность запросто достигается чисто нативными методами и никаких виртуальных машин для этого не надо.

> > "Папа, а ты с кем сейчас разговаривал" (с)
> Это к тому, что пусть процессор исполняет. А мудрить с
> безопасностью и виртуализацией нужно программно. Потому что

Кто сказал?

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

При чем тут сложность? Разделение адресных пространств отлично работает без всяких SIP-ов.

> натив, а свои микрокоды. Может, уже перебор, поскольку и
> так есть промежуточные преобразования?
И что? Если уж все равно теряем часть возможной производительности, то почему бы не потерять ее еще процентов 80? Так?
<miscellaneous>
Microsoft показала новую операционную систему 05.03.08 17:11   [Den]
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
Microsoft представила прототип новой операционной системы Singularity, ориентированной в первую очередь на ученых, пишет PC World. Бесплатный инструментарий для разработки приложений под эту ОС и ее исходный код выложены на сайте Microsoft Codeplex для всех желающих использовать их в исследовательских целях.

тут
Хех. Интересно, куда заведет индустрию этот дотнет угар. 05.03.08 17:36  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Не берусь делать прогнозы, но пока что направление движения мне не нравится.
Дык, сырцы та на нее там есть? И че, там ЮзерЛевел тока на Доте? 10.03.08 07:45  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Там не только юзер, но и кернел на доте 10.03.08 15:55  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Фишка в том, что для того, чтобы избавиться от оверхеда на переключение контекстов, они все процессы исполняют в одном, но в виртуальной машине, которая следит за тем, чтобы эти "процессы" (SIP-ы) не делали ничего лишнего. Исходики не качал, но по одному описанию насколько я понял исполнение нативного кода будет невозможно в принципе (потому что за ними следить будет нельзя и они смогут залезть в память других SIP-ов).
Нативный код — зло ;-) 11.03.08 09:41  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 11.03.08 10:04  Количество правок: 3
<"чистая" ссылка>
> Фишка в том, что для того, чтобы избавиться от оверхеда на
> переключение контекстов, они все процессы исполняют в
> одном, но в виртуальной машине, которая следит за тем,
> чтобы эти "процессы" (SIP-ы) не делали ничего лишнего.
Тут инженеры Intel начинают в истерике биться головой апстену — сколько сил, потраченных на аппаратную виртуализацию (сперва задач, а потом и целых "машин"), можно сказать, были впустую ;-)
Бабаян тоже курит в сторонке, оказывается, безопасность не нужно шить в процессор ;-)

> Исходики не качал, но по одному описанию насколько я понял
> исполнение нативного кода будет невозможно в принципе.
Да, только примитивы VM + Common Runtime Language

> (потому что за ними следить будет нельзя и они смогут
> залезть в память других SIP-ов).
Вотть! Кроссплатформенность + безопасность. Безопасность + кроссплатформенность! :-)
А вообще, применяя парадигму "отложенной разумности", а вернее, "каждому — своё", и считая, что безопасность всё-таки это больше логика, чем исполнение (а собственно, исполнением и занимается процессор), то всё происходящее выглядит разумно в высшей степени. ИМХО.
Виртуализация из той же оперы. CLR байткоды могут виртуализовываться ну просто расчудесно всё той же виртуальной машиной.
А аппаратную виртуализацию -- фф топку, производительность VMWare прекрасно говорит о том, что даже программная виртуализация нативного кода может быть очень и очень шустрой
Managed код — зло 11.03.08 13:45  
Автор: amirul <Serge> Статус: The Elderman
Отредактировано 11.03.08 13:47  Количество правок: 1
<"чистая" ссылка>
> Тут инженеры Intel начинают в истерике биться головой
> апстену — сколько сил, потраченных на аппаратную
> виртуализацию (сперва задач, а потом и целых "машин"),
> можно сказать, были впустую ;-)

Да в общем и не впустую. Эта сингулярность дорастет хотя бы до уровня линукса в лучшем случае лет через 15. А это очень не хилый срок в IT.

> Бабаян тоже курит в сторонке, оказывается, безопасность не
> нужно шить в процессор ;-)

> > исполнение нативного кода будет невозможно в принципе.
> Да, только примитивы VM + Common Runtime Language

Ну тогда я не ошибся - говно оно и есть говно.

> > (потому что за ними следить будет нельзя и они смогут
> > залезть в память других SIP-ов).
> Вотть! Кроссплатформенность + безопасность. Безопасность +
> кроссплатформенность! :-)

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

> А вообще, применяя парадигму "отложенной разумности", а
> вернее, "каждому — своё", и считая, что безопасность
> всё-таки это больше логика, чем исполнение (а собственно,
> исполнением и занимается процессор), то всё происходящее
> выглядит разумно в высшей степени. ИМХО.

"Папа, а ты с кем сейчас разговаривал" (с)

> Виртуализация из той же оперы. CLR байткоды могут
> виртуализовываться ну просто расчудесно всё той же
> виртуальной машиной.

Или я чего то не понимаю, или ты несешь пургу ;-)
Какая такая "отличная виртуализация" изначально виртуальных байт-кодов?

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

Так то нативный. Причем ПРИ АППАРАТНОЙ ПОДДЕРЖКЕ (привилегированные инструкции и все такое). Так что опять не туда. Исполнение виртуального кода по любому будет медленнее нативного, а уж если туда еще и GC вкрутить - так вообще сливайте воду. Ну и на хрена это надо? Я ж говорю: не решает НИ ОДНОЙ проблемы, просто тупо отнимая производительность. Ну и как тут не поверить в сговор производителей софта с производителями железа?
Тесты показывают, что managed код при нормальной VM даёт в... 11.03.08 15:38  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
> Хехе. Безопасность отлично обеспечивалась и аппратно.
> Несколько смущает лечение головной боли (оверхедом на
> переключение контекстов) отрубанием головы (исполнением в
> виртуальной машине, которая дает оверхед на пару порядков
> выше, чем аппаратное переключение контекстов).
Тесты показывают, что managed код при нормальной VM даёт в среднем производительность 60-70% от нативного. Тупорылую работу двиганья байтиков большей частью может делать VM со своими примитивами. Т.е. реально может получиться и 95% ;-) Т.е. нету "несколько порядков". Внимание! Это написано для чистых интерпретирующих байт-код VM!

> Кроссплатформенность - миф. И об этом я уже писал.
Это не миф. Это кривая реализация или от M$, или от создателей Mono.
Есть более интересные примеры. Браузер Opera Mini, к примеру, который работает на всех телефонах, где есть жаба + необходимые жабарасширения + память.

> "Папа, а ты с кем сейчас разговаривал" (с)
Это к тому, что пусть процессор исполняет. А мудрить с безопасностью и виртуализацией нужно программно. Потому что требования что к безопасности, что к виртуализации уже превысили тот уровень сложности, когда это разумно впихивать в железяку. А железяки тож уже давно исполняют не натив, а свои микрокоды. Может, уже перебор, поскольку и так есть промежуточные преобразования?
@#$%ежъ 11.03.08 16:04  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Тесты показывают, что managed код при нормальной VM даёт в
> среднем производительность 60-70% от нативного. Тупорылую

Пиздежъ

> работу двиганья байтиков большей частью может делать VM со
> своими примитивами. Т.е. реально может получиться и 95% ;-)

Пиздежъ.

> Т.е. нету "несколько порядков". Внимание! Это написано для
> чистых интерпретирующих байт-код VM!

Пиздежъ

> > Кроссплатформенность - миф. И об этом я уже писал.
> Это не миф. Это кривая реализация или от M$, или от
> создателей Mono.
> Есть более интересные примеры. Браузер Opera Mini, к
> примеру, который работает на всех телефонах, где есть жаба
> + необходимые жабарасширения + память.

Та же самая Opera Mobile работает под всеми смартфонами/коммуникаторами вообще. И в тыщу раз быстрее. Да и "большая" опера тоже работает на туевой хуче разных платформ и не жужжит. Кросплатформенность запросто достигается чисто нативными методами и никаких виртуальных машин для этого не надо.

> > "Папа, а ты с кем сейчас разговаривал" (с)
> Это к тому, что пусть процессор исполняет. А мудрить с
> безопасностью и виртуализацией нужно программно. Потому что

Кто сказал?

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

При чем тут сложность? Разделение адресных пространств отлично работает без всяких SIP-ов.

> натив, а свои микрокоды. Может, уже перебор, поскольку и
> так есть промежуточные преобразования?
И что? Если уж все равно теряем часть возможной производительности, то почему бы не потерять ее еще процентов 80? Так?
Снимите шоры С++ прочих "переносимых ассемблеров"! 12.03.08 09:35  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 12.03.08 09:44  Количество правок: 1
<"чистая" ссылка>
То, что делают полиморфные виртуальные машины каждый день и шутя, C++ штатными средствами сделать не сможет, а если и сможет, то через попу ;-)

http://www.smalltalk.ru/articles/cpp-pic.html
http://www.smalltalk.ru/articles/cpp-is-faster.html
http://mail.python.org/pipermail/python-list/2001-April/080473.html
И где шоры? 12.03.08 11:51  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Во первых C++ уж никак не претендует на звание ассемблера. Это очень удобный язык ВЫСОКОГО уровня.

> То, что делают полиморфные виртуальные машины каждый день и
> шутя, C++ штатными средствами сделать не сможет, а если и
> сможет, то через попу ;-)
>
> http://www.smalltalk.ru/articles/cpp-pic.html
> http://www.smalltalk.ru/articles/cpp-is-faster.html
> http://mail.python.org/pipermail/python-list/2001-April/080
> 473.html

Во вторых шор я так и не увидел. В последней ссылке ПРОСТЕЙШИЕ операции работают от 4 до 40 раз медленнее. И это еще без задействования GC, который по самым скромным подсчетам отжирает процентов 10 времени. А первые две... Я не увидел дату публикации, но заметил, что там тестируется VC++ 6.0 - скажем прямо, не лучшая реализация C++ компилятора, с не лучшим оптимизатором. С другой стороны косвенный вызов (через таблицу виртуальных функций) мало отличается по времени от прямого. Когда будет время - попробую варианты с "оптимизацией" и без.
GC в тех машинах неотключаем, его чуть "поднастроили". Ну и согласись, 2-4-да пусть 6 раз — это не на "порядки ниже". 12.03.08 12:13  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Всё нормально. Нет серебряной пули, победят гибридные вещи, которые возьмут от этих технологий это, от тех — то. Наоборот, споры вокруг этих горячих тем, а ещё лучше, разработки (у M$ много бабла, им можно), говорят о том, что это просто разные аспеты компьютинга, и оба достойны применений.
Можно для каждой программы создавать свою нативную машину вычислений, а можно объединить часто используемые вычислительные примитивы в одну нативную машину, и заставлять её исполнять творческие потуги прикладных программеров — вот и весь расклад ;-)
Пустой цикл не использует GC - поэтому им можно пренебречь 12.03.08 13:05  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Всё нормально. Нет серебряной пули, победят гибридные вещи,
> которые возьмут от этих технологий это, от тех — то.

Победят не гибридные вещи, а маркетинг. К моему величайшему сожалению маркетинг сейчас очень аргессивно продавливает дотнет.

> Наоборот, споры вокруг этих горячих тем, а ещё лучше,
> разработки (у M$ много бабла, им можно), говорят о том, что
> это просто разные аспеты компьютинга, и оба достойны
> применений.

Я ж не спорю. Но ДОСТОИНСТВ дотнета мне так никто и не привел. А недостаток я вижу невооруженным глазом (даже без тестов): если я запускаю какой нибудь дотнет приложение оно мало того, что тормозит, так еще и отжирает раза в 2-3 больше памяти, чем аналогичное по "нагруженности" нативное приложение. Конспирология конспирологией, но единственная положительная сторона и та для производителей железа. Старые компы не потянут такую нагрузку.

> Можно для каждой программы создавать свою нативную машину
> вычислений, а можно объединить часто используемые
> вычислительные примитивы в одну нативную машину, и
> заставлять её исполнять творческие потуги прикладных
> программеров — вот и весь расклад ;-)

Ты мне тут про смолтолк приводил примеры. Скажу сразу он настолько отличается от тех же плюсов, что в принципе для кого то там могут появиться плюсы, для кого то минусы и на самом деле холивор на тему что лучше был бы бессмысленным. И я бы вполне мог понять за что люди могут платить производительностью в случае смолтолка. Я же начинал разговор с дотнета. Тезисы:

1. Шарп не умеет НИЧЕГО сверх того, что умеют плюсы
2. Шарп не умеет некоторых удобных фишек плюсов
3. Дотнет тормозит и жрет память

Так на хрена он вообще нужен???

Собственно то же самое касается и джавы.
Ядро - это то, что на нативном коде. 11.03.08 13:30  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
А код диспетчера памяти и процессов? Он че, то же на #? А как драйвера для научного оборудования писать?
> А аппаратную виртуализацию -- фф топку, производительность
> VMWare прекрасно говорит о том, что даже программная
> виртуализация нативного кода может быть очень и очень
> шустрой
Гыг! Шутку оценил! В Реактоси под ВМ курсор на пиксел в час сдвигается.
О-о-о. Это не потому что WMVare медленный, а потому что виртуализация VGA/VESA нетривиальная задача. 11.03.08 15:06  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 11.03.08 15:15  Количество правок: 2
<"чистая" ссылка>
Запусти какой-нить консольный измеритель процессорных попугаев под реактосью в WMWare и под нативной OS, и посмотри разницу.

> А код диспетчера памяти и процессов? Он че, то же на #? А
> как драйвера для научного оборудования писать?
А вот драйвера-то никто не мешает писать managed кодом, если есть соотв. поддержка вирт. машины. Т.е. уже сейчас та же венда практически всю работу с оборудованием ведёт через себя, отдавая драйверописателю некий API.

Короче managed код и дрова для оборудования прекрасно бы полюбили друг друга.
Блин, ну об чем спор то? 11.03.08 15:18  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
На vmware исполняется нативный код прямиком на процессоре. Причем виртуализация достигается за счет аппратной поддержки. Дотнет, джава, VBVM и прочее говно исполняют НЕ нативный код. В лучшем случае они его динамически транслируют. То есть НА САМОМ деле виртуальная машина - неверный термин для джавы и дотнета, правильный термин в данном случае - ЭМУЛЯТОР. Одна аппаратная платформа (дотнет-процессор) эмулируется на другой (x86). Чтобы посмотреть на что способны современные ЭМУЛЯТОРЫ можно посмотреть на qemu (самый быстрый из известных мне эмуляторов). Ему можно даже простить, что он несколько фривольно относится к эмуляции памяти целевой машины ради ускорения самой эмуляции (пропускает некоторые проверки). Все равно скорость эмуляции без аппаратного ускорения (специальный third-party драйвер) в 2-3 раза меньше, чем нативно. Числодробилки - еще тормознее. Ну и на хрена мне такая радость В ОБЯЗАТЕЛЬНОМ ПОРЯДКЕ?

> Запусти какой-нить консольный измеритель процессорных
> попугаев под реактосью в WMWare и под нативной OS, и
> посмотри разницу.
Почему? 05.03.08 23:48  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
Потому, что C# забирая у программиста гибкость и отжирая кучу ресурсов 06.03.08 12:25  
Автор: amirul <Serge> Статус: The Elderman
Отредактировано 06.03.08 12:27  Количество правок: 1
<"чистая" ссылка>
Не дает НИКАКИХ преимуществ при написании программ.

Во всяком случае на вопрос: "За что я должен платить такую цену" я так ни разу и не получил вразумительного ответа от самых заядлых шарперов.

Более менее частые ответы (приведены ответы и встречные вопросы по этим ответам):

A. Бинарная переносимость
Q1. На @#$а она нужна? Не видел ни у кого проблем с деплойментом source-portable программ, скомпилированных под свою платформу каждая.
Q2. На самом деле чтобы программа была binary-portable ее нужно писать в source-portable стиле. Неоднократно встречал как .Net прога отказывалась работать (вернее работала не совсем так как нужно) под Mono.

A. Более быстрая разработка
Q. Миф. Те, кто приводил такой аргумент так и не смогли назвать причин, по которым она якобы ускоряется.

A. Более удобный IDE
Q. Та же самая Visual Studio. А Visual Assist X - так вообще круче только яйца. Более того, даже если бы IDE и был удобнее, то это было бы как раз следствие того самого угара: MS вкладывает в Net гораздо больше бабла, чем в натив, но натив при этом все еще не уступает Net-у ни в чем, а во многом даже лучше

A. Отсутствие утечек памяти и выхода за границы буфера
Q. В GC память течет так же, как и без него. Только для выявления ПРИЧИНЫ приходится прилагать уж очень нетривиальные усилия. Более того, в плюсах (TR1) уже введены (раньше они тоже были, но не в стандарте а в boost-е) умные указатели std::shared_ptr, std::intrusive_ptr и т.п., а для контроля границ буфера уже сто лет как есть std::vector.

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

A. C++ - более гибкий и поэтому бедным программистам постоянно приходится сушить голову над выбором одного из множества возможных решений.

Прикол в том, что этот аргумент приводился В ПОЛЬЗУ шарпа.

PS: Если кто может ответить на мой вопрос - you're welcome
Уточнение 12.03.08 19:18  
Автор: Neznaika <Alex> Статус: Member
<"чистая" ссылка>
Ты все говоришь правильно.
Но, давайте все-таки - не будем так категорично.

Даже если Вам лично не нужны костыли - это не значит, что их не нужно делать.

Смею заметить, что .NET в основном позиционируется для Web-a.
И не нужно требовать от него того, что требуется при разработке драйверов.

Далее. Насчет тезисов:
> 1. Шарп не умеет НИЧЕГО сверх того, что умеют плюсы
>
VBA - тоже не умеет ничего сверх того, что умеют C++.
Тем не менее, у него есть своя область применения.

> 2. Шарп не умеет некоторых удобных фишек плюсов
>
Не буду спорить.
Каждому из нас кажется более удобным тот язык, к которому мы привыкли.

> 3. Дотнет тормозит и жрет память
>
Память сейчас - уже никто не экономит, так что это не очень убедительно.
А тормозит .NET в основном только в момент "Just-in-time compilation",
причем это можно обойти через ngen.exe

Я сам .NET - не очень люблю, но из возможных плюсов:
1) C# -- более простой язык для изучения.
Т.е, с нуля его гораздо проще освоить, чем С++.

2) Для .NET уже написаны огромное количество системных классов -- типа работы с XML, SQL Server, Oracle, SOAP, Web Services, Cryptography и др. ботва. Конечно, удобно получить все сразу в уже готовом виде.

3) Решена проблема "DLL hell".

4) Выполнение программ в песочнице - это не просто GC.
Я что-то не помню, что бы в C++ была реализована модель защиты по правам доступа кода.

5) По смыслу, Microsoft хочет полностью контролировать ход выполнения прикладных программ. Им больше не нужны повальные эпидемии червей типа Nimda, Sasser, Blaster, SQL Slammer, etc. В случае c native C/C++ у них такой возможности нет. В случае c .NET Framework - есть. И им это важно. Поэтому они усиленно продвигают все технологии, связанные с .NET

Сдается мне, что список можно продолжить.
Могу, конечно ошибаться.
Я и не требую. вон топик то об операционной системе... 12.03.08 20:29  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Даже если Вам лично не нужны костыли - это не значит, что
> их не нужно делать.
>
> Смею заметить, что .NET в основном позиционируется для
> Web-a.
> И не нужно требовать от него того, что требуется при
> разработке драйверов.

Я и не требую. Вон топик то об ОПЕРАЦИОННОЙ СИСТЕМЕ написаной на шарпе.

> Далее. Насчет тезисов:
> > 1. Шарп не умеет НИЧЕГО сверх того, что умеют плюсы
> >
> VBA - тоже не умеет ничего сверх того, что умеют C++.
> Тем не менее, у него есть своя область применения.

Это было бы так, если бы шарп не позиционировался как универсальный язык. На нем пытаются писать и операционные системы и БД и прочий софт с очень высокими требованиями в том числе и к скорости выполнения.

> > 2. Шарп не умеет некоторых удобных фишек плюсов
> >
> Не буду спорить.
> Каждому из нас кажется более удобным тот язык, к которому
> мы привыкли.

Это опять таки так, но дело в том, что для шарпа не создают отдельную нишу, его пропихивают ВСЮДУ. Отсутствие "некоторых удобных фишек" не является чем то предосудительным, если язык взамен предоставляет свои (а какие фишки предоставляет шарп?)

> > 3. Дотнет тормозит и жрет память
> >
> Память сейчас - уже никто не экономит, так что это не очень
> убедительно.

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

> А тормозит .NET в основном только в момент "Just-in-time
> compilation",

В момент джит дотнет тормозит ОЧЕНЬ сильно, все остальное время он работает в несколько раз медленнее, чем натив.

> причем это можно обойти через ngen.exe

Хм. Никаких противоречий не видно? Зачем в цепочке исходник->байткод->машинный код звено "байткод", если результат один (хотя GC все равно скорее всего будет тормозить)

> Я сам .NET - не очень люблю, но из возможных плюсов:
> 1) C# -- более простой язык для изучения.
> Т.е, с нуля его гораздо проще освоить, чем С++.

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

> 2) Для .NET уже написаны огромное количество системных
> классов -- типа работы с XML, SQL Server, Oracle, SOAP, Web
> Services, Cryptography и др. ботва. Конечно, удобно
> получить все сразу в уже готовом виде.

Для плюсов этого добра еще больше.

> 3) Решена проблема "DLL hell".

Ну как бы в той же винде есть SxS и тоже отлично решает эту проблему. Как решена эта проблема в шарпе честно говоря не знаю

> 4) Выполнение программ в песочнице - это не просто GC.
> Я что-то не помню, что бы в C++ была реализована модель
> защиты по правам доступа кода.

Не понял. Вообще то современные процессоры поддерживают запрет на исполнение страниц. А запрет на чтение/запись есть еще с незапамятных времен. Или Вы какие то другие права доступа имеете в виду?

> 5) По смыслу, Microsoft хочет полностью контролировать ход
> выполнения прикладных программ. Им больше не нужны
> повальные эпидемии червей типа Nimda, Sasser, Blaster, SQL
> Slammer, etc. В случае c native C/C++ у них такой
> возможности нет. В случае c .NET Framework - есть. И им это
> важно. Поэтому они усиленно продвигают все технологии,
> связанные с .NET

Каким образом дотнет спасет от червей? Или его виртуальная машина тоже managed? Более того, на C++ при желании можно писать код с проверкой ВСЕХ обращений к памяти на предмет выхода за границы. Причем сделать это совершенно прозрачно для программиста. Да, оно будет тормозить по сравнению с нормальной программой, но я что-то не замечал, чтобы шарперов волновала скорость.

> Сдается мне, что список можно продолжить.
> Могу, конечно ошибаться.

Ну да.
Насчет топика 12.03.08 22:53  
Автор: Neznaika <Alex> Статус: Member
Отредактировано 12.03.08 23:01  Количество правок: 2
<"чистая" ссылка>
Давайте не будем принимать частное за типичное.

Сколько операционных систем написано на C#?
А сколько БД написано на C#?

- и -
Сколько БД написано на C?
Сколько операционных систем написано на C?

> (а какие фишки предоставляет шарп?)
>
Навскидку, первое что пришло в голову:LINQ to Objects; LINQ to SQL

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

> Хм. Никаких противоречий не видно? Зачем в цепочке
> исходник->байткод->машинный код звено "байткод", если
> результат один (хотя GC все равно скорее всего будет тормозить)
>
Нет, мне не видно.
После ngen.exe -- код оптимизируется для конкретного CPU.
Причем это делается автоматом в процессе инcталляции .NET приложения, а не при его построении.

> Для плюсов этого добра еще больше.
>
И что - все это встроено прямо в язык?
Написано и протестировано лучшими разработчиками Microsoft?

Или все-таки надо где-то искать, вытаскивать, прикручивать,
разбираться - как это все работает, выбирать какой из нескольких компонент лучше.
A?

> Ну как бы в той же винде есть SxS и тоже отлично решает эту
> проблему. Как решена эта проблема в шарпе честно говоря не знаю
>
Скажем так. SxS -- бледный аналог того, как это реализовано в .NET Framework
Притом что SxS есть только в WinXP SP2 и выше.
А .NET можно поставить хоть на Win2K.

> Не понял. Вообще то современные процессоры поддерживают
> запрет на исполнение страниц. А запрет на чтение/запись
> есть еще с незапамятных времен. Или Вы какие то другие
> права доступа имеете в виду?
>
Я имею в виду систему безопасности .NET Framework, при которой неавторизованный код
не может вызвать Ваш код и не может заставить его выполнять какие-либо действия.

Если не в курсе, то советую почитать про аттрибуты Demand и LinkDemand.

Например, я не открываю свои классы / методы / интерфейсы для вызова
произвольным недоверяемым кодом. Только код, подписанный моим ключом,
может обращаться к моей DLL.

> Каким образом дотнет спасет от червей?
>
Вы -- не совсем поняли.

Программа злоумышленника, написанная на C/C++ может сделать все (или почти все).
А программа злоумышленника, написанная на C# - может только похулиганить в своей песочнице.

Одним словом, когда все прикладные программы будут выполняться в среде .NET -
Microsoft будет спать спокойно. Поэтому они усиленно это дело продвигают.
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach