Посмотрел мельком. Вот оригинал https://github.com/CompVis/stable-diffusion. Качество скорее всего будет совершенно другое, у этой модели 0.8B весов, а у DALL-E 2 35B. Но если интересно поиграться, то развернуть вроде просто.
По поводу второго вопроса - нужные веса обученной сетки, которые Open AI никому не дает, надежда, что кто нибудь соберет датасет и обучит(нужно много GPU железа). Как к примеру было, когда Сбер обучил GPT-3 и выложил веса.
Так они к одинаковому результату и сейчас не приводят из-за рандома, еще накинуть рандома и генерировать больше результатов на один запрос не проблема. :) Мне скорее всего видится, что это сведется к некоторому итеративному процессу(дереву создаваемых изображений), генерируются варианты, человек выбирает лучшие, как-то с ними взаимодействует (пишет новое описание, обводит неудачные куски, что-то дорисовывает), после чего генерируются следующие варианты.
Как раз по тому, как строятся алгоритмы для нейронок, ей оптимально иметь максимально широкий датасет. Можете рассматривать это как "обобщение опыта", чем его больше тем лучше результат. По сути вы предлагаете просто выкинуть, какую-то часть датасета, улучшений это не даст. Придумают новые архитектуры нейронок, какая-то специализация будет, но счет будет идти на десятки. И большие описания(больше страницы текста) для современных нейронок скорее зло чем благо, так как вовсю встает эффект goldfish memory.
Так очевидно почему он не работает, потому что адрес указывает на read-only flash(ROM), который хотя и отображается в адресное пространство изменить нельзя. Работало бы если это был адрес в RAM.
А как же номера банкнот? Мне знакомая рассказывала, что когда наличка приходит в какой-то головной филиал, там стоят такие большие "счетные машины", которые и номер банкноты считывают, так что следы остаются, главное знать за какие концы потянуть.
Мы точно говорим про дамп микросхемы nand памяти? Естественно со стороны пользователя ничего зашифрованным выглядеть не будет, магия происходит на пути контроллер flash <-> микросхема nand памяти. Но если вы попытаетесь восстановить данные с дампа, то надо как минимум будет снять скремблирование(xor с некоторым генерируемым паттерном) которое там точно будет, а так же трансляцию адресов.
Программатор не поможет. Если там не банальная SPI флэшка, то там есть контроллер, который скремблирует или шифрует данные, а так же транслирует адреса(wear leveling, flash translation layer).
Когда учился, в ВУЗе был основной упор на железки(карты Карно, синтез комбинаторных логических схем и все такое). Поэтому про алгоритмы и и программирование приходилось добрасывать самостоятельно. Если бы меня спросил сейчас человек, уже как-то знакомый с программированием, как ему это подтянуть. Посоветовал бы:
Простенькую книжку по дискретной математики, какая понравится. (совершенно базовая: теория множеств, графы, мат. логика, комбинаторика)
Кормен. Алгоритмы: построение и анализ. По мне так, книжка просто супер, одна из самых полезных "фундаментальных", которую я когда либо прочитал по специальности.
Когда-то для меня еще школьника, все началось с книжки Керниган и Ритчи "Язык программирования С" и компилятора Watcom, скачанного с одной из BBS. Из игрушек помимо Civilization еще сильно запомнилась, XCOM.
«Демократия – плохая форма правления, однако ничего лучшего человечество не придумало» то же самое можно сказать и про рыночную экономику. При этом я придерживаюсь мнения, что большинство болячек системы можно лечить правильно регуляцией. По поводу "прогнило", желательно смотреть на периоде минимум 30-40 лет, тогда не все будет так очевидно.
>Вы считате, что нет кода кроме hot spot или что наполнение этого кеша >ничего не стоит? > Если ни то, ни другое, то не совсем понятно, к чему это..
Я имею ввиду, что мало или много для кэша зависит от вероятности cache-miss и латентности на этот cache-miss. И в контексте количественной оценки зависимости производительности архитектуры от этого параметра, она имеет некоторый вероятностный и совершенно нелинейный характер.
>Вообще-то, нет. Будьте внимательны, там написано аппаратный.
Хорошо.
>Это вы сейчас так непроизвольно взяли слова каджита и приписали их >себе?
Давайте считать:
ISA преобразуется один раз декодером в микро-инструкции, микро-инструкции сохраняются в кэше микро-инструкций, когда OoO ядро надо получить данные по инструкциям они берутся из кэша.
front-end дополняет этот граф исполнения сверху, то есть делает префетч на подгрузку инструкций и их декодирование, преобразование в микро-инструкции.
Декодер в OoO подходе это просто штука, которая преобразует некоторый буфер в входной набор микро-инструкций и обладает нужной пропускной способностью.
>При том, что сами недавно объявили декодер частью OoO?
Еще раз жирным "Декодер в OoO подходе", и где вы увидели что декодер является частью OoO? При том что я вам явно до этого расписал, про front-end, back-end и связующей их OoO. Отличии от классики очевидно, в том что инструкции превращаются в микро-инструкции, а не отправляются на исполнение. В это же время вы мне рассказывали про супер-скаляры в духе первого пентиума.
>Чукча не читатель, да?Decoding is done by the 4 Zen decoders > — прямо в той статье, откуда дернута картинка.
>Когда длина инструкции становится известной, можно отдать следующую > иструкцию на декодирование, даже если она не прошла через декодер > полностью. Более того, в зависимости от устройства декодера, у него > может находиться на каждой стадии конвейра по инструкции, в разных > стадиях декодирования, и это то, что делает конвейерный декодер — > конвейерным.
Именно поэтому я вам с самого начала и говорил, что декодер является единым блоком, потому что там есть полно внутренних оптимизаций. И рассматривать его как копи-паст четырех декодеров, не корректно.
>Но вот от уже ваших фантазий о тахионном декодере это действительно >далеко.
Там не было фантазий:
"то есть скорость декодирования гораздо выше чем инструкция-такт"
Если я вам скажу, что скорость обычно подразумевает throughput вас это успокоит?
>Только лишь?
>В мире монопольного доступа единственного потока к процу — да.
>Но это не магия внеочередного выполнения инструкций, OoO этим не >занимается тоже.
Для начала хорошо бы разобраться с одно поточкой прежде чем лезть в дебри.
>Спорите вы, в основном — из-за невнимательности и незнания матчасти.
>Этот просто показал на примере, что утверждение Поэтому CISC, >там или RISC, не имеет никакого решающего значения — >неверно, да нашел несколько крупных изъянов в ваших построениях.
Мне не надо изъяны, интересна количественная оценка прироста производительности при переходе ISA с CISC на RISC. В данном случаи она будет равна, что-то в духе: дельта изменения длины конвейера * вероятность сброса (то есть не предсказанного ветвления). При этом вы утверждаете что эта дельта изменения длины конвейера будет существенной, а не была просто забросана дополнительными вентилями в CISC подходе (пример с умножением).
>берет уже декодированные инструкции и >пытается их выполнить, если не >обнаружит зависимостей по данным.
Прочитайте еще раз все что я вам писал. Декодирование инструкций, OoO и исполнение, полностью развязаны. OoO оперирует некоторой формой графа зависимости инструкций, поэтому то что исполняется - *уже имеет все готовые зависимости*. Это абсолютно, не тот "линейный" супер-скаляр в духе первого пентиума, про который вы мне пытаетесь, что-то рассказать.
Не понятно, только почему тогда в исходном посте вы назвали его "аналоговым". И еще более непонятно, почему вы ему уделили такое внимание в контексте декодера.
>Декодер, как это ни удивительно, занимается декодированием инструкций. А >внеочередное выполнение (OoO) берет уже декодированные инструкции и >пытается их выполнить, если не обнаружит зависимостей по данным.
Декодер преобразует инструкции в микро-инструкции, микро-инструкции исполняются OoO движком, о чем я вам наверное уже 2 или 3 раза написал.
>Никаких эфирно-торсионных асинхронно-регистровых(!) супердекодеров в >них нет. Зато есть несколько независимых койнвейеризированных декодеров >в одной упряжке.
Про асинхронных, никто речь и не вел, а вот про алгоритмы и схемотехнические решения, да. Ровно тем же образом как и умножение можно реализовать за несколько тактов добавив логических элементов, а не то как считают "столбиком".
> Каждый из которых может выдавать на выходе до двух декодированных >инструкций на такт, но имеет штраф в длина конвейра на заполнение с нуля.
Это ваши фантазии. Zen к примеру декодирует 4 инструкции за такт, и декодер, что вполне логично является единым блоком. И сразу, очевидный вопрос, расскажите как эти четыре декодера могут быть независимыми, если инструкции переменной длины, и чтобы получить начало следующей надо в какой-то мере декодировать предыдущую.
Сброс конвейера, это конечно плохо, но в OoO подходе он в основном возможен лишь при ошибки предсказания ветвления.
PS: но вообще я не особо понимаю, о чем мы с вами спорим, особенно в контексте моего начального комментария и статьи. Будете спорить, что RISC за счет снижения сложности декодера(и снижения общего транзисторного бюджета ядра на 5-10%), имеет какие-то существенные преимущества, в контексте OoO архитектур современных высоко производительных процессоров?
Вы сами свои ссылки читали(особенно вторую)? Ни одной внятной рецензируемой статьи, подтверждающую вашу точку зрения, я лично не нашел.
Посмотрел мельком. Вот оригинал https://github.com/CompVis/stable-diffusion. Качество скорее всего будет совершенно другое, у этой модели 0.8B весов, а у DALL-E 2 35B. Но если интересно поиграться, то развернуть вроде просто.
По поводу второго вопроса - нужные веса обученной сетки, которые Open AI никому не дает, надежда, что кто нибудь соберет датасет и обучит(нужно много GPU железа). Как к примеру было, когда Сбер обучил GPT-3 и выложил веса.
Так они к одинаковому результату и сейчас не приводят из-за рандома, еще накинуть рандома и генерировать больше результатов на один запрос не проблема. :) Мне скорее всего видится, что это сведется к некоторому итеративному процессу(дереву создаваемых изображений), генерируются варианты, человек выбирает лучшие, как-то с ними взаимодействует (пишет новое описание, обводит неудачные куски, что-то дорисовывает), после чего генерируются следующие варианты.
Наверняка потому, что это простенький микроконтроллер, без MMU и защиты памяти.
Как раз по тому, как строятся алгоритмы для нейронок, ей оптимально иметь максимально широкий датасет. Можете рассматривать это как "обобщение опыта", чем его больше тем лучше результат. По сути вы предлагаете просто выкинуть, какую-то часть датасета, улучшений это не даст. Придумают новые архитектуры нейронок, какая-то специализация будет, но счет будет идти на десятки. И большие описания(больше страницы текста) для современных нейронок скорее зло чем благо, так как вовсю встает эффект goldfish memory.
Так очевидно почему он не работает, потому что адрес указывает на read-only flash(ROM), который хотя и отображается в адресное пространство изменить нельзя. Работало бы если это был адрес в RAM.
А как же номера банкнот? Мне знакомая рассказывала, что когда наличка приходит в какой-то головной филиал, там стоят такие большие "счетные машины", которые и номер банкноты считывают, так что следы остаются, главное знать за какие концы потянуть.
Согласен, если торчит eMMC, то задача становится значительно проще.
Мы точно говорим про дамп микросхемы nand памяти? Естественно со стороны пользователя ничего зашифрованным выглядеть не будет, магия происходит на пути контроллер flash <-> микросхема nand памяти. Но если вы попытаетесь восстановить данные с дампа, то надо как минимум будет снять скремблирование(xor с некоторым генерируемым паттерном) которое там точно будет, а так же трансляцию адресов.
Программатор не поможет. Если там не банальная SPI флэшка, то там есть контроллер, который скремблирует или шифрует данные, а так же транслирует адреса(wear leveling, flash translation layer).
Добро пожаловать в реальность! ) 99.9% "не стандартной/наколенной" крипты - решето. Крипто стандарты не просто так десятилетиями разрабатывают.
https://programmersought.com/article/13436370754/
В двух словах, суть в том, что дефолтный метод ZipCrypto Store не криптостойкий, если вместо него AES, то для "хакеров" все плохо.
Когда учился, в ВУЗе был основной упор на железки(карты Карно, синтез комбинаторных логических схем и все такое). Поэтому про алгоритмы и и программирование приходилось добрасывать самостоятельно. Если бы меня спросил сейчас человек, уже как-то знакомый с программированием, как ему это подтянуть. Посоветовал бы:
Простенькую книжку по дискретной математики, какая понравится. (совершенно базовая: теория множеств, графы, мат. логика, комбинаторика)
Кормен. Алгоритмы: построение и анализ. По мне так, книжка просто супер, одна из самых полезных "фундаментальных", которую я когда либо прочитал по специальности.
Когда-то для меня еще школьника, все началось с книжки Керниган и Ритчи "Язык программирования С" и компилятора Watcom, скачанного с одной из BBS. Из игрушек помимо Civilization еще сильно запомнилась, XCOM.
«Демократия – плохая форма правления, однако ничего лучшего человечество не придумало» то же самое можно сказать и про рыночную экономику. При этом я придерживаюсь мнения, что большинство болячек системы можно лечить правильно регуляцией. По поводу "прогнило", желательно смотреть на периоде минимум 30-40 лет, тогда не все будет так очевидно.
>Вы считате, что нет кода кроме hot spot или что наполнение этого кеша >ничего не стоит?
> Если ни то, ни другое, то не совсем понятно, к чему это..
Я имею ввиду, что мало или много для кэша зависит от вероятности cache-miss и латентности на этот cache-miss. И в контексте количественной оценки зависимости производительности архитектуры от этого параметра, она имеет некоторый вероятностный и совершенно нелинейный характер.
>Вообще-то, нет. Будьте внимательны, там написано аппаратный.
Хорошо.
>Это вы сейчас так непроизвольно взяли слова каджита и приписали их >себе?
Давайте считать:
ISA преобразуется один раз декодером в микро-инструкции,
микро-инструкции сохраняются в кэше микро-инструкций, когда OoO ядро надо получить данные по инструкциям они берутся из кэша.
front-end дополняет этот граф исполнения сверху, то есть делает префетч на подгрузку инструкций и их декодирование, преобразование в микро-инструкции.
Декодер в OoO подходе это просто штука, которая преобразует некоторый буфер в входной набор микро-инструкций и обладает нужной пропускной способностью.
>При том, что сами недавно объявили декодер частью OoO?
Еще раз жирным "Декодер в OoO подходе", и где вы увидели что декодер является частью OoO? При том что я вам явно до этого расписал, про front-end, back-end и связующей их OoO. Отличии от классики очевидно, в том что инструкции превращаются в микро-инструкции, а не отправляются на исполнение. В это же время вы мне рассказывали про супер-скаляры в духе первого пентиума.
>Чукча не читатель, да?
Decoding is done by the 4 Zen decoders> — прямо в той статье, откуда дернута картинка.>Когда длина инструкции становится известной, можно отдать следующую
> иструкцию на декодирование, даже если она не прошла через декодер
> полностью. Более того, в зависимости от устройства декодера, у него
> может находиться на каждой стадии конвейра по инструкции, в разных
> стадиях декодирования, и это то, что делает конвейерный декодер —
> конвейерным.
Именно поэтому я вам с самого начала и говорил, что декодер является единым блоком, потому что там есть полно внутренних оптимизаций. И рассматривать его как копи-паст четырех декодеров, не корректно.
>Но вот от уже ваших фантазий о тахионном декодере это действительно >далеко.
Там не было фантазий:
"то есть скорость декодирования гораздо выше чем инструкция-такт"
Если я вам скажу, что скорость обычно подразумевает throughput вас это успокоит?
>Только лишь?
>В мире монопольного доступа единственного потока к процу — да.
>Но это не магия внеочередного выполнения инструкций, OoO этим не >занимается тоже.
Для начала хорошо бы разобраться с одно поточкой прежде чем лезть в дебри.
>Спорите вы, в основном — из-за невнимательности и незнания матчасти.
>Этот просто показал на примере, что утверждение
Поэтому CISC, >там или RISC, не имеет никакого решающего значения— >неверно, да нашел несколько крупных изъянов в ваших построениях.Мне не надо изъяны, интересна количественная оценка прироста производительности при переходе ISA с CISC на RISC. В данном случаи она будет равна, что-то в духе: дельта изменения длины конвейера * вероятность сброса (то есть не предсказанного ветвления). При этом вы утверждаете что эта дельта изменения длины конвейера будет существенной, а не была просто забросана дополнительными вентилями в CISC подходе (пример с умножением).
>берет уже декодированные инструкции и >пытается их выполнить, если не >обнаружит зависимостей по данным.
Прочитайте еще раз все что я вам писал. Декодирование инструкций, OoO и исполнение, полностью развязаны. OoO оперирует некоторой формой графа зависимости инструкций, поэтому то что исполняется - *уже имеет все готовые зависимости*. Это абсолютно, не тот "линейный" супер-скаляр в духе первого пентиума, про который вы мне пытаетесь, что-то рассказать.
> 2k uOPs vs billions instructions and Instruction >>> uOP
> Это значит, что его нужно регулярно и быстро пополнять.
Для hot spot, где прежде всего и бывают затыки - не нужно.
>На блок-схеме видно 4 (конвейерезированных) Decoder. У каждого.
На блок-схеме видно единый блок декодирования, с надписью 4-way, то что я собственно и пытаюсь до вас донести.
>ШТА‽
Не понятно, только почему тогда в исходном посте вы назвали его "аналоговым". И еще более непонятно, почему вы ему уделили такое внимание в контексте декодера.
>Декодер, как это ни удивительно, занимается декодированием инструкций. А >внеочередное выполнение (OoO) берет уже декодированные инструкции и >пытается их выполнить, если не обнаружит зависимостей по данным.
Декодер преобразует инструкции в микро-инструкции, микро-инструкции исполняются OoO движком, о чем я вам наверное уже 2 или 3 раза написал.
>Никаких эфирно-торсионных асинхронно-регистровых(!) супердекодеров в >них нет. Зато есть несколько независимых койнвейеризированных декодеров >в одной упряжке.
Про асинхронных, никто речь и не вел, а вот про алгоритмы и схемотехнические решения, да. Ровно тем же образом как и умножение можно реализовать за несколько тактов добавив логических элементов, а не то как считают "столбиком".
> Каждый из которых может выдавать на выходе до двух декодированных >инструкций на такт, но имеет штраф в длина конвейра на заполнение с нуля.
Это ваши фантазии. Zen к примеру декодирует 4 инструкции за такт, и декодер, что вполне логично является единым блоком. И сразу, очевидный вопрос, расскажите как эти четыре декодера могут быть независимыми, если инструкции переменной длины, и чтобы получить начало следующей надо в какой-то мере декодировать предыдущую.
Сброс конвейера, это конечно плохо, но в OoO подходе он в основном возможен лишь при ошибки предсказания ветвления.
PS: но вообще я не особо понимаю, о чем мы с вами спорим, особенно в контексте моего начального комментария и статьи. Будете спорить, что RISC за счет снижения сложности декодера(и снижения общего транзисторного бюджета ядра на 5-10%), имеет какие-то существенные преимущества, в контексте OoO архитектур современных высоко производительных процессоров?
И Вам спасибо, за интересную дискуссию! )