![]() ![]() |
28 Marzec 2006, 15:37
Post
#81
|
|
|
Uzależniony od forum ![]() ![]() ![]() ![]() ![]() Postów: 1 254 Dołączył: 26 Kwiecień 05 |
.
Ten post został edytowany przez voytass84: 11 Styczeń 2010, 18:25 |
|
|
|
29 Marzec 2006, 12:35
Post
#82
|
|
|
PWr PhD student ![]() ![]() ![]() ![]() ![]() Postów: 1 459 Dołączył: 16 Luty 04 |
wyręczę Cię trochę, na za miesiąc mam zaprojektować sumator 8 bitowy na zajęcia z ukłądów logicznych. Wystarczy podpiąc 8 takich i już mamy sumator 64bitowych liczb całkwoitych..itd. Jak tak się skrzykniemy całą społecznością PClaba, to może za 10 lat swotrzymy jakiś 486
|
|
|
|
29 Marzec 2006, 12:43
Post
#83
|
|
|
PAX ![]() ![]() ![]() ![]() ![]() Postów: 5 455 Dołączył: 2 Marzec 04 |
Intel mógłby najpierw zwiększyć ilosć cache L1 L1 u Intela dziala kompletnie inaczej niz np u AMD. P4 przechwuja zdekodowane mikrooperacje - 12 u-Ops - 12tys. Po prostu zdecydowali sie podejsc naczej do problemu niz AMD i nie mozna porownywac rozmiarow L1, takie podejscie jest niespecjalnie miarodajne. ps. Poza tym, wydawalo mi sie, ze juz w tym watku bylo to opisane doklandie... No Shark niezła robota... Ja też zaczynam się w tym kierunku dokształcać Co do cache L3 to miał już ją Gallatin - 2MB... Dlaczego Intel nie kontynuował prac nad L3? Zapewne dlatego, ze dla P4 i generalnie procesorow jednordzeniowych niewiele wnosil... poteznie zwiekszal koszt produkcji, a przyrost wydajnosc byl mizerny. Dlatego moja reakcja na cache L3 u AMD byla na poczatku taka, a nie inna Cache L2/L3 jest buforem miedzy ramem a procesorem, ew rdzeniami, w pewnym momencie zwiekszenie go nie daje rzadnego wzrostu wydajnosci, czesc po prostu bedzie 'lezala odłogiem'. Ten post został edytowany przez Gwynbleidd: 29 Marzec 2006, 12:49 |
|
|
|
29 Marzec 2006, 15:33
Post
#84
|
|
|
Compute Unified Device Architecture ![]() ![]() ![]() ![]() ![]() Postów: 8 669 Dołączył: 26 Styczeń 05 |
Zapewne dlatego, ze dla P4 i generalnie procesorow jednordzeniowych niewiele wnosil... poteznie zwiekszal koszt produkcji, a przyrost wydajnosc byl mizerny. Oj coś mi się zdaje że nie Na pewno L3 dało dużo |
|
|
|
29 Marzec 2006, 15:54
Post
#85
|
|
|
Ten od CPU ![]() ![]() ![]() ![]() ![]() Postów: 2 674 Dołączył: 13 Sierpień 04 |
|
|
|
|
29 Marzec 2006, 15:56
Post
#86
|
|
|
Compute Unified Device Architecture ![]() ![]() ![]() ![]() ![]() Postów: 8 669 Dołączył: 26 Styczeń 05 |
|
|
|
|
29 Marzec 2006, 15:59
Post
#87
|
|
|
Ten od CPU ![]() ![]() ![]() ![]() ![]() Postów: 2 674 Dołączył: 13 Sierpień 04 |
Oj coś mi się zdaje że nie Na pewno L3 dało dużo Czytałeś co chwile wcześniej napisał Gwynbleidd o cache L1 u Intela ? Chyba nie CYTAT L1 u Intela dziala kompletnie inaczej niz np u AMD. P4 przechwuja zdekodowane mikrooperacje - 12 u-Ops - 12tys. Po prostu zdecydowali sie podejsc naczej do problemu niz AMD i nie mozna porownywac rozmiarow L1, takie podejscie jest niespecjalnie miarodajne A jakby już chceć porównać rozmiary cache, to L1 w Northwoodzi/Galatinie, nie ma sumarycznie 20 KB. Cache danych ma 8 KB, a Trace Cache ( cache instrukcji ) ma 12K uOps ( 12 tyś mikro instrukcji ), a co do pojemności liczonej w bajtach, to ma pojemnosc 96 KB Więc sumarycznie wychodzi 104 KB. |
|
|
|
29 Marzec 2006, 16:02
Post
#88
|
|
|
PAX ![]() ![]() ![]() ![]() ![]() Postów: 5 455 Dołączył: 2 Marzec 04 |
No... Wtedy opóźnienie by spadło do min. Całkiem dobry pomysł... Generalnie to tak... ale cena bylaby kosmiczna W sumie AMD sie troche 'przyblizyl' do tego powyzszej propozycji integrujac kontroler pamieci w procesorze, eliminujac opoznienia wynikajace z calego balaganu na plycie glownej, ktory 'lezy' zazwyzaj miedzy ramem a procem. Dlatego zapewne nie potrzebuje w ogole tak duzo cache, 512kB-1MB na rdzen/procesor gdy intel laduje zazwyczaj od 1-2 MB Ten post został edytowany przez Gwynbleidd: 29 Marzec 2006, 16:03 |
|
|
|
29 Marzec 2006, 17:02
Post
#89
|
|
|
Compute Unified Device Architecture ![]() ![]() ![]() ![]() ![]() Postów: 8 669 Dołączył: 26 Styczeń 05 |
|
|
|
|
29 Marzec 2006, 17:06
Post
#90
|
|
|
PAX ![]() ![]() ![]() ![]() ![]() Postów: 5 455 Dołączył: 2 Marzec 04 |
|
|
|
|
29 Marzec 2006, 17:06
Post
#91
|
|
|
Użyt(szkodnik)! :PP ![]() ![]() ![]() ![]() ![]() Postów: 2 324 Dołączył: 13 Wrzesień 04 |
Myśleliście nad ciekłym azotem do chłodzienia tego ''cacka''??
|
|
|
|
29 Marzec 2006, 17:08
Post
#92
|
|
|
Compute Unified Device Architecture ![]() ![]() ![]() ![]() ![]() Postów: 8 669 Dołączył: 26 Styczeń 05 |
|
|
|
|
29 Marzec 2006, 17:16
Post
#93
|
|
|
PAX ![]() ![]() ![]() ![]() ![]() Postów: 5 455 Dołączył: 2 Marzec 04 |
Myśleliście nad ciekłym azotem do chłodzienia tego ''cacka''?? eee tam. Spojrz na Pentium M albo Turiona - wydzielaja srednio od 25-35W - cos takiego moznaby wiekszym radiatorem ogarnac. Przy zastosowaniu odpowiednich technologii, ulozeniu poszczegolnych blokow funkcyjnych zeby rozprowadzic cielplo na cala powierzchnie, no i jeszcze pewnie pare myków moznaby zastosowac to w sumie jakies ekstremalne chlodzenie nie byloby potrzebne. |
|
|
|
29 Marzec 2006, 20:46
Post
#94
|
|
|
Gaduła ![]() ![]() ![]() Postów: 282 Dołączył: 23 Marzec 04 |
Cache danych ma 8 KB, a Trace Cache ( cache instrukcji ) ma 12K uOps ( 12 tyś mikro instrukcji ), a co do pojemności liczonej w bajtach, to ma pojemnosc 96 KB jeśli chodzi o efektywny rozmiar trace cache, ciekawych informacji dostarcza RMMA: http://www.digit-life.com/articles2/cpu/rmma-presler.html (tabela 9) jak widać, TC pojemnościowo odpowiada ~10 (w niezbyt życiowym przykładzie nopów) do ~64 KB klasycznego cache. wydajność nie jest oczywiście porównywalna... |
|
|
|
![]() ![]() |
|
|
| Wersja Lo-Fi | Aktualny czas: 13 Marzec 2010, 20:57 |