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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
В таком случае и с таким кэфом можно подумать и о принятии... 07.06.09 14:25  Число просмотров: 2362
Автор: 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
<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-2023 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach