У ОС свое видение приоритетов, а у приложения -- своё. В итоге реклама в боковом меню браузера у меня заливается соловьём в HD, а моя несчастная табличка из 30 строк грузится 20 секунд. Бывало у вас такое? Да, это про сеть и браузер, не про процессор.
Исследование идет не по пути увеличения количества ядер, а оно про распределение вычислений между агентами, которые ядром-то грех назвать. В статье использовано фото 4-хбитного процессора, а наши ядра будут в разы проще, если не на порядки.
Это ваше право ставить под вопрос экспертность авторов статьи. Про количество узлов и коммутацию -- вот это серьезный вызов, с этим предстоит работать. Мы делали это ранее, сделаем и теперь надеюсь, с помощью сообщества.
Это рекуррентные вычисления, и из тысяч потоков на вашем компьютере их использует, наверное, каждый. Даже в этом случае количество таких потоков в сотни-тысячи раз меньше числа ядер вашего процессора.
Я кое-что знаю о процессорах, и программировал те из них, архитектуру которых ещё можно удержать в одной голове. По теме: Ной был подневольным любителем, когда строил ковчег. Титаник строили профессионалы. Примерно так звучит притча. У нас есть сотни человеко-лет опыта, на который мы можем опираться, есть конкретная задача и незашоренность. Иными словами, есть всё.
Вы делаете бесшовный переход с частных сложностей к общим постулатам, которые озвучивают проблему в общем. А статья про решение общей проблемы, и в ней нигде не говорится, что это будет просто, но мы ищем именно простое решение, как его нашли разработчики процессора i4004, вот именно на таком уровне - CMOS и технологии ключей
Может стоит пойти поработать в соответствующую сферу лет на 5-10
Это плюс в нашей ситуации. Кто-то должен быть со свежим взглядом. Я регулярно смотрю в глаза человеку, кто проектировал процессоры, черпаю оттуда вдохновение. Он работает на два уровня выше, и эта статья не про дефекты разработки процессоров (они почти идеальны с учетом реалий), а про принципиально новую архитектуру построения полупроводниковых вычислителей.
Вы правы. Подходы к проектированию софта всему виной, ибо программирование пошло в массы. Это вызов, который железо будущего должно держать, но сейчас не держит.
И вернуться в плане простоты и понятности к компам 80-х с Basic и детской радостью познания
Ня! 640кБ хватит всем. Было дело.
Я-то думал, аффтар хочет выбросить эмулируемое/имитируемое легаси, которого в современных машинах много.
Да-да-да. Вот это постраничное переключение памяти и прочие издержки архитектуры прошлого века. Началась затея именно с размышлений об этом, но, пока размышляли, ситуация качественно поменялась, гротескно, я бы сказал.
Мы как раз проводим исследование, чтобы это доказать. В поддержку есть только экспертное мнение инженеров-электронщиков и программистов. Интуитивно чувствуется, что утверждение верно, и кто-то должен быть первым, кто его наконец подтвердит.
Из теорий есть только стишок из детства про шайку зайцев и льва, хотя это фольклор.
GPU используется для игр и профессиональных или узких задач. Современные процессы, о которых здесь идет речь, также включают обычные персональные компьютеры, которые используются для серфинга в интернете и для подготовки документов. Прямо сейчас я насчитал 59 процессов только гугл-хрома, а общее количество процессов моего ноутбука гораздо больше, и они порождают потоки, которых вообще страшно представить сколько (посмотрел — 3300+). Всё это упирается в 4 физический ядра, которые должны быть достаточно мощными, чтобы в пике обработать все потоки без торможения. Вот на этом поле хотелось бы поработать — дешево выполнять всю эту работу.
Рискну заявить, что в начале прошлого века не было таких мощнейших средств прототипирования и разработки с одной стороны, и такого количества разношерстных задач с другой стороны. Вспомните количество процессов в Win 95-98 и сравните с сегодняшней картиной. Вы правы, что задача на порядки сложней, потому что вместо коммутации элементов придется делать дизайн с нуля, однако, инструментарий тоже на порядки круче, чем в былые времена.
Эти парни хотели оптимизацию использования железа, когда у них уже было железо и оно частенько простаивало. Мы ещё не дошли до такой развитой стадии, кроме того, я бы желал снять думы о локальной параллелизации с программиста, сделав всю черновую работу за него. Благо делается ведь это достаточно тривиально.
Прочитал Синклер асм и вздрогнул, потому что начинал со спектрумовских бейсика и ассемблера. Представьте себе, что шина у вас – это некий кубик со множеством входов на каждой грани, куда можно подключиться и закачивать задачи. Всю периферию вы подключаете в любой свободный вход, и она там обслуживается. Всё асинхронно, но для простоты у всего одна частота и взаимодействие определяется контрактом при подключении. Внутри кубика множество уровней, по которым перемещаются исполнители и передают задачи, причем перемещаются по желанию, используя общие циклы сдвига. Вот примерно так мы это видим в самом первом грубом приближении.
У ОС свое видение приоритетов, а у приложения -- своё. В итоге реклама в боковом меню браузера у меня заливается соловьём в HD, а моя несчастная табличка из 30 строк грузится 20 секунд. Бывало у вас такое? Да, это про сеть и браузер, не про процессор.
Исследование идет не по пути увеличения количества ядер, а оно про распределение вычислений между агентами, которые ядром-то грех назвать. В статье использовано фото 4-хбитного процессора, а наши ядра будут в разы проще, если не на порядки.
Нас интересует максимум
Это ваше право ставить под вопрос экспертность авторов статьи.
Про количество узлов и коммутацию -- вот это серьезный вызов, с этим предстоит работать. Мы делали это ранее, сделаем и теперь надеюсь, с помощью сообщества.
Это рекуррентные вычисления, и из тысяч потоков на вашем компьютере их использует, наверное, каждый. Даже в этом случае количество таких потоков в сотни-тысячи раз меньше числа ядер вашего процессора.
Я кое-что знаю о процессорах, и программировал те из них, архитектуру которых ещё можно удержать в одной голове.
По теме: Ной был подневольным любителем, когда строил ковчег. Титаник строили профессионалы. Примерно так звучит притча.
У нас есть сотни человеко-лет опыта, на который мы можем опираться, есть конкретная задача и незашоренность. Иными словами, есть всё.
Вы делаете бесшовный переход с частных сложностей к общим постулатам, которые озвучивают проблему в общем. А статья про решение общей проблемы, и в ней нигде не говорится, что это будет просто, но мы ищем именно простое решение, как его нашли разработчики процессора i4004, вот именно на таком уровне - CMOS и технологии ключей
.
Это плюс в нашей ситуации. Кто-то должен быть со свежим взглядом. Я регулярно смотрю в глаза человеку, кто проектировал процессоры, черпаю оттуда вдохновение. Он работает на два уровня выше, и эта статья не про дефекты разработки процессоров (они почти идеальны с учетом реалий), а про принципиально новую архитектуру построения полупроводниковых вычислителей.
Вы правы. Подходы к проектированию софта всему виной, ибо программирование пошло в массы. Это вызов, который железо будущего должно держать, но сейчас не держит.
По п.1 тема раскрыта тут:
https://habr.com/ru/users/Asmodeux/publications/articles
/
Пара пунктов о достижениях команды:
1. Алгоритм в 12 строк, работавший публично больше 10 лет, почти каждый год в плюс. Сломался год назад. Не кОрысти ради, а принципа для (пруф https://www.darwinex.com/invest/AUX)
2. Квинтетная модель данных, полмиллиарда записей (https://www.youtube.com/watch?v=l0eg2xuC9Ks)
Статья о том, что как раз проблем нет, мы делаем именно это, но только прототипировать (симулировать) будем не FPGA, а чуть ниже уровнем.
Сложновато для пятницы, и пока слабо осязаемо.
Ня! 640кБ хватит всем. Было дело.
Да-да-да. Вот это постраничное переключение памяти и прочие издержки архитектуры прошлого века. Началась затея именно с размышлений об этом, но, пока размышляли, ситуация качественно поменялась, гротескно, я бы сказал.
Амдал и подумать не мог про 3300+ процессов.
Мы как раз проводим исследование, чтобы это доказать. В поддержку есть только экспертное мнение инженеров-электронщиков и программистов. Интуитивно чувствуется, что утверждение верно, и кто-то должен быть первым, кто его наконец подтвердит.
Из теорий есть только стишок из детства про шайку зайцев и льва, хотя это фольклор.
GPU используется для игр и профессиональных или узких задач. Современные процессы, о которых здесь идет речь, также включают обычные персональные компьютеры, которые используются для серфинга в интернете и для подготовки документов. Прямо сейчас я насчитал 59 процессов только гугл-хрома, а общее количество процессов моего ноутбука гораздо больше, и они порождают потоки, которых вообще страшно представить сколько (посмотрел — 3300+). Всё это упирается в 4 физический ядра, которые должны быть достаточно мощными, чтобы в пике обработать все потоки без торможения. Вот на этом поле хотелось бы поработать — дешево выполнять всю эту работу.
Рискну заявить, что в начале прошлого века не было таких мощнейших средств прототипирования и разработки с одной стороны, и такого количества разношерстных задач с другой стороны. Вспомните количество процессов в Win 95-98 и сравните с сегодняшней картиной.
Вы правы, что задача на порядки сложней, потому что вместо коммутации элементов придется делать дизайн с нуля, однако, инструментарий тоже на порядки круче, чем в былые времена.
Кстати, планировал обратиться к авторам некоторых комментариев в личку с предложением обсудить некоторые мысли. И буду рад любым обращениям по теме.
Эти парни хотели оптимизацию использования железа, когда у них уже было железо и оно частенько простаивало. Мы ещё не дошли до такой развитой стадии, кроме того, я бы желал снять думы о локальной параллелизации с программиста, сделав всю черновую работу за него. Благо делается ведь это достаточно тривиально.
Прочитал Синклер асм и вздрогнул, потому что начинал со спектрумовских бейсика и ассемблера.
Представьте себе, что шина у вас – это некий кубик со множеством входов на каждой грани, куда можно подключиться и закачивать задачи. Всю периферию вы подключаете в любой свободный вход, и она там обслуживается. Всё асинхронно, но для простоты у всего одна частота и взаимодействие определяется контрактом при подключении.
Внутри кубика множество уровней, по которым перемещаются исполнители и передают задачи, причем перемещаются по желанию, используя общие циклы сдвига.
Вот примерно так мы это видим в самом первом грубом приближении.