так рождаются нездоровые сенсации. java vs с++

А net-framework они случайно в кэш первого уровня встроить не хотят?

 

apple

Зачем это надо - ведь MSIL позиционируется как универсальный промежуточный язык для .Net кода. Его аппаратная реализация будет имхо тормознее, чем результат правильной перекомпиляции под обычную (классическую) платформу. Так что несмотря на подобные идеи (такие в сети имеются), врядли Intel или AMD решаться на создание аппаратной поддержки.

 

HitmaN85

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

 

apple

Пока что и встраивать нечего, но то, что МС грезит подобными идеями - бесспорно. К примеру, Sun тоже давно мечтает о Java-копроцессоре.



Elderine

Сишный код оптимизирован? Если компилятор повставлял в каждую итерацию цикла проверку целостности стека и операции с плавающей запятой реализовал через тормозной CRT, то...

 

Elderine

Ты смотрел на то, что сотворила жаба?

Не то, что набрано в редакторе кода, а то, что реально исполняется?

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



Я уже встречал подобные "сенсации", когда .net программа практически на равных состязалась в скорости с кодом, написаным на асме: отставание было в 1.5 раза. При ближайшем рассмотрении оказалось, что количество итераций в .net-проге было уменьшено вдвое по инициативе компилера



P.S.

Приведи код на сях, интересно попробовать.

 

alpet

Зачем это надо - ведь MSIL позиционируется как универсальный промежуточный язык для .Net кода. Его аппаратная реализация будет имхо тормознее, чем результат правильной перекомпиляции под обычную (классическую) платформу.



Решится, по крайней мере, Microsoft. Будь MSIL хоть трижды не ее. По закону -- он ей не принадлежит, хоть и разработан по сути -- иначе начнутся проблемы с АМО.

Быстродействие техники растет, цена падает, так что вполне реально сделать и процессорную поддержку.

Здесь не важно, что будет на самом деле медленнее. Важно, что все предыдущие программы будут работать медленнее, если вообще будут работать. Это значит, что разработчикам нужно переписывать на .NET, то есть покупать ПО (скорее всего у Microsoft, благо до 7 ноября кто угодно может утянуть Express-версию бесплатно -- 30МБ -- и пользоваться ей бессрочно в том числе и в коммерческих целях даже через Soft Key продавать =)))).

Процент "халявщиков" хоть и высок, однако и тут помогает M$ в кажущемся непроцветании монополизации.

Плюс слухи о закрытии поддержки Delphi, что вызвало некоторый переход дельфийцев на C#. И т.д.



Введение поддержки MSIL в процессор сравнимо с "введением" в винду библиотек от MSVS (MFC etc) благодаря чему все восхищаются, "А что такие проги масенькие! Не то, что на Delphi (у которого бпл-ки не включили в состав винды)".

Вот и с этим также: отобьют у Sun часть клиентов плюс, руководствуясь "добрыми намериниями", перегрызут горло всем непересевшим на .NET, так как при учете новой архитектуры ставка сделается на быстродействие MSIL.



AMD - пожалуйста, не подчиняйтесь, и на Ваших процессорах .NET-винда будет работать в 2 раза медленнее, XP же уже не поставишь на Intel-процессоры.

Хотите XP поставить на AMD? - пожалуйста, только учтите, что это все старо и новые проги работать вряд ли быстро будут. Все равно эмулятор ставить. Лучше не мучайся - переходи на Intel по той же цене.

То есть без .NET никто никуда не уедет, а Microsoft заработает кучу денег.



[add]

Поправьте меня, где не так.

 

apple

И после 7го тоже

 

Elderine



Привел бы оба кода здесь?

 

apple

Врядли что выйдет, даже у такого гиганта, с такими спецами, которые способны затормозить любое железо. Хотя меня уже сейчас раздражает непомерная тормознутость VS2005 (есть подозрения что это все-таки баг), врядли удасться создать MSIL-код, что будет быстро выполняться на аппаратном CLR, и тормозить на многогигарцовом и многоядерном x86 процессоре. Вот если будет тормозить сама CLR - найдутся умники способные написать оптимизированную ее реализацию, так как пока все открыто. В этом случае правда ситуация дойдет до комизма - все попрежнему будут пользоваться виндой, но запускать ее будут из под виртуальной машины в свою очередь запущенную из-под линуха. Если Мелкомягкие попытаются надавить на камнепроизводителей, те наверняка дружно поддержат что-то из "Linux+Java+нативный код". Иное их поведение (сиречь прогибание), в свою очередь даст свободу действий остальным компаниям (IBM Cell).

 

меня уже сейчас раздражает непомерная тормознутость VS2005

Да, у меня тоже с ним странность. На работе 256МБ ОЗУ + PIV Celeron 2.0 GHz. dotnetfx 2.0 Ставился дооолго.

Дома машина получше AMD64 3000+ 1GB ОЗУ -- dotnetfx 2.0 поставился очень быстро.

А вот студия работает быстрее на работе!

Даже не работает - летает. Загружается за максимум 2 секунды против 5-7 дома.

Зато дома можно загрузить одновременно еще и Delphi7, и MSDN, и VMware с XP, и музыку слушать. Компилируется пустая форма секунды за 2-3. Студия работает чуть медленнее.

 

alpet

Врядли что выйдет, даже у такого гиганта, с такими спецами, которые способны затормозить любое железо... врядли удасться создать MSIL-код, что будет быстро выполняться на аппаратном CLR, и тормозить на многогигарцовом и многоядерном x86 процессоре.

Специально тормозить и не надо, особенно MSIL

Я писал про то, что обычные Win32-приложения на таком процессоре будут тормозить.

Впрочем, такой процессор -- будущее.

Сначало сделают NET-Windows, уберут реестр, поменяют файловую систему. И прочие пакости, чтобы Win32-программы поддерживались частично

Таким образом, очень даже реальна перспектива массового перехода либо на NET либо на Java.

 

apple

Только не на Java. Java ещё держится только за счёт серверных приложений на базе никсов. С .net она конкурировать не сможет. Долго не протянет, если только МС вдруг не разорится

 

win32 программы еще как минимум лет 10 будут поддерживаться, а то и больше. А процессор с аппаратным CLR (или чем-то аналогичным) если и появится, то оооочень нескоро, т.ч. переживать по этому поводу не стоит.

 

masquer

Не в проц, но в какую-то железку это точно скоро засунут. Под предлогом оптимизации харда под .NET добавят туда начинку для аппаратной поддержки DRM, всякой криптографии. Всё-таки МС невыгодно ссориться с AMD и разрывать тандем с Intel, вернее это рискованно. А железку они и сами смогут сделать и позаботятся об установке OEM. 40% рынка того стоят.

 

Quantum

Согласен, но держится очень прочно. В Европе Java стала в последние годы серверным стандартом, MS используется все реже несмотря на всю рекламу дот нета. Не знаю, удастся ли им переломить ситуацию.

 

Интересно будет на такое чудо посмотреть, имхо, дотнет в дополнительном аппаратном ускорении не нуждается вообще. Даже если изобретут такую железку (с защитой и дрм) то очень скоро появятся его эмуляторы от китайских умельцев

 

Вот пример пузырьковой сортировки на C# и C++

http://files.rsdn.ru/32671/sort.zip

В качестве массива - файл input.bin в одном каталоге с программой

(найдете в C++-проекте, скопируете в C#)

Тест проводил 3 раза. C# быстрее в среднем на 15%

Взял сдесь: http://www.rsdn.ru/Forum/Message.aspx?mid=1847575

 

masquer

Купи себе X-box.

Даже если и так, хотя звучит слишком категорично, МС в последнюю очередь интересуют вопросы производительности, переносимости и т.д. Покончить с реверсингом и пиратством - вот их конечная цель! Понятно, что .net уйдёт в железо не для повышения производительности, а всего лишь под этим предлогом. С самого начала всё к этому шло.

 

Всем доброго утра!



http://mityajj.jino-net.ru/uploads/1145701163/new_try2.7z

- коды.

Декомпилированный код тоже смотрел, вроде не отличается от того что писал я.



Кстати, это идея, надо то же самое написать теперь на c# и посмотреть кто круче, шарп или жаба.

 

ну так я ж и говорю - на такой вариант модчипы есть

Ну-ну, блажен кто верует