Bitcoin Forum

Local => Идеи => Topic started by: tvv on September 22, 2012, 08:24:41 AM



Title: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on September 22, 2012, 08:24:41 AM
Hello.

  А вот интересно, никто еще не пробовал написать эмулятор CPU на GPGPU? ;)

А то смотрю нынче CPU становиться явно лишней зачастью в компютере ;))
(как показали замеры, старая карта 4890 оказалась в 25 раз быстрее нового 8-ядерного процессора!)

Так что думаю проблем особых написать эмулятор не будет...

Vladimir


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: AV on September 22, 2012, 09:49:20 AM
Оставьте компам проц и биос, это операционные системы пора оптимизировать для выполнения на GPU их самих и их приложений.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on September 22, 2012, 09:52:51 AM
Ну это понятно, но это долго и реально только для того что сразу писано платформо-независимым и имеет исходники...

А вот эмулятор написать не долго, и весь старый код будет работать без переделки.
(производительность в 99% случаев не важна, да и она думаю не замедлиться,
а на задачах допускающих распараллеливание точно увеличиться)


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: AV on September 22, 2012, 09:58:46 AM
А вообще говоря, видеокарта быстрее процессора только на определённом типе задач - на простых легко распараллеливаемых вычислениях.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: Balthazar on September 22, 2012, 11:11:28 AM
Hello.

  А вот интересно, никто еще не пробовал написать эмулятор CPU на GPGPU? ;)

А то смотрю нынче CPU становиться явно лишней зачастью в компютере ;))
(как показали замеры, старая карта 4890 оказалась в 25 раз быстрее нового 8-ядерного процессора!)

Так что думаю проблем особых написать эмулятор не будет...

Vladimir

А смысл? GPU в широком спектре задач проиграет равночастотному Pentium III. Кэш никакой, предсказание ветвлений никакое, префетч никакой... Да все никакое, собственно.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: ShadowAlexey on September 22, 2012, 12:03:02 PM
Вы забываете, возможно вместо предсказателя ветвлений просто исполнять ВСЕ ветки...
Ну в общем то конечно там одни костыли на костылях, так что не стоит...


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on September 22, 2012, 12:11:07 PM
А смысл? GPU в широком спектре задач проиграет равночастотному Pentium III. Кэш никакой, предсказание ветвлений никакое, префетч никакой... Да все никакое, собственно.

все так, да не совсем так ;)

Если сравнивать 1 ядро - то может быть оно немного и уступает,
но совсем чуть-чуть тк в пентиуме много лишнего дерьма понакручено.

Но ядер-то у GPGPU в сотни раз больше!   Так что заменит сотни пентиумов,
пускай даже каждый из них чуть-чуть уступает - не критично.

PS  смотри на это по-другому - для работы мне например и п1-75 хватало,
а вот CPU+MB стоят дороже даже крутой видяхи(хотя и дешевая в 25 раз быстрее),
куда полезнее за эти деньги еще один GPGPU воткнуть.  Ну или 50% съэкономить.

PPS  куда мир катицца ынтересно ;)   Год назад сам взял для крутого компа
под комп. графику и рендер дешевую MB со встроенной видяхой,
и съэкономил на нафиг не нужной видяхе половину цены - посчитал что поток
данных на RAMDAC занимает всего несколько % пропускной способности памяти
и понял что видяха лишняя запчасть, да и тесты это подтверждали, многоядерник
обладал скоростью на программной графике даже выше чем самая крутая видяха...
(Ну а теперь похоже мир перевернулся - скоро можно будет брать крутую видяху с GPGPU
и экономить на CPU и MB, похоже кто-то из них явно лишний ;) )


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on September 22, 2012, 12:15:57 PM
Вы забываете, возможно вместо предсказателя ветвлений просто исполнять ВСЕ ветки...
Ну в общем то конечно там одни костыли на костылях, так что не стоит...

вот-вот, вот и я говорю когда в руках молоток то все вокруг кажеться гвоздями
когда много ядер, то можно тупо наперед исполнять хоть все 256 вариантов, выбрасывая потом лишнее...

Извратец конечно тот еще получиться, но вспоминая x86 код (а я его после PDP-11 увидел),
думаю мне уже ничего более кривым уже не покажеться ;)


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: Balthazar on September 22, 2012, 12:23:55 PM
Вы забываете, возможно вместо предсказателя ветвлений просто исполнять ВСЕ ветки...
Ну в общем то конечно там одни костыли на костылях, так что не стоит...
Если исполнять все ветки, то будет катастрофический просер (именно просер, а не проигрыш) тем же x86 по производительности на ватт при равной производительности. Предсказание ветвлений еще у Pentium IV работало с эффективностью, очень часто превышающей 99.9%. На GPU будут в полной загрузке все блоки в те моменты, когда х86 выключит большую часть ядра. ::)


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on September 22, 2012, 12:28:34 PM
Ну вот, значит и старую добрую кнопочку turbo можно сделать, программно, в виде turbo / low_power ;)

Зеленые явно оценят...



Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: Balthazar on September 22, 2012, 12:31:01 PM
Т.е. искуственно заставить систему жрать побольше без какой-либо пользы, а потом добавить кнопочку для уменьшения прожорливости? Как-то это странно. ::)

Тем более, что x86 в режиме энергосбережения довольно мало потребляют и без всяких кнопочек... Не так как ARMы, но гораздо меньше GPU. ::)


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on September 22, 2012, 12:32:56 PM
А это кстати еще вопрос кто будет меньше жрать - в x86 всякой лишней фигни очень много,
а тут она будет эмулироваться очень редко, только при необходимости, остальное время лишнии ядра стоят.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: Balthazar on September 22, 2012, 12:38:48 PM
А это кстати еще вопрос кто будет меньше жрать - в x86 всякой лишней фигни очень много,
Эта фигня отключается динамически в случае ненадобности, сейчас не 1999 год. ;)

А вот попытка исполнять все ветки одновременно приведет ко вполне однозначному результату.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: FAN on September 22, 2012, 01:12:30 PM
ну так можно дойти до того что прикрутили к видяхе флешку, лан и все - гтовый компьютер на видеокарте :)

но уже давно есть готовые решения, микропк на контроллерах, в которых уже все это есть и стоят они от 35 до 150 уе...
+ к ним можно подключать кучу датчиков и исполнительных девайсов и вообще делать как минимум умный дом...


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on September 22, 2012, 01:21:38 PM
ну так можно дойти до того что прикрутили к видяхе флешку, лан и все - гтовый компьютер на видеокарте :)

похоже все к этому и идет

а десктопы кстати уже практически не нужны - заменяются не только ноутами, но и планшетами, телефонами и тд

единственно еще с мощными видяхами как-то пока держаться - там где мощность этих видях нужна

но уже давно есть готовые решения, микропк на контроллерах, в которых уже все это есть и стоят они от 35 до 150 уе...
+ к ним можно подключать кучу датчиков и исполнительных девайсов и вообще делать как минимум умный дом...

а это уже из другой оперы - GPGPU это прежде всего большая выч моща,
а для управления чаще всего хватает и однокристалок


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: LikMigTel on September 28, 2012, 06:28:52 AM
Все банально. Каждая железяка сделана под свои задачи. Сравнивать одно с другим можно только в рамках узкой конкретной задачи.
Все широкопрофильные вещи более удобные но могут выполнять каждую конкретную задачу хуже чем узкопрофильный вариант который больше ничего не умеет.

Издержки универсализации.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on September 28, 2012, 04:24:52 PM
Может и так, но я не знаю задач где нужен CPU мощнее п1-75 (сам на таком сидел довольно долго, знаю что говорю ;) ).

Конечно он в какие-то моменты сильно тормозит(графика, звук и тд и тп) - но тормозит-то на задачах,
которые идеально подходят для более специализированных DSP и сопроцессоров.


Таким образом, получается что CPU проще эмулировать на более специализированном оборудовании
тк требований к быстродействию CPU практически нет - там где тормозит CPU его лучше заменять чем-то другим.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: naima53 on September 28, 2012, 05:00:23 PM
Может и так, но я не знаю задач где нужен CPU мощнее п1-75 (сам на таком сидел довольно долго, знаю что говорю ;) ).

Конечно он в какие-то моменты сильно тормозит(графика, звук и тд и тп) - но тормозит-то на задачах,
которые идеально подходят для более специализированных DSP и сопроцессоров.


Таким образом, получается что CPU проще эмулировать на более специализированном оборудовании
тк требований к быстродействию CPU практически нет - там где тормозит CPU его лучше заменять чем-то другим.

Я вот не особо специалист в этих компутерех, но сказанное Вами выглядит неплохо... Например, сейчас на целероне 1700 мгц жутко тормозит современные браузеры под ХП. Но тормозят именно при проигрывании флеш видео роликов, причем тот же самый фильм в таком же качестве приспокойно идет в классик медиа плеере к-лите. Так какого ж он рожна собственно должен там тормозить, если браузер это просо "труба" для данных, загружаемых из сети (ну, тот же фильм, но не сразу "весь" на диске, а только первые скажем 20 секунд) ??? Значит там что то точно "заоптимизировали" лишнее...  :-\


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 06, 2012, 08:18:38 PM
меня удивляет, что человек видевший pdp-11 в состоянии генерировать столько бредовых вопросов

(как показали замеры, старая карта 4890 оказалась в 25 раз быстрее нового 8-ядерного процессора!)
...

замеры чего? температуры на Северном полюсе?
неужели непонятно, что эти замеры относятся только к определенному классу задач? А CPU - процессор универсальный, и его способность решать весь имеющийся спектр задач явно лучше, чем у GPU.

А по поводу байки о том, что те, кто знавал DEC с его pdp-11 и vax не понимают, как вообще может работать система команд x86:
Где теперь тот DEC?
Ну а x86 давно уже исполняется на эмуляторах - все современные CPU декодируют команды x86, переводя их во внутреннюю упрощенную систему команд, и только потом исполняют...


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: naima53 on October 07, 2012, 12:32:42 PM
SHawk  Пожалуйста ответьте на вопрос. Я вижу Вы тут почти единственный кто разбирается в алгоритмах шифрования..

Вот тут человек пишет что заметил некую закономерность в именах кошельков. Я тоже ее заметил, когда по своей безграмотности пытался подобрать пару адрес\приватный ключ к списку адресов, запрограммированному с помощью регулярных выражений.  :P
 Насколько это может быть опасно в смысле на сколько упростит задачу подбора пары адрес\прив. ключ, например с помощью программ, аналогичных vanitygen  (https://bitcointalk.org/index.php?topic=25804.0) ? Ведь, насколько я понял, для того что бы подобрать пару адрес(короткий, который исп-ся для зачисления денег)\прив ключ вовсе не нужно делать рассчет всех 256-чего-то-там а достаточно 160-чего-то-там..Ведь таких приватных ключей может быть много, но все они позволят снять чужие деньги.....  :-\ А тут еще и "артефакты" при создании этих самых коротких адресов..  :-\ Кстати, последний свой коммент ОР убрал из того потока, где он предложил что-то-там с примером в коде той утилиты (его же авторства), там было сказано типа "вы можете сами себя укусить если сделать то-то и то то.."




A slightly off-topic, but curious factoid:

I've just noticed that VERY few of these addresses begin with 1[a-z] ... The overwhelming majority begins with 1[A-Z] or 1[0-9]. I would have expected a more random distribution. Any explanation for that? Perhaps I'm missing something obvious.  



Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 07, 2012, 01:34:35 PM
мне лень искать ссылки на то обсуждение, но, как я помню, на этот вопрос сразу был дан ответ типа "не парься, это особенность адреса кошелька и все в пределах статистических правил..."


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 07, 2012, 01:38:57 PM
Кстати, в биткойне если допустим тупо перебрать все эти 160 бит(для ускоренных алгоритмов это возможно), то это приведет к взлому кошелька(или платежа?).

Или уже прикрутили многоуровневую защиту?..

PS  там тоже SHA которые можно быстро перебирать теми-же асиками, или другой код?


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: naima53 on October 07, 2012, 02:03:18 PM
мне лень искать ссылки на то обсуждение, но, как я помню, на этот вопрос сразу был дан ответ типа "не парься, это особенность адреса кошелька и все в пределах статистических правил..."
Вы уж простите меня, но если просто ткнуть на Quote From то откроется та самая ссылка, а вообще вот..
https://bitcointalk.org/index.php?topic=92423.msg1190007#msg1190007

На вопрос не ответили..


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 07, 2012, 05:06:30 PM
мне лень искать ссылки на то обсуждение, но, как я помню, на этот вопрос сразу был дан ответ типа "не парься, это особенность адреса кошелька и все в пределах статистических правил..."
Вы уж простите меня, но если просто ткнуть на Quote From то откроется та самая ссылка, а вообще вот..
https://bitcointalk.org/index.php?topic=92423.msg1190007#msg1190007

На вопрос не ответили..

А это разве не ответ?
Quote
It is definitely an artifact of the base58 encoding and is normal. A small number of addresses will have a slightly smaller length as well.  For a simple illustration, imagine a number set with numbers evenly distributed between 1 and 5999999. This number set will have numbers starting with 6,7,8,9 but will occur far less frequently than ones starting with 1,2,3,4,5. In bitcoin base58 the lowercase letters stand for the highest base58 digits.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 07, 2012, 05:10:50 PM
Кстати, в биткойне если допустим тупо перебрать все эти 160 бит(для ускоренных алгоритмов это возможно), то это приведет к взлому кошелька(или платежа?).

Продолжаешь идиотничать?
Приведи пример хоть одного "ускоренного алгоритма", для которого возможно перебрать 160 бит?
Спорим на 10btc, что не приведешь?


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: naima53 on October 07, 2012, 06:13:07 PM
мне лень искать ссылки на то обсуждение, но, как я помню, на этот вопрос сразу был дан ответ типа "не парься, это особенность адреса кошелька и все в пределах статистических правил..."
Вы уж простите меня, но если просто ткнуть на Quote From то откроется та самая ссылка, а вообще вот..
https://bitcointalk.org/index.php?topic=92423.msg1190007#msg1190007

На вопрос не ответили..

А это разве не ответ?
Quote
It is definitely an artifact of the base58 encoding and is normal. A small number of addresses will have a slightly smaller length as well.  For a simple illustration, imagine a number set with numbers evenly distributed between 1 and 5999999. This number set will have numbers starting with 6,7,8,9 but will occur far less frequently than ones starting with 1,2,3,4,5. In bitcoin base58 the lowercase letters stand for the highest base58 digits.
Спасибо, после пятого раза чтения перевода понял и стало стыдно...  :P


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 07, 2012, 07:28:44 PM
Продолжаешь идиотничать?

ой как опять самокритично ;)

Приведи пример хоть одного "ускоренного алгоритма", для которого возможно перебрать 160 бит?

а ты типа статей не читаешь...
(Ну да ладно - пусть будет на твоей совести ;) )

Ну хоть закон Мура-то поди знаешь, слыхал?..

Скорость развития в 2 раза в год, и продолжает(и скорее всего и дальше продолжит) такими-же темпами,
не смотря на многие физические ограничения - доходят до упора, придумывают чего-нить новенького и дальше...
(потому что закон планово-экономический, а не технический - технологии менять легче чем терять маркетинг)

Ну дак вот, стандартная скорость развития компов - в 2 раза в год, то есть 1 бит если по длине перебора в год.

То есть за год техника развивается настолько, что может за то-же время перебирать ключи на 1 бит длинее.

То есть, если такими темпами и дальше пойдет, то эти 160(80) бит всего лет через 50 будет ломать
за несколько минут стандартный домашний компютер, даже без всяких ухищрений вроде сетей и кластеров.


Так что я повторяю вопрос:  взлом(или полный перебор) 160 бит шифра приведет к взлому кошелька или нет?

Спорим на 10btc, что не приведешь?

маловато будет - 10 бтц я и так намайню вообще ничего не делая, даже на древней 4890 меньше чем за год.

А вот если биток когда кончиться период майна взлетит до ляма баксов как было задумано,
то думаю за такие деньги его только ленивый ломать не будет...

Тем более что на многих кошельках сотни тыс монет - за несколько сотен млрд баксов прикинь сколько можно взломать.

PS  фишку-то битка заценил?  Счас пока период майна он стоит близко к себестоимости по цене энергии и тп,
это и есть основная его защита - то есть "подделывать"-то можно, и даже узаконенно(майнинг),
но это не слишком выгодно пока он стоит на уровне затрат по его генерации.   Но дальше он будет стоить
столько, сколько товару и услуг приходиться на 1 бтц, то есть основный принцип его защиты(невыгодность) будет нарушен...


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 07, 2012, 07:45:18 PM
слышь, аналитик, закон Мура ты неправильно процитировал. Ошибся на 100%.
Так что 160 бит за 300 лет должно перебраться.
Но мы ж не о будущем говорили?
Quote
тупо перебрать все эти 160 бит(для ускоренных алгоритмов это возможно)
это твои слова? Ты не написал "будет возможно через 50 лет", ты написал "это возможно".
А по поводу 10btc - мне показалось, что у тебя есть такая сумма.
Но я готов и на 100 поспорить.
Даже так - назови сумму сам :)


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 07, 2012, 07:56:03 PM
слышь, аналитик, закон Мура ты неправильно процитировал. Ошибся на 100%.

нифига - это в книгах он не правильно приведен.  Смотри прайсы, последнии лет 20.
(Там по технологии что-то вроде 18 мес, но при этом растет так-же и частота и число элементов на кристалле)

Так что в 2 раза в год, ровно 1 бит.

Так что 160 бит за 300 лет должно перебраться.

ну вообще-то 160 лет(точнее лет 100), если полным тупым перебором.

Но ты-то должен знать что сложность подобных асимметричных кодов - корень из длины, то есть 80 бит.
(32 бит и счас любой домашний комп перебирает довольно быстро, то есть лет 50 это правильная оценка)

Но мы ж не о будущем говорили?
Quote

вообще без разницы когда - вопрос в том взлом кода(а он таки не просто возможен, но и неизбежен по закону Мура!)
приведет к взлому кошелька или нет?..

тупо перебрать все эти 160 бит(для ускоренных алгоритмов это возможно)
это твои слова? Ты не написал "будет возможно через 50 лет", ты написал "это возможно".
А по поводу 10btc - мне показалось, что у тебя есть такая сумма.
Но я готов и на 100 поспорить.
Даже так - назови сумму сам :)

а ты еще и считать не умеешь ;)

Имея такой алгоритм можно на майне абсолютно спокойно положить процентов 40 в карман,
то есть 7200*0.4 = 2880 бтц.  В сутки.   Готов спорить на такие суммы? ;)

Vladimir


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 07, 2012, 08:18:25 PM
слышь, аналитик, закон Мура ты неправильно процитировал. Ошибся на 100%.
нифига - это в книгах он не правильно приведен.  Смотри прайсы, последнии лет 20.
(Там по технологии что-то вроде 18 мес, но при этом растет так-же и частота и число элементов на кристалле)
Так что в 2 раза в год, ровно 1 бит.

ну да, в книгах неправильно, один ты знаешь, как правильно. Не врешь? Обосновать можешь? Хоть по прайсам за последние лет 20?

Но ты-то должен знать что сложность подобных асимметричных кодов - корень из длины, то есть 80 бит.

Нет, я этого не знаю. Мало того, я даже знаю, что это не так.
Твоя ахинея про корень из длины имеет отношение к поиску коллизий. К парадоксу дней рождений тоже имеет отношение.
К "сложность подобных асимметричных кодов" отношения не имеет!
Перебирать, в среднем, придется 159 бит. Все остальное - бред.

Имея такой алгоритм можно на майне абсолютно спокойно положить процентов 40 в карман,
то есть 7200*0.4 = 2880 бтц.  В сутки.   Готов спорить на такие суммы? ;)

По этому вопросу я готов спорить на любую сумму!
А ты?

Да и я не прошу раскрывать секрет добычи 2880 бтц в сутки.
Приведи любой другой алгоритм - ты же утверждал
Quote
тупо перебрать все эти 160 бит(для ускоренных алгоритмов это возможно)

я правильно понимаю, ты знаешь какие-то "ускоренные алгоритмы" для которых возможен перебор 160 бит?
Заметь, ты написал 160, а не 80. Ты тогда еще не знал про корень из закона Мура?  ;D


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 07, 2012, 08:50:44 PM
ну да, в книгах неправильно, один ты знаешь, как правильно. Не врешь? Обосновать можешь? Хоть по прайсам за последние лет 20?

еще раз - открываешь прайсы и смотришь.  Ну хоть архив компютерных журналов посмотри...
(у нас был такой местный "монитор", в москве не помню, но точно тоже был)

Объемы памяти, емкость дисков и тд - ровно в 2 раза в год.
(иногда отстают от плана - но потом его нагоняют.  Например была задержка при переходе с шаговых на линейные приводы)
Частоты растут, тактов меньше на команду тратят - примерно в 1.4 раза каждое новое поколение процессора,
но теперь похоже будут так-же увеличивать число ядер, вот в том году 4-6-ядерники были, в этом уже 8 и тд.


Я даже цены на старые компы так считаю - цена будет пропорционально корню, или квадрат из отношения.
(то есть диск на 80 гиг стоит sqrt(80/160) = 70.7% цена 160 гиг диска, или 2 80-ка стоят как 1 на 320)

То есть за 2 года комп дешевеет в 2 раза, или -30% за год. 
(Ну еще 20% за б/у-шность, 20 за гарантию.  Как-то так)

А емкость(и производительность) удваивается каждый год.
(по технологии там 1.5 года тк удвоение только частично за счет технологии, а частично за счет частоты и др - это в книжках,
а маркетинг предельно простой - удвоение за год, и считать проще)

Нет, я этого не знаю. Мало того, я даже знаю, что это не так.
Твоя ахинея про корень из длины имеет отношение к поиску коллизий. К парадоксу дней рождений тоже имеет отношение.
К "сложность подобных асимметричных кодов" отношения не имеет!
Перебирать, в среднем, придется 159 бит. Все остальное - бред.

тем не менее это официальная оценка криптостойкости - корень из числа комбинаций

(Там что-то с разложением на простые множители связано - а их примерно корень из числа шт)

По этому вопросу я готов спорить на любую сумму!
А ты?

еще раз - какой смысл мне спорить на копейки, если примение алгоритма дает на порядки больше?
(Вот если бы ты че-нить умел делать... ;) )

я правильно понимаю, ты знаешь какие-то "ускоренные алгоритмы" для которых возможен перебор 160 бит?
Заметь, ты написал 160, а не 80. Ты тогда еще не знал про корень из закона Мура?  ;D

160 битный асимметричный код ломается за 80 бит перебора - это стандартно, без всяких ускорений.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: loga on October 08, 2012, 07:50:34 AM
160 битный асимметричный код ломается за 80 бит перебора - это стандартно, без всяких ускорений.
Расскажи как.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 08, 2012, 07:56:34 AM
Как-как - тупо перебором конечно.

Просто в асимметричных кодах перебирать можно не все коды, а в 2 раза меньше(типа корень квадратный).
Как-то так.   Это в теории этих кодов должно быть описано - у них криптостойкость меньше чем их длина.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: Balthazar on October 08, 2012, 04:52:35 PM
Нахождение коллизии hash160(публичный ключ) = hash160(публичный ключ №2) не приведет ко взлому кошелька в целом, но пользоваться средствами, отправленными на соответствующий адрес смогут владельцы обеих пар ключей, при условии что средства были отправлены именно на адрес (потому что адрес это x58 нотация hash160(pubkey)), а не публичный ключ.

Если средства отправлены не на хэш, а на полный вариант публичного ключа, то все это не играет никакой роли независимо от законов Мура и прочей лабуды. Так же это не играет роли, если адрес является хэшем скрипта, а не ключа.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 08, 2012, 05:04:14 PM
А второй уровень защиты добавить никак нельзя?..

Допустим потом еще какой-нить второй хэш другого типа спросить от того-же ключа еще раз...

То есть типа коллизией первый уровень можно взломать быстро(ну если комп мощный),
а вот дальше уже допустим несколько подтверждений на каждую попытку, и пусть по 10 мин перебирают,
битов даже может быть и не много, если по несколько минут ждать ответа от сети то замучишься ждать...


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: Balthazar on October 08, 2012, 05:24:47 PM
о_О


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: needbmw on October 08, 2012, 05:30:51 PM
кстати идея не нова! (я о теме сабжа)

Чарльз Мур, создатель языка программирования Форт (Forth), довёл до стадии промышленного производства уникальную разработку — многоядерный процессор GA144 http://www.greenarraychips.com/home/products/index.html (http://www.greenarraychips.com/home/products/index.html). Чип размером 10х10 мм уже поступил в продажу по цене $20 (при заказе от десяти штук), также доступны материнские платы для него. Фактически, это аппаратное воплощение самого языка программирования Форт.

Крайне необычный процессор по ряду параметров не имеет себе равных среди CPU:
144 независимых ядра, которые активируются только при поступлении инструкции, то есть у этого процессора нет такой характеристики как «тактовая частота»;
скорость выполнения инструкций 1400 пикосекунд (эквивалент 700 МГц);
энергопотребление 7 пикоджоулей на одну инструкцию;
энергопотребление в «спящем» режиме менее 100 нановатт;
Многоуровневое программирование даёт возможность писать очень быстрый и простой микрокод либо использовать высокоуровневый язык программирования, либо сочетать оба этих метода в кластерах вычислительных ядер с указанием среди них «хостов» и «сопроцессоров» на выбор.

http://habrahabr.ru/post/133291/ (http://habrahabr.ru/post/133291/)


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: FAN on October 08, 2012, 06:24:55 PM
и хтота их видел живьем? процы :)


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 08, 2012, 06:30:29 PM
Объемы памяти, емкость дисков и тд - ровно в 2 раза в год.

словесный понос продолжается?
Объем дисков очень просто посмотреть в википедии.
Первый винчестер появился в 1980 году и его объем был 5 МБ. Поскольку ты считать даже на пальцах не умеешь, сделаю это за тебя:
1981 - 10МБ, 82 - 20, 83 - 40, 84 - 80, 85 - 160, 86 - 320, 87 - 640, 88 - 1Гб, 89 - 2, 90 - 4, 91 - 8, 92 - 16, 93 - 32, 94 - 64, 95 - 128, 96 - 256, 97 - 512, 98 - 1ТБ
99 - 2 ТБ, 2000 - 4, 2001 - 8, 2002 - 16, 2003 - 32ТБ... ничего странного не замечаешь?
Можем не с 80-го начать.
Quote
2005 год — максимальная ёмкость 500 Гб.
тогда, по-твоему: 2006 - 1ТБ, 2007 - 2, 2008 - 4, 2009 - 8, 2010 - 16, 2011 - 32, 2012 - 64ТБ.
Что-то я не вижу в прайсах в этом году винчестеров на 64ТБ. Наверное, потому, что год еще не закончился? Да?  ;D
В прошлом году ведь продавались 32терабайтники? Просто их быстро раскупили?

(иногда отстают от плана - но потом его нагоняют.  Например была задержка при переходе с шаговых на линейные приводы)

Было бы неплохо, хоть одно подтверждение хоть одного твоего высказывания где-то увидеть...


А емкость(и производительность) удваивается каждый год.
(по технологии там 1.5 года тк удвоение только частично за счет технологии, а частично за счет частоты и др - это в книжках,
а маркетинг предельно простой - удвоение за год, и считать проще)

Привел бы что-ли хоть один пример чего-то, что удвоилось за год?

тем не менее это официальная оценка криптостойкости - корень из числа комбинаций

Если это официальная оценка, дай ссылку на нее?

(Там что-то с разложением на простые множители связано - а их примерно корень из числа шт)

А при чем тут разложение на простые множители? Ты хэш раскладывать собираешься? Или что еще?


По этому вопросу я готов спорить на любую сумму!
А ты?
еще раз - какой смысл мне спорить на копейки, если примение алгоритма дает на порядки больше?
(Вот если бы ты че-нить умел делать... ;) )

Я тебе еще раз повторяю - на ЛЮБУЮ сумму!

Ну, а если "делать", в твоем понимании, это трындеть по-всюду "Я брежу! есть тут кто-нибудь, кто сможет мой бред реализовать?" - то да, такое я делать не умею...


160 битный асимметричный код ломается за 80 бит перебора - это стандартно, без всяких ускорений.

Где ты видишь 160-битный асимметричный код? Ты опять бредишь? SHA не является асимметричным алгоритмом.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 08, 2012, 06:44:31 PM
Как-как - тупо перебором конечно.

Просто в асимметричных кодах перебирать можно не все коды, а в 2 раза меньше(типа корень квадратный).
Как-то так.   Это в теории этих кодов должно быть описано - у них криптостойкость меньше чем их длина.


В 2 раза меньше - это 159 бит, а не 80.

Теория асимметричных кодов не имеет никакого отношения к стойкости хэш-функции SHA.

Если ты где-то краем уха слышал что-то про малопонятные тебе асимметричные коды, то это не дает тебе права безапелляционно рассуждать о криптостойкости также непонятных тебе хэш-функций.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: naima53 on October 08, 2012, 06:54:02 PM
...
Если средства отправлены не на хэш, а на полный вариант публичного ключа, то все это не играет никакой роли независимо от законов Мура и прочей лабуды. Так же это не играет роли, если адрес является хэшем скрипта, а не ключа.
Просветите нас, как это сделать  ::) Хотя бы ради повышения грамотности...


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: Balthazar on October 08, 2012, 07:11:04 PM
...
Если средства отправлены не на хэш, а на полный вариант публичного ключа, то все это не играет никакой роли независимо от законов Мура и прочей лабуды. Так же это не играет роли, если адрес является хэшем скрипта, а не ключа.
Просветите нас, как это сделать  ::) Хотя бы ради повышения грамотности...
Это можно сделать, вручную создав транзакцию, и отправив ее на клиент в hex-представлении соответствующим методом RPC. Стандартных же средств сделать это клиентом нет.

Кстати, созданные стандартным клиентом generated транзакции идут на публичный ключ, а не на хэш. По-другому клиент просто не умеет, то есть все выплаты с майнинга идут на публичный ключ, если майнинг использует для обмена с биткоином протокол getwork. Если используется getmemorypool, то ситуация другая, большинство реализаций использующих его пулсерверов перечисляют награду на хэш публичного ключа.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 08, 2012, 10:11:32 PM
словесный понос продолжается?
Объем дисков очень просто посмотреть в википедии.
Первый винчестер появился в 1980 году и его объем был 5 МБ.

чушь.

5-10МБ - это 90-91 год.  Причем в 5" упаковке с шаговым двигателем.  (3.5" значит раза в 2 меньше при той-же плотности)

(не путать с 8-10" дисковыми пакетами от ЕС и СМ ЭВМ - это совсем другая майнфреймовская пестня(лебединная ;) )
Там тупо площадь блина раз в 10 больше)


Год назад самые ходовые были 1.5-2T - в этом году значит должно быть 3-4T.
(дальше можешь рассчитать сам)

Вот тупо даты выпуска с этикеток (с того хлама что под рукой на полке)
20гиг - 2008г (мл. модель - скорее всего в том-же году на тех-же головках и дисках были варианты в 2-6 раз больше)
2Т - 2011
400Г - 2006г
123Г - 2004г
10Г - 2001г(гарантийка, выпуск хз)
80Г - 2003г
4.3Г - 2000г

Сам аппроксимируешь?..

PS  могу фотки этикеток сделать если не веришь.  (Впрочем ты и глазам своим все равно не поверишь ;) )


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 08, 2012, 10:20:27 PM
В 2 раза меньше - это 159 бит, а не 80.

ой...

А тебе не приходила в голову такая простая мысль - что нелинейность приводит тупо к потери информации?..

У линейных функций действительно 2**N кодовых комбинаций. 
(Но там такая жалость - обратная считается вообще за 1 итерацию.
А введение нелинейности вообще уменьшает множество возможных кодов)

PS  со всякими АКФ/ВКФ, кодами грея, ECC и кодовыми расстояними знаком?


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: FAN on October 09, 2012, 12:27:18 AM
лучше сделать эмулятор басика на спартане(виртексе), который сэмулировать на цпу, который в свою очреедь сэмулировать на гпу...
и тогда с одной видяшки можно будет выжать 1000 асиков по 10Тхеш/с каждый и начнется новаяя эра майнинга... :)


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 09, 2012, 05:26:28 PM
словесный понос продолжается?
Объем дисков очень просто посмотреть в википедии.
Первый винчестер появился в 1980 году и его объем был 5 МБ.

чушь.

5-10МБ - это 90-91 год.  Причем в 5" упаковке с шаговым двигателем.  (3.5" значит раза в 2 меньше при той-же плотности)

(не путать с 8-10" дисковыми пакетами от ЕС и СМ ЭВМ - это совсем другая майнфреймовская пестня(лебединная ;) )
Там тупо площадь блина раз в 10 больше)


Год назад самые ходовые были 1.5-2T - в этом году значит должно быть 3-4T.
(дальше можешь рассчитать сам)

Вот тупо даты выпуска с этикеток (с того хлама что под рукой на полке)
20гиг - 2008г (мл. модель - скорее всего в том-же году на тех-же головках и дисках были варианты в 2-6 раз больше)
2Т - 2011
400Г - 2006г
123Г - 2004г
10Г - 2001г(гарантийка, выпуск хз)
80Г - 2003г
4.3Г - 2000г

Сам аппроксимируешь?..

PS  могу фотки этикеток сделать если не веришь.  (Впрочем ты и глазам своим все равно не поверишь ;) )



Ох и утомил ты своим бредом.
Вот ты привел цифры со своих этикеток. И что ты этим хотел сказать? Что ты не умеешь "аппроксимировать"?
Да не умеешь.
400Г - 2006г
        по твоей теории в 2012 году набегает 25 ТБ
123Г - 2004г
        по твоей теории в 2012 году набегает 31 ТБ
10Г - 2001г(гарантийка, выпуск хз)
        по твоей теории в 2012 году набегает 20 ТБ
80Г - 2003г
        по твоей теории в 2012 году набегает 41 ТБ
4.3Г - 2000г
        по твоей теории в 2012 году набегает 18 ТБ


5-10МБ по-твоему были в 91 году? а ничего, что это всего несколько 3х-дюймовых дискет, которые появились раньше 90-х?


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: naima53 on October 09, 2012, 05:31:20 PM
Суперофтопиковая тема.. даже стыдно за то что я начал, упомянув про слабость (символическую) в сети BTC

Да что вы паритесь с плотностью дисков? Ведь вообще разговор был про удвоение выч. мощности..  :-\  Да и ведь уперлись производители дисков в физические ограничения вроде как головок резистивных (поправьте если не так)


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: Balthazar on October 09, 2012, 05:32:00 PM
Помню 40-меговый макстор... До сих пор работает :D


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: naima53 on October 09, 2012, 05:36:27 PM
Помню 40-меговый макстор... До сих пор работает :D
qwebec вроде 30 метров в 5"25 с шаговым механизмом (жжужалка под вин95, на ней фокспро с медицинской фигней какой то был  ::) из под сеанса дос-а... Проапгрейдил на сигейт 160ку, (мб ест...но), на нем до сих пор лежат ключи от PGP , тоже под дос еще...


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 09, 2012, 05:44:28 PM
В 2 раза меньше - это 159 бит, а не 80.

ой...

А тебе не приходила в голову такая простая мысль - что нелинейность приводит тупо к потери информации?..

У линейных функций действительно 2**N кодовых комбинаций. 
(Но там такая жалость - обратная считается вообще за 1 итерацию.
А введение нелинейности вообще уменьшает множество возможных кодов)

PS  со всякими АКФ/ВКФ, кодами грея, ECC и кодовыми расстояними знаком?


Слушай, балбес, у меня высшее математическое образование и не надо меня пугать терминами, в которых ты сам не разбираешься.

Хочешь, я приведу тебе пример НЕЛИНЕЙНОЙ функции, у которой 2**N (как ты это назвал?) "кодовых комбинаций"? И нет никакой потери информации.
Так что твой тезис "нелинейность приводит тупо к потери информации" в корне неверен, как и все, что ты несешь.

Давай поспорим с тобой, что есть такая функция?
Если у тебя нет денег, можем поспорить на то, что проигравший перейдет на этом форуме в режим readonly и перестанет тут бредить?  ;D

И еще. Ты кроме всего прочего забыл, что на вход SHA (той самой 160-битной функции) поступает значительно больший по размерам блок, чем получается на выходе.
Поэтому ни один хоть немного умный человек ни в каком бреду не рискнет утверждать, что у функции SHA из 2**160 выходных значений есть недостижимые.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 09, 2012, 05:50:57 PM
Суперофтопиковая тема.. даже стыдно за то что я начал, упомянув про слабость (символическую) в сети BTC

Да что вы паритесь с плотностью дисков? Ведь вообще разговор был про удвоение выч. мощности..  :-\  Да и ведь уперлись производители дисков в физические ограничения вроде как головок резистивных (поправьте если не так)

прошу прощения, что перешел на диски, но это единственное, от чего есть этикетки у Трактователя закона Мура...
Боюсь, что на уровне мипсов и флопсов он не способен изъясняться...

Да и вообще, пора завязывать... повеселились и будет...


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: naima53 on October 09, 2012, 05:59:07 PM
....
Да и вообще, пора завязывать... повеселились и будет...
Да, а то я начинаю думать что тут промелькнула сколько то постов выше СтрашнаяИстина и ее решили замазать...  ::) Как тут (https://bitcointalk.org/index.php?topic=105095.msg1156866#msg1156866) (кстати вполне замазали, а член тот исчез, и не переквалифицировался ли он в , в, ну, Вы меня поняли кого  :P )


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: Balthazar on October 09, 2012, 06:04:26 PM
Член тот исчез после провала одной идиотской темы. ::)

https://bitcointalk.org/index.php?topic=106453.0


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 09, 2012, 07:54:38 PM
Ох и утомил ты своим бредом.
Вот ты привел цифры со своих этикеток. И что ты этим хотел сказать? Что ты не умеешь "аппроксимировать"?
Да не умеешь.

а ты не заметил, что оценка примерно одинаковая получается?
Это при том что разница в 100 раз по объему!..

Но ты не ленивый, как я посмотрю ;)

400Г - 2006г
        по твоей теории в 2012 году набегает 25 ТБ
123Г - 2004г
        по твоей теории в 2012 году набегает 31 ТБ
10Г - 2001г(гарантийка, выпуск хз)
        по твоей теории в 2012 году набегает 20 ТБ
80Г - 2003г
        по твоей теории в 2012 году набегает 41 ТБ
4.3Г - 2000г
        по твоей теории в 2012 году набегает 18 ТБ

Хм.  Хочешь сказать что сейчас идет отставание на 2-3 года?..   И правда.
(ну почему тоже понятно - кризис и все такое, тут конкурентов съели,
плюс этот вирус который попалил фирмварь винтов...  Ну и технологические сложности с новыми головками и блинами)

Но не переживай - они нагонят.   

Логичнее было бы забить, и дальше просто продолжать теми же темпами - но как показывает анализ
предыдущих отставаний им почему-то закон Мура дороже, и они через несколько лет догоняют.
(Например при переходе от шаговых к линейным движкам была задержка - потом новые модели
поперли как грибы после дождя, один круче другого)

(Хотя на этот раз могут и забить - с процами ведь тоже задержка из-за того что софт не рассчитан на много ядер,
но думаю что если развитие пойдет по пути эмуляции CPU на микроядрах GPGPU то нагонят)


5-10МБ по-твоему были в 91 году?

у нас - да, хотя возможно они появились чуть раньше.

Причем первые были 5" и двойной высоты, потом у них пошли 5" одинарной высоты (ST-225, ST-251)


а ничего, что это всего несколько 3х-дюймовых дискет, которые появились раньше 90-х?

а это ничего.  Причем абсолютно ничего - дискеты это гибкая пленка...  Хотя какая-то связь наверняка есть.

Разработка идет головки и покрытия диска - это определяет плотность записи.

Дальше по плотности записи определяется емкость через площадь - то есть дистигнутый уровень технологии
уже легче сувать куда угодно, 5" и 3" отличаются раза в 2 по площади.
(но выпуск моделей обычно идет именно по емкости - если это один сегмент рынка.
Иногда поставлялись диски ноутбучного типоразмера через переходники - цена при этом была та-же.
Либо 2 диска одинаковой емкости отличались раза в 2-3 по числу головок - соотв. диски новой технологии
были легкие и простые, старые тяжелые с несколькими блинами, но емкость и цена одинакова)

Vladimir


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 09, 2012, 08:39:48 PM
Слушай, балбес, у меня высшее математическое образование и не надо меня пугать терминами, в которых ты сам не разбираешься.

ну я же уже намекал что нобелевку вам не дают не за то что математик у Нобеля жену увел ;)

Довольно бесполезный математики народец - тормозной-с ;)   Нет готовой теоремы - и все, приехали...
(а я вот всегда Ж чую где надо искать, хотя половину математики уже наверно и не вспомню без справочника ;) )

Хочешь, я приведу тебе пример НЕЛИНЕЙНОЙ функции, у которой 2**N (как ты это назвал?) "кодовых комбинаций"? И нет никакой потери информации.

да запросто - но такая функция не будет криптографической, такая вот блин жалость.
Обратная функция найдеться очень быстро - в отличии от функций где комбинаций вроде бы меньше,
но они почему-то криптографические.  (потому и перебирать надо не в 2 раза меньше, а в 2 раза меньше бит)

Так что твой тезис "нелинейность приводит тупо к потери информации" в корне неверен, как и все, что ты несешь.

получается что приводит, как ни странно

весь и смак-то криптографии в том что решений много и перебирать их долго

Если у тебя нет денег, можем поспорить на то, что проигравший перейдет на этом форуме в режим readonly и перестанет тут бредить?  ;D

ну нету у тебя денег, которые могут меня заинтересовать (меня и весь биткоин-то интересует только косвенно,
а так это копейки даже полная его капитализация)

А вот что полезного ты можешь предложить?.. ;)
(умел бы аналитически преобразовывать полиномы - можно было бы поговорить,
а ты даже SHA записать в символической форме не можешь, не то что его обработать)


И еще. Ты кроме всего прочего забыл, что на вход SHA (той самой 160-битной функции) поступает значительно больший по размерам блок, чем получается на выходе.

да

именно это и облегчает задачу, хотя ты наверняка думаешь наоборот

Поэтому ни один хоть немного умный человек ни в каком бреду не рискнет утверждать, что у функции SHA из 2**160 выходных значений есть недостижимые.

с ПШС сигналами знаком?   Даже там не все гладко, шумит-с не смотря на все старанья с подбором кодов...

Vladimir


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 09, 2012, 08:54:13 PM
(а я вот всегда Ж чую где надо искать, хотя половину математики уже наверно и не вспомню без справочника ;) )

И что твоя Ж уже нашла в этой жизни? Тебе есть чем гордиться?

Хочешь, я приведу тебе пример НЕЛИНЕЙНОЙ функции, у которой 2**N (как ты это назвал?) "кодовых комбинаций"? И нет никакой потери информации.

да запросто - но такая функция не будет криптографической, такая вот блин жалость.

Спорим, она будет криптографической?


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 10, 2012, 06:50:58 AM
Спорим, она будет криптографической?

(Биты переставишь? ;) )

не будет - не того класса как нужна в биткойне.

Ну а так просто хочешь я тебе из 1 цифры приведу код, который не вскрывается даже полным перебором?
(кстати полный перебор сможешь сделать даже в уме)

PS  да кстати а что они там подразумевают под эллиптическими кривыми? ;)
(свойства эллипса знаешь? ;) )


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 10, 2012, 07:29:55 AM
Слушай, балбес, у меня высшее математическое образование и не надо меня пугать терминами, в которых ты сам не разбираешься.

и что, что-нить еще помнишь?

Сможешь рассчитать например пушку для электронного луча?
(с учетом волновых функций - без этого можно и на линейке посчитать)
В смысле вывести формулы, с нуля...


Ну или че-нить попроще.  Например - какая будет скорость перебора скажем у кг asic чипов по современной технологии...
(а потом оценить сколько битов в принципе можно ломануть тупо в лоб при желании)


Хочешь, я приведу тебе пример НЕЛИНЕЙНОЙ функции, у которой 2**N (как ты это назвал?) "кодовых комбинаций"? И нет никакой потери информации.
Так что твой тезис "нелинейность приводит тупо к потери информации" в корне неверен, как и все, что ты несешь.

вообще насчет общего случая и речи не было - а в SHA точно приводит тк там выбран такой метод реализации

насчет общего случая - вопрос интересный, IMHO скорее всего тоже, но проверять лень ;)

а в SHA совершенно точно информация теряется - что облегчает перебор


Если у тебя нет денег,

а ты богатый? ;)

Сколько можешь денег дать?   (не мне конечно - вложить в проекты)


И еще. Ты кроме всего прочего забыл, что на вход SHA (той самой 160-битной функции) поступает значительно больший по размерам блок, чем получается на выходе.

намекну немного - в SHA нелинейность достигается функциями с потерей информации,
поэтому это очень сильно упрощает задачу, а не усложняет как ты думаешь. 
(вот как этого можно сразу не понять - не понимаю)


Поэтому ни один хоть немного умный человек ни в каком бреду не рискнет утверждать, что у функции SHA из 2**160 выходных значений есть недостижимые.

ну во-первых для одинарной SHA это еще надо проверять,
а во-вторых там двойная - а вот у двойной такие комбинации будут уже наверняка!  (хоть и не 100% конечно)

Как этого можно не понимать?..

Vladimir
PS  кстати теоретически для любого кода можно построить полную таблицу, и ломать за 1 такт.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: naima53 on October 10, 2012, 01:51:38 PM
....
PS  кстати теоретически для любого кода можно построить полную таблицу, и ломать за 1 такт.

Вот за такой выпад мне на иноветке ответили:  ;D Да, но только тогда если вы будете записывать биты непосредственно в атомы, то всех атомов на платене Земля не хватит для записи такой таблицы. ..... ..... Конечно вы можете подобрать ключ, это не невозможно, так же не невозможно как и тот единственный сперматазоид из миллиардов превратился в Вас в Вашей матери..  ;D ;D Кстати, СмертьИналоги помоему ответил, насколько я понял он в команде разработчиков этого всего


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 10, 2012, 01:58:30 PM
А кто сказал что надо ограничиваться атомами на земле? ;)  Да и они плохо подходят для процессора...

Ну мож какой-нить межпланетный газ заюзать?..  Почему бы и нет - теоретически возможно...

PS  ну и потом не обязательно атомы - кстати в квантовых обещают что они такие задачки
на нескольких атомах как орешки будут щелкать ;)


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 10, 2012, 05:23:42 PM

вообще насчет общего случая и речи не было - а в SHA точно приводит тк там выбран такой метод реализации
насчет общего случая - вопрос интересный, IMHO скорее всего тоже, но проверять лень ;)
а в SHA совершенно точно информация теряется - что облегчает перебор


Че ты юлишь? Все твои утверждения в форуме прописаны и разобраны мной на цитаты. Перечитай.
Когда ты говорил "она не будет криптографической" - ты о SHA, что ли, говорил или, все же, о другой какой-то функции?

а ты богатый? ;)
Да.

намекну немного - в SHA нелинейность достигается функциями с потерей информации,

Засунь свои намеки себе в то место, которым ты думаешь ("чуешь")...
Мне твои намеки не нужны - я знаю, что такое нелинейность и чем она достигается. Ты же, явно, не знаешь, что и демонстрируешь своим бредом.


Поэтому ни один хоть немного умный человек ни в каком бреду не рискнет утверждать, что у функции SHA из 2**160 выходных значений есть недостижимые.

ну во-первых для одинарной SHA это еще надо проверять,
а во-вторых там двойная - а вот у двойной такие комбинации будут уже наверняка!  (хоть и не 100% конечно)

Как этого можно не понимать?..

Ты опять думаешь своей "Ж".
"а во-вторых там двойная" - это ты что имел ввиду?
Двойная функция SHA256 используется для... угадай чего?
Одинарная функция SHA1 используется для... еще раз угадай?
А теперь угадай, о каком из вариантов ты говорил, когда вопрошал "Кстати, в биткойне если допустим тупо перебрать все эти 160 бит(для ускоренных алгоритмов это возможно), то это приведет к взлому кошелька(или платежа?)"?


PS  кстати теоретически для любого кода можно построить полную таблицу, и ломать за 1 такт.

Спорим на щелбан, что это невозможно?
Хотя, да, спорить ты трусишь...
1. Во всей вселенной нет возможности сохранить 2**160 состояний.
2. Среди 2**160 состояний ты за один такт НИЧЕГО НЕ НАЙДЕШЬ!


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 10, 2012, 05:55:17 PM
Когда ты говорил "она не будет криптографической" - ты о SHA, что ли, говорил или, все же, о другой какой-то функции?

да не применить тут другие!  Специфика биткойна панимаешь такая...

Ну то есть попутать биты или еще чего такого конечно возможно - но проблема в том что эту функцию
должны знать все, а это экв ключу.  То есть такие функции в применениях как в биткойне вообще ломаются
за 1 раз без всякого перебора...


Спорим на щелбан, что это невозможно?
Хотя, да, спорить ты трусишь...
1. Во всей вселенной нет возможности сохранить 2**160 состояний.
2. Среди 2**160 состояний ты за один такт НИЧЕГО НЕ НАЙДЕШЬ!

тут и терабайт нормальной памяти не найдешь, дак и что с того?..

Принцип вполне рабочий.
(если бы думал дальше как математик - многое бы понял.
А физ реализуемость никого не волнует - никто же не собирался так делать.
Принцип выше)

Vladimir
PS  хитрый код можно задать таблицей - самое универсальное.  Но поскольку она известна - ломается сразу.
А если асимметричка - там взломостойкость ниже чем число битов, это неизбежно.
(только XOR не теряет информацию - но он линейный и сразу ломается!..
Больше ты никак не введешь несимметрию, не потеряв информацию и не снизив устойчивость.
По кр мере не на такой простой реализации...)


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 10, 2012, 06:55:20 PM

PS  хитрый код можно задать таблицей - самое универсальное.  Но поскольку она известна - ломается сразу.
А если асимметричка - там взломостойкость ниже чем число битов, это неизбежно.
(только XOR не теряет информацию - но он линейный и сразу ломается!..
Больше ты никак не введешь несимметрию, не потеряв информацию и не снизив устойчивость.
По кр мере не на такой простой реализации...)


я не понимаю твоего бреда.

"PS  хитрый код можно задать таблицей - самое универсальное.  Но поскольку она известна - ломается сразу." - ты только что утверждал, что ЛЮБОЙ код (а не только "хитрый") можно задать таблицей. Но что-то ни один общеизвестный криптографический стандарт не "ломается сразу".

"только XOR не теряет информацию" - это неверно.

"Больше ты никак не введешь несимметрию, не потеряв информацию и не снизив устойчивость." - с каких пор мы стали стремиться к "несимметрии" - зачем она нам, я не понимаю...

Почитай на досуге определение термина "асимметричка". Или дай свое определение.

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

Если ты так уверен в своей позиции - чего ж не споришь?
Только не ной опять про мои деньги, которые тебе не нужны. На щелбан давай поспорим?


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: naima53 on October 11, 2012, 02:49:27 PM
Это конечно все интересно, но моя шапка из фольги краями начала уже проникать в мозг и замыкать  ;D Так вот я начинаю думать что эту тему решили завалить хитрые агенты Инте..ов и АНДов дабы тут не появился какой нибудь гений и не написал код, позволяющий многократно ускорить работу процессоров в прикладных задачах.
 Несколько лет назад мне знакомый передал несколько раровских архивов что бы я попробовал снять с них пароль, на них были важные для него данные. Я примерно знал, как это работает и подумал что если пароли не длинные то чем черт не шутит. Стал искать темы в инете и столкнулся с информацией о Cuda . Переводов почти не было, но это заинтриговало меня. Запустил (уже не помню но не крарк) командный расшифровщик на Нвидии своей и ужаснулся на сколько это быстрее проца! В итоге 2 из 6ти архива открылись с использованием словарей, остальные - забил через неделю подбора. В общем-то так и познакомился с BTC , а вовсе не из за денег, жаль, потому что узнал про него как раз из за того что там началось использование ГПУ, то есть поздно уже было.
 Я понимаю что далеко не все задачи в IBM-PC возможно решать таким гигантским распараллеливанием, но вполне можно многие задачи переложить на ГПУ. Думаю, корпорациям в-общем то не выгодно такой расклад, ведь старое железо получит большое "второе дыхание".


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: kimmeriets on October 12, 2012, 05:15:23 AM
Слушай, балбес, у меня высшее математическое образование
Перельман, ты?


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 16, 2012, 01:50:33 PM


Кстати, а сколько аппаратный майнер занимает лог. элементов(или транзисторов) ?


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 16, 2012, 05:29:40 PM


Кстати, а сколько аппаратный майнер занимает лог. элементов(или транзисторов) ?


сделай что-нибудь самостоятельно - ответь на свой вопрос сам:

1. найди на этом форуме или в таблице сравнения оборудования на википедии ту самую ПЛИС фирмы Xilinx, на которой сделано большинство "аппаратных майнеров";
2. сходи на сайт фирмы Xilinx и найди описание этой микросхемы. В нем будет указано количество лог. элементов и условных вентилей (не транзисторов);
3. считай, что ты получил искомое число, т.к. реализация двух конвейеров SHA256 как раз и занимает почти всю микросхему.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 20, 2012, 01:02:11 AM
1. найди на этом форуме или в таблице сравнения оборудования на википедии ту самую ПЛИС фирмы Xilinx, на которой сделано большинство "аппаратных майнеров";
2. сходи на сайт фирмы Xilinx и найди описание этой микросхемы. В нем будет указано количество лог. элементов и условных вентилей (не транзисторов);
3. считай, что ты получил искомое число, т.к. реализация двух конвейеров SHA256 как раз и занимает почти всю микросхему.


1.  Мне в падлу искать по всему интернету где вы (укуренные линуксоиды(tm) ;) ) исходники своих поделок прячите - бывает
   быстрее заново написать, чем что-то найти...   Складывать в одно место(хотя бы ссылки) слабо? ;)

2.  Мне в падлу ковыряться во всяком не документированном Г вроде ксилинкса... 
   (насколько я знаю ни одна из fpga-шных фирм описание внутренней архитектуры кристалла не дает)

   К тому-же если бы ты занимался fpga чуть серьезнее, то знал бы, что ячейки в них бывают разные - иногда
на простой триггер надо 2 ячейки, а иногда там целый чип идет за ячейку(блоки SRAM, АЛУ и тп в новых сериях)...

3.  Судя по аппаратной схеме SHA там надо 256 триггеров на сдвиговый регистр + чуть-чуть логики.
   (итого думаю не более 300 ячеек уровня триггера, а вот сколько это на кремнии х.з.)

Vladimir
PS  да, кстати, еще одна перспективная тема которую можно поднять за счет майнинга - разработка открытых fpga!
Вот такой проект имело бы смысл замутить - тут тираж за счет мелких разработчиков может быть большим...
Есть желание скинуться на такой проект?..
(дальше немного рекламки и китайцы заметят - начнут штамповать на своих фабриках по 10 копеек,
а технологии современные у них есть)


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: Balthazar on October 22, 2012, 06:09:22 PM
У китайцев давно есть опенсорсные фпга-майнеры.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 22, 2012, 07:02:44 PM
Я имел ввиду не майнеры, а саму fpga матрицу сделать открытой и дешевой.

А уж на готовой матрице не долго сделать хоть майнер хоть что...

То есть майнинг может помоч сделать матрицы дешевыми и открытыми.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 26, 2012, 03:30:09 PM
я, тут, загорал недельку, так что отсутствовал в теме...

Quote
бывает быстрее заново написать, чем что-то найти

Это ж ты не о себе писал? Сомневаюсь, что ты хоть что-то можешь написать быстрее, чем найти в сети готовое...

Quote
(насколько я знаю ни одна из fpga-шных фирм описание внутренней архитектуры кристалла не дает)

Бред. Все fpga-шные фирмы дают описания на свои чипы.

Quote
К тому-же если бы ты занимался fpga чуть серьезнее, то знал бы, что ячейки в них бывают разные - иногда
на простой триггер надо 2 ячейки, а иногда там целый чип идет за ячейку(блоки SRAM, АЛУ и тп в новых сериях)...

Что значит "чуть серьезнее"? Объясни, плиз.
Я полностью написал майнер под fpga, полностью написал к нему интерфейсную часть для компьютера, полностью написал софт, работающий с сетью.
В результате майню на всем своем. Ты знаешь тех, кто "чуть серьезнее"?

В "fpga" в которых "надо 2 ячейки на триггер" SHA256 не влезет и они, кстати, cpld называются - термин fpga к ним неприменим. Во ВСЕХ пригодных для майнинга fpga полный триггер встроен в каждую ячейку.

Quote
Судя по аппаратной схеме SHA там надо 256 триггеров на сдвиговый регистр + чуть-чуть логики.

Это очень примитивное суждение. При такой реализации SHA будет работать очень медленно и неэффективно. Триггеров, для нормальной работы нужно значительно больше, причем на КАЖДЫЙ такт. Кроме того, логики тоже немало уходит - там полно сумматоров по модулю 2**32, которые и жрут весь временнОй ресурс...

Quote
разработка открытых fpga
Че ты там разрабатывать собрался? Придумаешь свою собственную ячейку 2-И-НЕ-tvv и будешь ее китайцам впаривать?


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 26, 2012, 06:02:13 PM
Это ж ты не о себе писал? Сомневаюсь, что ты хоть что-то можешь написать быстрее, чем найти в сети готовое...

зря сомневаешься - разбираться с этими каракулями обычно сложнее чем переписать сразу как надо,
аккуратно написанных проектов единицы.

Я и с математикой особо не церемонюсь - все что надо предпочитаю выводить сам.
(потому и не помню имен тех балбесов чьими именами названы теоремы и функции - а тебя судя по всему это ставит в полный тупик тк ничего кроме названий ты похоже в школе не учил и сути не понимаешь)

Бред. Все fpga-шные фирмы дают описания на свои чипы.

ни одного не видел - секрет фирмы-с...

Что блин меня напрягает - мне конечно пофиг как они свои проблемы решали, но например при отладке хотелось бы осциллом и hex-редактором видеть и понимать какой бит конфигурации чего означает и где может глючить...

Что значит "чуть серьезнее"? Объясни, плиз.
Я полностью написал майнер под fpga, полностью написал к нему интерфейсную часть для компьютера, полностью написал софт, работающий с сетью.
В результате майню на всем своем. Ты знаешь тех, кто "чуть серьезнее"?

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


В "fpga" в которых "надо 2 ячейки на триггер" SHA256 не влезет и они, кстати, cpld называются - термин fpga к ним неприменим. Во ВСЕХ пригодных для майнинга fpga полный триггер встроен в каждую ячейку.

вот и я про то-же - на каждый элемент там много всякой фигни лишней + коммутатор,
так что КПД использования кремния ниже плинтуса.


Quote
Судя по аппаратной схеме SHA там надо 256 триггеров на сдвиговый регистр + чуть-чуть логики.

Это очень примитивное суждение. При такой реализации SHA будет работать очень медленно и неэффективно. Триггеров, для нормальной работы нужно значительно больше, причем на КАЖДЫЙ такт. Кроме того, логики тоже немало уходит - там полно сумматоров по модулю 2**32, которые и жрут весь временнОй ресурс...

Тюююю...

До тебя еще до сих пор даже не дошло, что может быть 2 формы реализации этой функции - параллельная и последовательная.

Базовая(исходная) именно последовательная, кстати.  Из нее уже оптимизацией получен алгоритм для 32-бит CPU - и кстати далеко не все функции так можно эффективно преобразовать - скорее всего они специально выбирали SHA стандарт из определенного класса функций, который легко оптимизировать под CPU.  Но сути это не меняет - для любой функции всегда есть последовательная схема, а вот оптизированный алгоритм под CPU может существовать не всегда.

Ну дак вот, никакого 32-бит сумматора там нет - там просто несколько лог. элементов, и все.  Никаких 32-бит АЛУ не нужно - в последовательной форме их и нету изначально, это уже потом когда преобразовывали просто воспользовались готовым АЛУ CPU, коли уж оно есть в процессоре, отчего ж не использовать его.


А схема там предельно простая - похожа на CRC схемы, тока в отводках от регистра часть XOR заменена другими для придания нелинейности, вот и все.  И кстати там в вики и аппаратная последовательная схема тоже есть - надо было читать внимательно...


Quote
разработка открытых fpga
Че ты там разрабатывать собрался? Придумаешь свою собственную ячейку 2-И-НЕ-tvv и будешь ее китайцам впаривать?
[/quote]

ну, типа того ;)

Софт потом и опенсорсники допилят, это уже проще, на первое время можно и без этого эту простую схему описать и так в кодах, а софт допиливать потом не спеша.

Главное что продаваться такие чипы будут уже по цене производства, без лишних накруток.

Слабо проект нового fpga чипа разработать?..

Vladimir


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: naima53 on October 26, 2012, 07:21:44 PM
ТВВ, где мой психпортрет?  ;D или это была просто разведка...  :-\


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 26, 2012, 09:26:40 PM
Quote
зря сомневаешься - разбираться с этими каракулями обычно сложнее чем переписать сразу как надо,
аккуратно написанных проектов единицы.

я сомневаюсь не в чьих-то каракулях (которых повидал немало и всегда мог в них разобраться, в отличии от тебя), а сомневаюсь я в твоих способностях что бы то ни было написать самостоятельно...

Quote
Я и с математикой особо не церемонюсь - все что надо предпочитаю выводить сам.

Голословно. Что ты за последний месяц/год вывел сам?

Quote
ни одного не видел - секрет фирмы-с...
то, что ты не умеешь читать даташиты уже давно понятно. Но из этого не следует, что это "секрет фирмы-с" - это только твой "секрет"...

Quote
VHDL мало чем отличается от любого другого языка - в принципе его можно с равным успехом преподавать даже в школе, вместо бейсика, так что в принципе любой школьник может сделать то-же самое...

Спорим, у тебя пальцев на руках больше, чем человек на этом форуме, способных это сделать (включая и ветки на других языках)? Так что свои "в принципе" оставь при себе.

Quote
А схема там предельно простая - похожа на CRC схемы, тока в отводках от регистра часть XOR заменена другими для придания нелинейности, вот и все.

Если ты знаешь одну единственную схему на сдвиговом регистре с обратной связью и отводами, это еще не значит, что весь мир на ней построен. Расширь свой кругозор. Почитай учебники.
SHA НЕ ОПИСЫВАЕТСЯ схемой, которая  "похожа на CRC".

Хоть ты и непроходимый тупица, но попытаюсь тебе втемяшить главное отличие от твоих crc-подобных схем - в "твоих" схемах на каждом такте изменение конкретных бит зависит от малого количества других бит. Например в одноканалке каждый бит зависит только от одного соседнего, и только один (первый или последний) от каких-то нескольких бит (обратной связи). Эти схемы очень легко реализуются на простой логической схемотехнике.
В современных же компьютерных криптоалгоритмах давно ушли от таких схем. Именно для того, чтобы усложнить построение специализированных крипто- акселераторов. В SHA2 - в том числе. В SHA2 есть биты, зависящие одновременно от более чем 60 входных бит даже после всех упрощений и оптимизаций. На обычной логике никакая неимоверная оптимизация эту схему упростить не может. Это принципиально и никак не зависит от твоей личной безграмотности и жопа-чувств. Если вдруг, ты "жопой чуешь", что здесь есть поле для оптимизации - чувствуй это втихаря, или доказывай (аргументируй) свой жопа-бред.



Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 27, 2012, 04:20:20 AM
Типа для тебя логика с 60 входами диковинка и предел сложности?

А ты хоть знаешь что для АЛУ нужно порядка N**2 элементов?

То есть для логики с 60 входами нужно 60-100 лог. элементов всего,
а для АЛУ 32 бит порядка 1000, причем с гораздо более сложной логикой!

Доходит?..

PS  c VDHL справились вполне так себе весьма средненькие инженеры,
или как ты думаешь почему мне самому не пришлось читать даташиты?..

PPS  счас если дойдут руки до форума по программированию,
можно будет провести натурный эксперимент за сколько школьник освоит VHDL.
Тока я потом за твое ЧСВ не отвечаю ;)


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 27, 2012, 05:37:29 AM
Спорим, у тебя пальцев на руках больше, чем человек на этом форуме, способных это сделать (включая и ветки на других языках)? Так что свои "в принципе" оставь при себе.

я даже в своем маленьком городе знаю людей кто знает VHDL больше, чем у тебя всего пальцев, включая 21-й ;)
(а в списке контактов их еще на порядки больше, так что не бином ньютона твой вхдл, уж поверь)

Другое дело что майнингом они не интересуются, это да...

Quote
А схема там предельно простая - похожа на CRC схемы, тока в отводках от регистра часть XOR заменена другими для придания нелинейности, вот и все.

Если ты знаешь одну единственную схему на сдвиговом регистре с обратной связью и отводами, это еще не значит, что весь мир на ней построен. Расширь свой кругозор. Почитай учебники.
SHA НЕ ОПИСЫВАЕТСЯ схемой, которая  "похожа на CRC".

я знаю тока методов описания всяких кодов и их применений гораздо больше, чем ты можешь себе представить...
Даже знаю про "скрытый бит" из FPU DEC, и знаю почему его нет в ЕС ЭВМ(IBM). 
(а ты знаешь?  Особенность схемотехники построения АЛУ - уважающие себя аппаратчики должны знать про эту фичу)
Не считая всяких кодов вроде Фиббоначи из экспериментального многоразрядного ЦАП-а КАМАК,
кодов спутниковой связи, корректоров ошибок...  АКФ, ВКФ, CDMA и много других страшных слов ;)
(кстати умеешь спутниковые модемы настраивать? и знаешь почему qualcomm отымел моторолу по плотности сотовой связи? )


Но с этими кодами ты тут сильно прокололся - задан SHA не алгоритмом, а именно _логической битовой_ функцией!!!
(сюрприз:  и вся математика этих кодов описана именно по этой базе, а не в арифметической форме алгоритма для CPU!
То есть криптоанализ ты похоже даже не знаешь как выглядит, и даже не видел исходных функций для него)

Есть класс арифметических кодов(про которые ты похоже не слышал, а я это прекрасно понимаю) и тп - вот их
может быть и можно задать сразу алгоритмом, хз.  Но не SHA это точно - потому что у него вся база и исходная
математика описана именно в логических битовых функциях!..

То есть совершенно не важно что существует ускоренный алгоритм его расчета на CPU - это побочный отход оптимизации,
и никто сам этот алгоритм ковырять не будет.  Для анализа надо смотреть именно исходную форму(а она побитовая - сюрприз)
этой функции тк под этот класс схем и создавалась вся математика и доказательства его устойчивости...



Хоть ты и непроходимый тупица,
но попытаюсь тебе втемяшить главное отличие от твоих crc-подобных схем - в "твоих" схемах на каждом такте изменение конкретных бит зависит от малого количества других бит. Например в одноканалке каждый бит зависит только от одного соседнего, и только один (первый или последний) от каких-то нескольких бит (обратной связи). Эти схемы очень легко реализуются на простой логической схемотехнике.

как самокритично ;)

А ничего что в аппаратной схеме лог. элемент можно воткнуть хоть перед каждым триггером,
и можно хоть вообще все биты всего 256/512 бит регистра поменять за 1 такт?..   (сюрприз1? ;) )

А ничего что если внимательно посмотреть на схему SHA, там окажеться всего 2 отводки?  (точнее подводки ;) )


Просто в алгоритме для CPU там за один проход пытаются сразу считать несколько битов - коли уж АЛУ CPU универсальное,
то почему бы не использовать все биты и не считать по 32 бита за раз.

То есть, один цикл оптимизированного алгоритма экв.  8-32 тактам последовательной схемы.
(но ковырять сам этот алготм довольно глупо - он уже в другой базе и у него другая математика, исходный битовый проще)


То есть, на каждом бите данных регистр может изменяться всего в паре мест - но после 32 битов эти изменения
распостраняются уже довольно далеко - потому тебе и кажеться что там лавинный эффект очень большой,
хотя этого нет.   (и кстати по секрету скажу что если отводок сделать больше, то взломать его будет легче)


В современных же компьютерных криптоалгоритмах давно ушли от таких схем. Именно для того, чтобы усложнить построение специализированных крипто- акселераторов. В SHA2 - в том числе. В SHA2 есть биты, зависящие одновременно от более чем 60 входных бит даже после всех упрощений и оптимизаций. На обычной логике никакая неимоверная оптимизация эту схему упростить не может. Это принципиально и никак не зависит от твоей личной безграмотности и жопа-чувств. Если вдруг, ты "жопой чуешь", что здесь есть поле для оптимизации - чувствуй это втихаря, или доказывай (аргументируй) свой жопа-бред.

просто ты не понимаешь что один проход алгоритма для CPU экв. 32 проходам битового алгоритма.
(но базовый исходный которым описан SHA - именно битовый, это без вариантов, и вся математика под него)

То есть ты видешь результат от f(f(f(...f(x) ))) (32 раза - иногда в подобных математиках это записывают как 32 степень)
многократного применения этой функции за один вызов подпрограммы оптимизированного под CPU алгоритма, вот и все.
И думаешь что там что-то сложное - нифига просто это экв многократному вызову 1-бит функции, и там всего пара отводок,
ну а входы вообще никого не волнуют - это всего экв. 1 слою элементов от универсального АЛУ, который ты идиот
реализовал в своей fpga, тупо не думая взяв и перенеся преобразованный и оптимизированный алгоритм под CPU с мощным
универсальным АЛУ.  Кстати один тока этот универсальный АЛУ занимает ячеек в десятки раз больше всего ядра
последовательного майнера...

Vladimir
PS  возможно что на старших fpga(где уже есть целые готовые блоки АЛУ, RAM и тп) разницы особой не будет(но в asic
все немного иначе - там никто не заставляет лепить не нужные универсальные блоки), но ты все равно полный лох тк думаешь
что для аппаратного майнера нужна только большая матрица fpga - а это далеко не так тк несколько последовательных
ядер можно всунуть в любую маленькую матрицу, что учитывая халявность старого хлама все равно выгодно,
хоть и не бьет рекорды по пиковой производительности(что и не нужно для майна - важна тока цена 1 MH/s)...


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 27, 2012, 10:44:10 AM
То есть ты видешь результат от f(f(f(...f(x) ))) (32 раза - иногда в подобных математиках это записывают как 32 степень)
многократного применения этой функции за один вызов подпрограммы оптимизированного под CPU алгоритма, вот и все.
И думаешь что там что-то сложное - нифига просто это экв многократному вызову 1-бит функции, и там всего пара отводок,
ну а входы вообще никого не волнуют - это всего экв. 1 слою элементов от универсального АЛУ, который ты идиот
реализовал в своей fpga, тупо не думая взяв и перенеся преобразованный и оптимизированный алгоритм под CPU с мощным
универсальным АЛУ.  Кстати один тока этот универсальный АЛУ занимает ячеек в десятки раз больше всего ядра
последовательного майнера...

Нафига ты пишешь всю эту ахинею? Ты думаешь, что есть люди, программирующие fpga и не понимающие всего этого лучше тебя?
Ты даже "Фиббоначи" неправильно пишешь. Твоя тотальная безграмотность поражает.
То что ты пишешь - общие, смешные слова.
Изначально, на описанную тобой операцию будет уходить 32 такта работы устройства. Именно для того, чтобы делать эту операцию за такт и создают АЛУ. Иначе будет огромный простой всех остальных участков, которым в данный момент не нужно "сложение за 32 такта". Только не гундось о том, что в твоем устройстве такты маленькие - ты этого не добьешься.
Давай проведем эксперимент. Я напишу на VHDL сложение двух 32-битных слов, откомпилирую и опубликую количество ресурсов, потраченное после разводки на эту операцию. А ты выкинешь АЛУ нафиг, извлечешь из своей думалки "ядро последовательного майнера", откомпилируешь (или опубликуешь здесь, если компилировать нечем) и посчитаешь (посчитаем) количество ресурсов, которые уйдут на твою реализацию. Ну и скорость работы (количество тактов) сравним заодно.
И посмеемся/поплачем... :)
До этого момента, все сказанное тобой воспринимается как полный бред и мечты не подкрепленные даже попытками сделать что-то на практике или что-то доказать общепринятым научным языком (терминами).


Vladimir
несколько последовательных
ядер можно всунуть в любую маленькую матрицу, что учитывая халявность старого хлама все равно выгодно,
хоть и не бьет рекорды по пиковой производительности(что и не нужно для майна - важна тока цена 1 MH/s)...

Какова у тебя получается цена 1MH/s?
Вот в этом то и проблема - ты ничего в своей жизни не доводил до конца. Иначе ты бы понимал, как глубоко ты заблуждаешься.
Предлагаю еще один спор - спорим, что на "халявном старом хламе" ты (да и никто другой) не соберешь устройство, которое бы по цене 1MH/s превосходило бы показатели того, что уже есть в продаже?


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 29, 2012, 04:07:45 AM
Нафига ты пишешь всю эту ахинею? Ты думаешь, что есть люди, программирующие fpga и не понимающие всего этого лучше тебя?

а чтобы ты понял, хоть что-то.  Но я вижу это мало помогает...

В чипах и технологиях ты кстати совсем не разбираешься - чего я тебе и пытаюсь показать на пальцах.

Ты даже "Фиббоначи" неправильно пишешь. Твоя тотальная безграмотность поражает.

забавный ты ;)   Обычно народ к "VDHL" прикапывается - а тебе уже больше не к чему чтоли?..
(вон специально не стал исправлять очепятку - но даже не думал что ты на это попадешься, удивил ;) )

Давай проведем эксперимент. Я напишу на VHDL сложение двух 32-битных слов, откомпилирую и опубликую количество ресурсов, потраченное после разводки на эту операцию. А ты выкинешь АЛУ нафиг, извлечешь из своей думалки "ядро последовательного майнера", откомпилируешь (или опубликуешь здесь, если компилировать нечем) и посчитаешь (посчитаем) количество ресурсов, которые уйдут на твою реализацию. Ну и скорость работы (количество тактов) сравним заодно.
И посмеемся/поплачем... :)

а до тебя ведь нифига и не доходит, даже после того как разжевал 2*2...

Ну ладно, OK, похоже и правда придеться проводить натурный эксперимент...

Первый вопрос(на засыпку) - в чем мерить-то будем, умник?
Ты правда думаешь что компилятор тебе покажет информацию о чипе и технологии, а не более высокого уровня?

Вот зачем я тебе 2*2 только объяснял не понимаю, если ты все равно не читаешь...


Какова у тебя получается цена 1MH/s?
Вот в этом то и проблема - ты ничего в своей жизни не доводил до конца. Иначе ты бы понимал, как глубоко ты заблуждаешься.
Предлагаю еще один спор - спорим, что на "халявном старом хламе" ты (да и никто другой) не соберешь устройство, которое бы по цене 1MH/s превосходило бы показатели того, что уже есть в продаже?

хм... Это ты про себя чтоли?  Я думал у тебя этот уродец работает...  Ну да ладно.

Цена MH/s у меня абсолютно круглая - полный 0, поскольку старый хлам бесплатная халява которую лень нести на помойку.

Ты правда думаешь что можно сделать новое дешевле?..


Но главного принципа ты все равно не понял - в новых проектах такой подход будет сильно выгоднее.
(Подскажу - и даже новые чипы с майнерами могут стоить почти 0.   Сможешь теперь дагадаться почему?.. 
Да, и объясни почему заказ чипов в полупроводниковых фирмах может полностью убить прибыль от майнинга...)

Vladimir
PS  в технологиях, маркетинге, схемотехнике и архитектуре чипов ты все-же нифига не понимаешь...


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 29, 2012, 04:17:05 AM
Да, кстати, в каком размере fpga нынче 1 ячейка стоит дешевле?..
(этот тот класс на котором ты сделал майнер, или чипы меньшего размера имеют меньшую удельную стоимость?)

То есть удельная стоимость лог. элемента - если цену чипа разделить на число ячеек.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 29, 2012, 04:43:36 PM
Ну ладно, OK, похоже и правда придеться проводить натурный эксперимент...

Первый вопрос(на засыпку) - в чем мерить-то будем, умник?

Да в чем хочешь, умник.

Ты правда думаешь что компилятор тебе покажет информацию о чипе и технологии, а не более высокого уровня?

Напомню - думаешь и предполагаешь здесь ты. Я же знаю, что говорю.


Цена MH/s у меня абсолютно круглая - полный 0, поскольку старый хлам бесплатная халява которую лень нести на помойку.
Ты правда думаешь что можно сделать новое дешевле?..

давай, ты сначала сделаешь или расскажешь, как сделать, а потом цену назовешь.
А то я готов по названой цене купить с миллион майнеров. Продашь? Не? Тогда и не пи...



Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 29, 2012, 04:51:55 PM
Да, кстати, в каком размере fpga нынче 1 ячейка стоит дешевле?..
(этот тот класс на котором ты сделал майнер, или чипы меньшего размера имеют меньшую удельную стоимость?)

То есть удельная стоимость лог. элемента - если цену чипа разделить на число ячеек.


кстати - ни в каком. цена в пересчете на вентиль стабильна для всего семейства сделанного по одной технологии.


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: tvv on October 29, 2012, 05:06:39 PM
Да в чем хочешь, умник.

хочу в физической площади на кремнии

>Ты правда думаешь что компилятор тебе покажет информацию о чипе и технологии, а не более высокого уровня?
Напомню - думаешь и предполагаешь здесь ты. Я же знаю, что говорю.

ни хрена ты не знаешь - компилятор покажет в лог. элементах или блоках

а физически в fpga к каждому логическому элементу еще коммутатор прилагается, который занимает во много раз больше площади!

Поэтому супер-пупер fpga хорошо если 1 мкм ASIC будет соответствовать по площади на кремнии,
по энергопотреблению чуть лучше конечно.


Цена MH/s у меня абсолютно круглая - полный 0, поскольку старый хлам бесплатная халява которую лень нести на помойку.
Ты правда думаешь что можно сделать новое дешевле?..

давай, ты сначала сделаешь или расскажешь, как сделать, а потом цену назовешь.
А то я готов по названой цене купить с миллион майнеров. Продашь? Не? Тогда и не пи...

я уже объяснял как задействовать хлам.

Конечно ради 1 старого модема тратить несколько дней на ковыряние в ПЗУ не выгодно,
но если скинуться, то все окупается тк этого хлама у людей очень много.
(то есть фактически за счет майнинга можно поднять крутой проект по реверс-инжинирингу)

Vladimir


Title: Re: /идейка/ эмулятор CPU на GPGPU
Post by: SHawk on October 29, 2012, 05:29:38 PM
хочу в физической площади на кремнии

количество вентилей, помноженное на размерность техпроцесса не спасут "отца русской демократии" ?


ни хрена ты не знаешь - компилятор покажет в лог. элементах или блоках
а физически в fpga к каждому логическому элементу еще коммутатор прилагается, который занимает во много раз больше площади!
Поэтому супер-пупер fpga хорошо если 1 мкм ASIC будет соответствовать по площади на кремнии,
по энергопотреблению чуть лучше конечно.

При чем здесь противопоставление fpga-asic? (И без тебя всем понятно, что на asiс-ах получается эффективней, чем на fpga. Это здесь никому объяснять не нужно).
Из твоей дырявой башки уже совсем выветрился предмет спора?
Тогда напомню - ты противопоставлял использование стандартной схемы сложения двух 32-битных слов своему "ядру последовательного майнера".
Ты утверждал, что алгоритмически ты это сделаешь круче. Вот это я и хочу, чтобы ты доказал.

Изначально ты утверждал, что никто кроме тебя не умеет оптимально реализовывать SHA. Все кругом делают плохо. Насколько плохо, ты, правда, разобраться не в силах, Но ты можешь сделать лучше. Делай...