информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаSpanning Tree Protocol: недокументированное применениеПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Ростелеком заподозрили в попытке... 
 Линуксовый ботнет, распространяющийся... 
 Конец поддержки Internet Explorer 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / dnet
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Спору нет. :) Но я отвечал про C2D, потому что как раз,... 05.06.09 08:40  Число просмотров: 2115
Автор: Sla <Sla> Статус: Member
<"чистая" ссылка>
> Я о том, что если бы алгоритм принципиально не ужимался до
> размеров L1 современных CPU - как, к примеру, OGR - тогда
> производительность кэшей являлась бы ботлнеком в свое роде,
> или, точнее - гирей на ногах :)
Спору нет. :) Но я отвечал про C2D, потому что как раз, возможно, есть смысл раздуть данные и они в таком могут не поместиться в L1 C2D.

> "да практически без разницы! Phenom II отличается от Phenom
> только улучшенным механизмом L3 кэширования, ну и объем L3
> увеличен. в rc5 это никак не сказывается - ибо весь код
> умещается в L1I , а данные полностью умещаются в L1D "
Там еще были кое-какие изменения, в том числе по латентности инструкций, но несущественные для rc5 :)
<dnet>
[OGR] насколько видюха быстрее проца (условно)? 02.06.09 23:43  
Автор: Bullvar Статус: Незарегистрированный пользователь
<"чистая" ссылка>
почитал форум, википедию про CUDA - тип до 40-кратного превосходства GPU над CPU. Неужто правда?
Где почитать, какую видюху выгоднее для коровки?
[RC5] [OGR] насколько видюха быстрее проца (условно)? 03.06.09 12:42  
Автор: гость Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> почитал форум, википедию про CUDA - тип до 40-кратного
> превосходства GPU над CPU. Неужто правда?
> Где почитать, какую видюху выгоднее для коровки?

GF 8600 GT (64 конвейера) делает 66Мкеев/сек
это чуть больше, чем топовый на сегодня четырехядерник (Phenom II x4 3GHz)

GF 280 делала бы примерно 8 раз больше
по моим мыслям видюхи сейчас в 10 раз быстрей! если взять... 03.06.09 17:01  
Автор: maestro_sochi <maestro> Статус: Member
<"чистая" ссылка>
по моим мыслям видюхи сейчас в 10 раз быстрей! если взять топовую видюху с 1 чипом то она примерно даст 500 а проц если его разогнать то около 50. вот и выходит в 10 раз примерно!
[RC5] по моим мыслям видюхи сейчас в 10 раз быстрей! если взять... 03.06.09 17:30  
Автор: aLEXt <Alex Trusty> Статус: Member
<"чистая" ссылка>
> по моим мыслям видюхи сейчас в 10 раз быстрей! если взять
> топовую видюху с 1 чипом то она примерно даст 500 а проц
> если его разогнать то около 50. вот и выходит в 10 раз
> примерно!

на 3ГГц квадкоре больше 50 выйдет, особенно если AMD.
у меня амд 3 ядра по 3.55 выходит 44 мегакея! 04.06.09 08:51  
Автор: maestro_sochi <maestro> Статус: Member
<"чистая" ссылка>
[RC5] окей, твоя победить :) 04.06.09 10:43  
Автор: aLEXt <Alex Trusty> Статус: Member
<"чистая" ссылка>
Твои прикидки оказались точнее )
но это феном 2 ! а феном 1й 4*2500 дает 41 мегакей... а если... 04.06.09 11:48  
Автор: maestro_sochi <maestro> Статус: Member
<"чистая" ссылка>
> Твои прикидки оказались точнее )
но это феном 2 ! а феном 1й 4*2500 дает 41 мегакей... а если его до 2700 разогнать то 44-45
[RC5] но это феном 2 ! а феном 1й 4*2500 дает 41 мегакей... а если... 04.06.09 12:34  
Автор: гость Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > Твои прикидки оказались точнее )
> но это феном 2 ! а феном 1й 4*2500 дает 41 мегакей... а
> если его до 2700 разогнать то 44-45

да практически без разницы! Phenom II отличается от Phenom только улучшенным механизмом L3 кэширования, ну и объем L3 увеличен. в rc5 это никак не сказывается - ибо весь код умещается в L1I , а данные полностью умещаются в L1D
именно по той же причине суперпупер L2 кэш Core 2 не помогал... 04.06.09 12:38  
Автор: гость Статус: Незарегистрированный пользователь
<"чистая" ссылка>

> в rc5 это никак не сказывается - ибо весь код
> умещается в L1I , а данные полностью умещаются в L1D

именно по той же причине суперпупер L2 кэш Core 2 не помогал ему победить K8 в rc5
Не только по этой. Точнее, кэш тут вообще ни при чем. У Core... 04.06.09 16:35  
Автор: Sla <Sla> Статус: Member
<"чистая" ссылка>
> именно по той же причине суперпупер L2 кэш Core 2 не
> помогал ему победить K8 в rc5
Не только по этой. Точнее, кэш тут вообще ни при чем. У Core 2 все упирается в количество одновременно выполняемых инструкций rol и lea. У него по 1, а у K7/K8/K10 - по 3 + независимый MMX блок. Иными словами, Core 2 упирается в ALU, а K7/K8/K10 - в декодер.
K7 медленнее K8 на той же частоте по причине более привередливого декодера, надо более тщательно, вручную, выравнивать инструкции по границам окна декодера и можно добиться точно такой же производительности, как и K8.
Единственное, K8 начиная с ревизии Veniсе выполняет lea reg32,[reg32+reg32] за 1 такт, а не за 2, из этого можно выжать еще около 2-3-х процентов производительности.
[RC5] Не только по этой. Точнее, кэш тут вообще ни при чем. У Core... 04.06.09 18:56  
Автор: aLEXt <Alex Trusty> Статус: Member
Отредактировано 04.06.09 18:59  Количество правок: 1
<"чистая" ссылка>
> > именно по той же причине суперпупер L2 кэш Core 2 не
> > помогал ему победить K8 в rc5
> Не только по этой. Точнее, кэш тут вообще ни при чем. У
> Core 2 все упирается в

Все так, но, гипотетически предположим - локальность кода и данных чуть превышает размеры L1 - ... ???
:)

Как и в случае с ORG - нас тогда не слишком бы интересовал темп выполнения КОНКРЕТНЫХ ИНСТРУКЦИЙ, не так ли?
Все равно интересовал бы, вопрос только в том, сколько... 04.06.09 19:12  
Автор: Sla <Sla> Статус: Member
<"чистая" ссылка>
> Все так, но, гипотетически предположим - локальность кода и
> данных чуть превышает размеры L1 - ... ???
> :)
> Как и в случае с ORG - нас тогда не слишком бы интересовал
> темп выполнения КОНКРЕТНЫХ ИНСТРУКЦИЙ, не так ли?

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

Хотя, согласен, можно использовать и такой вариант, когда S-буферы не будут влазить в L2 K8/10, но быстро будут таскаться из кэша C2D. Но, сдается мне, по скорости такой вариант будет проигрывать существующему. Конкретный пример - у C2D SSE2 реализован гораздо лучше, чем в K8, но все равно ядро, написанное на чистом SSE2 более чем в 2 раза проигрывает существующему go2a (которое int32/mmx+) за счет большой латентности инструкций, которую не получается скрыть (если только в 64-бит попробовать). А вот обратный вариант возможен - сделать так, чтобы помещалось в L1D у K8 и нет - у интела. Возможно, что тут и можно что-то выиграть, хоть и не факт, прикидывать надо в коде :)
[RC5] это все хорошо 04.06.09 23:27  
Автор: aLEXt <Alex Trusty> Статус: Member
Отредактировано 04.06.09 23:30  Количество правок: 1
<"чистая" ссылка>
> Все равно интересовал бы, вопрос только в том, сколько
> получилось бы обсчитывать ключей в параллель, чтобы скрыть
> возросшую латентность операций чтения.
>
> Хотя, согласен, можно использовать и такой вариант, когда
> S-буферы не будут влазить в L2 K8/10, но быстро будут
> таскаться из кэша C2D. Но, сдается мне, по скорости такой

Разумеется, ни в коем случае не следует раздувать область локальности так, что она не поместится в L1 - это будет отстой ;)
Я о том, что если бы алгоритм принципиально не ужимался до размеров L1 современных CPU - как, к примеру, OGR - тогда производительность кэшей являлась бы ботлнеком в свое роде, или, точнее - гирей на ногах :)

кстати, изначальный тезис как раз утверждал несущественность для rc5 характеристик кэшей уровнем ниже L1 :)

"да практически без разницы! Phenom II отличается от Phenom только улучшенным механизмом L3 кэширования, ну и объем L3 увеличен. в rc5 это никак не сказывается - ибо весь код умещается в L1I , а данные полностью умещаются в L1D "
Спору нет. :) Но я отвечал про C2D, потому что как раз,... 05.06.09 08:40  
Автор: Sla <Sla> Статус: Member
<"чистая" ссылка>
> Я о том, что если бы алгоритм принципиально не ужимался до
> размеров L1 современных CPU - как, к примеру, OGR - тогда
> производительность кэшей являлась бы ботлнеком в свое роде,
> или, точнее - гирей на ногах :)
Спору нет. :) Но я отвечал про C2D, потому что как раз, возможно, есть смысл раздуть данные и они в таком могут не поместиться в L1 C2D.

> "да практически без разницы! Phenom II отличается от Phenom
> только улучшенным механизмом L3 кэширования, ну и объем L3
> увеличен. в rc5 это никак не сказывается - ибо весь код
> умещается в L1I , а данные полностью умещаются в L1D "
Там еще были кое-какие изменения, в том числе по латентности инструкций, но несущественные для rc5 :)
[RC5] Возможно 05.06.09 10:10  
Автор: aLEXt <Alex Trusty> Статус: Member
Отредактировано 05.06.09 10:10  Количество правок: 1
<"чистая" ссылка>
> Спору нет. :) Но я отвечал про C2D, потому что как раз,
> возможно, есть смысл раздуть данные и они в таком могут не
> поместиться в L1 C2D.
Возможно, нужно проверять )

Но я ставлю 9 к 1, что эффект будет негативный :)
Смотря что с чем сравнивать. :) Если с текущим go-2 - то,... 05.06.09 17:13  
Автор: Sla <Sla> Статус: Member
<"чистая" ссылка>
> Но я ставлю 9 к 1, что эффект будет негативный :)

Смотря что с чем сравнивать. :) Если с текущим go-2 - то, имхо, есть варианты, а если с каким-то другим возможным решением, то я ничего не возьмусь утверждать :)
[RC5] Смотря что с чем сравнивать. :) Если с текущим go-2 - то,... 06.06.09 00:46  
Автор: aLEXt <Alex Trusty> Статус: Member
<"чистая" ссылка>
> > Но я ставлю 9 к 1, что эффект будет негативный :)
>
> Смотря что с чем сравнивать. :) Если с текущим go-2 - то,
> имхо, есть варианты, а если с каким-то другим возможным
> решением, то я ничего не возьмусь утверждать :)

С чем сравнивать? Именно с текущим go-2 ;)
В таком случае и с таким кэфом можно подумать и о принятии... 07.06.09 14:25  
Автор: Sla <Sla> Статус: Member
<"чистая" ссылка>
> > > Но я ставлю 9 к 1, что эффект будет негативный :)
> С чем сравнивать? Именно с текущим go-2 ;)

В таком случае и с таким кэфом можно подумать и о принятии пари :)
Но тут надо прикинуть, а пока есть вот такое: rapidshare.de/files/47447688/r72_x86.rar.html
(ядро #11, go-2b) - может, кто-то и найдет там пару процентов. По крайней мере, моему P-M оно понравилось. :)

http://rapidshare.de/files/47447688/r72_x86.rar.html
[RC5] В таком случае и с таким кэфом можно подумать и о принятии... 09.06.09 10:45  
Автор: aLEXt <Alex Trusty> Статус: Member
<"чистая" ссылка>

> rapidshare.de/files/47447688/r72_x86.rar.html
> (ядро #11, go-2b) - может, кто-то и найдет там пару
> процентов. По крайней мере, моему P-M оно понравилось. :)

на Core2 почти 4%

[Jun 08 01:58:12 UTC] RC5-72: Benchmark for core #10 (GO 2-pipe alt)
0.00:00:17.70 [11,281,618 keys/sec]
[Jun 08 01:58:12 UTC] RC5-72: using core #11 (GO 2-pipe b).
[Jun 08 01:58:32 UTC] RC5-72: Benchmark for core #11 (GO 2-pipe b)
0.00:00:17.14 [11,658,742 keys/sec]
На P-M тоже 4-5, феном поменьше вроде. 09.06.09 14:45  
Автор: Sla <Sla> Статус: Member
<"чистая" ссылка>
> на Core2 почти 4%
На P-M тоже 4-5, феном поменьше вроде.

а, вот, нашел
Phenom 9550:
[May 30 12:11:48 UTC] RC5-72: using core #6 (GO 2-pipe).
[May 30 12:12:09 UTC] RC5-72: Benchmark for core #6 (GO 2-pipe)
0.00:00:17.31 [9,538,662 keys/sec]
[May 30 12:13:28 UTC] RC5-72: using core #11 (GO 2-pipe b).
[May 30 12:13:48 UTC] RC5-72: Benchmark for core #11 (GO 2-pipe b)
0.00:00:16.78 [9,835,315 keys/sec]

K8 вот не пробовал (до и после Venice)
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach