Renesas Electronics Corp поддерживает .NET Micro Framework

petrun · 14-08-10 18:41:21

Linfan пишет:

Ну вот это называется по другому big_smile В таком случае нужно говорить:
"Для быдлокодеров типа (k)Арманчика, которые не могут оптимизировать свой код изначально и не могут создать оптимальную архитектуру приложения, дотнет предоставляет набор функций по оптимизации кода"
В нативном коде (в машкодах) уже давно не пишут (лет 20 так точно). Поэтому сравнивать дотнет с нативным кодом - глупое и бессмысленное занятие. Т.к. на самом деле сравнивается неоптимизированный код на C++ или еще на чем-то, с таким же кривым кодом на сишарпе, но прошедшим процедуры оптимизации при JIT компиляции.

Я имел в виду то, что при определенных условиях JIT компилятор будет генерировать более оптимизированный код, чем компилятор работающий до выполнения.

Linfan · 14-08-10 19:04:02

Я имел в виду то, что при определенных условиях JIT компилятор будет генерировать более оптимизированный код, чем компилятор работающий до выполнения.

Все правильно. И эти "определенные условия" - неоптимальный исходный код для компилятора + отсутствие оптимизации кода в компиляторе.

Добавлено спустя 03 мин 40 с:

На цифровую схемотехнику ходить надо было, клоун. Shame.

Вот именно! Зачем же ты ее прогуливал? Или ниасилил и понавыдергивал из контекста удобных лозунгов? big_smile
Вот уж точно что Shame & Shave в одном отдельно взятом (k)Арманчике lol

petrun · 14-08-10 19:14:16

Linfan пишет:

отсутствие оптимизации кода в компиляторе.

неправда ваша.Не всегда.JIT может иметь ту информацию, которая принципиально не доступна обычному компилятору.
А именно конкретные парметры, с которыми вызывается тот или иной кусок программы.
Лично видел БПФ на яве, которое работало(с комплексными значениями) быстрее чем из fftw.

Linfan · 14-08-10 19:27:31

Лично видел БПФ на яве, которое работало(с комплексными значениями) быстрее чем из fftw.

Вполне может быть. Не отрицаю такой возможности. Хотя бы потому, что тот же ffwt вполне может быть неоптимизирован.
Напр., мой знакомец по необходимости ковырял код libpng и жутко матерился про оптимизацию.

petrun · 14-08-10 19:41:34

Linfan пишет:

Вполне может быть. Не отрицаю такой возможности. Хотя бы потому, что тот же ffwt вполне может быть неоптимизирован.

Анонсируется оно как очень оптимизированное решение.Тут дело в том, что JIT компилит программу каждый раз, уже зная заданный размер массива.
А тут сами понимаете, какой простор для оптимизаций.

Armanx64 · 14-08-10 19:46:23

Все правильно. И эти "определенные условия" - неоптимальный исходный код для компилятора + отсутствие оптимизации кода в компиляторе.

Высер, а почему ты в 30 лет не соображаешь?
Процов - куча. Компилятор создаёт нативный код под нечто сферическое и минималистическое + дофига всяких "а если так работает, то ещё и так, иначе через те делай другое". На пары я, в отличие от тебя, ходил. Это не хвастовство, конечно, но я - единственный на всю группу, имеющий по схемотехнике "отлично".
Предкомпилятор же в .NET создаёт код IL который к процу не привязан никак. А уже в процессе выполнения IL быстро транслируется в ЯМК, работающий исключительно на текущем процессоре. И максимально оптимизированный. Поэтому иногда кроме универсальности есть и прирост.

Высер, а ты хотя бы школу окончил?

MOP3E · 14-08-10 20:23:21

Могу добавить свои 5 копеек. Не так давно появились компьютерные игры, которым для работы обязательна поддержка SSE3. Я со своим Athlon XP 2000+ был жутко удивлён, когда компьютерная игра "Партизан" отказалась запускаться. Также, многоядерность поддерживают далеко не все как компьютерные игры, так и прикладные программы. Очевидно, что производительность такого универсального ПО снижается из-за использования в нативном коде архаичных инструкций и меньшего числа ядер, чем у текущего процессора. В пользу таких выводов говорит, например, высокая производительность Linux Gentoo, все бинарники в которой скомпилированы с оптимизацией под архитектуру конкретного компьютера.

Linfan · 14-08-10 20:33:23

На пары я, в отличие от тебя, ходил. Это не хвастовство, конечно, но я - единственный на всю группу, имеющий по схемотехнике "отлично".

о_О... вот это спортсмэн )))))))))))

Слух, [censored], тебя просили - ссылки на MSDN что дотнетовский JIT оптимизирует код под индивидуальный процессор, а не общие 32/64bit инструкции.

И да будет тебе имбицилу известно, что те же сишные компиляторы не создают "сферичиский код в вакууме" а позволяют его оптимизировать под конкретный процессор. Тебе вон даже МОРЗЕ пруф привел.

И ваще, я поражаюсь - "отличнег-кармановец" не знает что такое примитивные типы данных, но блин уже мнит себя светилом программирования. Ояебу образование нынче big_smile

Отредактировано Linfan (14-08-10 21:12:50)

Майор Очевидность · 14-08-10 20:36:51

Linfan, воздержитесь от, кхе, сильных выражений в адрес оппонента.
не лучше Бродяги сейчас смотритесь, честное слово.

MOP3E · 14-08-10 20:37:13

Linfan пишет:

Тебе вон даже МОРЗЕ пруф привел.

Я имел в виду именно то, что библиотеки .Net Framework вполне могут быть оптимизированы под современные типы процессоров. И, соответственно, более эффективно исполняться на более продвинутых моделях процессоров.

petrun · 14-08-10 20:39:11

MOP3E пишет:

Я имел в виду именно то, что библиотеки .Net Framework вполне могут быть оптимизированы под современные типы процессоров. И, соответственно, более эффективно исполняться на более продвинутых моделях процессоров.

А компиляторы в нативный код уже не могут оптимизировать под конкретный процессор?Бида-бида.

Отредактировано petrun (14-08-10 20:39:22)

Linfan · 14-08-10 20:45:35

MOP3E пишет:

Я имел в виду именно то, что библиотеки .Net Framework вполне могут быть оптимизированы под современные типы процессоров. И, соответственно, более эффективно исполняться на более продвинутых моделях процессоров.

Уверен, что прога откомпайленная в MS VS с оптимизацией под продвинутый процессор будет работать хуже чем IL-овский код?
Тут речь не про вин-лин холивар, а про то, что Арман не зная элементарных вещей (напр. чем int от float или double отличается), берется учить всех как правильно жить.
Касательно оптимизации в IL - она есть бесспорно, но оптимизация у нативных компайлеров гораздо продвинутее. Проблема тут лишь в том, что таж венда и весь софт под нее вынужденно компилируется под весь спектр процов для максимального охвата пользователей (ну ессно с учетом 32/64bit платформ).

Svart Testare · 14-08-10 21:00:59

Майор Очевидность пишет:

воздержитесь от, кхе, сильных выражений в адрес оппонента

Тем более с намёком на то откуда человек. Это просто некрасиво.

Linfan · 14-08-10 21:13:17

Тем более с намёком на то откуда человек. Это просто некрасиво.

+1. fixed

Armanx64 · 14-08-10 21:29:17

Да блин, что за хрень?
Да. Оптимизировать вы можете. Только в случае с нативным кодом оптимизация жертвует универсальностью. Сильно жертвует.
.NET оптимизирует, нет, .NET исполняет код под данный процессор.

ссылки на MSDN что дотнетовский JIT оптимизирует код под индивидуальный процессор, а не общие 32/64bit инструкции.

MSDN читай сам. Скан из книги для сомневающихся:

s11.radikal.ru/i183/1008/58/86e1f421667f.png

Книга "C# 2008 и платформа .NET 3.5 для профессионалов"
Кстати, абзацем выше ещё шло про превосходство подхода .NET над подходом JVM.

Добавлено спустя 01 мин 01 с:
Высер, go blow yourself!

И не забывайте, кто изобрёл JIT

Отредактировано Armanx64 (14-08-10 21:30:44)

MOP3E · 14-08-10 21:35:04

petrun пишет:

А компиляторы в нативный код уже не могут оптимизировать под конкретный процессор?Бида-бида.

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

Linfan · 14-08-10 21:39:17

MSDN читай сам

Глупый ты smile В писаниях типа "донет для чайников" выражается личное мнение автора и его взгляд на проблему в общем. Конкретные данные про оптимизацию нужно добывать только из MSDN или сайта МС. Тем паче что даже в твоей книженции написано "может оптимизировать", что подразумевает "а может и не оптимизировать". Это популярная литература, тем болеее что она переводная.
Так что "отличнег" ищи данные от МС, а информацию из серии "на заборе написано" - оставь для школьников.

и опять же <холивар mode>"Только в случае с нативным кодом оптимизация жертвует универсальностью. Сильно жертвует. " - это проблема проприетарного бинарного ПО </холивар mode> lol

petrun · 14-08-10 21:40:06

Armanx64 пишет:

И не забывайте, кто изобрёл JIT

А причем тут LISP?
MOP3E
Описанные вами проблемы успешно решает опенсорц.Да и вообще система репозитариев.

MOP3E · 14-08-10 21:50:08

petrun пишет:

Описанные вами проблемы успешно решает опенсорц.

Путём раздачи исходников? Сколько часов в генте компилируется пакет ООО?

Майор Очевидность · 14-08-10 21:51:31

MOP3E пишет:

Сколько часов в генте компилируется пакет ООО?

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

Linfan · 14-08-10 21:53:02

MOP3E пишет:

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

Вот тут ты МОРЗЕ категорически не прав. Библиотеки дотнета в платформенно-независимом байткоде. Оптимизация происходит в момент исполнения (Just-in-runtime). Поэтому дотнет-приложения и подтормаживают при старте/вызове дополнительных библиотек в рантайме. И памяти хавают весьма прилично.

petrun · 14-08-10 21:56:03

MOP3E пишет:

Путём раздачи исходников? Сколько часов в генте компилируется пакет ООО?

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

Linfan · 14-08-10 22:02:47

Кстати, порылся по MSDN по поводу хваленой JIT оптимизации, и выясняется, что МС эти данные принципиально не публикует, ограничиваясь лишь устной декларацией про крутизну и навороченность.
social.msdn.microsoft.com/forums/en-us/ … E86D78EA5F

Как показывают интелловские сравнения (не МС) под AMD оптимизация хреновая (если ваще есть) т.к. интеллячие процы получают ~10% преимущество:
www.compdoc.ru/comp/cpu/compare_webpril/

Поэтому про "всеобъемлещую оптимизацию" в дотнете как радостно провозглашал Арманчик, можно забыть. Это больше маркетинговый ход. Она выборочная и не для всех процессоров. В отличии от нативных компайлеров.

Отредактировано Linfan (14-08-10 22:05:09)

MOP3E · 14-08-10 22:05:31

petrun пишет:

с пакетными ситемами можно давать машине заранее скомпиленый бинарник

Благополучно вернулись к

MOP3E пишет:

несколько экзешников для каждого типа процессоров

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

petrun · 14-08-10 22:13:32

MOP3E пишет:

Потому что .Net Framework - это возможность увеличить скорость работы программ

В общем случае - нет, vm никогда не будет быстрее.У классического компилятора простор для оптимизации куда шире.
Вы про профилировку слышали?А про элементы суперкомпиляции в современных компиляторах(особенно в в функциональщине)?А про оптимизацию времени линковки?
Это если не брать обычные, но затратные техники.

MOP3E пишет:

достичь (в идеале) абсолютной мультиплатформенности без открытия исходных текстов.

Даже не говоря о том, что байт-код прекрасно декомпилируется, ожидать это от МС платформы - смешно.
Да и было уже все это.

MOP3E пишет:

Благополучно вернулись к
MOP3E wrote:
несколько экзешников для каждого типа процессоров

Если это прозрачно для пользователя, то какая разница?Быстрее ведь.

Отредактировано petrun (14-08-10 22:14:11)

Форум StopLinux

Объявление

#26 14-08-10 18:41:21

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#27 14-08-10 19:04:02

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#28 14-08-10 19:14:16

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#29 14-08-10 19:27:31

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#30 14-08-10 19:41:34

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#31 14-08-10 19:46:23

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#32 14-08-10 20:23:21

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#33 14-08-10 20:33:23

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#34 14-08-10 20:36:51

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#35 14-08-10 20:37:13

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#36 14-08-10 20:39:11

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#37 14-08-10 20:45:35

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#38 14-08-10 21:00:59

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#39 14-08-10 21:13:17

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#40 14-08-10 21:29:17

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#41 14-08-10 21:35:04

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#42 14-08-10 21:39:17

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#43 14-08-10 21:40:06

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#44 14-08-10 21:50:08

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#45 14-08-10 21:51:31

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#46 14-08-10 21:53:02

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#47 14-08-10 21:56:03

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#48 14-08-10 22:02:47

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#49 14-08-10 22:05:31

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

#50 14-08-10 22:13:32

Re: Renesas Electronics Corp поддерживает .NET Micro Framework

Подвал форума