Здравствуйте, Erop, Вы писали:
E>Я наверное как-то непонятно сказал. Что от этого улучшится? Что станет быстрее, дешевле, легче, модифицируемие и т. д.?
Всё. Быстрее, дешевле, легче. И создание железа, и софта, и ОС.
E>Для Юникса -- да, для железа под Юникс ни разу ни Си. Так как были на том же железе ещё и кобол и фортран крайне популярны, например. Ещё Ада где-то по ящикам обтиралась, кстати...
Не придирайся к словам. Если бы проц умел испольнять Си, Юниксу хуже от этого стало бы?
__>>Для иФона ОбджективСи. E>А разве туда нативный код нельзя вставлять? Кроме того, objC -- это всего лишь интерфейс API, и только. Внутри всё те же процы, и всё тот же С, если посмотреть уровнем повыше
И что что можно? А ты в асемблер можеш вставить внутреннюю команду АМД? И как, сильно мешает жить?
__>>Для Андроида — джава. E>А они ещё не сдались на предмет нативных вставок?
То же самое что и выше.
__>>Если процессор умеет нативно выполнять системный язык — это просто отлично. E>Воот я вижу один очевидный недостаток, по крайней мере. Если ты, грубо говоря, сделаешь проц, который интерпретирует байткод, то ты остановишь прогресс этого твоего "системного языка". И конкурирующие платформы тебя быстренько скушают...
Джаву уже съели?
E>Так что список минусов уже открыт. А плюсы-то в чём?
Да во всём плюсы. Если софт пишется на языке который не нативный для ОС и железа — вот это реальные минусы.
Здравствуйте, master_of_shadows, Вы писали:
__>Всё. Быстрее, дешевле, легче.
Что-то как-то мы друг друга похоже не понимаем совсем.
Давай по пунктам разберём?
__>И создание железа,
Создание железа, IMHO, только затруднится, так как надо реализовать в железе виртуальную машину для защищённого кода, GC и много всего ещё. При этом ещё придётся зафиксировать байткод, так что следующую версию проца придётся втискивать в прокрустово ложе старого стандарта...
так что для разработчиков железа, как раз, не понятно откуда облегчение-то придёт.
__>и софта
Опять же не понятно. Не пофигу ли софту JIT там или проц? Наоборот, JIT может прогрессировать быстрее, и иметь инсталляционную базу намного шире, чем конкретная модель проца... Так что для разработчиков ПО либо пофиг, либо минус. __>, и ОС.
Про ОС вообще интересно. Сейчас как ОС на экзотическое железо делают? Ядро линуха или фряхи адаптируют и всё в ажуре. А если надо будет управляемую ОС с нуля писать, то это намного дольше и дороже...
__>Не придирайся к словам. Если бы проц умел испольнять Си, Юниксу хуже от этого стало бы?
Я опять тебя не понимаю. Как ты себе представляешь выделенное?
Типа в проц закачивают исходники С? Если так, то юникс бы никогда не заработал. А если не так, то я не совсем понимаю как...
__>И что что можно? А ты в асемблер можеш вставить внутреннюю команду АМД? И как, сильно мешает жить?
Так это тоже команда ассемблера получается. Просто другого. И всё это входит в "системный язык", выходит...
__>>>Если процессор умеет нативно выполнять системный язык — это просто отлично. E>>Воот я вижу один очевидный недостаток, по крайней мере. Если ты, грубо говоря, сделаешь проц, который интерпретирует байткод, то ты остановишь прогресс этого твоего "системного языка". И конкурирующие платформы тебя быстренько скушают...
__>Джаву уже съели?
В смысле? Я опять тебя не понимаю? Ты имеешь в виду какой-то проц, который явский байткод умеет интерпретировать? IMHO, это просто невозможно... Так что что именно должны были съесть?
__>Да во всём плюсы. Если софт пишется на языке который не нативный для ОС и железа — вот это реальные минусы.
А в чём минусы? Компиляторы, вроде как, давно уже хорошие писать научились...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Для чего она лучшая? Почему лучшая? Чем JIT или компилятор снаружи процессора хуже микрокода внутри?..
Программный JIT лучше. Во-первых его легко обновить, во-вторых ему доступно значительно больше памяти чем потенциально внутри процессора, и, в случае прекомпиляции, еще и на порядки больше времени. Единственный потенциальный плюс железного JIT (именно JIT, никто байткод напрямую на железе не выполняет и выполнять не будет) это существенно лучшие показатели ужора электричества.
Здравствуйте, Erop, Вы писали:
__>>И создание железа, E>Создание железа, IMHO, только затруднится, так как надо реализовать в железе виртуальную машину для защищённого кода, GC и много всего ещё.
GC в процессоре вообще бессмысленно делать, ничего не даст. Можно сделать низкоуровневые аппаратные хелперы для него. Например неблокирующие счетчики или железную транзакционную память.
__>>Джаву уже съели? E>В смысле? Я опять тебя не понимаю? Ты имеешь в виду какой-то проц, который явский байткод умеет интерпретировать? IMHO, это просто невозможно...
Здравствуйте, Ночной Смотрящий, Вы писали:
E>>В смысле? Я опять тебя не понимаю? Ты имеешь в виду какой-то проц, который явский байткод умеет интерпретировать? IMHO, это просто невозможно...
НС>http://en.wikipedia.org/wiki/Jazelle
А как оно выполняет функциональный вызов-то?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
E>>Так что список минусов уже открыт. А плюсы-то в чём?
__>Да во всём плюсы. Если софт пишется на языке который не нативный для ОС и железа — вот это реальные минусы.
Да нет там никаких минусов Сейчас единственными «ненативной» для проца является всякая функциональщина, имхо. Всякая императивщина аккуратно ложится на архитетуру проца, и все счастливы.
Более того, какой именно язык, нативный для ОС, ты будешь класть в процессор? С? С++? Prolog? (Тут на форуме пробегала инфа о том, что Винда использует пролог для определения набора драйверов, которые должны ставиться в систему)
А что делать не с ОСью, а сприложениями в этой ОСи? Со всеми этими дотнетами, джавами, сями, эрлангами, рубями, питонами и т.п.? Или делаем только один убер-язык, а остальные предаем анафеме?
__>>Джаву уже съели? E>В смысле? Я опять тебя не понимаю? Ты имеешь в виду какой-то проц, который явский байткод умеет интерпретировать? IMHO, это просто невозможно... Так что что именно должны были съесть?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
M>А что делать не с ОСью, а сприложениями в этой ОСи? Со всеми этими дотнетами, джавами, сями, эрлангами, рубями, питонами и т.п.? Или делаем только один убер-язык, а остальные предаем анафеме?
Предложившего этот путь быстрее самого предадут анафеме.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
E__>>Предложившего этот путь быстрее самого предадут анафеме.
__>Раскажите это Эпл.
А что ей рассказывать? Байткод их процессоры точно не выполняют. Даже в случае с бойкотом сторонних языков, который уже снят, на айфоне работал Objective-C и Javascript, что уже никак нельзя считать одним языком
Здравствуйте, Mamut, Вы писали:
E__>>>Предложившего этот путь быстрее самого предадут анафеме.
__>>Раскажите это Эпл.
M>А что ей рассказывать? Байткод их процессоры точно не выполняют. Даже в случае с бойкотом сторонних языков, который уже снят, на айфоне работал Objective-C и Javascript, что уже никак нельзя считать одним языком
У эппла остались их процессоры?
Расскажите это маньякам, которые запустили на айфоне Убунту.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>> Посмотри рефлектором код лейаута различных панелей.
НС>Я тебе еще раз повторяю — рендеринг и базовый лейаут выполняется асинхронным нативным движком. А то, что в различных панелях видно рефлектором, это уже не низкоуровневый лейаут, про который ты писал. НС>http://blogs.msdn.com/b/greg_schechter/archive/2006/06/09/623566.aspx
Наверно, стоило уточнять, что ты имел ввиду WPF 4.0, сэкономили бы время на пару итераций. Да, там есть некая wpfgfx_v0400.dll, которая используется там, где до этого (WPF в 3.0-3.5) были непосредственные вызовы COM-АПИ DirectX.
И все равно, извини, отдает полным непониманием происходящего. Да, DirectX был нативный, и сейчас упомянутая более высокоуровневая обертка "wpfgfx" — тоже нативная... Однако, размещение визуальных элементов в "виртуальном" буфере страницы осуществляется по прежнему наследниками элемента Panel (Grid, StackPanel, WrapPanel). И оно по-прежнему 100% managed. Т.е. значения всех bounds вычисляются managed по всему visual tree, сами эти изменения попадают в нативную обертку, которая строит сцену при рендеринге, и т.д. Но это не принципиально, ибо затраты на непосредственное отображение на современных компах не столь значительны (это я из опыта использования 100% Java RDP клиентов). А вот с форматированием, когда счет элементам идет на многие-многие тысячи и есть многоуровневые вложения (взять для примера достаточно большой Word-документ) — это требует определенной шустрости, чтобы не ждать несколько секунд после применения нового стиля к документу, пока оно там "утрясется".
В общем, именно этот момент пока критичный. Не зря браузеры соревнуются по быстродействию именно в этом плане, т.к. операция форматирования, при достаточно сложном visual tree, порой нетривиальная, итеративная, триггерящая многократные проходы.
Я предполагал, что и так достаточно очевидно, на чем именно использование WPF дает преимущество в плане быстродействия — это там, где удается задействовать ресурсы видеоускорителя. Например, из значительных перемен я обнаружил отказ от старых BitmapEffects, которые ранее выглядели скорее как эксперимент, случайно попавший в продакшн. Новые Effects действительно находятся там где надо, и делают свою работу эффективно. Вот это и есть ниша WPF — "богатое" графическое отображение. Но в плане вычисления расположения элементов, никакие видеоускорители, увы, пока что не помощники.
Возможно, что когда-нить задействуют нечто вроде CUDA в WPF, и все станет иначе. Но это не в обозримом будущем, ибо 4.0 вышел недавно, и ему надо прожить достаточно долгую жизнь, чтобы окупить вложения в него.
Здравствуйте, vdimas, Вы писали:
V>Наверно, стоило уточнять, что ты имел ввиду WPF 4.0
Опять какие то фантазии. Я имел в виду WPF 1.0. 2006 в url ссылки знаешь что означает?
V>И все равно, извини, отдает полным непониманием происходящего.
Это точно. Вопрос в том, с чей стороны.
V>В общем, именно этот момент пока критичный. Не зря браузеры соревнуются по быстродействию именно в этом плане, т.к. операция форматирования, при достаточно сложном visual tree, порой нетривиальная, итеративная, триггерящая многократные проходы.
Ага, именно поэтому в IE 9 сделали упор на аппаратную акселерацию рендеринга.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Программный JIT лучше. Во-первых его легко обновить, во-вторых ему доступно значительно больше памяти чем потенциально внутри процессора, и, в случае прекомпиляции, еще и на порядки больше времени. Единственный потенциальный плюс железного JIT (именно JIT, никто байткод напрямую на железе не выполняет и выполнять не будет) это существенно лучшие показатели ужора электричества.
Да как раз байт-код стек-ориентированных VM в железе можно исполнять напрямую, без JIT, из-за его простоты. Если брать конкретный байткод .Net VM, то он не пригоден для непосредственного исполнения железным процом в любом случае, хоть с джитом, хоть без, из-за способа кодирования вызовов, определения размеров объектов, наследования и прочей мета-информации, по которой ни один проц не сможет работать. Но, можно сделать байт-код с минимальным отличием, чтобы эти отличия стоили не дороже, чем работа обычного загрузчика нативного исполняемого файла в современных ОС. И такой бай-код в "реальных" адресах можно было бы исполнять напрямую, без микрокода, ввиду его простоты.
Здравствуйте, vdimas, Вы писали:
V>Да как раз байт-код стек-ориентированных VM в железе можно исполнять напрямую, без JIT
И без оптимизации. Только это интерпретирующее гавно никому не нужно будет.
V>, из-за его простоты. Если брать конкретный байткод .Net VM, то он не пригоден для непосредственного исполнения железным процом в любом случае, хоть с джитом, хоть без, из-за способа кодирования вызовов
Это мелочь, ХЗ чего ты за нее уцепился. Трансляции в микрокод это не помешает.
Здравствуйте, vdimas, Вы писали:
V>Наверно, стоило уточнять, что ты имел ввиду WPF 4.0, сэкономили бы время на пару итераций. Да, там есть некая wpfgfx_v0400.dll, которая используется там, где до этого (WPF в 3.0-3.5) были непосредственные вызовы COM-АПИ DirectX.
Да ладно. Раньше WPF точно также не работал с DirectX напрямую, а использовал milcore.dll.
V>И все равно, извини, отдает полным непониманием происходящего. Да, DirectX был нативный, и сейчас упомянутая более высокоуровневая обертка "wpfgfx" — тоже нативная... Однако, размещение визуальных элементов в "виртуальном" буфере страницы осуществляется по прежнему наследниками элемента Panel (Grid, StackPanel, WrapPanel). И оно по-прежнему 100% managed. Т.е. значения всех bounds вычисляются managed по всему visual tree, сами эти изменения попадают в нативную обертку, которая строит сцену при рендеринге, и т.д. Но это не принципиально, ибо затраты на непосредственное отображение на современных компах не столь значительны (это я из опыта использования 100% Java RDP клиентов). А вот с форматированием, когда счет элементам идет на многие-многие тысячи и есть многоуровневые вложения (взять для примера достаточно большой Word-документ) — это требует определенной шустрости, чтобы не ждать несколько секунд после применения нового стиля к документу, пока оно там "утрясется".
Да что ты привязался к этим панелям В них же простейший код! Тормоза начинаются там, где нужно считать место для геометрий и глифов, в которые в итоге выливаются все элементы. Этим занимается unmanaged.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Опять какие то фантазии. Я имел в виду WPF 1.0. 2006 в url ссылки знаешь что означает?
Ну там вообще все "деревянно", managed 100% лейаут и построение сцены путем непосредственного вызова знакомых ф-ий DirectX. Для далеких от IT, можно сказать, что рендеринг нативный. Но блин, он всегда нативный в конечном итоге, даже в windows.Forms. Короче, филосовская часть вопроса меня не интересует вообще, я достаточно по времени и на достаточно низком уровне работал с DicrectX, так что неплохо представляю себе происходящее.
V>>И все равно, извини, отдает полным непониманием происходящего.
НС>Это точно. Вопрос в том, с чей стороны.
Давай вести разговор двух взрослых дядь более предметно. Если у тебя действительно есть желание, и ты не поленишься вооружишься Рефлектором, то мне не трудно показать, где именно происходят вычисления координат элементов при каждом событии обновления лейаута. ИМХО, там никакой недоступной для понимания магии, т.е. можно обойтись без "чужих мнений" и довериться собственным глазам.
Здравствуйте, MxMsk, Вы писали:
MM>Да ладно. Раньше WPF точно также не работал с DirectX напрямую, а использовал milcore.dll.
Все структуры и константы, описывающие примитивы, преобразования и т.д. — напрямую из DirectX. А прослойка эта была связана скорее всего в несовместимостью самого DirectX м/у версиями 9.0 и теми, что выше. У меня и в нативной части приложения был некий слой-абстракция, обеспечивающий единый АПИ для разных версий DirectX.
MM>Да что ты привязался к этим панелям В них же простейший код! Тормоза начинаются там, где нужно считать место для геометрий и глифов, в которые в итоге выливаются все элементы. Этим занимается unmanaged.
Это он на первый взгляд простейший, но смотри далее, что скрывается за каждым обновлением. Фишка форматирования в том, что оно может сбрасываться и начинаться заново, и так до полного "утрясания". Это весьма нагрузочный код для большого кол-ва элементов и большой их вложенности. И managed-тормоза тут связаны с медленным проходам по массивам в managed. Я уже приводил тут данные, что числодробильные алгоритмы работают в managed в 3-5 раз медленнее. Что есть числодробильные алгоритмы? Это обычно довольно примитивные вычисления на каждом шаге цикла, но при большом кол-ве итераций. Медленно дотнет итерирует, се ля ви.
Здравствуйте, vdimas, Вы писали:
V>Все структуры и константы, описывающие примитивы, преобразования и т.д. — напрямую из DirectX. А прослойка эта была связана скорее всего в несовместимостью самого DirectX м/у версиями 9.0 и теми, что выше.
Опять фантазии. Счастливо оставаться со своими заблуждениями, я пас. Реальное положение дел тебе все равно не интересно.
Сейчас единственными «ненативной» для проца является всякая функциональщина, имхо. Всякая императивщина аккуратно ложится на архитетуру проца, и все счастливы.
