Да, действительно неправда. Конечно, увеличение мощности (W) и есть (по определению) увеличение энергопотребления. Но производительность связана с мощностью не напрямую. Например, последние почти 5 лет TDP серверных процессоров почти не изменилась, а количество ядер на кристалле, кэша и производительность отдельных ядер существенно увеличились.
Lifestyle все-же поменьше, чем утилит, и то, что есть, как правило, хорошей оценки не заслуживает.
Программа для судей и количество программ таковы, что хочется быстро-быстро посмотреть, и поставить оценку. Простые программы получат лучшие баллы поэтому. Я тоже смотрю по-быстрому, но ставлю хорошие оценки, если программа не успела упасть, идея достаточно оригинальная, или просто видно, что разработчик постарался.
Кстати я уже поставил 1 за оригинальность 5 разным alarm clock'ам. Про Intelligent Alarm Clock читал, жду его, чтобы поставить пятерки. Пока не появлялся.
В НЗ — дома от 250 штук, з.п. программиста пусть 80, процент банковкий около 5.
В Германии дороги хорошие — можно купить жилье в дешевом или очень дешевом месте, а работать в дорогом. Мало лет потребует, но поездить придется… Если покупать там, где работаешь, соотношение дохода к стоимости жилья примерно как в НЗ сейчас. В Москве вроде недвига падает, если подождать, соотношение может стать таким же.
Раньше не могло быть холиваров, т.к. K5 — первая полностью оригинальная x86 совместимая архитектура от AMD. До этого не было особенной разницы. 2 недели назад общался с одним из ее архитекторов, вспоминали те времена.
Отличная идея. Владимир, сорри что прерываю твой бенефис :) С другим количеством ядер вряд ли получится в Vtune, но с другой частотой и микроархитектурой как часть «Generate advice» может лечь хорошо. Прогнал пользователь на CVT 2Ghz, а advicer говорит — на NHM 3Ghz было бы столько то.
Да, есть подразделение, которое координирует коммиты и стратегию относительно ядра. Но дрова пишутся отдельно каждой командой, которая делает железки. Кто делает сетевухи — пишет для них дрова. Аналогично граф карточки и т.д.
Вика бОльший эксперт в Лараби, чем я. Насколько я помню, каждое ядро в первой лараби — почти Pentium 1, с некоторым набором дополнительных векторных команд. Насколько этот набор совместим с SSE — я не помню.
В Trace cache были определенные проблемы, в частности с Replay, но в Интел есть несколько команд архитекторов. Как минимум одна из них считает, что в Trace cache было рациональное зерно. Он не вернулся в Нехалем, но в нем уже есть его потомок. Есть тенденция постепенного увеличения этого небольшого кэша, наполняемого декодированными микро-операциями.
В каждой очередной микроархитектуре есть блок, который чаще других оказывается на критическом пути, не давая достигнуть желаемого IPC. Действительно, бывало, что это Instructions Decoder. Но это лишь один из десятка основных элементов, несбалансированное развитие которых в следующих архитектурах может помешать.
Одним из способов решить противоречие, которое мы обсуждаем, был trace cache. Уже тоже есть небольшой кэш из уже декодированых инструкций для небольших циклов, и это направление будет развиваться в следующих архитектурах. Кодировки становятся длиннее, кэша становится больше (I1 cache только не растет)
Спасибо, я видел опечатку, но, к сожалению, отправленный кже коммент редактировать нельзя.
Тут играет роль моя профессиональная деформация — Вика работает с компаниями, которые пишут приложения для массового рынка, а я — с enterprise-telco. Там клиентов гораздо меньше, и им сложнее сказать — нет, извините, наше основное конкурентное преимущество (совместимость) мы забрасываем. x86 выстрелил за счет массового спроса, а стал использоваться в enterprise, вытесняя риски, за счет того, что догнал их по производительности и надежности при меньшей цене(деньги на R&D окупаются за счет массового спроса).
Софт, который разрабатывался для старых архитектур (а я работал с продуктами, в которых тысячи человеко-лет), часто давно крутится в нескольких слоях виртуализации. На 286 он крутился, обслуживая, например, 5 абонентов, а на современном сервере — по 5 тысяч на ядро.
В Itanium ах сначала была тормозная аппаратная реализация x86. Потом появилась программная, в виде binary translation, и все не то что бы залетало, но стало заметно лучше.
Как раз недавно с коллегами за кофе обсуждали izard.livejournal.com/28263.html. Получилось, что через 20 лет надо будет делать расширение. Если будут маркетинговые соображения — то еще раньше.
Кстати +1, они вроде из Штатов не доставляют, я бы себе новый держатель для бэджика купил. Так что каждый редкий приезд к корням превращается в шоппинг тур.
Ну если бюджет появляется с неба, то вернул бы возможность летать бизнес классом через атлантику (было такое в очень удачный год, но достаточно давно и ненадолго)
Ничего бы не менял — не компетентен решать за весь Интел. Если ничего не трогать, то даже со мной в качестве Самого Главного сколько-то лет все проработает нормально, инерции хватит. Если трогать — сделаю только хуже. Серьезно, редко кто может принимать минимально компетентные решения более чем на 2 уровня вверх от текущего положения. Разве что, в области управления государством. Тут — все мы эксперты.
Оптика будет постепенно подходить все ближе к процессору, но даже это вопрос следующего десятилетия. Квантовые, нейропроцессоры в ближайшее время анонсированы не будут :)
Между кремниевой технологией сегодняшнего дня и 30 летней давности — огромная разница. За следующие 30 лет тоже много поменяется.
Немного некорректно конечно, но 128 битные камни уже есть (SSE1-4.2),
256 битные камни — Sandy Bridge (AVX).
512 битные — Larrabee.
А 128 битная адресация не нужна — семнадцать миллионов терабайт адресации должно хватить на время существования солнечной системы :)
Программа для судей и количество программ таковы, что хочется быстро-быстро посмотреть, и поставить оценку. Простые программы получат лучшие баллы поэтому. Я тоже смотрю по-быстрому, но ставлю хорошие оценки, если программа не успела упасть, идея достаточно оригинальная, или просто видно, что разработчик постарался.
В Германии дороги хорошие — можно купить жилье в дешевом или очень дешевом месте, а работать в дорогом. Мало лет потребует, но поездить придется… Если покупать там, где работаешь, соотношение дохода к стоимости жилья примерно как в НЗ сейчас. В Москве вроде недвига падает, если подождать, соотношение может стать таким же.
В Trace cache были определенные проблемы, в частности с Replay, но в Интел есть несколько команд архитекторов. Как минимум одна из них считает, что в Trace cache было рациональное зерно. Он не вернулся в Нехалем, но в нем уже есть его потомок. Есть тенденция постепенного увеличения этого небольшого кэша, наполняемого декодированными микро-операциями.
Одним из способов решить противоречие, которое мы обсуждаем, был trace cache. Уже тоже есть небольшой кэш из уже декодированых инструкций для небольших циклов, и это направление будет развиваться в следующих архитектурах. Кодировки становятся длиннее, кэша становится больше (I1 cache только не растет)
Тут играет роль моя профессиональная деформация — Вика работает с компаниями, которые пишут приложения для массового рынка, а я — с enterprise-telco. Там клиентов гораздо меньше, и им сложнее сказать — нет, извините, наше основное конкурентное преимущество (совместимость) мы забрасываем. x86 выстрелил за счет массового спроса, а стал использоваться в enterprise, вытесняя риски, за счет того, что догнал их по производительности и надежности при меньшей цене(деньги на R&D окупаются за счет массового спроса).
Софт, который разрабатывался для старых архитектур (а я работал с продуктами, в которых тысячи человеко-лет), часто давно крутится в нескольких слоях виртуализации. На 286 он крутился, обслуживая, например, 5 абонентов, а на современном сервере — по 5 тысяч на ядро.
Между кремниевой технологией сегодняшнего дня и 30 летней давности — огромная разница. За следующие 30 лет тоже много поменяется.
256 битные камни — Sandy Bridge (AVX).
512 битные — Larrabee.
А 128 битная адресация не нужна — семнадцать миллионов терабайт адресации должно хватить на время существования солнечной системы :)