Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Малич Юрий, Вы писали:
МЮ>>Пример из жизни. Распаковщик 7z, написанный на c#, работает на 30-50% медленне, чем откомпилированный с++.
AVK>А ты попробуй на МС++ откомпилировать.
Не понял. Исходники С++ итак были откомпилированы под MSVC 6 и MSVC 2003. Или имелось ввиду откомпилировать исходники С++ под Managed C++? Последнее тяжеловато будет. Там много классов и всё это добро в управляемую кучу переносить? А смысл?
"Малич Юрий" <5722@news.rsdn.ru> wrote in message news:608920@news.rsdn.ru...
> Не понял. Исходники С++ итак были откомпилированы под MSVC 6 и MSVC 2003. Или имелось ввиду откомпилировать исходники С++ под Managed C++? Последнее тяжеловато будет. Там много классов и всё это добро в управляемую кучу переносить? А смысл?
Вероятно, он имел в виду не использовать управляемый расширения, а просто скомпилировать с ключиком /clr
"Малич Юрий" <5722@news.rsdn.ru> wrote in message news:608945@news.rsdn.ru...
> А в чём практическая ценность такого теста? На сколько я понимаю все функции не __gc классов как были в x86 коде так в нём и останутся.
Нет. Весь твой код скомпилируется в МСИЛ. Для того, "остались" в x86 нужно будет использовать специальную прагму — #pragma unmanaged. По умолчанию код скомпилированный с /clr рассматривается как managed.
M>>Как уже сказал AVK, такие оптимизации работают только внутри одной сборки. А на уровне JIT можно производить намного более крутые оптимизации, так как информации куда как больше.
S> К сожалению не всегда.
Что не всегда?
S> Те же дженерики, например компараторы могут (и должны) инлайнится, тогда их скорость достигнет шаблонных, пусть и с ограничениями. S> А вот раскрыть проинлайнить методы возможно и в IL. Хотя не особо то это и нужно, но если писать драйвера то ....
M>>Как уже сказал AVK, такие оптимизации работают только внутри одной сборки. А на уровне JIT можно производить намного более крутые оптимизации, так как информации куда как больше.
A>теоретически только... никто между сборками глобальных оптимизаций делать не будет... A>секурити и другие прибамбасы начнут сильно логику путать... потому никто это делать не будет.
Кгм. Извини, но, кажется, у тебя данные какие-то неверные. Мягко говоря. Говоря точнее, с потолка взятые. Ну или того хуже — с компьюленты, ZDNet и т.п.
M>>JIT — такая область, где оптимизировать можно многое. Особенно с поддержкой этого дела на уровне ОС.
A>а смысл?!. все это будет из разряда отмазок — поставьте себе памяти побольше и процессор помощнее...
Что-то я не понял логической связи. При чём к оптимизации JIT больший объём памяти? Какие это даёт отмазки?
A>что-то конечно поправят, но в основном массового пересмотра и доработки не будет. им надо технологию вперед двигать, а не вылизывать код... потому забъют они на оптимизации крутые...
А, ну, тебе лучше знать, конечно, что там Микрософт планирует.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Нет. Весь твой код скомпилируется в МСИЛ. Для того, "остались" в x86 нужно будет использовать специальную прагму — #pragma unmanaged. По умолчанию код скомпилированный с /clr рассматривается как managed.
сборка успехом не закончилась. В исходниках проекта 7z файл "aeskey.c" скомпилировался, но
Alone fatal error LNK1284: metadata inconsistent with COFF symbol table: symbol '?aes_enc_key@@$$J212YGIQBEIQAUaes_ctx@@@Z' (0A000037) mapped to '?aes_enc_key@@$$J212YGIPBEIPAUaes_ctx@@@Z' (06000001) in aeskey.obj
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alku, Вы писали:
A>>теоретически только... никто между сборками глобальных оптимизаций делать не будет...
VD>Уже делают. Джиту нет разницы другая это сборка или нет. Именно по этому в дотнете нет разницы где лежит используемый код, а для С++ очень даже важно.
A>>секурити и другие прибамбасы начнут сильно логику путать... потому никто это делать не будет.
VD>Нет. Все вопросы защиты отрабатываются на статическом анализе. А оптимизации не имют права изменять семантику кода.
вот про это поподробней плиз... это что помечают методы какие могут быть инлайнами или не могут, где какие дополнителоьные проверки втыкать или что?! про то что и как делает компайлер довольно мало информации... или я плохо искал
A>>а смысл?!. все это будет из разряда отмазок — поставьте себе памяти побольше и процессор помощнее... VD>А тогда что вопросы задешь? Как грится... хавай как есть.
"...не хочу есть дело, хочу есть крем-брюле..." (с)
A>>что-то конечно поправят, но в основном массового пересмотра и доработки не будет. им надо технологию вперед двигать, а не вылизывать код... потому забъют они на оптимизации крутые...
VD>Ну, я тебе тут рядом ссылку дал... Погляди там есть презентаха. В ней как раз рассказывается об оптимизации при инсталляции. Вот там можно и крутые оптимизации применить. Иначе тормоза будут из-за самого оптимизатора.
Ресерч в основном занимаеться двиганием найки и разработкой новшеств...
но до реальных продуктов они очень редко опускаються
из-за этого макрософт начал очень серьезно спонсировать разработки, которые он потом могет подхватить и переработать — за это им спасибо... если бы мне за такое деньги платили тоже бы двигал "науку"
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Здравствуйте, AndrewVK, Вы писали:
AVK>>Практика показывает что ни о каких порядках речи не идет — в худшем случае процентов 20.
МЮ>Пример из жизни. Распаковщик 7z, написанный на c#, работает на 30-50% медленне, чем откомпилированный с++. Причём я изучал самые работающие c# функции в профайлере, жирок срезать никак не получается. .
и я про тоже... претензии у НЕТ как на единственную среду разработки после 2005 года... на сегодняшний момент выпущенное ядро готово частично для офис апликаций и достаточно сильно готово для создания веб-сервисов... технологий в ядре немеряно, фич немеряно, но из-за такого объема очень страдает общая "вылизаность" кода... местами просто жуть на сколько в лоб решения применяються... яркий пример SortedList... за счет объектности и защещенности кода "просрали" на первых парах наработки с++ — в частности очень быстрые колекции и алгоритмы... многие вещи теперь приходиться писать чуть ли не с нуля...
в крайности впадать не буду — технология нравиться, а вот уровень ее развития пока не очень... 2005-2006 покажет на сколько макрософт смогла повысить скорост и качество NET
Здравствуйте, mihailik, Вы писали:
M>>>Как уже сказал AVK, такие оптимизации работают только внутри одной сборки. А на уровне JIT можно производить намного более крутые оптимизации, так как информации куда как больше.
A>>теоретически только... никто между сборками глобальных оптимизаций делать не будет... A>>секурити и другие прибамбасы начнут сильно логику путать... потому никто это делать не будет.
M>Кгм. Извини, но, кажется, у тебя данные какие-то неверные. Мягко говоря. Говоря точнее, с потолка взятые. Ну или того хуже — с компьюленты, ZDNet и т.п.
за наличие дополнительной информации прийдеться расплачивать либо скоростью либо памятью... а скорее всего и тем и другим.
сборки наверное не просто так придумали... с какой стати JIT лазить по сборкам и выгребать что и куда лучше заинлайнить мона? ему должно быть проще jump на функцую сделать, чем ее инлайнить... на макрософте тоже люди работают, и они перед собой трудновыполнимых задач ставить не любят потому и решения не будут сильно изщренными, до тех пор пока это не станет критичным...
а так должно получаться что JIT поднял сборки заинлайнил из них все что нужно и может после этого их выгружать?!
да — это может вписываться в схему компиляции, но не в схему оптимизации... так чтобы прога была оптимизирована по скорости надо всю эту оптимизацию на компайлер выносить, а не на JIT...
M>>>JIT — такая область, где оптимизировать можно многое. Особенно с поддержкой этого дела на уровне ОС.
область хорошая, только я сомневаюсь что выгодно на уровне кернела заниматься оптимизацией кода, лучше оптимизацию проводить вообще до запуска проги... а поддержака на уровне OC скорее всего сведеться до переноса часто вызываемых функций на уровень ядра или ихним внесением в API винды.
A>>а смысл?!. все это будет из разряда отмазок — поставьте себе памяти побольше и процессор помощнее...
M>Что-то я не понял логической связи. При чём к оптимизации JIT больший объём памяти? Какие это даёт отмазки?
за все надо платить, за NET технологию приходиться расплачиваться потреблением памяти и скоростью пока только запуска...
A>>что-то конечно поправят, но в основном массового пересмотра и доработки не будет. им надо технологию вперед двигать, а не вылизывать код... потому забъют они на оптимизации крутые...
M>А, ну, тебе лучше знать, конечно, что там Микрософт планирует.
предпологать ни кто не мешает но с точки зрения бизнеса оно так выглядит...
S>> Те же дженерики, например компараторы могут (и должны) инлайнится, тогда их скорость достигнет шаблонных, пусть и с ограничениями. S>> А вот раскрыть проинлайнить методы возможно и в IL. Хотя не особо то это и нужно, но если писать драйвера то ....
M>Драйвера на IL? И как ты себе это представляешь?
Легко при загрузке OC будут компилироваться под процессор. Хотя Intel и собирается сдлелать Athlon 64 совместимый процессор но различия могут быть большими, а JIT компиляторы каждая компания под свои процессоры сделать могут.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
M>>Драйвера на IL? И как ты себе это представляешь? S> Легко при загрузке OC будут компилироваться под процессор. Хотя Intel и собирается сдлелать Athlon 64 совместимый процессор но различия могут быть большими,
Вообще говоря различия незначительные.
— Athlon 64 не поддерживает SSE3 в настоящей ревизии (обещают в следующей)
— Athlon 64 не поддерживает HyperThtreading, а следовательно команды MONITOR и MWAIT — и не будет, так как емеу он не нужен
— IA32E не предусматривает поддрежку 3dnow — так и JIT её пока ещё не использует.
— у Интела есть проблема с инструкциями BSF/BSR — when source is 0 & operand size is 32:In 64-bit mode, the processor sets ZF, and the upper 32 bits of the destination are undefined.
S> а JIT компиляторы каждая компания под свои процессоры сделать могут.
x86-64: противостояние титанов выходит на новый уровень?
Последние дни оказались довольно жаркими для различных сетевых СМИ, и главной причиной этого оживления стали новости с IDF (Intel Developer Forum, «форум Intel для разработчиков»), проходящей сейчас в Сан-Франциско. Как и ожидалось, компания Intel продемонстрировала технологию, использование которой сделает возможным производство процессоров, на аппаратном уровне совместимых как с 32-х, так и с 64-х битными наборами инструкций. Иными словами, подтвердились слухи о проекте Yamhill, недавно переименованном в «Clackamas Technology» (именно так называется новая технология, и именно это скрывалось за аббревиатурой «CT»), главной целью которого изначально являлся выпуск Intel процессора с поддержкой расширенного набора инструкций x86-64 (Intel назвала набор инструкций IA-32E, что расшифровывается как «IA-32 Extended Technology»).
Основой Clockamas Technology является новый ALU (Arithmetic Logic Unit, устройство выполнения операций с целыми числами), который может работать и в 32-х, и в 64-х битном режиме. По словам Intel, в ядре x86 процессоров Intel с 64-х битными расширениями устройство ALU, новый прототип изготовлен по 90 нм техпроцессу и способен функционировать с частотой 4 ГГц в 64-х битном режиме и 7 ГГц в 32-х битном, ускорение работы составляет около 20%, а уменьшение энергопотребления – целых 56%. Представители Intel заявляют также, что преимущества нового ALU будут использованы в том числе более поздних процессорах Prescott (появление таких процессоров ожидается в конце этого года), несмотря на то что, вполне вероятно, что физически этот самый ALU уже включен во все новые процессоры Intel, просто он соответствующим образом не настроен.
Вопрос о полной совместимости AMD64 с IA-32E ещё рассматривается, но многие эксперты уже высказываются в пользу того, что «если программа запускается на одной из этих архитектур, она, как правило, будет запускаться и на другой». Для «ввода в строй» своего нового набор инструкций Intel потребуется способствовать обновлению BIOS материнских плат и пр. действий для его успешной поддержки на низком уровне, на уровне же приложений IA-32E имеет очень много общего с AMD64.
По мнению аналитиков, подобная «схожесть, граничащая с идентичностью» двух архитектур объяснима с финансовой точки зрения – Intel было невыгодно «проталкивать» принципиально отличную от AMD64 архитектуру – слишком велики были бы издержки при отвоевывании позиций, занятых (и занимаемых) AMD на рынке (тем более что сам факт разработки 64-х битных процессоров в том числе для рынка серверов является ударом по позициям другого продукта Intel – семейства процессоров Itanium – и материальные потери компании вследствие этого неизбежны). В итоге, нет необходимости описывать какие-то принципиальные новшества IA-32E – т.к. их попросту нет, архитектура основана на тех же принципах, что и AMD64.
С точки зрения патентов, занятая Intel позиция достаточно правомерна – недавно всплыли подробности соглашения по перекрестному доступу к патентам, подписанного компаниями в 1995 году. Не вдаваясь в подробности, в применении к сегодняшним событиям смысл соглашения заключается в следующем: Intel беспрепятственно может использовать наработки AMD в области строения процессоров. Тем самым, сложившуюся сегодня ситуацию можно понимать по-разному: с одной стороны, Intel, возможно, банально скопировала AMD64 для использования её в своих процессорах. С другой же, учитывая заметно бОльшую долю рынка процессоров, шаги Intel в направлении внедрения 64-х битной архитектуры «в массы», да ещё совместимой с AMD64, можно назвать мощным подспорьем для развития самой AMD64, и, как следствие, укрепление позиций AMD – ведь тогда отпадает проблема борьбы за продвижение своей технологии, несовместимой с конкурирующей технологией.
Как стало известно, первым носителем Clockamas Technology станет чип Nocona, предназначенный для следующего поколения процессоров семейства Xeon DP (Dual Processor – т.е. предназначенные для двухпроцессорных систем). Pentium Xeon с разъемом LGA775 (Socket T) на основе чипа Nocona будут иметь рабочую частоту 2.8-3.6 ГГц, 1 МБ кэша второго уровня, 800 МГц FSB, а также будут обладать поддержкой набора инструкций SSE3. Ожидается, что переход Xeon DP на 800 МГц шину QPB (Quad Pumped Bus) с более «узкой» 533 МГц, в совокупности с другими качественными улучшениями (удвоенный кэш первого уровня, переход на 90 нм техпроцесс, использование механизма предсказания условных переходов, применяемого в Prescott) позволят новому чипу сделать качественный скачок в плане производительности. Конечно, учитывая уровень тепловыделения сегодняшних Prescott, многих уже интересует аналогичный параметр новых Xeon – это все-таки не «настольный» продукт для энтузиастов, а «серверный» процессор, позиционируемый на корпоративного заказчика. Тем не менее, Intel уверяет, что её новая технология управления энергопотреблением, реализованная в Nocona, позволит успешно справиться с проблемой чрезмерного нагревания ядра – насколько все эти заявления окажутся близки к истине, покажет время.
По словам представителей компании, анонсирован Nocona будет во втором квартале 2004 года – причем некоторые крупные поставщики серверных систем, такие как HP, планируют представить свои продукты на основе новых процессоров Intel в первой половине этого года. В то же время, пока неясно, сколько времени потребуется Intel, чтобы доработать и утвердить инфраструктуру для наборов системной логики, материнских плат и др. стандарты, необходимые для успешного продвижения процессоров нового типа.
Далее, в конце 2004 – начале 2005 года ожидается появление процессоров Xeon с ядрами Potomac (семейство Xeon MP) и JayHawk (семейство Xeon DP). Оба чипа также будут производиться по 90 нм техпроцессу с использованием Clackamas Technology, равно как и иметь 800 МГц шину QPB, внушительный кэш второго и третьего уровней, и работать на тактовых частотах порядка 4 ГГц.
Особо отметим реакцию Microsoft: во-первых, одновременно с началом IDF 2004, выходит пресс-релиз, в котором сообщается о «полной поддержке новых 64-х битных процессоров Intel со стороны будущих версий MS Windows»; во-вторых, стало понятно, что такие системы, как Windows XP 64-Bit Edition и Windows Server 2003 for 64-Bit Extended Systems изначально планировались не просто как версии для работы с процессорами AMD64, но как операционные системы, поддерживающие обе альтернативные 64-х битные архитектуры. В итоге, выход 64-х битных версий Windows был перенесен с третьего квартала прошлого года на вторую половину 2004 года (напомним, что бета версии этих продуктов уже доступны, и сейчас долгожданные Windows-системы для 64-х битных компьютеров готовятся к выходу).
Итак, что же мы имеем в итоге? Во-первых, появления первых «массовых» продуктов, основанных на x86-64 процессорах производства Intel, стоит ожидать все ещё не ранее начала 2005 года (учитывая, что первые «настольные» IA-32E процессоры Intel обещает в конце 2004 года, а «серверные» Xeon DP поддерживают только двухпроцессорные системы, т.е. будут конкурировать в основном с Opteron 200-й серии). Во-вторых, несмотря на некоторые различия в аппаратном строении, 64-х битные архитектуры IA-32E и AMD64 практически идентичны с точки зрения ПО, что, в свете новых фактов, неудивительно и позволяет говорить об их совместимости на уровне приложений. В-третьих, в итоге сейчас мы имеем четкую тенденцию производителей и аппаратного, и программного обеспечения к относительно скорому переходу на единую 64-х битную платформу, призванную обеспечить лучшую производительность и удовлетворить возрастающие потребности конечных потребителей.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Здравствуйте, Serginio1, Вы писали:
S>>Дата: 2/19/04 | Время: 06:49 | Автор: Biffant |
МЮ>Судя по автору статейка с www.amdnow.ru. Думаю я её читал.
Ай прозорливый
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alku, Вы писали: VD>>Нет. Все вопросы защиты отрабатываются на статическом анализе. А оптимизации не имют права изменять семантику кода.
A>вот про это поподробней плиз... это что помечают методы какие могут быть инлайнами или не могут, где какие дополнителоьные проверки втыкать или что?!
Есть набор принципиально безопасных инструкций. Есть код верификации. Этот код позволяет определить, что тестируемый код не содержит опасных операторов. Есть даже утилита называется PEVerify.exe.
В дотнете так же можно ограничить некоторый код в использовани других сборок/классов. Так же есть механизм программной защиты, когда проверки делаются динамически на базе политики защиты.
Проверки осуществляется за долго до компиялции кода или встраиваеются джитом в машинный код (если речь идет о программируемой защите). Это позволяет гарантировать, что проходящий джит-компиляцию код полностью безопасен.
Ну, и любой инлайнинг ничего уже нарушить не может. Он еж делается на 100%-но надежном коде. Семантику (реально выполняемых кодом действий) инлайнинг и другие оптимизации не меняют. Стало быть они полностью безопасны и не могут вызвать проблем с защитой или надежностью.
A> про то что и как делает компайлер довольно мало информации... или я плохо искал
Ну, про это написано не мало. Поищи в МСДН-е на слова CAS и PEVerify.
A>Ресерч в основном занимаеться двиганием найки и разработкой новшеств... A>но до реальных продуктов они очень редко опускаються
Да? А про дженерики ты слышал? Да и вообще, ты ту страничку хорошо прочел? Там есть график с планами, по которым уже в следующем году эта хрень войдет в компиляторы от МС. Конечно как всегда на год задержат, но...
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alku, Вы писали:
A>за все надо платить, за NET технологию приходиться расплачиваться потреблением памяти и скоростью пока только запуска...
Согласись, что расплата памятью на сегодня — это самая дешевая расплата из всех, что можно представить.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Я программист, но хочу выразит несогласие как пользователь: пользователи очень не любят, когда программисты ленятся писать нормально работающий не тормозящий продукт и вместо этого говорят пользователям: "проапгрейдетесь-ка лучше за свои деньги". Я против такого подхода.
Ты просто не так говоришь. Надо говорить так:
Вы можете заплатить мне мои положенные 1000 баксов в месяц мне еще два раза (так как напишу эту программу я вам на два месяца медленнее), или купить на 200 баксов памяти. Выбор за вами...
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Пример из жизни. Распаковщик 7z, написанный на c#, работает на 30-50% медленне, чем откомпилированный с++. Причём я изучал самые работающие c# функции в профайлере, жирок срезать никак не получается. .
А исходники есть? Дал бы глянуть, может я бы тогда и подрезать общую прослойку. Правда 30 процентов — это уже мало на что влияет.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
но с точки зрения бизнеса оно так выглядит...
