Комментарии 59
Есть и другая сторона этого вопроса. Ощущение от скорости работы на моем десктопе за последние 20 лет мало поменялись. А вот после накатывания очередной версии оси на то же железо падает в разы. Где то я слышал о карательных сговорах производителей железа и софта. Хотя отношение к этому как к чипированию у большинства. Типа ку-ку.
Wintel?:)
Ощущение от скорости работы на моем десктопе за последние 20 лет мало поменялись.
Да ладно вам! Вы уже просто видимо забыли эти загрузки винды по несколько минут, ожидания загрузки софта и «микро-лаги», адский хруст
сижу на пк 2005г(но конкретно я им пользуюсь с 2014, в основном для браузера и ютуба в 480р), 3 года назад почувствовал что начал работать медленно.
Перешёл на винду 10, мне говорили что она быстрая. Винда 10 грузится по 10-15 минут, браузер ещё 3 минуты открывается. Когда открылся, не хватает озу, создается своп, снова всё тупит, а отклик винта иногда подмимается до 6к милисекунд. Поставил ссд, на него систему, браузер, нужные проги. докинул озу с 2 до 4гб. прекрасно работал со всем, что мне надо, 20-25секунд на загрузку винды до кликабельности ярлыков на рабочем столе. Даже гта5 запускается и дает 2фпс на минималках и с недогрузами. Недавно решил изучить юнити, и понял что комп безвозвратно устарел. Отдал его другу под сервер для чего то легкого, а сам перешёл на AM4 платформу на r3 1200, под будущий апгрейд.
Честно от перехода с hdd на ssd эффекта больше чем от перехода с 775 на AM4, так что с вами согласен только про своп на hdd и хруст винтов, но если правильно всё настроить, то и его нет. Особенно на win XP, там и к озу гуманное отношение, в простое 120-150мб выжирает всего, а из-за этого до свопа сложнее довести, да и места на диске меньше занимает, и обращается к нему для своих нужд довольно редко, так что хруста или подвисаний из-за отклика дисков на XP нет.
Перешёл на винду 10, мне говорили что она быстрая. Винда 10 грузится по 10-15 минут, браузер ещё 3 минуты открывается. Когда открылся, не хватает озу, создается своп, снова всё тупит, а отклик винта иногда подмимается до 6к милисекунд. Поставил ссд, на него систему, браузер, нужные проги. докинул озу с 2 до 4гб. прекрасно работал со всем, что мне надо, 20-25секунд на загрузку винды до кликабельности ярлыков на рабочем столе. Даже гта5 запускается и дает 2фпс на минималках и с недогрузами. Недавно решил изучить юнити, и понял что комп безвозвратно устарел. Отдал его другу под сервер для чего то легкого, а сам перешёл на AM4 платформу на r3 1200, под будущий апгрейд.
Честно от перехода с hdd на ssd эффекта больше чем от перехода с 775 на AM4, так что с вами согласен только про своп на hdd и хруст винтов, но если правильно всё настроить, то и его нет. Особенно на win XP, там и к озу гуманное отношение, в простое 120-150мб выжирает всего, а из-за этого до свопа сложнее довести, да и места на диске меньше занимает, и обращается к нему для своих нужд довольно редко, так что хруста или подвисаний из-за отклика дисков на XP нет.
НЛО прилетело и опубликовало эту надпись здесь
Как Java? Или при установке перекомпиляция все же требуется? А что если я меняю видеокарту? Г Надо пересобирать весь софт?
НЛО прилетело и опубликовало эту надпись здесь
И чтобы был быстрый результат, оно должно работать как хорошо настроенный ковеер на заводе. Каждый станок производит ровно столько (не больше не меньше) сколько может переработать следующий станок. То что ядра простаивают ожидая информации из памяти — лишь один из многочисленных примеров бутылочных горлышек в вычислениях.
Ага. Вот поэтому я и говорил о понижении частоты. Без этого сбалансировать не очень то получается…
НЛО прилетело и опубликовало эту надпись здесь
Опять не понял. Зачем все затачивать под одну частоту?
Я тока говорил, что жизнь становится сложнее по мере того, как растет разрыв по скорости между процессором и памятью.
и насчет того что для балансировки надо выбирать софт тоже согласен. Но и это тоже становится все сложнее и сложнее.
Я тока говорил, что жизнь становится сложнее по мере того, как растет разрыв по скорости между процессором и памятью.
и насчет того что для балансировки надо выбирать софт тоже согласен. Но и это тоже становится все сложнее и сложнее.
НЛО прилетело и опубликовало эту надпись здесь
память сейчас сильно ускорится с выходом ДДР5 так что я думаю память догонит процессор
Это хорошее замечание -догнать конечно не догонит, но жить станет определенно легче :)
именно поэтому программирование должно совершить революцию, а не просто не программировать лучше.
Да я уже даже готов согласиться. Только вот подумаю, сколько софта придется портировать и такая тоска меня берет… :)
Мне кажется то что сейчас происходит с вебом — говорит о том, что скоро будут везде два ядра и средняя частота, а вот количество и частота оперативы вырастет невероятно
Рискну предположить, что частоту вообще надо понижать.Ну не знаю… Повышение частоты — это ведь практически пропорциональное повышение производительности. Никто просто так не будет пренебрегать подобной возможностью.
Да я понимаю что понижение частоты — это не очень реалистично. Только если удастся компенсировать за счет чисто железных оптимизаций.
Мне эта идея нравится с чисто логической точки зрения. Попытка сбалансировать IO и вычислительную мощность. Bytes/flops. Stream/Linpack.
Мне эта идея нравится с чисто логической точки зрения. Попытка сбалансировать IO и вычислительную мощность. Bytes/flops. Stream/Linpack.
А зачем их балансировать таким образом? Да, обычно программы упираются в IO, но иногда нужно и вычисления запустить какие-то. Зачем ужимать их скорость? Даже если появятся оптимизации архитектуры — слоган «новый процессор на 20% быстрее» звучит лучше чем «новый процессор такой же по скорости, зато на 20% экономичнее» и на десктопах, и на мобилках; разве что в серверном сегменте дела могут обстоять по-другому.
Я тут с точки зрения дизайна железки смотрю. Причём да — железки северной. И дилемма которая иногда возникает, это сделать больше ядер на меньшей частоте или меньше на большей
А разница между «новый процессор на 20% быстрее» и «новый процессор на 20% эффективнее»? Софистикой рекламщики играть давно уже умеют.
Если я правильно понимаю текущую ситуации, то в настоящее время есть два «бутылочных горлышка» это:
— отвод тепла от кристалла
— ограничение скорости информационного потока через интерфейсные выводы кристалла процессора (корпуса процессора)
Требуется так использовать ресурсы числа транзисторов и частоты дискретизации, что бы при этих ограничениях получить максимальную производительность, а уж что отрезать и расширять это уже вторично.
Мое мнение лучше максимально конвееризованное решение, дает больше гибкости и потенциала к большой производительности. Позволяет в широких пределах варьировать частоту и число транзисторов.
— отвод тепла от кристалла
— ограничение скорости информационного потока через интерфейсные выводы кристалла процессора (корпуса процессора)
Требуется так использовать ресурсы числа транзисторов и частоты дискретизации, что бы при этих ограничениях получить максимальную производительность, а уж что отрезать и расширять это уже вторично.
Мое мнение лучше максимально конвееризованное решение, дает больше гибкости и потенциала к большой производительности. Позволяет в широких пределах варьировать частоту и число транзисторов.
Рискну предположить, что частоту вообще надо понижать.
Многие приложения всё ещё зависят от частоты.
На чипе нужны не только ядра с разной микроархитектурой (big.LITTLE), но и разные по назначению как у Esperanto Technologies.
Так что частоту нужно увеличивать, но только для определённых ядер.
Это то, что можно сделать не меняя программную модель.
При низкой частоте ядер можно рассчитывать только на широкий SIMD и надежду,
что всё будут делать именно на нём.
Это потребует от программистов размышлений над каждой мелочью.
Я же сторонник совсем иной архитектуры.
Тысячи небольших in-order RISC-ядер имеющих локальную scratchpad SRAM, работающие на 5+GHz + умный префетчер и кэш когерентный DMA.
В том же CELL, SPE запускали на 6-7ГГц при 90нм процессе. Но PowerPC ядро не могло работать на высокой частоте, да и чип бы расплавился при подведении большой мощности.
Думаю сейчас не нужно делать очень длинный конвейер чтобы добиться высокой частоты.
Scratchpad это более сложный вопрос.
Проблема scratchpad в том, что никто не смог преодолеть проблемы её менеджмента и потенциального роста. Даже в GPU не осилили.
Большая проблема такого подхода это программная модель. Фатальная ошибка дизайнеров CELL — была в ориентированности на язык C++. Ну нельзя такое программировать на низкоуровневыми языках. Точнее можно, но лишь приложив 10х усилий.
Как-то так, если не упарываться полноценными data flow архитектурами.
Таким мне представляется компьютерный мир в пост-муровскую эпоху.
Дожить бы до неё.
Это потребует от программистов размышлений над каждой мелочью.При низкой частоте ядер можно рассчитывать только на широкий SIMD и надежду,
что всё будут делать именно на нём.
Такое ощущение, что думать над оптимизацией в любом случае придется сильно больше чем раньше. Я кстати даже не про симды — а про серверные приложения где поток ждет данные быстро обрабатывает их и засыпает.
что всё будут делать именно на нём.
Такое ощущение, что думать над оптимизацией в любом случае придется сильно больше чем раньше. Я кстати даже не про симды — а про серверные приложения где поток ждет данные быстро обрабатывает их и засыпает.
Тысячи небольших in-order RISC-ядер имеющих локальную scratchpad SRAM, работающие на 5+GHz + умный префетчер и кэш когерентный DMA.
Сделать первое не такая большая проблема. Гораздо большая проблема «накормить» эту машину данными. умный префетчер и кэш когерентный DMA. — хорошая затея осталось только сделать :) А как насчет внутрипроцессорной сети? Как эти ядра будут друг с другом коммуницировать?
Сделать первое не такая большая проблема. Гораздо большая проблема «накормить» эту машину данными. умный префетчер и кэш когерентный DMA. — хорошая затея осталось только сделать :) А как насчет внутрипроцессорной сети? Как эти ядра будут друг с другом коммуницировать?
Сделать первое не такая большая проблема.
Разумеется, я говорю про то что можно реализовать прямо сейчас, а не через N лет.
При достаточной мотивации конечно.
А как насчет внутрипроцессорной сети? Как эти ядра будут друг с другом коммуницировать?
Обычный grid. Тут со времён RAW ничего особо лучше не придумать.
Префетчер должен посылать данные заранее к конкретному ядру.
Вот над чем нужно думать.
У меня пока нет ответов на все вопросы, но я и не занимался детальной проработкой.
Так, скорее пара мыслей крутится.
Но чтобы не оказаться с dead-on-arrival архитектурой, нужно идти строго от компилятора к железу, а не наоборот.
PS: Ставьте blockquote (кавычка сверху в редакторе) или хотя бы пробел между цитатой и своими словами — ничего же не понятно.
PS: Ставьте blockquote (кавычка сверху в редакторе) или хотя бы пробел между цитатой и своими словами — ничего же не понятно.
Просто попробовать blockquote
Обычный grid. Тут со времён RAW ничего особо лучше не придумать.
Префетчер должен посылать данные заранее к конкретному ядру.
Вот над чем нужно думать.
У меня пока нет ответов на все вопросы, но я и не занимался детальной проработкой.
Так, скорее пара мыслей крутится.
Я боюсь, что этот грид будет или затычкой в системе или места занимать в 10 раз больше чем все эти ядра вместе взятые…
С чего бы гриду занимать много места? Его задача передать данные по адресу узла.
en.wikichip.org/wiki/intel/microarchitectures/polaris
en.wikichip.org/wiki/intel/microarchitectures/polaris
А когерентность кэшей? Или я не понимаю чего то?
В моей схеме у ядер либо нет кэшей, либо максимум read-only кэши + специальные кэши для атомиков. Все коммуникации происходят через сообщения и атомики.
Запись идёт или в память (в т.ч. в LLC), или между узлами напрямую без вовлечения механизмов соблюдения когерентности.
Примерно таким мог быть CELL 2.
Запись идёт или в память (в т.ч. в LLC), или между узлами напрямую без вовлечения механизмов соблюдения когерентности.
Примерно таким мог быть CELL 2.
Думаю сейчас не нужно делать очень длинный конвейер чтобы добиться высокой частоты.
Для in-order точно не нужно
Для in-order точно не нужно
Современная вычислительная парадигма (фон Нейман) родилась достаточно давно, росла и развивалась (реализовывались в кремнии потенциальные возможности), сейчас она стареет: прорывных и не реализованных возможностей уже нет и идет привязывание бантиков (костылей). Скоро она умрет и вот только от ее «детей» можно ожидать нового прорыва (увеличения производительности).
Собирать 100-500 ядер на одном кристалле нет особого смысла: вычислительная парадигма фон Неймана не имеет такого понятия, как второй процессор и соответственно многопроцессорность это «костыль».
Собирать 100-500 ядер на одном кристалле нет особого смысла: вычислительная парадигма фон Неймана не имеет такого понятия, как второй процессор и соответственно многопроцессорность это «костыль».
data flow — именно она и будет (человеческий мозг имеет примерно такую архитектуру).
Все data flow, которые я пока видел превращались в compiler driven architecture. И у меня сложилось ощущение, что они долго не живут…
Думаю проблема будет побеждена в момент когда программирование перейдет из парадигмы «выполни вот эту последовательность действий» в парадигму «нужен результат с вот таким набором и иерархией свойств». Будет что то типа ООС (Объектно Ориентированные Свойства).
compiler driven architecture — как временный костыль очень подходит, только на программу нужно посмотреть немного с другой точки зрения (сейчас пытаюсь сформулировать в виде текста статьи).
compiler driven architecture — как временный костыль очень подходит, только на программу нужно посмотреть немного с другой точки зрения (сейчас пытаюсь сформулировать в виде текста статьи).
ага. вот это интересно было бы почитать :)
Только лучше не лонг рид :)
Только лучше не лонг рид :)
лонг рид — если это про размер текста, то спешу огорчить. Описание распределенного процессора занимает на порядок больший объем чем описание коммуникационной системы (110 страниц рукописного текста). Причешу вопросы коммуникаций и тогда за процессор возьмусь. Думаю будет поток мыслей под названием «Цифровое бессмертие: Вычислительный объем» и как результат минус 15-20 кармы ))))
Давайте помогу с написанием. У меня более или менее сносно получается формулировать мысли :)
Вполне можно, но мне все равно сначала нужно сделать процедуру депонирования, потом опубликовать сырой материал в инете (у меня присутствует стандартный авторский «сдвиг»). Мне хочется, что бы все что делаю было общественным достоянием с привязкой к моему имени. Как только доберусь до публикации сырого материала, отправлю Вам на рецензию (первая статья была рецензирована многими людьми и получился читаемый вариант). Для второй специалистов не нашлось — редкая тема (специалисты в этой тематике считают что там все изобретено и не заморачиваются внимательным чтением — понятно что нужно вникать, а времени даже на работу не хватает). Могу в личку процитировать ответ зам директора крупной телекоммуникационной компании.
НЛО прилетело и опубликовало эту надпись здесь
Какие реальные задачи Вы собираетесь выполнять на подобной архитектуре? Для однопоточных задач все равно будут использовать быстрые CPU, для многопоточных — GPU (которая SIMD, поэтому при прочих равных будет мощнее, чем независимые ядра). И как под нее программировать?
Нужно сломать слишком много стен в головах людей (ну или об головы).
Думаю основной прогресс начнется тогда когда будут получены две технологии.
1. Смогут разносить вычисления на разные кристаллы (без потери производительности — вы обещали прочитать, но вопросов или рецензии нет).
2. Смогут победить последовательный образ мышления программиста или изменят парадигму программирования.
Думаю основной прогресс начнется тогда когда будут получены две технологии.
1. Смогут разносить вычисления на разные кристаллы (без потери производительности — вы обещали прочитать, но вопросов или рецензии нет).
2. Смогут победить последовательный образ мышления программиста или изменят парадигму программирования.
Тут TSMC не согласна, что закон Мура при смерти.
Опять же в статье по ссылке, обратите внимание на все эти многослойные вещи, когда на одном кристалле и слои памяти, и слои вычислителей. Мне кажется, одна из тенденций, о которой можно упомянуть — это near-data computing. Эти слоеные пироги на кристалле позволяют не тягать данные через бутылочное горлышко интерфейса ОП и кэши.
Дизайнеры куда больше озабочены оптимизацией, чем инновациями. Соответственно, мы будем видеть все меньше новшеств на кристалле CPU или GPGPU.
Опять же в статье по ссылке, обратите внимание на все эти многослойные вещи, когда на одном кристалле и слои памяти, и слои вычислителей. Мне кажется, одна из тенденций, о которой можно упомянуть — это near-data computing. Эти слоеные пироги на кристалле позволяют не тягать данные через бутылочное горлышко интерфейса ОП и кэши.
Ну еще бы TSMC согласилась с этим. Эпоха перманентынх апгрейдов закончится и ее бизнес похудеет изрядно. Только ыот физические барьеры все сложнее преодолевать.
А насчет near data — каков размер такой памяти?
А насчет near data — каков размер такой памяти?
А насчет near data — каков размер такой памяти?
Это общее название подхода, а не технологии памяти, поэтому размер варьируется в широких пределах в зависимости от реализации.
Примеров приведу несколько, во-первых, упомянутая вами HBM. Такую штуку сейчас добавляют в некоторые промышленные FPGA Xilinx и Altera/Intel. Объём HBM — 16 ГБ, пропускная способность — 460 ГБ/с. Т.е. плисина имеет быструю и ёмкую оперативу под рукой.
Второй вариант, когда в качестве памяти выступает non-volatile memory, например Flash, а вычислители совмещаются с контроллерами Flash и реализуются например на FPGA, тогда объём памяти исчисляется терабайтами (см. проект Blue DBM). Это уже не слоёный пирог, но тоже near-data computing.
«По ту сторону закона Мура» будет ровно то, что сейчас творится на рынке мобильных процессоров, которые и радо бы загнулись уже, но неадекватный спрос порождает такое же предложение.
Поясню точнее — нужно больше производственной мощности, меньше тепловыделения/энергопотребления и самое важное — максимально оптимизированное ПО для этих задач.
Я часто слышу истории про геймдейвов, когда им не хватает оперативки и решение " а давайте добавим ещё в требования". Когда системы упрутся в потолок (условно, скорее всего такого не будет никогда) придётся заниматься оптимизацией потребляемых ресурсов; вырезанием ненужных библиотек и краеугольным камнем станет поддержка многопоточности/распараллеливания процессов (если верить неким слухам, то скоро AMD сможет представить 4 потока на 1 ядро).
Как было сказано, самое правильное решение — уменьшение рабочей частоты с сохранением производительности. Чем это можно добится? Как минимум задействовав несколько целевых ядер (как в мобильных телефонах), которые будут отвечать за свою узкую задачу. Или сделать реконфигурируемую систему — некий гибрид FPGA-CPU, с гибкостью первого и производительностью второго.
Чего это позволит добится? Ну как минимум уменьшение энергопотребления (опять таки в телефонах это самая первая задача). Как максимум… Никто не задумывался, почему есть 32-х слойные памяти и нет 2-х слойных процессоров? потому что теплоотвод не позволяет. Если же получится уменьшить теплогенерацию, то почему бы не «наслоить» одно ядро на второе (тут снова Мур будет в силе) или ядро на память или… В общем перспектив очень много.
Поясню точнее — нужно больше производственной мощности, меньше тепловыделения/энергопотребления и самое важное — максимально оптимизированное ПО для этих задач.
Я часто слышу истории про геймдейвов, когда им не хватает оперативки и решение " а давайте добавим ещё в требования". Когда системы упрутся в потолок (условно, скорее всего такого не будет никогда) придётся заниматься оптимизацией потребляемых ресурсов; вырезанием ненужных библиотек и краеугольным камнем станет поддержка многопоточности/распараллеливания процессов (если верить неким слухам, то скоро AMD сможет представить 4 потока на 1 ядро).
Как было сказано, самое правильное решение — уменьшение рабочей частоты с сохранением производительности. Чем это можно добится? Как минимум задействовав несколько целевых ядер (как в мобильных телефонах), которые будут отвечать за свою узкую задачу. Или сделать реконфигурируемую систему — некий гибрид FPGA-CPU, с гибкостью первого и производительностью второго.
Чего это позволит добится? Ну как минимум уменьшение энергопотребления (опять таки в телефонах это самая первая задача). Как максимум… Никто не задумывался, почему есть 32-х слойные памяти и нет 2-х слойных процессоров? потому что теплоотвод не позволяет. Если же получится уменьшить теплогенерацию, то почему бы не «наслоить» одно ядро на второе (тут снова Мур будет в силе) или ядро на память или… В общем перспектив очень много.
Да не только AMD думает про HT 4. Для каких то прилаг (где латентности нужно прятать) это помогает даже. Для HPC как правило HT отключают. Кста, подумал тут что это одна из тех фишек которые приближают СPU к GPU. Я как раз сейчас дкмаю про этот Fusion. Дойдут руки — напишу
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
По ту сторону закона Мура