Здравствуйте, vdimas, Вы писали:
С>>Клиент 1С 8.3+ точно так же запускается на терминальных серверах, и делается это повсеместно в городе Москве. V>Зачем?
Это общепринятая практика. Можете позвонить например в сеть автосервисов Вилгуд и спросить тамошнего техдиректора — "зачем?", в транспортные компании, в еще кучу мест — и везде будет одно и то же — серверы терминалов на Windows и либо тонкие клиенты, либо обычные десктопы.
Если вы хотите развить тему, то предлагаю вынести её в отдельный топик.
Re[27]: Что на самом деле произошло с Windows Vista
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, netch80, Вы писали:
V>>>Не Эльбрус, конечно, но круче архитектуры x64 в бесконечное кол-во раз. V>>>Смотришь, и глаз радуется. )) N>>Чему именно радуется? N>>VLIW? Так неуместно же для такой области.
V>Какой "такой"?
DRAM+кэш, OoO.
V>Современный комп/ноут/планшет — это платформа для аудио-видео приложений. V>Людям надо общаться, смотреть киношки, играть в игрушки. V>Сейчас даже обучающий софт очень и очень интерактивный. V>Или читалка "голосовая". V>Ну конечно, только такая мультимедийные архитектуры, как Эльбрус или IA64 максимально уместны.
IA64 мультимедийный — тянет на шутку дня. Ты точно не начал опять путать VLIW и SIMD?
V>А вот x86 максимально неуместна для таких приложений. V>Аудио-кодеки для интернета всё-равно же в CPU выполняются. V>Ты же работал с SIP когда-то, должен помнить. ))
А теперь непонятно, зачем смешивать VLIW не то с GPU, не то с выделенным видеопроцессором.
N>>Структура команды? Так после блока разбора переменность длины и всякие префиксы/суффиксы уже пофиг. А вот необходимость связывать в бандлы — мешает. V>Не вижу раскрытия темы.
Какое слово непонятно? (tm)
N>>128 регистров? Никто их столько не используют, 99.9% кода даже 32 не занимают.
V>Дык, есть команды обращения к текущему "окну" шириной в 8 или 32 регистра.
V>Как раз операционка может использовать одни регистры, прикладные приложения — другие, причем разные. V>Для текущего потока один раз выставляет адрес "окна" регистров. V>Оч удобно, как по мне. Можно добиться, чтобы было меньше свопа регистрового файла при переключении контекстов/потоков.
Ты, по-моему, начал рассказывать про SPARC.
У IA64 это всё значительно муторнее — никто не гарантирует полный круг больше стандартных 96, и штатно переключения контекстов требуют полного сохранения.
N>>Равнозначность регистров? Переименование решает эту проблему для большинства случаев.
V>Самая большая ложь, которую я вижу тут постоянно. )) V>Переименование регистров не решает проблему кучи лишних пар PUSH/POP, вызванных этой неуниверсальностью.
Есть какие-то реальные цифры количества этих "кучи лишних"?
А то в SysV AMD64, например, все неуниверсальные регистры входят в набор входных-выходных, а не callee-saved. А ещё есть группа scratch. Одного этого достаточно, чтобы не поверить.
V>>>И оно дешевле в пересчёте на транзистор при аналогичных объемах выпуска... N>>Дешевле что именно? V>Производительность к кол-ву транзисторов.
Есть где-то надёжные данные? Или только реклама от Intel? N>>Всё равно сейчас процентов 80 это кэш. V>Дык, с удвоенным кешем L0 и процы почти вдвое больше стоят. ))
Спасибо, кэп
N>>Дальше блоки предсказаний и разбора кода — ну, вот на последнем можно кое-как сэкономить. V>А это, батенька, у нас основной тепловыделитель, то бишь ограничитель частоты.
Ну вот потому я и говорю, что было что исправлять.
V>>>И тут AMD обломала весь кайф ))) N>>Да-да. Просто они сделали то, что можно было очень легко сделать прямо сейчас и получить плавный переход. V>Ну, для AMD речь стояла не о "плавном переходе", а о "жить или умереть". V>AMD пришлось продать все свои заводы в США и перейти на полностью заказной выпуск чипов. V>Но на эти деньги от проданных заводов они разработали и отладили новую архитектуру, т.е. банально выжили как экономическая единица.
Хм... ладно, сочту за оправдание.
N>>Причём воспользоваться минимальными усилиями в плане собственно компиляции (open64 вообще на коленке сляпан, а доработать gcc было легко V>Да как легко-то? Куча новых регистров (Rx), способ линковки и релокации символов другой совершенно. V>Всё это потребовало денег и людских ресурсов.
Ну ведь меньше, чем на IA64 с совершенно новой логикой всего?
V>Собсно, цель была дать возможности работать 32-разрядным приложениям в 64-битной ОС. Только научив свою архитектуру такой работе можно было выжить. Вот с этим моментом они справились просто на отлично. Согласись, что остальные моменты на фоне этого, главного, просто меркнут.
В краткосрочной перспективе (5 лет) — да. В большей — нет. Уже более 15.
Ладно, я таки закрываю это под воздействием аргументов про необходимость выживания.
N>>Причём, я уверен, если бы они подождали развития новых технологий ещё лет 20, а потом бы стали строить что-то подобное Itanium — у них бы получилось лучше. V>Ну, они украли дековскую Альфу и наш Эльбрус. Им надо было конвертировать наворованно в прибыль "сейчас", а не "потом". ))
Насчёт "украли" не буду влезать, но хочу заметить, что в IA64 что-то не видно специфичных особенностей ни Альфы, ни того старого Эльбруса.
N>>А так — попытка построения в 2000 на концепциях в лучшем случае начала 90-х. Если не раньше. V>Э-э-э... Давай уточним. Речь идёт о концепциях суперкомпьютеров, которые (концепции) решили применить в декстопном проце.
Это с чего это VLIW — концепция суперкомпьютера?
N>>2. Оно само разбирает цикл уже на этапе JIT или native generation. На уровне IL это цикл. V>Дык, на уровне исходника тоже цикл. Ничего не меняется, оптимизирующий компилятор должен этот IL преобразовать.
Ну а я говорил о записи в самом IL. Так что не то.
N>>Я бы скорее ожидал что-то в духе Agnerʼовского ForwardCom (где длина вектора, обработанного одной командой, в принципе не ограничена) — переложить это на конкретную ограниченную длину уже банально. Хотя и оно заточено под текущую схему концепций соотношения команды и кэша. V>Ну это когда оптимизатор совсем уж тупой. ))
А зачем на него водружать то, что способен сделать компилятор в IL, у которого всяко больше ресурсов, или вообще кодер?
The God is real, unless declared integer.
Re[23]: Что на самом деле произошло с Windows Vista
Здравствуйте, CreatorCray, Вы писали:
CC>Звучит помпезно, но хотелось бы таки увидеть твоё объяснение.
Чем меньше команд и проще структура языка, тем проще портировать.
CC>Это сильно зависит от того, что мы делаем.
Сам по себе язык переносим. Проблемы обычно бывают с crt, части которой опираются на ОС.
CC>Если задача просто перенести — да, но если надо ещё и получить максимум производительности на новой платформе то уже может понадобиться перепланировать алгоритмы и структуры данных.
Дык в этом и смысл наличия разнообразных архитектур — у каждой свои сильные стороны, потому для разных применений разные архитектуры будут оптимальными. Но работать при этом будет везде.
CC>Я правильно понимаю что у них в общем то одна архитектура?
В них мало общего, помимо названия. Более того, некоторые из них построены по архитектуре фон Неймана, другие — Гарварда.
CC>Почему тогда по производительности лучшие ARM еле еле дотягивают до Core M семейства?
Потому что ты вырезал из цитаты самый главный момент — про объединение с фабрикой FPGA. Совместно с ней ядра ARM рвут все десктопные процы как тузик грелку. Так что если интересуешься real-time high performance, но ничего про это не слышал (а судя по твоим ответам, так оно и есть), почитай про платформу Xilinx Zynq. На ней недавно появился кластер в Амазоне, так что тема активно набирает популярность. Ну и в мире DSP и sensor fusion они почти незаменимы, т.к. десктопные процы слишком "нежные", много жрут, но производительность при этом очень даже "так себе" как раз из-за отсутствия программируемой фабрики ПЛИС, которая позволяет реализовать наиболее "тяжёлую" часть аглоритма в железе.
CC>Мне интересно твоё мнение. Своё мне уже известно.
См. выше.
Здравствуйте, CreatorCray, Вы писали:
CC>Тебе шашечки или ехать?
Мне ехать. Причём желательно побыстрее. CC>Работает быстрее.
Даже не близко
CC>А какая там внутри неонка — да до лампочки. Предсказуемость поведения следующего поколения куда более ценно.
Это только для тех, кому не важна латентность. Иначе все десктопные процы сосут со страшной силой.
Здравствуйте, vdimas, Вы писали:
C>>А без разницы. Пока что нет систем с байт-кодом, которые систематически превосходили бы по производительности нативный код. V>Я получал сравнимую с нейтивной скорость, и?
В отдельных тестах, и то не всегда. Я даже не знаю какие байт-кодовые системы сейчас существуют, которые не обременены обязательной memory safety.
Sapienti sat!
Re[19]: Что на самом деле произошло с Windows Vista
Здравствуйте, netch80, Вы писали:
N>Ограничения же могут быть лицензионные — ставить компилятор уровня icc на каждую машину это... мнэээ... дорого.
Это вопрос в подходе к продажам. Если он будет практически искаропки везде, то цена будет порядка единиц долларов, уже включенных в цену ОС, а красноглазикам вообще бесплатно дадут.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, vdimas, Вы писали:
C>>Я точно помню, что и в более ранних DirectX можно было рисовать через GDI. Но оно было криво до невозможности всё, так как в Win98 оно автоматически блокировало поверхность, что вызывало взятие WIN16MUTEX. Т.е. любой вызов чего-то, кроме GDI-функций был чреват жёстким зависанием из-за не-реэнтерабельности API. V>Так не надо было рисовать в отображаемый в данный момент буфер и тем более в отображаемый GDI-буффер.
Варианты были — рисовать в заэкранный буфер, но это было 100% программной операцией, без всякого ускорения. Более того, в DD тоже ускорения рисования не было. При блокировке Win16Mutex'а драйвера не работали, так что GDI рисовал чисто программно.
C>>Потому оно использовалось разве что для вывода текста. V>Я его использовал для вывода видео, ApplicationSharing, графического редактора и т.д. и т.п.
На заблокированных поверхностях DD? Не верю.
Здравствуйте, vdimas, Вы писали:
V>Только представь на минуту, если бы MS стала развивать свой IE с теми расширениями CSS, которые вот только недавно появились.
Тогда это была бы не MS.
V>И еще выкатила бы реализацию Canvas и GLSL/WebGL? V>Да там взрывы от пуканов этих тормозящих нариков разнесли бы всё нахрен ))
Уже к 2003-му году IE6 был уродством на фоне Mozilla. Ещё через два года на IE6 остались только самые убогие.
Sapienti sat!
Re[19]: Что на самом деле произошло с Windows Vista
Здравствуйте, Ikemefula, Вы писали:
I>Байткод и есть компромисс.
По большому счёту современный код x86 и есть байт-код, ибо процессоры, способные напрямую выполнять команды из этого набора аппаратно, не выпускаются уже лет 20 (ЕМНИП последним таким процессором был Pentium MMX, хотя могу ошибаться с конкретной моделью, а проверять что-то лень).
Здравствуйте, alex_public, Вы писали:
_>В смысле? Ты не знаешь какую производительность выдаёт Clang? ) Конечно он чуть похуже чем gcc и icc, но не так чтобы очень существенно. Если хочется посмотреть при этом непосредственно на байт код, то разделение компиляции на отдельные этапы (в начале в байт-код, а потом в нативный) делается там просто лишним ключиком командной строки.
В том смысле, что хочется систему, где программы поставляются в байт-коде, а потом на конкретной архитектуре дособираются. Пока я вижу такое только в дотнете: поставил программу, и система там сама шуршит, нгенит, и при этом позволяет и сразу запустить, пусть чуть медленнее. А в идеале было бы, чтобы и ядро системы пересобиралось под конкретную архитектуру.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, IncremenTop, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
CS>>WinForms и "софта корпоративного" — нет вопросов. Но WPF и "софт корпоративный" как-то рядом не стоят...
IT>Ага, 70% корпоративного софта в Мск пишется на WPF, а не Winforms по вполне понятным причинам.
И что же они интересно пишут?
Я вот знаю только про ёжиков из Kaspersky Lab...
Re[3]: Что на самом деле произошло с Windows Vista
Здравствуйте, Ops, Вы писали:
C>>Можно добавить аннотации на функции, которые чуть выше критичных инлайновых. Ops>Ты вообще в курсе, сколько современные компиляторы инлайнят сами?
Не так много, как кажется сначала. Попробуй собрать с -O3 и -Os и сам посмотри на разницу.
Sapienti sat!
Re[21]: Что на самом деле произошло с Windows Vista
Здравствуйте, Ops, Вы писали:
C>>Не так много, как кажется сначала. Попробуй собрать с -O3 и -Os и сам посмотри на разницу. Ops>В чем, в размере?
Размере и скорости. Кстати, у меня в некоторых случаях -Os ещё и выигрывает по скорости.
Здравствуйте, c-smile, Вы писали:
CS>И что же они интересно пишут?
WPF позволяет написать тоже самое, что на Winforms. Даже в таком же дельфи-стиле — кнопка-обработчиквсемогутор. Почему отдельные любители Winforms на него кирпичами — загадка.
CS>Я вот знаю только про ёжиков из Kaspersky Lab...
А я знаю про CRM-ки до интерфейсов для управления боевыми роботами.
Здравствуйте, c-smile, Вы писали:
I>>Растр ни при чем. Растром в браузере можно рисовать не хуже чем в нативном виндовском апи.
CS>Хуже. Проблема в том что спецификация <canvas> требует чтобы рисовалось в bitmap. Соответственно там CPU rendering.
Даже такого рендеринга за глаза хватит, что бы рисовать быстро.
Re[22]: Что на самом деле произошло с Windows Vista
Здравствуйте, koandrew, Вы писали:
I>>Байткод и есть компромисс. K>По большому счёту современный код x86 и есть байт-код, ибо процессоры, способные напрямую выполнять команды из этого набора аппаратно, не выпускаются уже лет 20 (ЕМНИП последним таким процессором был Pentium MMX, хотя могу ошибаться с конкретной моделью, а проверять что-то лень).
Как работает процессор, дело десятое. x86 хоть и не выполняются напрямую, но обрабатывается специальными устройствами. То есть, тайминги не в твою пользу.
