Добрый день.

Эту тему мы начали обсуждать зесь, но, так как она там была "совсем не в тему", было решено ее вынести в отдельный топик.

Все началось с моего предположения об исторической важности появления .NET
Я считаю, что .NET был создан для того чтобы освободить процессоры (CPU) от тяжелого наследия x86 архитектуры.

Постараюсь описать проблему:

Когда-то появилась архитектура x86. Под нее стали писать программы. Скомпилированная программа представляет собой набор процессорных команд (инструкций).
Процессоры развивались, появлялись новые команды и наборы команд (MMX SSE и тд.), но  все старые оставались, ибо, стоило их убрать ПО скомпилированное для старых процессоров не работалобы на новых. При этом программа скомпилированная, скажем, с поддержкой  i386 работая на Pentium 4 не использовала его потенциал полностью.

Неплохим решением стала архитектура применяемая в *NIX - там, учитывая распространение большого количества ПО в исходных кодах, можно было скомпилировать программу (или вобще всю систему) под  конкретный процессор. Но для продуктов M$, такой подход был неприемлем, и дело не только в нежелание распространять ПО в исходных кодах, но и в том, что для обычного юзера, такой подход вызвал бы сложности (например исполняемый файл с одной машины не стал бы работать на другой), замена процессора потребовала бы перекомпиляцию системы и тд.

Сейчас назрела ситуация, когда в рамках х86 стало тесно. Некоторые процессоры уже не работают с командами х86, а имеют транслятор х86 в свои команды, появилась 64 разрядная архитектура (которая тоже вынуждена быть совместимой с х86).

Что делать?
Ответ использовать виртуальные машины. Использовать .NET
Для тех кто не знает: Программа скомпилированная под .NET представляет собой не набор инструкций процессора, а набор инструкций виртуальной машины, которая, в свою очередь, транслирует из в команды процессора.
Таким образом ПО больше не зависит от процессора, и для нового процессора нужно лишь заново скомпилировать виртуальную машину и все старое по будет работать на 100% используя новый процессор.

И что из этого вытекает?
По-моему, как только все основное ПО перейдет на .NET, нас ждет революция в мире процессоров. Появление новых архитектур, и новый скачек производительностей.


Кто что на это скажет, Вы согласны или нет?

  Для этого нужен кросплатформенный .NET, а он не такой на самом деле.

Если кросплатформенный в смысле Windows, Linux и тд, то нет, не нужен.
*NIX системы готовы к смене архитектур. Их можно запустить почти везде, от Sony PS3 до мобильника.

х86 держит именно windows, будучи основной ОС в мире.

почему ИМЕННО .Net?
вроде же, это не единственная платформа (или машина)
а проблем там щас хватает, по моему сведению.

У .Net проблем просто куча... Взять, хотя бы проект Mono. По моим, опять же, сведениям под линухом шарповские гуишные проги еще доолго работать нормально не будут.

Даже у явы, вроде, проблемы со связкой многопоточность+кроссплатформенность...

А если учесть, что технологии, облегчающие разработку многопоточных приложений (типа OpenML) находятся щас в зачаточном состоянии даже на С++, то я не уверен, что все так радужно, как говорит Vasay

ЗЫ. Я высказал, что знаю. Может, "мои сведения" устарели. Тогда интересно послушать более свежие

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



Что-то не замечал ;-)



Проэкт моно - это *NIX  (причем нафиг он там нужен?), а я уже писал, что *NIX готово к переходу на новые архитектуры.

А хотим мы того или нет, но скоро почти все ПО под Вин будет на .NET....

  Еси тока мелкомягие не скажут что .net это фигня, а вот какой-нибудь .NET++ вот это рулез, так что бросайте дружно .NET и переходите на че-нить еще более навороченное. Win32 это по крайней мере нативный код процессора и ему некуда деваться.

Добавлено через 35 секунд
А x64 скорее эволюция чем революция, потому переход на него будет "мягким".

Не понимаю, почему в том, что чьи-то программы не используют новейшие технологии, виновата архитектура процессора?

Vasay, 
давай вернемся к IA-64
почему Itanium-ы занимают по большей части лишь серверную нишу?
почему их нет (или малое количество) на десктопных системах?
первая причина - это цена
но она все же не главный фактор
истинная же причина - отсутствие совместимости с X86 (X64)
это ведет к необходимости перекомпиляции огромного числа приложений
это число настолько огромно, что трудно себе представить
серверный софт - это узкоспециализированный софт, его в разы меньше, чем общее количество всех программ
поэтому перекомпиляция оправдана
что предлагаете вы
перейти на .NET
все вроде бы хорошо и логично, только есть одна проблема
в отличие от перекомпиляции в случае с IA-64, тут необходимо полное переписывание всего существующего софта на управляемых языках (C#, VB.NET, ...)
вы считаете, что это рациональнее?   

Это сообщение отредактировал(а) MAKCim - 19.10.2007, 19:43

  А зачем? Нужен только фреймворк под итаниум.

софта нет
вот в чем вопрос
сначала его написать надо, потом CLR под Itanium, а уж потом радоваться жизни   
естественно, чем сильнее продвигают .NET, тем больше софта под него
но перекомпиляция все равно проще и дешевле
так что дело тут совсем не в объективной необходимости .NET как толчка к отказу от X86   


Это сообщение отредактировал(а) MAKCim - 19.10.2007, 22:42

ну кто тут хотел поспорить? чего все ушли?   

Выходные все же   

MAKCim, 

Я абсолютно согласен с тем что ты говоришь.
Единственное, хотел бы заметить, что пройдет время (не так уж и много), и весь основной софт будет на .net и его наследниках или конкурентах (у JAVA есть шансы, я верю   ! ) И тогда, переход на другую архитектуру (например IA-64) не будет столь проблемптичным - да какой-то старый софт не будет работать, но разве нас волнует, то что некоторые программы, криво написанные под вин95 не хотят нормально работать в ХР

Привет, я тоже внесу свои три копейки!  Никто не упомянул о том, что чтобы скомпилировать сам фреймворк, нужен компилятор под платформу, на которой этот фреймворк будет работать. Нет компилятора - нет фреймворка. А если есть компилятор, то и приложение любое можно на нем собрать. Просто будет компилиться несколько версий софта, для каждой платформы своя. Человек купит и получит приложение под конкретную систему, под конкретную ОС, придет домой, поставит и нет проблем. Тот же фреймворк тоже необходимо инсталлировать при смене железа, да и ОС тоже. Так в чем смысл? Не легче ли просто сделать так, чтобы по ОС юзера определялось, какую сборку ему предоставить. Так что этот процесс можно вообще автоматизировать и протекать он будет прозрачно для юзера. Тем более сомневаюсь, что можно обойтись лишь перекомпиляцией фреймворка под новую платформу, там куча побочных проблем возникнет! Вон моно так и не получила широкого распространения, хотя в свое время WinFX был переименован, чтобы подчеркнуть нацеленность в том числе на опенсорс, да и название самого IL несколько раз меняли, думаю по тем же причинам. Так что сомнительно все это, имхо! О быстрой смене архитектуры процессора думаю вообще речи идти не может! А основная цель .NET - это удобство разработки и нацеленность на "приберание к рукам" определенной ниши.

P.S. В чет-то повторил доводы MAKCim-а, думаю он на меня зол не будет!!!   

Это сообщение отредактировал(а) Loony - 11.12.2007, 08:59

а пачаму не Java от Sun?

Добавлено @ 09:40


Это изначальный, один из основополагающих принципов Майкрософт "написанное когда то должно работать всегда";)

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


Это сообщение отредактировал(а) VSergeyV - 11.12.2007, 09:55

Loony, 

Не соглашусь, представь, есть фирма, выпустила какую-то софтину, скомпилела ее под все существующие процы, стала продавать, потом фирма перестала поддерживать софтину, появились новые процы, требуется новый билд, кто его сделает? а в случае с .NET ничего перекомпилировать не придется.

И еще вы представляете среднестатистического юзера? Этот юзер вряд ли знает какой процессор у него стоит, он хочет скачать програмку, ему предлагают 10 версий - он скачает одну, она не запустится, он забъет... А так - он купил комп с соответствующей виндов$, она сама переодически обновляет .NET и юзер не парится   . 


VSergeyV, 


Потому что Sun не Microsoft, она могла предложить, но не могла обязать.   

Это же сколько времени должно пройти, чтобы и фирма закрылась и процы новые появились и прямо все так плохо стало!?    Согласен, сейчас до сих пор пользуются приложениями под дос, написанными еще под 386 проц, но ситуация все же меняется в лучшую сторону. К тому же эта фирма будет поддерживать софт, если потребность будет, а нет - найдется аналог. А в том же .NET-e тоже могут произойти кардинальные изменения.



Так я об этом упомянул, надо автоматизировать процесс, ему не придется ничего скачивать, он заплатит деньги, щелкнет по линку, примет лицензию и все. Идентификация пройдет автоматически.

Я не ярый противник .NET, у нее много плюсов, я и сам пишу на шарпе. Но в том контексте, в которой ее тут преподносят она не истина в последней инстанции. По крайней мере на данном этапе развития технологий.

Вообще-то не совсем так. Программа транслируется в команды процессора один раз перед первым исполнением, а в дальнейшем исполняется уже как откомпилированная, без всякой трансляции.

  Насколько я знаю, после 1й динамической компиляции сборки кэшируются, а затем при повторной загрузке сборки только линкуются динамически, т.е. это уже больше похоже на экзешник подгружающий кучу Dll-ек. Но в любом случае при линковке должна идти проверка сборок из кэша на валидность, потому загрузка в любом случае будет дольше чем загрузка Win32 программы.

Vit, 
Alexeis, 

Это конечно так  

Но суть от этого не меняется - программы на .NET могут быть платформо-независимыми (при наличии .NET под соответствующую платформу).


Дальше идут мои наблюдения:

Почему M$ так нуждается в платформо-независимости?  - если они этого не сделают, они потеряют огромную часть рынка, 
Один пример:

А нужен ли человеку (не программисту, дизайнеру, проектировщику), а рабочему - водителю, крановщику, летчику (зарплаты которых, кстати, иногда повыше зарплаты хорошего программиста) домашний компьютер? - нет! А как же интернет? Почта? Игры наконец? Возьмем консоль SPS3 - она со всем прекрасно справится - с играми все ок, двд, мр3 - нет проблем, браузер есть, не хватает возможностей? Так можно linux запустить (есть спец дистрибутив), тут и аська, тут и скайп, неплохой офис, и все бесплатно! может гимп и уступает фотошопу, зато бесплатно, обработать фотку сделанную какой-нибудь цифровой мыльницей - хватит.
Т.е. девайс стоймостью менее 20000р заменяет комп стоймостью 45000 без по (можно и линукс поставит  ). 

У M$ есть своя консолька - xbox 360, есно линукс там не работает, но и windows тоже, так как процессор то не x86. Пожалуй, скомпилить виндовс они смогли бы, но чтоже делать с софтом?

А теперь представим, что проблем с софтом нет, почему бы человеку не купить xbox 360, еще за 2000р купить лицензионную винду (тут еще и офис втюхать можно) - и всем счастье - M$ загнала не только приставку, но и пару лицензионных софтин, а человек сэкономил на покупке не нужного ему компа.

Или возьмем манагера среднего звена, у которого нет времени играть в игры (а может и есть), а для работы у него свой ноут, но у него есть и ребенок который хочет "погамится" или посидеть в инете? Опять же зачем брать дорогущий комп?

И этот рынок M$ упускает из-за тяжелого груза наследия x86... 

Все выше мое скромное мнение.

Гхм. 45 тыс. р. — это значительно больше стоимости среднего домашнего ПК. Машина за 20 тыс. р. справится со всем перечисленным, и ещё на средней паршивости монитор останется. Кстати, насчёт монитора. К приставке необходимо добавить HD-телевизор, потому что на обычном ни о каком интернете и т.п. речи идти не может.
А PS3 — это Cell. И проблема там не в PowerPC, а в самой несимметричной архитектуре с одним универсальным ядром и специализированными векторными сопроцессорами, которые надо суметь задействовать. Без этого обвеса — очень средненькое ядро.

Я не понимаю, чем Xbox, на котором можно будет запускать и комфортно работать с офисом, будет отличаться от обычного компьютера, на котором и так всё прекрасно работает сегодня и сейчас. Приставки, они всё-таки немного под другие цели заточены. Как домашний мультимедийный центр — возможно, похоже к тому и идёт.

Кстати, аппаратно-независимый набор инструкций был реализован и применяется до сих пор в IBM System i (AS/400) задолго до Java и .NET. Приложения, написанные 20 лет назад, запускаются сегодня, хотя платформа сменила процессорную архитектуру.

И, наконец, виртуальные машины не панацея. Сейчас становится модным (и, думаю, оправданно) параллелизм: производители процессоров пустились в гонку ядер и аппаратных потоков. А эффективному распараллеливанию, увы, никакой фреймворк пока помочь не в состоянии.

Void, 



Комп для игр сопоставимый по мощности с PSP3 имхо дешевым не выйдет, стоимость одной видяхи будет от 15к. + подходящая мать для нее + корпус с соответствующим охлаждением и блоком питания...
HD телик становится уже делом обычным, да к PSP3 можно обычный жк через dvi подключить...

+PSP3 заменяет dvd/Blu-Ray - проигрователь... 

т.е. как Вы и сказали:


и этот мультимедийный центр спокойно заменит домашний ПК для домохозяйки или ребенка  и M$  лишится одной проданной копии видовс.



Она будет дешевле (при тех же игровых возможностях), удобней (для игр ребенку, просмотру dvd домохозяйке), может быть не столь универсальна, но не всем это надо.  


П.С. Ладно, возможно пример не удачный       
п.п.с. Да и вообще игры - зло, лучше купить лыжи/борд/велик, или абонимент в спортзал  .  Просто, недавно приятель купил себе комп для игр (причем не самый навороченный) за 45к, вот мне и навеяло сравнение. 

Это сообщение отредактировал(а) Vasay - 11.12.2007, 20:05

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

IMHO, революцией с этого фронта не пахнет. x86 привычно хают, но в сегодняшнем состоянии он «достаточно хорош», чтобы не тратить миллиарды на разработку и распространение новых архитектур в десктопно-домашнем сегменте.

Речь как всегда идёт об основных проблемах разработки софта:

1. Быстродействие кода
2. Качество (безглючность) кода
3. Скорость разработки
4. Цена разработки

Нельзя оптимизировать разработку сразу по всем параметрам. Чем-то приходится жертвовать.

Быстродействие кода - конечно любая виртуализация делает код медленнее, тут спору нет. Единственное замечание - скорость кода может быть далеко не настолько критичной во многих местах. Естествеенно если планируется писать ядро операционки, ядро базы данных или реализацию какого-то сложного алгоритма, то этот параметер будет иметь наивыший приоретет. Но 95% приложений трятят 99% своего времени на ожидание ответа по сети, ожидание ответа от сервера или базы данных и только 1% времени на выполнение своего кода. Тут оптимизировать по этому параметру абсолютно бессмысленно, выигрышь будет несоизмерим с затратами.


Качество (безглючность) кода - любые фреймворки и готовые библиотеки значительно уменьшают вероятность ошибок. Отсутствие указателей, проверки на переполнения, автоматическое разрушение объектов, проверки на наличие объекта, и т.д. и т.п. - всё это очень сильно уменьшает время разработки.  Любой, кто хоть раз искал утечки памяти или ошибки когда неправильный указатель затирал случайную область памяти знает что подчас ловля такого бага это занятие не на одну неделю для коллектива програмистов, особенно при большом проекте, да ещё если ошибка трудновоспроизводимая и редко повторяющаяся.

Скорость разработки - использование библиотек и фреймворков значительно ускоряют написание приложения. Одно дело если есть готовая библиотека реализующая, допустим, сетевой протокол и для отправки по сети чего-то требуется лишь пара строк кода, и другое дело самостоятельная реализация протокола: изучение спецификаций, написание обёртки, обработка всех ошибок - такая задача может потянуть не на один месяц разработки, причём гарантирует весьма многочисленные ошибки, от которых избавит только длительное бета-тестирование. Опять-таки, естественно, что готовая библиотека писалась не для данного проекта, а для общего назначения, а следовательно содержит огромный избыточный код, скорее всего не оптимизированна под требуемые нужды, жрёт гораздо больше памяти и работает медленнее. Если память или скорость работы для данного проекта критичны, то есть смысл писать самому библиотеку заточенную под данные нужды, если не очень критична, то использование готовой библиотеки, фреймворка и т.п. позволит значительно ускорить процесс разработки.


Цена разработки - я вынес этот вопрос отдельно, тогда как в большинстве книжек его сопрягают со скоростью разработки. В принципе это так, разработка с применением фреймворков более быстра, следовательно более дешёвая. Но есть и ещё один фактор. Если вы наймёте дешёвого програмиста на С++ то проблем огребёте по самое немогу с отлавливанием мыслимых и немыслимых багов типа утечек памяти или внезапно выскакивающих Access Violation не поддающихся никакой систематизации и которые фиг сэмулируешь. Это связано с тем что корявый и не тщательно написанный низкоуровневой код очень трудно отлаживать, особенно сложно в нём искать логические ошибки типа переход по указателю который вообще-то должен быть скажем на единицу больше. Кроме того в низкоуровневом коде зачастую бизнес-логика прячется за сотнями строк "технического" кода, особенно если код написан не очень аккуратно. Выход? Нанимать только высококлассных специалистов? Это может быть весьма накладно для фирм разработчиков, тем более что в больших приложениях зачастую сложного кода - пара модулей, а остальные сотни модулей делают что-то совсем простое и очевидное. Использовать для их написания высококласных специалистов - большая расточительность, для этого подойдут вчерашние студенты, люди без большого опыта работы, не искушенные с более продвинутыми языками и технологиями.

Прошло почти полтора года.

Что изменилось?

.NET живет и развивается. 

Процессорной революции не произошло..... пока.

Но, совсем недавно появилась платформа для нетбуков от Freescale несовместимая с x86. К сожалению текущие версии windows работать на таком буке не сможет.
http://blogs.pcmag.ru/node/981

Так же должны появится подобные платформы от Qualcomm и Texas Instruments.

Возможно, это начало?


 

Прошло 17 лет!

MS пытается перейти прийти на ARM. Не первый раз, но в этот раз, вроде, есть шансы )

Винграду привет! Давно я тут не был!

При этом не может сделать свою IDE кроссплатформенной   
https://blog.ndepend.com/visual-studio-multi-platform/

А им это интересно (с финансовой точки зрения) ?


Версию под ARM они то как раз сделали: https://learn.microsoft.com/ru-ru/visualstu...es?view=vs-2022


п.с. больше года назад взял Huawei MateBook E Go на SnapDragon cx8 gen 2 - вполне работоспособный девайс, особых проблем с совместимостью софта не заметил, эмуляциях x86/AMD64 работает нормально.

Другое дело, что производительность там очень посредственная, при энергоэффективности не сильно лучше чем у AMD U серии, которая значительно производительней.
Но и процессор то древний (переделанный под Windows SnapDragon 855).

В ближайшие дни должны появиться публичные тесты новых Windows ноутбуков на SnapDragon X Elite - если по энергоэффективности это будет уровень Apple M* или хотя бы близко - то можно сказать, что "процессорная революция" началась   

Это сообщение отредактировал(а) Vasay - 27.5.2024, 20:32

Раз они продвигают .Net Core как мультплатформенный язык, то надо бы и IDE предложить (VS Code не IDE). Плюс очень смешно выглядят заявления что .Net мультплатформенный, но IDE написанная на этом "мультплатформенном" языке прибита гвоздями к одной ОС.