Вот у меня вопрос.
На работе мне седня программист выдал, что С++ язык неперспективный ибо Borland, фирма разработчик (я так поняла разработчик С++) уступает Мелкософту, который использует С# (в чем я чет сомневаюсь) и Borland скоро вымрет…Препод же с инста говорит обратное, в принципе про С# он и не заикается, но зато всячески хвалит С++…
НО работать мне придется с С# а учиться на C++
Собсно вопрос: в чем разница между этими языками? (я еще С# даж не смотрела=))
и кто прав?
11 ноября 2008 в 11:00
2Dmitry Frozik Sharov
приеду домой и займусь. В качестве примера уже выбрал подсчёт обратной матрицы
11 ноября 2008 в 0:02
ну кстати, могу свою реализацию кинуть правда на асме, но не суть
интересно, реально ли вообще в managed хотя бы 50% скорости получить, я как-то игрался, но не получил и 10% (я не силен в .NET)
//password-crackers.ru/category_177/program_129...
11 ноября 2008 в 0:00
тупо мд5 будет столь же эффективен – слишком уж он стандартен и скорее всего куда-нибудь завернут
да и памяти требует предсказуемое количество.
10 ноября 2008 в 23:05
Или хеширования. Тупо мд5
10 ноября 2008 в 23:04
#69, Dmitry Frozik Sharov
> Если посмотреть графики производительности Ubuntu, то можно заметить, что с каждой версией она тормозить начинает сильнее и сильнее. Тут важны идентичная работа. Мало ли чего там добавляют.
полностью согласен. но я как-то больше в сторону gentoo, который, как ни странно, с каждой версией чуть ли не быстрее и быстрее.
#72, Dmitry Frozik Sharov
> Приведите пример, работа с массивами/вызов методов/циклы/работа со строками, да что угодно, и покажите как native код сделает .NET.
похоже я придумал. какие-нибудь алгоритмы, жонглирующие битовыми масками все свое время исполнения. какие-нибудь замысловатые алгоритмы шифрования, например.
10 ноября 2008 в 12:05
#71, Дмитрий lnk~ Матвеев
То, что обработчики прерываний написаны не на управляемом коде вполне понятно, у нас просто нет доступа до регистров, как у вас программистов c и c++ с inline asm. Spec# и c# не обладают и не будут обладать таким функционалом, потому что неизвестно на какой платформе и на каком процессоре будет выполняться код. И это нисколько не говорит, что .NET сливает native коду. Приведите пример, работа с массивами/вызов методов/циклы/работа со строками, да что угодно, и покажите как native код сделает .NET. Что вы постоянно говорите о том, что сами не знаете наверняка. Я призню, что GC может быть очень медленным, поэтому специально для этого я написал статью, в которой показал как можно работать и без GC. Не понимаю, что сложно что ли доказать один раз, если вы так уверены?
#70, Андрей (aka md6) Горбоконь
Удобство зависит от реализации. Вы посмотрите исходники классов .NET и поймёте, что многие из них – обёртки над win api и ничего криминального здесь нет, в mono также. Это увеличит время разработки с той лишь разницей, что под каждую определённую ОС вам придётся реализовывать классы работающие с фунциями ОС по разному.
10 ноября 2008 в 8:00
#66 Dmitry Frozik Sharov
Вроде давно известно что даже в Singularity (или как её), которая пишется в основном на managed code, низкоуровневый код обработки прерываний x86 написан на языке ассемблера и C
(это я о том что тут до-диез сливает native-code-у)
#69 Dmitry Frozik Sharov
А вот не надо смотреть на производительность Ubuntu – кривоватый дистр. У меня Debian Etch и Debian Lenny работают одинаково
10 ноября 2008 в 4:01
Костыли, потому что, если бы это было действительно удобно в .net, то не приходилось бы импортировать функции по работе с памятью из Win32Api, и писать специальный класс-обертку для удобной работы, что в целом у вас заняло 250 строк кода. В общем информацию к размышлению принята
Так и в чем же мощь .net'a?..Кажется, я что-то пропустил..
10 ноября 2008 в 2:03
#67, Леонид maxleo Максимов
Если посмотреть графики производительности Ubuntu, то можно заметить, что с каждой версией она тормозить начинает сильнее и сильнее. Тут важны идентичная работа. Мало ли чего там добавляют.
#68, Андрей (aka md6) Горбоконь
Почему костыли? В 99,99% случаев вам это даже не понадобится. Это информация к размышлению,и мощь .NET далеко не только в GC.
9 ноября 2008 в 23:03
#66, Dmitry Frozik Sharov
Вам совсем немножко не кажется, что предложенное в статье – это костыли .NET'а, только лишь бы отказаться от С++?
9 ноября 2008 в 22:04
#61, Dmitry Frozik Sharov
> Леонид maxleo Максимов, на сколько я понимаю вы разработчик на c++. Вы можете привести пример, где .NET сольёт по полной native коду?
Я не разработчик на C++, но попробую.
Microsoft SQL Server Management Studio написана, насколько я понимаю, на .NET. так вот, в сравнении с утилитами для SQL Server 2000 тормозит этот новомодный продукт безбожно. я не имею в виду всякие извращения: даже такое простое действие, как разворачивание узла иерархии объектов происходит так медленно, что можно вешаться.
9 ноября 2008 в 15:04
#63, Андрей (aka md6) Горбоконь
Моя основная задача на работе – считать баланс, разрешать/блокировать звонки, смс, делать роутинг звонков. В секунду в часы пик должно обрабатываться до 5 000 000 абонентов. По вашему это не должно работать? Например, как решить проблему с GC я показал в этой статье – //frozik.habrahabr.ru/blog/44208/ .
#65, Дмитрий lnk~ Матвеев
Есть сведения, где на c# был реализован загрузчик, ну чтобы производительность сравнить?
9 ноября 2008 в 10:02
Сольет в бутлоадерах
9 ноября 2008 в 9:02
>> Сольёт на 3D проектах
Эт еще на каких? Если использовать тот же самый Managed DirectX, то проигрывать он будет там, где работает проц… А рисоваться все равно будет на видюхе…
8 ноября 2008 в 23:01
>Вы можете привести пример, где .NET сольёт по полной native коду?
Сольёт на 3D проектах
Сольёт на критичных к выполнению приложениях
8 ноября 2008 в 20:05
#55, Леонид maxleo Максимов: "а я говорил о том, что ASP.NET-приложение, запущенное не под IIS, а на каком-то другом веб-сервере, заметно сдаст в производительности"
И? Не вижу связи с темой беседы, а именно с тем, насколько велика потеря производительности полукомпилируемых приложений в сравнении с native-кодом.
8 ноября 2008 в 18:00
Леонид maxleo Максимов, на сколько я понимаю вы разработчик на c++. Вы можете привести пример, где .NET сольёт по полной native коду?
8 ноября 2008 в 14:05
>> В случае же с .NET приложение компилируется в промежуточный IL код. А уже во время выполнения происходит загрузка виртуальной машины, и компиляция IL кода в native код специфичный для процессора на котором выполняется приложение.
Маленькое уточнение: IL ассемблируется в байт-код, который в процессе выполнения на виртуальной машине проходит через JIT компилятор, генерирующий native код
8 ноября 2008 в 9:00
>> А то что только nvidia – так не жалко, неужели есть другие производители?
Ооо, это очередной вызов на холивар?)) Ну так на данный момент ATI HD4870X2 лучшая видюха))
>> например, прорисовка фильмов. никто не мешает уточнить форму предмета с помощью шейдеров, а затем уже использовать трассировку лучей. хотя, признаюсь, притянуто за уши.
Как ни странно, я делал трассировку лучей на GPU. И, растеризация мне понадобилась в одном случае. Нарисовать quad. А уже сцену я передавал через текстуры.
7 ноября 2008 в 23:02
#51, Константин Дёмин
> Леонид, спасибо за справку, не знал про GS в OpenGL. =)
да я просто пошел почитать, что конкретно есть шейдер
я как-то забросил эту область еще до их появления, но интуитивно (или с помощью морфемного анализа?) представлял, что используется он для рассчетов освещенности. но это были лишь догадки.
7 ноября 2008 в 23:02
#54, Ростислав Чутков
> А то что только nvidia – так не жалко, неужели есть другие производители?
как ни странно, есть.
7 ноября 2008 в 23:01
На CUDA пароли брутфорсить хорошо. Все таки от шейдеров это сильно отличается в сторону функциональности и масштабируемости. А то что только nvidia – так не жалко, неужели есть другие производители?
7 ноября 2008 в 23:01
#52, Alexander Cyborg Zubakov
> когда я говорил о Web, я имел виду, что чаще используются приложения, написанные на интерпретируемых и полукомпилируемых языках, чем программы, скомпилированные в native-код
а я говорил о том, что ASP.NET-приложение, запущенное не под IIS, а на каком-то другом веб-сервере, заметно сдаст в производительности из-за JIT-компилирования и виртуализации (а также отсутствия модулей для других веб-серверов, но этого я на момент высказывания в виду не имел).
7 ноября 2008 в 23:01
#53, Тимур Багаутдинов
> И интересно увидеть пример приложения из области GPGPU, где так сильно понадобились геометрические шейдеры.))
например, прорисовка фильмов. никто не мешает уточнить форму предмета с помощью шейдеров, а затем уже использовать трассировку лучей. хотя, признаюсь, притянуто за уши.
кроме того, я аккуратно сказал "что-то вроде CUDA", так что какие могут быть претензии?
7 ноября 2008 в 23:00
Леонид, спасибо за справку, не знал про GS в OpenGL. =)
7 ноября 2008 в 23:00
#48, Леонид maxleo Максимов.
ОК, согласен насчет определения CGI. Другой вопрос, что мы обсуждаем различия приложений, скомпилированных в native-код и приложений, исполняемых виртуальной машиной / интерпретатором. А посему когда я говорил о Web, я имел виду, что чаще используются приложения, написанные на интерпретируемых и полукомпилируемых языках, чем программы, скомпилированные в native-код (их я и обозвал CGI-приложениями).
7 ноября 2008 в 23:00
>> в таком случае советую использовать что-то вроде CUDA.
Да лана, не вижу сейчас никаких преимуществ использования данной технодогии.
1. Работает только на карточках от NVidia
2. Как ни крути, придеться изучать архитектуру карточки и делать низкоуровневую оптимизацию.
3. Использование классических шейдеров намного результативнее.
>> ваше приложение каким-то хитрым и замысловатым образом использует графическую подсистему для увеличения вычислительной мощности
И интересно увидеть пример приложения из области GPGPU, где так сильно понадобились геометрические шейдеры.))
7 ноября 2008 в 22:05
#42, Константин Дёмин
> Хм, знаете, у меня есть приложение, очень активно использующее шейдеры (вершинные, пиксельные и даже геометрические). А у Вас *nix-подобная система. Скажите, что мне делать – думать о портировании своего супер-мега-приложения на Вашу платформу или лечь поспать (и всё пройдёт)?
это другое применение. в сфере развлечений преимущество сейчас однозначно на стороне NT. если для вас так важны несколько процентов пользователей, работающих с UNIX-подобными системами, то это может означать только одно – ваше приложение каким-то хитрым и замысловатым образом использует графическую подсистему для увеличения вычислительной мощности. в таком случае советую использовать что-то вроде CUDA.
btw (wiki): OpenGL supports geometry shaders through the use of an extension, though it may be incorporated into the standard itself with version 3.1.
7 ноября 2008 в 22:03
#44, Dmitry Frozik Sharov
> Когда происходит компиляция в MSIL уже происходит оптимизация (не для debug версий). Но если и этого мало, то конечно можно создать native image вашей managed сборки используя ngen.exe, что конечно приведёт к тому что вы потеряете всю гибкость.
если бы ngen.exe действительно умел оптимизировать код, то это было бы просто замечательно. но имхо это просто сохранитель образов, собраных с помощью JIT. хотя я еще почитаю.
7 ноября 2008 в 22:02
#47, Alexander Cyborg Zubakov
> А разве под исполняющейся программой мы, в данном случае, понимаем непосредственно сам интерпретатор, а не программу, которую этот интерпретатор исполняет? Сам-то Perl, конечно, бинарное native-приложение, а вот программы, написанные на языке Perl – это интерпретируемые приложения.
cgi собственно устанавливает, что то, что вывалится на стандартный выход исполняемого файла (вне зависимости от способа исполнения, будь то бинарный исполняемый файл или скрипт, исполняемый интерпретатором или серверным модулем) и есть результат его работы и подлежит отправке пользователю (шапка в том числе).
> Да и то, есть такая штука, как серверный модуль, когда о CGI говорить вообще нельзя. А все, что Вы перечислили существует и в виде серверных модулей. И пусть Perl и Python не так распространены в таком виде, но вот PHP так точно получил куда большее распространение в качестве модуля SAPI.
несмотря на то, что php часто реализуется в виде серверного модуля (одна из оптимизаций, позволяющих увеличить пропускную способность), он все равно использует cgi.
вот одно из определений, выданных гуглом:
CGI:The common gateway interface (CGI) is a standard way for a Web server to pass a Web user's request to an application program and to receive data back to forward to the user. When the user requests a Web page (for example, by clicking on a highlighted word or entering a Web site address), the server sends back the requested page. However, when a user fills out a form on a Web page and sends it in, it usually needs to be processed by an application program. The Web server typically passes the form information to a small application program that processes the data and may send back a confirmation message. This method or convention for passing data back and forth between the server and the application is called the common gateway interface (CGI). It is part of the Web's Hypertext Transfer Protocol (HTTP).
ЗЫ: я за правильные редакторы, в которых не важно, что за символы образуют отступы.
7 ноября 2008 в 1:01
#41, Леонид maxleo Максимов: "как не получает? а php, perl и python для вас не достаточно распространены?"
А разве под исполняющейся программой мы, в данном случае, понимаем непосредственно сам интерпретатор, а не программу, которую этот интерпретатор исполняет? Сам-то Perl, конечно, бинарное native-приложение, а вот программы, написанные на языке Perl – это интерпретируемые приложения.
Да и то, есть такая штука, как серверный модуль, когда о CGI говорить вообще нельзя. А все, что Вы перечислили существует и в виде серверных модулей. И пусть Perl и Python не так распространены в таком виде, но вот PHP так точно получил куда большее распространение в качестве модуля SAPI.
P.S. Я за 4 пробела =)))
6 ноября 2008 в 15:04
я за табуляцию и C-p, C-n, C-f, C-b
6 ноября 2008 в 14:03
Тимур, скорее придётся забыть об OpenGL.
До третьей версии ТОЧНО, а там посмотрим.
PS: присмотритесь, название темы уже само по себе холиварно (наличие "VS"). Сейчас дойдём до "табуляция VS 4 пробела", "WSAD против стрелочек" и т.п. Сразу обозначу свою позицию: табуляция и WSAD.
6 ноября 2008 в 14:01
#41, Леонид maxleo Максимов
Когда происходит компиляция в MSIL уже происходит оптимизация (не для debug версий). Но если и этого мало, то конечно можно создать nativeimage вашей managed сборки используя ngen.exe, что конечно приведёт к тому что вы потеряете всю гибкость.
6 ноября 2008 в 7:05
>> Хм, знаете, у меня есть приложение, очень активно использующее шейдеры (вершинные, пиксельные и даже геометрические)
Разрабатывать с помощью OpenGL))
Правда про геометрические шейдеры пока придется позабыть
6 ноября 2008 в 4:02
>>Леонид maxleo Максимов
>>все описаное выше актуально только для одного из известных мне веб-серверов. а если у меня другой? какой-нибудь кернельный tux, например?
Хм, знаете, у меня есть приложение, очень активно использующее шейдеры (вершинные, пиксельные и даже геометрические). А у Вас *nix-подобная система. Скажите, что мне делать – думать о портировании своего супер-мега-приложения на Вашу платформу или лечь поспать (и всё пройдёт)?
Насчёт RTOS я с Вами согласен, тут лидируют нативность. Будем ждать, когда виртуализация сделает шаг вперёд, достаточный для соревнования с двоичным кодом.
6 ноября 2008 в 0:02
#34, Alexander Cyborg Zubakov
> В таком случае интересно, почему подавляющая часть всего, что есть в вебе написана с использованием таких технологий, как ASP.NET, Java, PHP, Perl, Python, но не CGI. Если все так плохо, почему же CGI не получает широкого распространения?
как не получает? а php, perl и python для вас не достаточно распространены?
> Значит, наверное, не так уж и велика потеря производительности. Значит, вероятно, есть очевидные преимущества использования VM и интерпретаторов в среде Web.
интерпретаторы хороши тем, что однажды загруженный в них код легко переиспользуется при последующих запусках – не нужно создавать новые процессы и средства взаимодействия. но это уже оптимизации.
> Почему же, если так важна производительность, все большее развитие и распространение получают технологии виртуализации?
очевидно. важна не столько производительность, сколько надежность.
#35, Dmitry Frozik Sharov
> #34, Леонид maxleo Максимов
> Много видели скомпилённого JITом ассемблерного кода релизной сборки?
> Часть информации по JIT оптимизации можно найти в статье
честно говоря, даже не пытался взглянуть на выход JIT. почитал статью. никаких особых оптимизаций (кроме самых банальных и почти бесплатных) не встретил. конечно, JIT – оптимизирующий компилятор. также как и тот, что заменяет mov ax, 0 на xor ax, ax. сложных оптимизаций он по понятным причинам не производит.
#37, Dmitry Frozik Sharov
> #33, Леонид maxleo Максимов
> А какой практический смысл его инициировать каждый раз. Один раз загрузились, потом гоняем. Одино приложение на все запросы. Перегрузка appdomainов происходит толко в нескольких случаях:
> * Machine.Config, Web.Config or Global.asax изменились
> * Содержание bin директории изменилось
> * Перекомпиляция aspx, ascx или asax достигла предела, установленного в <compilation numRecompilesBeforeAppRestart=/> в machine.config или web.config (по умолчанию 15)
> * Физический путь виртуальной дирректории был изменён
> * Изменена CAS policy
> * Рестарт Веб сервиса
> * Ну и в 2.0 добавилось, что при удалении поддиректорий в проекте.
все описаное выше актуально только для одного из известных мне веб-серверов. а если у меня другой? какой-нибудь кернельный tux, например?
#40, Alexander Cyborg Zubakov
> Если же говорить о RTOS, так для этих систем важна, в первую очередь, предсказуемость. В данном случае идеи виртуализации, исполнения байт-кода трансляторами, интерпретация и т.п. приобретают еще большее значение.
имхо трансляторы и, особенно, отложенная сборка мусора есть далеко не самые предсказуемые вещи.
5 ноября 2008 в 22:05
Дмитрий lnk~ Матвеев, если с программой работает пользователь в диалоговом режиме, то говорить о скорости не совсем корректно. Собственно, RTOS тут ни при чем.
Если же говорить о RTOS, так для этих систем важна, в первую очередь, предсказуемость. В данном случае идеи виртуализации, исполнения байт-кода трансляторами, интерпретация и т.п. приобретают еще большее значение.
5 ноября 2008 в 11:04
#38, Дмитрий lnk~ Матвеев
В RTOS важно не время задержки реакции, а чтобы этого времени было достаточно для приложения и оно было гарантированно, Это относится к большинству RTOS.
5 ноября 2008 в 7:04
>Alexander Cyborg Zubakov 2 ноя 2008 в 22:44
>Пользователь реагирует на вывод программы секунд 5, если не больше. А
>программа выполняется за миллисекунды, будь она написана на C# или на
>C++. Это раз.
В RTOS большие задержки критичны. Это раз.
4 ноября 2008 в 16:04
#33, Леонид maxleo Максимов
>собственно выполнения cgi-скрипта пару секунд инициализации .net.
А какой практический смысл его инициировать каждый раз. Один раз загрузились, потом гоняем. Одино приложение на все запросы. Перегрузка appdomainов происходит толко в нескольких случаях:
* Machine.Config, Web.Config or Global.asax изменились
* Содержание bin директории изменилось
* Перекомпиляция aspx, ascx или asax достигла предела, установленного в <compilation numRecompilesBeforeAppRestart=/> в machine.config или web.config (по умолчанию 15)
* Физический путь виртуальной дирректории был изменён
* Изменена CAS policy
* Рестарт Веб сервиса
* Ну и в 2.0 добавилось, что при удалении поддиректорий в проекте.
Во всех остальных случаях переинициализация вам не грозит.
Как то пропустил этот вопрос, заметил только после того, как Тимур Багаутдинов отписался.
4 ноября 2008 в 15:03
>> собственно выполнения cgi-скрипта пару секунд инициализации .net.
А зачем именно cgi?
Думаю, используя всякие XML Schema, WSDL, протокол SOAP, можно заставить все это заработать
4 ноября 2008 в 9:05
#34, Леонид maxleo Максимов
Много видели скомпилённого JITом ассемблерного кода релизной сборки?
Часть информации по JIT оптимизации можно найти в статье //www.codeproject.com/KB/dotnet/JITOptimization...
4 ноября 2008 в 2:00
В таком случае интересно, почему подавляющая часть всего, что есть в вебе написана с использованием таких технологий, как ASP.NET, Java, PHP, Perl, Python, но не CGI. Если все так плохо, почему же CGI не получает широкого распространения?
Значит, наверное, не так уж и велика потеря производительности. Значит, вероятно, есть очевидные преимущества использования VM и интерпретаторов в среде Web.
Почему же, если так важна производительность, все большее развитие и распространение получают технологии виртуализации?
4 ноября 2008 в 1:02
#30, Тимур Багаутдинов:
>> это есть самый ужасный минус, если программа на си++ выполняется за 0.1 микросекунды, а на си№ – за 3.0000001 секунды
> Эт интересно где такая ситуация встречается?
> Да и в пользу C# можно сказать то, что намного легче спаять какой-нибудь веб-сервис или распределенное приложение, чем на С++.
ситуация такая как раз и встречается при написании веб-сервисов. посчитайте, сколько человек вы сможете обслужить, если прибавите к нескольким миллисекундам собственно выполнения cgi-скрипта пару секунд инициализации .net.
4 ноября 2008 в 0:05
#27, Dmitry Frozik Sharov
>>использование прямого преобразования кода в native код не позволяет использовать различного рода оптимизации, характерные для конкретной архитектуры
> Как раз оптимизация и происходит на лету для конкретной модели процессора. Что позволяет увеличить скорость выполнения.
я имею в виду нормальные оптимизации, которые включают в себя изменение порядка исполнения команд, специфическое (с учетом особенностей работы кеша) разворачивание циклов и тому подобные сложные (а зачастую даже заумные) вещи, которые просто нельзя исполнять на лету – слишком уж долго они выполняются.
простой пример:
благодаря правильному компилятору довольно древний (по современным меркам) 300 MHz процессор c TDP < 1W, простаивающий 20 тактов при каждом обращении к памяти, и мааленьким кешем второго уровня, не доступным для записи примерно половину времени, по производительности превосходит продукты intel с частотой 2 GHz и TDP ~100W.
кстати, я сомневаюсь в способности JIT вообще заниматься оптимизациями – ему хотя бы успеть просто оттранслировать код в нативные инструкции.
а про то, что GC может быть один на систему – не знал, спасибо.
3 ноября 2008 в 23:02
#30, Влад KeViNTM Лисовский
Да не за что =). Рад помочь, потому что всё в голове не удержишь.
#32, Ростислав Чутков
. Все допускают ошибки, даже вы. Чтобы научиться программировать на .NET уходит не один год, если вы считаете, что всё знаете, то это далеко не так. Чем больше знаешь, тем больше понимаешь, что ещё много осталось. Я не говорю про синтаксис, который учиться за 1 ночь чтением документации, я говорю про стиль написания вашего кода, чтобы он работал быстро, и был на столько качественный, что вам perfmon никогада бы не пригодился. Я рад, что c# становится всё более и более распростанённым языком. Всё больше и больше людей приходит в эту область. Пусть они начинают с начала, но через 1-3 года они будут состоятельными программистами, все когда то начинали. Меня всегда развлекали люди, разговаривающие о каких то абстрактных вещах как быдло кодеры и т.д. Сколько я таких не знаю, они ничего не достигли. Беря инструмент, нужно представлять зачем он, его плюсы и минусы, и нет ничего на все случаи жизни.
Не надо так отзываться о других, труд надо ценить
3 ноября 2008 в 20:01
>> это есть самый ужасный минус, если программа на си++ выполняется за 0.1 микросекунды, а на си№ – за 3.0000001 секунды
Эт интересно где такая ситуация встречается?
Да и в пользу C# можно сказать то, что намного легче спаять какой-нибудь веб-сервис или распределенное приложение, чем на С++.
3 ноября 2008 в 20:01
Ширпотребный быдлоынтерпрайз солюшн, ну конечно, намного легче на C#. Да нет, хороший язык, а вот программисты на нем, в большинстве своем, люди не то чтобы далекого ума. Потому как много и не требуется.
3 ноября 2008 в 14:04
Dmitry Frozik Sharov, спасибо за интересные ответы.
3 ноября 2008 в 3:01
Ирина, язык C# проще в изучении, чем C++. Читай Троелсена.
Дистрибутив ищи по файлообменным сетям (рекомендую торрент-сети из-за строгой типизации обмена) ИЛИ бери экспресс-версию (в свободном доступе на microsoft.com).
3 ноября 2008 в 1:03
#26, Леонид maxleo Максимов
>начнем с простого. в .NET GC (garbage collector) выполняется в отдельном потоке, что, как известно, увеличивает количество нитей выполнения в процессе, уменьшая время исполнения каждой из них…
Берём дамп приложения, анализируем и видим, что у процесса нет потока GC, у него есть поток Finilize. В системе в зависимости от типа GC возможны 3 варианта работы, которые сводятся к тому, что либо один поток GC на все приложения, либо по одному потоку на ядро процессора. Как уже заметили, сборка мусора происходит, когда GC начинает испытывать давление. Сборка мусора от первого поколения происходит быстро и почти незаметно, куда сложнее со вторым и третьим поколением, когда начинается изменение границ памяти для поколений. Но работа хорошего программиста на .NET как раз и сводиться к тому, чтобы не нагружать GC.
>использование прямого преобразования кода в native код не позволяет использовать различного рода оптимизации, характерные для конкретной архитектуры
Как раз оптимизация и происходит на лету для конкретной модели процессора. Что позволяет увеличить скорость выполнения.
3 ноября 2008 в 1:01
C++ не будет вытеснен C# хотябы потому, что ядро виртуальной машины ещё пока не входит в ядро основных операционных систем, а значит низкоуровневые вещи на нём не сделаешь. Тут надо многое менять, и думается будет сложно реализовать Garbage Collector, который бы работал на разных уровняхв Windows, понятия не имею что там в nix, но они даже и не подумают об этом скорее всего.Также .NET неразумно использовать в приложениях где какими либо обстоятельствами накладываются ограничения по ресурсам. Например, чтобы загрузить все модули приложения, а также провести на лету компиляцию надо достаточно много памяти, и процессорного времени. В вашем приложении написанном на .NET будет дополнительно несколько потоков в нагрузку от CLR. Ну и собственно ограничение наличия виртуальной машины. Ну и конечно c++ не умрёт как один из языков .NET.
На счёт производительности могу сказать только то, что всё зависит от программиста .NET может не уступать native коду. Тут уж надо уметь подстраиваться под GC и делать всё, чтобы он как можно меньше собирал мусор, и собирал его правильно. После 100 процентного покрытия вашего кода JIT'ом приложение будет летать.
На самом деле я против изначального использования платформы .NET для обучения, надо получить пару шишек от утечек памяти, выходов за рамки массива. Потом это всё пригодится, а особенно, когда захотите использовать unmanaged код.
В чём различия c++ и .NET?
Во первых различие в компиляции. Когда вы компилируете c++ приложение обычно оно сразу компилируется в native код, специфичный для конретного процессора/операционной системы. В случае же с .NET приложение компилируется в промежуточный IL код. А уже во время выполнения происходит загрузка виртуальной машины, и компиляция IL кода в native код специфичный для процессора на котором выполняется приложение. Из этого следует, что ваше приложение будет работать во всех ОС, где есть виртуальная машина .NET.
Во вторых это работа с памятью. Если в чистом c++ вы выделили в heap кусок памяти, то вам его надо будет где то освободить. В .NET за вас работу по освобождению памяти возьмёт на себя Garbage Collector.
В третьих это различие в библиотеках. .NET предлагает их великое множество на любой вкус. Конечно для c++ есть тоже много библиотек в виде STL, Boost и так далее. Но аналогов для таких вещей, как Linq, WCF, WPF в c++ я не знаю.
В четвёртых это разработка. Гораздо легче пустить в разработку приложения человека, зная, что он не испортит работу других, если не использовать unmanaged код. В c++ из за одного неумелого движения по работе с памятьюпотом можно месяцами отлавливать падения программы в неожиданных местах. Ну и чисто субъективно код с# легче читается, чем c++.
В пятых это поддержка и отладка. Анализировать проблемные области гораздо удобнее в .NET коде, нежели в native коде. В это входит анализ дампов упавшего приложения.
P.S. Компиляторы это не низкоуровневые приложения, и писать их я думаю удобнее на .NET, чем на c++.
3 ноября 2008 в 0:02
#23, Alexander Cyborg Zubakov
> Пользователь реагирует на вывод программы секунд 5, если не больше. А программа выполняется за миллисекунды, будь она написана на C# или на C++. Это раз.
так реагирует медлительный пользователь. меня, например, раздражают программы, запускающиеся дольше пары секунд. однако для сервера, которому необходимо ежесекундно запускать сотни различных программ, такое время запуска совершенно не приемлемо.
> А теперь два, честно говоря уже "баян", так что совершенно не понятно, почему нужно в хз какой раз это говорить. Где достоверные данные о том, что программы на C++ исполняются быстрее, чем аналогичные на C#?! Быстрее происходит процесс запуска программы, но после того, как программа транслирована в native-код и начала исполняться, нет никакой разницы, на чем она была написана!
начнем с простого. в .NET GC (garbage collector) выполняется в отдельном потоке, что, как известно, увеличивает количество нитей выполнения в процессе, уменьшая время исполнения каждой из них. далее, GC вызывается только при возникновении необходимости, в результате чего значительная часть ресурсов не освобождается сразу, и очередное выделение большого количества ресурсов заставляет ваш процесс ждать неопределенное время (что также плохо сказывается на предсказуемости времени исполнения).
по поводу собственно производительности: использование прямого преобразования кода в native код не позволяет использовать различного рода оптимизации, характерные для конкретной архитектуры, в результате чего код получается заметно менее производительным, нежели сгенеренный оптимизирующим компилятором C++.
2 ноября 2008 в 23:01
Никому эти достоверные данные не нужны, потому что если ставятся требования производительности, то байт-код обычно и не принимается во внимание. Справедливо или нет – но зачем?! Ведь есть хорошие оптимизирующие компиляторы C++.
2 ноября 2008 в 22:04
#22, Леонид maxleo Максимов: ">ибо если программа на с++ выполняется на 3 секунды быстрее чем на C#, то это не есть большой минус.
это есть самый ужасный минус, если программа на си++ выполняется за 0.1 микросекунды, а на си№ – за 3.0000001 секунды"
Пользователь реагирует на вывод программы секунд 5, если не больше. Апрограмма выполняется за миллисекунды, будь она написана на C# или на C++. Это раз.
А теперь два, честно говоря уже "баян", так что совершенно не понятно, почему нужно в хз какой раз это говорить. Где достоверные данные о том, что программы на C++ исполняются быстрее, чем аналогичные на C#?! Быстрее происходит процесс запуска программы, но после того, как программа транслирована в native-код и начала исполняться, нет никакой разницы, на чем она была написана!
2 ноября 2008 в 22:00
#20, Влад KeViNTM Лисовский:
> ибо если программа на с++ выполняется на 3 секунды быстрее чем на C#, то это не есть большой минус.
это есть самый ужасный минус, если программа на си++ выполняется за 0.1 микросекунды, а на си№ – за 3.0000001 секунды
2 ноября 2008 в 20:01
>На работе мне седня программист выдал, что С++ язык
>неперспективный ибо Borland, фирма разработчик (я так
>поняла разработчик С++) уступает Мелкософту
Настоящие программисты не несут такой бред.
2 ноября 2008 в 18:02
#17,Виктор Григорьев +1.
#18 Владимир Volodia Уваров, никто и не говорит что с++ умрёт…просто, возможно, в винде его вытеснит более простой C#, ну а линуске и юниксе с++ – бесспорный лидер.
2 ноября 2008 в 18:02
и кстати быстрота выполнения и размер программы уже не так актуально в наше время, а вот быстрота разработки и лёгкость в поддержке ой как актуальна…или не так?
ибо если программа на с++ выполняется на 3 секунды быстрее чем на C#,
то это не есть большой минус.
2 ноября 2008 в 15:02
По моему личному мнению язык С++ не умрет так как ни С# ни Java немогут соревноваться с ним по скорости выполнения программ…
2 ноября 2008 в 14:05
так вот ниша у шарпа очень просторная, и пределы ее необозримы
2 ноября 2008 в 12:02
#15,Сергей Lucius Старовой, и что есть ниша для шарпа и её пределы?
2 ноября 2008 в 11:05
[quote] C# уже доминирует. Сравните спрос на программистов C++ и C# [/quote]
Ага, а спрос на программистов для 1с еще больше. Значит 1с доминирует?
У шарпа есть своя ниша. За ее пределы он в обозримом будущем не выйдет. О каком доминировании может идти речь?
2 ноября 2008 в 10:04
Леонид maxleo Максимов…русский мсдн – это интересно. Можно ссылку?
пока яндекс ничего толкового не выдал
2 ноября 2008 в 10:04
на каком то форуме написано, что мелкософт официально сделает перевод к новому году, некоторые же советуют подтягивать английский…чем думаю и стоит заняться.
2 ноября 2008 в 1:03
оффтоп
1 ноября 2008 в 23:02
вот мне б как раз рус не помешал бы=)
1 ноября 2008 в 23:01
кстати, где-то должна уже появиться русская студия (в том числе экспресс), а также переведенный мсдн.
1 ноября 2008 в 21:04
2Man Of Unix
И нафига для обучения языку Visual Studio ?
ну…проблема в том что у меня на изучение данного языка всего 2 дня, то бишь праздники…воть…в С++ я вроде как шарю…ток вот не могу никак допереть как инверсию серого сделать…серый то получился…а вот инверсия…
ну короче у меня на все про все 2 дня=) а работать придется вVisual Studiо, так что наверное лучше сразу к этой среде привыкать…
1 ноября 2008 в 21:00
Спрос не главный показатель. Вот если бы C++ программистов сокращали…
А тут все просто, есть (относительно) новая технология – на базе нее можно делать экспериментальные проекты, получать на них гранты, заключать новые контракты, и т.п. бизнес просто активнее идет. Но не разработка.
1 ноября 2008 в 20:05
Ира, держи ссылку:
//www.microsoft.com/downloads/details.aspx?Fami...
1 ноября 2008 в 20:05
C# уже доминирует. Сравните спрос на программистов C++ и C#
1 ноября 2008 в 20:02
>На работе мне седня программист выдал, что С++ язык неперспективный ибо Borland, фирма разработчик (я так поняла разработчик С++) уступает Мелкософту, который использует С# (в чем я чет сомневаюсь) и Borland скоро вымрет…
ну далеко не только борланд выпускает компиляторы C++ и язык разработали не они =)
И нафига для обучения языку Visual Studio ?
1 ноября 2008 в 20:02
У Майкрософта есть своя реализация компилятора С++, и что-то мне подсказывает, что намного лучше, чем у Борланда. Да и про гнутый и интеловский, в Sun Studio тоже забывать не стоит.
>> Ну, Си-шарп — детище Мелкомягких, создан для Дот Нета
А Mono на что?
Да и откуда такая статистика по использованию языков?
Отличий хватает у этих языков.
Можно почитать Троелсен "C# и платформа .NET", там в начале описано, что эт за штука и про философию .NET.
1 ноября 2008 в 19:03
и еще…если кто знает киньте ссылку на Visual Studio желательно рус (хоть и не реально наверно) и чтоб ключ не требовал=)