Первый пример с 4к экраном. Данные общие, пара гигибайт сверх-быстрой памяти на ВСЕ ядра read-only общая, а writable информация (результат вычисления) - 1 пиксель. Норм получилось!
второй пример с sql запросом. В таблице миллиард записей, каждая запись - пару килобайт. И каждому ядру кэш пара килобайт, как раз запись и промежуточные вычисления поместятся. Если нужно запись осуществить в каждую ячейку - ну так записи все независимые, тоже норм ложится в новух архитектуру. Потом можно разом всё выгручить. Вот если сложные аггрегации есть - тогда да, нужно какую-то рекурсивно-каскадную модель вычисления строить, вот это да, интересно как сделать чтобы не тормозило. Но в целом то, если ядер миллион будет вычислительных - уж памяти гигабайт общей и по килобайту каждому ядру персональной можно будет засунуть на пластину.
покажите мне GPU где есть хотя бы миллион ядер? ну-ка-ну-ка?
20 млрд ядер, 8080 - 20 тыщ транзисторов (а нам сложнее и не нужно!) = миллион ядер. Ну пусть оверхед 50-90%. тогда 100 тыщ ядер, что тоже сильно больше любого gpu
дешёвые свичи/роутеры для соединения между N портами прогоняют всё через центральный вычислитель и если вдруг нагрузить не 2 порта из 20 нагрузкой в гигабит, а хотя бы 5 портов - упс, всё начинает лагать.
Дорогие свичи роутеры умеют прямые соединения между 2 портами обрабатывать независимо и все 20 портов могут работать на максимальной поддерживаемой скорости в гигабит, что даёт 20 Гбит суммарную пропусную способность (In + Out если сложить), или намного больше если порты 2.5/10Гбит, или есть 40 штук вместо 20.
А если влепить х*** схемотехнику наотъ***сь, то 2 пользователя пересылающие друг друг файл заставят всех страдать.
Сколько SQL-запросов в секунду сможет обрабатывать Web сервер на такой архитектуре? На сколько быстрее обработается рейтрейсинг на 3 миллиарда треуголников?
давайте я вам отвечу! На 4к экране примерно 10 миллионов пикселей. Значит 10 миллионов ядров очень даже пригодятся для рейтрейсинга на 3 миллианрда треугольников. А с учётом двойном буфферизации - 20 миллионов ядер! прекрасный пример же!
------------
сколько sql запросов обрабатывать? Ну смотрите, в таблице - 1 миллиард записей. Прилетает запрос, применяем к каждой из записей фильтр = 1 миллиард ядер для простейшего процессинга нужно. Потом результат объядиняем рекурсивно. на втором этапе рекурсии и объединения по простой аггрегирующей функции (сумма например, или счётчик) - 500 миллионов ядер, на третьем - 250 млн ядер и тд.
перекидываются между C++ и cppfront (cpp2). Совместимость бинарная на уровне линковки, на уровне хидеров, более того в одном файле можно писать на миксе языков в "не строгом" режиме
кому правильнее-то? ну если чё-то случится - и чё? это ж не команда с автобусным фактором 1. отвалится интернет на даче - так кроме тебя некому всё равно было настроить роутер и симку, а если есть кому - так поменяют симку. и тд. цифровой концлагерь ради "правильнее" не нужен.
ну отлично, датацентр на 100 полок будет требовать 102 полки, ну и дополнительных 100квч электроэнергии каждый месяц пожалуйста!
И это в среднем на пару процентов. А какие-то специфичные приложения просядут процентов на 10, упс, подумаешь дополнительных 20 лямов баксов вложить чтобы поисковые запросы пользователей обслуживать или их видосики пережимать?
ниже в комментарии заметили, что через 30 лет случилось разово.
Если уменьшить срок с 100 лет непрерывной работы до, пусть даже, 10, то это значит что разовые сбои в кластерах где тысячи процессоров, а возможно сотни тысяч начнут сбоять не через 10-30 лет (разово), а через 1-3 года.
Вложения сотен миллионов долларов превратятся из "10 лет можно работать перед тем как продавать как устаревшее" в "каждый год нужно нужно менять N% камней, а через пять лет - списывать в утиль.
прижимной силы на потребительских машинах ноль. Более того, обычные седаны-хэтчбеки имеют форму крыла (а не антикрыла как нужно для прижимной силы), а значит прижимная сила - отрицательная
вы напрасно на столбы грешите, напротив, правильно спроектированные мачты освещения и знаки состоят из двух частей которые легко разделяются; одна часть остаётся в земле, а вторая улетает в воздух, делает оборот и падает позади сбившей его машины.
Это часть сити-дизайна, а не недоработка физики. столбы которые так не делают - убивают людей и по возможности их не устанавливают рядом с дорогами в странах, где думают о безопасности водителей.
это же издевательство 10см фокусировка в шлеме.... оптика должна быть на бесконечность настроена или хотя бы на десятки метров. Иначе перенапряжение хрусталика на ровном месте.
в эсператно ударение всегда на второй с конца слог (если их больше одного); не нужны ударения тоже. С этими тортами и тортами, звонит и звонит уже плешъ в голове
const на аргументе который копируется - не часть abi, она не меняет сигнатуру функции, только указание компилятору что не стоит таки разрешать менять объект. Всегда есть отвратительная опция const_cast сделать.
Кроме того могут быть mutable члены, хотя std::set наверное не имеет их.
В хидере метод может быть определен с const на аргументе и без него в реализации. И наоборот. Конст на аргументе переданом по копии не часть интерфейса функции
что фактически не имеет смысла, т.к. делает лишнее копирование объекта типа std::set<int> при передаче его в функцию f
обычно - да, в среднем типичном случае вы правы и это ошибка.
Но этот код имеет смысл, если функция принимает множество, внутри его изменяет и выбрасывает потом, при этом исходное множество не должно изменяться. практично ли это? может быть нет. "фактически не имеет смысла" - нет, не согласен, смысл есть хотя это и corner-case
ну даже если стандарт и есть - зачем в корку-то падать/ломать всё от того что пользователь таб вставил? разделитель? Отлично, работаем.
Первый пример с 4к экраном. Данные общие, пара гигибайт сверх-быстрой памяти на ВСЕ ядра read-only общая, а writable информация (результат вычисления) - 1 пиксель. Норм получилось!
второй пример с sql запросом. В таблице миллиард записей, каждая запись - пару килобайт. И каждому ядру кэш пара килобайт, как раз запись и промежуточные вычисления поместятся. Если нужно запись осуществить в каждую ячейку - ну так записи все независимые, тоже норм ложится в новух архитектуру. Потом можно разом всё выгручить. Вот если сложные аггрегации есть - тогда да, нужно какую-то рекурсивно-каскадную модель вычисления строить, вот это да, интересно как сделать чтобы не тормозило. Но в целом то, если ядер миллион будет вычислительных - уж памяти гигабайт общей и по килобайту каждому ядру персональной можно будет засунуть на пластину.
покажите мне GPU где есть хотя бы миллион ядер? ну-ка-ну-ка?
20 млрд ядер, 8080 - 20 тыщ транзисторов (а нам сложнее и не нужно!) = миллион ядер. Ну пусть оверхед 50-90%. тогда 100 тыщ ядер, что тоже сильно больше любого gpu
дешёвые свичи/роутеры для соединения между N портами прогоняют всё через центральный вычислитель и если вдруг нагрузить не 2 порта из 20 нагрузкой в гигабит, а хотя бы 5 портов - упс, всё начинает лагать.
Дорогие свичи роутеры умеют прямые соединения между 2 портами обрабатывать независимо и все 20 портов могут работать на максимальной поддерживаемой скорости в гигабит, что даёт 20 Гбит суммарную пропусную способность (In + Out если сложить), или намного больше если порты 2.5/10Гбит, или есть 40 штук вместо 20.
А если влепить х*** схемотехнику наотъ***сь, то 2 пользователя пересылающие друг друг файл заставят всех страдать.
давайте я вам отвечу! На 4к экране примерно 10 миллионов пикселей. Значит 10 миллионов ядров очень даже пригодятся для рейтрейсинга на 3 миллианрда треугольников. А с учётом двойном буфферизации - 20 миллионов ядер! прекрасный пример же!
------------
сколько sql запросов обрабатывать? Ну смотрите, в таблице - 1 миллиард записей. Прилетает запрос, применяем к каждой из записей фильтр = 1 миллиард ядер для простейшего процессинга нужно. Потом результат объядиняем рекурсивно. на втором этапе рекурсии и объединения по простой аггрегирующей функции (сумма например, или счётчик) - 500 миллионов ядер, на третьем - 250 млн ядер и тд.
Хорошие примеры привели! ещё есть?
всё так. Единственный существующий прототип компилятора - трансформер в обычный С++
перекидываются между C++ и cppfront (cpp2). Совместимость бинарная на уровне линковки, на уровне хидеров, более того в одном файле можно писать на миксе языков в "не строгом" режиме
https://www.youtube.com/watch?v=ELeZAKCN4tY
капитан, снимите шляпу, погоны на уши давят.
кому правильнее-то? ну если чё-то случится - и чё? это ж не команда с автобусным фактором 1. отвалится интернет на даче - так кроме тебя некому всё равно было настроить роутер и симку, а если есть кому - так поменяют симку. и тд. цифровой концлагерь ради "правильнее" не нужен.
а детей-то может быть 5! и 7! и 12!
ну если какая-то компания решила всё занулять - счастья им и здоровья. Тащить это в стандарт не надо!
ну отлично, датацентр на 100 полок будет требовать 102 полки, ну и дополнительных 100квч электроэнергии каждый месяц пожалуйста!
И это в среднем на пару процентов. А какие-то специфичные приложения просядут процентов на 10, упс, подумаешь дополнительных 20 лямов баксов вложить чтобы поисковые запросы пользователей обслуживать или их видосики пережимать?
ниже в комментарии заметили, что через 30 лет случилось разово.
Если уменьшить срок с 100 лет непрерывной работы до, пусть даже, 10, то это значит что разовые сбои в кластерах где тысячи процессоров, а возможно сотни тысяч начнут сбоять не через 10-30 лет (разово), а через 1-3 года.
Вложения сотен миллионов долларов превратятся из "10 лет можно работать перед тем как продавать как устаревшее" в "каждый год нужно нужно менять N% камней, а через пять лет - списывать в утиль.
прижимной силы на потребительских машинах ноль. Более того, обычные седаны-хэтчбеки имеют форму крыла (а не антикрыла как нужно для прижимной силы), а значит прижимная сила - отрицательная
просто в Жуковском после получения диплома видимо не принято быть сотрудником в сфере науки.
это в конкретном физическом эксперименте с щелью каземира, насколько я понял из википедии.
Если у вас есть вариант как создать ещё менее пустое пространство - велком с предложениями
вы напрасно на столбы грешите, напротив, правильно спроектированные мачты освещения и знаки состоят из двух частей которые легко разделяются; одна часть остаётся в земле, а вторая улетает в воздух, делает оборот и падает позади сбившей его машины.
Это часть сити-дизайна, а не недоработка физики. столбы которые так не делают - убивают людей и по возможности их не устанавливают рядом с дорогами в странах, где думают о безопасности водителей.
краштест:
https://www.youtube.com/watch?v=D8-UTN3qKaY
ещё один
https://www.youtube.com/watch?v=FLhyG2azDIo
это же издевательство 10см фокусировка в шлеме.... оптика должна быть на бесконечность настроена или хотя бы на десятки метров. Иначе перенапряжение хрусталика на ровном месте.
в эсператно ударение всегда на второй с конца слог (если их больше одного); не нужны ударения тоже. С этими тортами и тортами, звонит и звонит уже плешъ в голове
const на аргументе который копируется - не часть abi, она не меняет сигнатуру функции, только указание компилятору что не стоит таки разрешать менять объект. Всегда есть отвратительная опция const_cast сделать.
Кроме того могут быть mutable члены, хотя std::set наверное не имеет их.
В хидере метод может быть определен с const на аргументе и без него в реализации. И наоборот. Конст на аргументе переданом по копии не часть интерфейса функции
обычно - да, в среднем типичном случае вы правы и это ошибка.
Но этот код имеет смысл, если функция принимает множество, внутри его изменяет и выбрасывает потом, при этом исходное множество не должно изменяться. практично ли это? может быть нет. "фактически не имеет смысла" - нет, не согласен, смысл есть хотя это и corner-case