Pull to refresh
1
0
Дмитрий @dimaleks

HPC, CUDA программист

Send message

Очень странная новость, честно говоря. Никаких деталей нигде нет. Какое железо, какая сеть, кто интегратор? Как вообще можно запустить такого размера суперкомпьютер без взаимодействия с поставщиками оборудования (а этого взаимодействия нет из-за санкций)?
Разве что какое-то китайское решение. Но я не слышал, чтобы Китай раньше строил машины на своём оборудовании где-то вне самого Китая. Очень мутно всё это

Если я не ошибаюсь, это главное здание МГУ. Там довольно много общежитий, а соответствующей инфраструктуры в здании 50х годов нет — вот и приходилось так провода тянуть.
Но я не использую анимации, а слайды делаю дублируя предыдущий и удаляя ненужные части + использую сетку для ориентации.

Попробуйте анимацию magic move, она как раз сделана для такого подхода. Иногда процесс перемещения одинаковых блоков при переключении слайда можно очень просто, и, главное, наглядно анимировать.
Я довольно давно профессионально работаю на CUDA, и вы не совсем правы.

2х2 на видеокарте всегда будет одним и тем же числом. Все операции (кроме специальной быстрой математики, которую еще нужно включить) IEEE-compliant. Недетерменированность может возникать разве что от использования атомарных операций с плавающей запятой, их порядок неопределен. Это может повлиять на результат, но обычно разница в последних нескольких значащих разрядах. А если использовать хороший устойчивый алгоритм, то разница между запусками и вовсе будет минимальная.

Я никогда не смотрел ни на код, ни на работу кодеков, по этому поводу ничего не могу сказать. Возможно, вы нашли какой-то баг. Возможно, алгоритму нужна высокая точноть, и single precision и 32 бита — это просто недостаточно. Тогда, как заметил InChaos, нужно переходить на карты Tesla и double precision
Вопрос к сожалению не нубский, а очень непростой. Сейчас в процессоре можно выделить frontend и backend: первый загружает команды из кэша, декодирует их и отправляет на выполнение в один из портов. Обычно производители публикуют информацию по архитектуре своих процессоров с указанием того, сколько и каких инструкций он может выполнить на том или ином порте и сколько инструкций можно загрузить и декодировать за такт.
Но это такие «рафинированные» цифры, которые никак не учитывают out-of-order execution, branch prediction, кэш инструкций и т.д. В реальности получить цифры, хоть сколько-то близкие к 4.0, почти невозможно, даже написав очень простой специализированный код.
Другой вопрос, что IPC далеко не всегда показывает загрузку процессора. Например, эта метрика не знает, насколько полезные инструкции выполняются (может многие из этих инструкций — это работа с индексами), она никак не учитывает использование векторых операций, которые могут повысить производительность в 4-8 раз.
Если интересна тема, рекомендую хороший сайт http://www.agner.org, там человек много экспериментирует и приводит эмпирические оценки с соображения для многих скрытых деталей.
Цитата автора сайта по теме:
I think the decoding front end and the renamer are designed with a 4-wide pipeline for a throughput of four µops per clock. These µops are queuing up in the reservation station if execution of them is delayed for any reason. The scheduler can issue more than 4 µops per clock cycle in bursts until the queue is empty.
Попробуйте метод Верле, стандартный в молекурярной динамике. Выше порядок точности, гораздо лучше сохраняет полную энергию системы (в вашем случае это неважно, но всё же), а вычислений сил столько же, сколько и в Эйлере. На английской википедии Velocity Verlet написан и сам алгоритм, смотрите тот, который из четырёх пунктов
Продавец ведь всегда один, разве нет? Я про классы покупателей
Простите, отправил недописанный комментарий! Должно было быть примерно так:
  1. Запрашивать достаточно по одной корове. В любом случае запрос нескольких коров одновременно можно разбить на несколько запросов по одной корове с бесконечно малым промежутком по времени.
  2. Похоже, что все классы покупателей можно рассматривать по-отдельности.
    Пусть у нас есть только один класс k1, пусть для него оптимальной будет стратегия S1.
    Стратегия,
    … в моём понимании, это некоторый функционал от всех имеющихся на данный момент данных (о клиентах, о коровах, о запросах и т.д.) и времени, который принимает значение 0 или 1. 0 означает, что в этот момент времени мы ждём, 1 — запрашиваем корову.
    Аналогично, для класса k2 — стратегия S2. Теперь предположим, что нужно решить задачу для двух классов: k1 и k2. Так вот, я утверждаю, что оптимальной будет просто независимая комбинация двух стратегий S1 и S2 (в одной мы ориентируемся только на данные по клиентам первого класса, во второй — только на второго). Если же предположить, что есть более хорошая стратегия, то она даст больше доходности на одном из классов. Тогда для задачи только с одним классом можно применить эту, улучшенную стратегию (урезанную на один класс) и получить большую доходность, а это противоречие.
    Немного сумбурно и не очень строго, но надеюсь, понятна мысль.
  3. Можно считать, что параметры распределения известны. Так как интересует матожидание доходности, то любым начальным отрезком времени (конечным) можно пренебречь. А за этот начальный отрезок можно с любой заданной точностью найти параметры распределения.

Таким образом, как мне кажется, задача сводится к одному классу клиентов с известным параметром l, и это уже значительно более поддающаяся решению задача.
Хотел бы добавить несколько соображений.
  1. Запрашивать достаточно по одной корове. В любом случае запрос нескольких коров одновременно можно разбить на несколько запросов по одной корове с бесконечно малым промежутком по времени.
Это работает в большинстве мест в MacOS, где можно редактировать текст.
Еще полезные комбинации:
Cmd+delete удаляет до конца строки,
Opt+left/right перемещает курсор по слову,
Opt+delete удаляет по слову.
Пойти в конец строки — это Cmd+right. Или left, если нужно в начало
Спасибо за статью, приятно видеть, что Cuda используется в коммерческих проектах. Сам сейчас работаю в академической среде, во многом с кудой.
У меня вопрос: у вас есть ссылки на доступное описание алгоритма сжатия JPEG? Интересно оценить сложность задачи. Судя по вашей производительности в 30 ГБ/c это compute-bound метод?
И еще один: вы не интересовались новой связкой P100 + IBM Power + NVlink? Чтобы устранить задержки от PCI-E?

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity