Megabyte

Chciałeś chyba napisać 40bitowa szynowa adresowa i 48bitowa przestrzen wirtualna. 40bitowa szyna nie robi wielkiej roznicy bo i tak kontroler by wiecej nie obsluzyl. Rzeczywiście do 48bitowej przestrzeni można się troche przyczepić ale czy to jest na pewno wystarczający powód żeby nie móc nazwać obecnego Athlona64 procesorem 64bitowym? A co wchodzi w ten "standard 64bit" ?

A możesz mi wyjaśnić dlaczego? Tyle osób już to pisało a nikt nie był w stanie odpowiedzieć dlaczego.

Tylko 32bit. Intel uznał że 64 bity w laptopach nie są potrzebne a szkoda.

No ja np rok temu zaopatrzyłem się w 2GB RAM i musze przyznać że się przydaje. Nic tak bardziej nie wkurza jak ciągła praca dysku spowodowana małą ilością RAMu. W przyszłym roku jak Conroe będzie zdobywać coraz większą część rynku wiele osób będzie kupować już 4GB RAM albo chociaż 2GB z możliwością dołożenia kolejnych 2GB. Jak już pisałem przy 4GB w 32bit są już kłopoty z wykorzystaniem takiej ilości pamięci. Powinien także w końcu wyjść Windows Vista, wtedy raczej bez 64bit nie będzie się dało obejść. Dlatego ja właśnie ciekaw jestem wydajności Conroe w 64bit. Bardzo dobrze że AMD zrobiło AMD64. Gdyby nie to pewnie teraz Intel wprowadzał by na szybkiego jakieś beznadziejne rozszerzenia do swoich 32bitowych procesorów:/

To jednak Ty nie masz racji. PC to nie tylko maszynka do gier. Przy wielu różnych obliczeniach sse w ogóle nie jest potrzebne, a tam gdzie jest to potrzebne to jest wykorzystywana głównie karta graficzna. W PS3 jest taki podział ról pomiędzy CPU a kartą graf że Cell tam idealnie pasuje ale nie do PC. Nie w takiej formie. To że niedługo ludzie w kompach zaczną mieć więcej RAMu niż 4GB to jedna sprawa. Ale co z tym że pojedynczy proces ma wyłącznie dostęp do 2GB? Co z tym że nieraz przydaje się większa ilość przestrzeni wirtualnej bez rzeczywistego przydzielania pamięci? AMD oprócz poszerzenia przestrzeni adresowej zwiększyła ilość rejestrów ogólnego przeznaczenia i przez to widać duży wzrost wydajności po przekompilowaniu programu na 64bit (przynajmniej na Athlonie64). Nie wiem jak Ty ale ja wole czerpać zarówno korzystość z wielordzeniowości ale i także 64bit. Wydajności nigdy za wiele :P Dlatego właśnie jestem ciekaw jak Conroe poradzi sobie w 64bitach. Mam nadzieje że przyrost będzie taki jak w A64 a nie P4 :/

Ja na XP x64 pracuje odkąd wyszła wersja RC2 czyli już około rok i nie widze w tym nic dziwnego. :razz:

O ile dobrze się orientuje to zbiory (klasa std::set) jest implementowana za pomocą drzew czerwono-czarnych.

Przypominam że w standardowej bibliotece są klasy do obsługi listy i drzew. Nie trzeba pisać własnych :)

Na XP x64 pracuje na codzien począwszy od wydania wersji RC2 czyli już prawie rok i zrezygnować z niego nie moge a do samego drukowania nie będe się przecież przełączał na zwykłego XP.

Udało się komuś uruchomić drukarke HP LaserJet 1020 na tym windowsie? Bo zastanawiam się nad kupnem ale bez sterowników to nic nie wydrukuje :/ Chyba że ktoś mi poleci inną dobrą tanią drukarke laserową ze sterownikami pod XP x64.

Firewall sprzętowy to właśnie taki, który sam sobie liczy a nie każe robić tego głównemu procesorowi. Jedno jest pewne, ten firewall z nf4 jest lepszy niż w nf3. A taki jest właśnie temat tej rozmowy. Wykazać różnice pomiędzy nf3 a nf4.

Ja jakoś dalej nie wierze. Na stronie NVidii o chipsecie nforce 4 ultra można poczytać: I to ActiveArmor Secure Networking Engine ma tylko nforce4 ultra i nforce4 sli. Źródło: http://www.nvidia.com/page/nforce4_ultra.html Widzisz gdzieś info przy nforce3 żeby odciążął CPU?

Od omawiania funkcji DirectX jest SDK. Chcesz znaleźć dobre książki i artykuły o programowaniu w DirectX to naucz się angielskiego.

Nvidia troche zamieszała z tym firewallem. Zrobili oprogramowanie, które chodzi na wszystkich nf4 i nawet nf3 z tego co widze. Jest to jednak softwarowy firewall, sprzętowe wspomaganie jest na płytach z chipsetem nf4 ultra i sli (active armor). Tak więc podsumowując w nf4 wprowadzono: - sprzętowy firewall - SATA2 - PCIe - SLI

aArray to nic innego jak referencja do obiektu o typie std::vector<std::vector<_Type> >. Referencja zostalo użyta żeby nie operować na kopii obiektu tylko na nim samym. " _Type Value = _Type() " oznacza że ostatni parametr jest opcjonalny i jeżeli go nie podasz, zostanie użyty obiekt utworzony przez domyślny konstruktor. "(*i).resize (uHeight, Value)" oznacza w tym wypadku to samo co "i->resize (uHeight, Value)". Pytasz o podstawy cpp, polecam kupić jakąś książke.

Z tego co słyszałem to wersje Express mają kosztować 50$ no chyba że pojawią się z dwoma licencjami 1. pisanie programów niekomercyjnych, Visual za darmo 2. pisanie programów komercyjnych, Visual za 50$ Niestety Visual C++ Express nie ma kompilatora pod x86_64 a wersje standard pewnie nie będzie mieć możliwości włączenia optymalizacji kompilacji. Cena wersji professional będzie zabójcza:/ Żebym miał kase to i na tą impreze można by było się wybrać :wink: - www.devconnections.com/shows/CPPFall2005/default.asp?s=67

Visual C++ 6.0 już dawno nie jest wspierany przez MS i może dajmy sobie z nim spokój. Wprawdzie jest bardzo szybki ma nie duże wymagania ale do standartu C++ mu dużo brakuje. Nie zabardzo rozumiem o co Ci chodzi z tymi błędami. Dlaczego Visual C++ 2005 jest lepszy od Dev-cpp z gcc - szybciej kompiluje - lepiej optymalizuje zarówno kod 32bit jak i 64bit. Jest wogóle gcc pod win które skompiluje pod x86_64? - utworzone exeki są nieporównywalnie mniejsze - brak problemów w porównaniu z gcc z wieloma rzeczami np UNICODE (wcout, wstring) - dużo lepszy edytor - rewelacyjny debugger, potrafi wykrywać m.in naruszenie sterty, np gdy zapisujemy do pamieci po tym jak ja zwolnilismy, wyjechanie za tablice, użycie niezainicjalizowanej zmiennej i wiele wiele innych podczas gdy w Dev-cpp nawet nie udało mi się odpalić debuggera. No niestety wymagania ma nie małe ale jeżeli ktoś ma odpowiedni komputer to po co się męczyć z prymitywnym Dev-cpp jak jest Visual C++ :-P

:blink: Ty chyba nigdy nie używałeś Visual C++. Wersji 2005 czy nawet 2003 dev-cpp nie dorasta do pięt. Choć z jednym się zgodze Visual ma znacznie wieksze wymagania. Ja polecam zassanie ze strony MS Visual C++ 2005 Express Edition za darmo.

Do czegos takiego nie potrzeba osoby z dobra znajomoscią C++. Jak widać nie wiesz czego chcesz.

Dzięki za info. Jak się później okazało test 1 został zbyt mocno zoptymalizowany przez kompilator i jest tak krótki że nie daje miarodajnych wyników. W trzecim teście widać mocny spadek prędkości w porównaniu do niecałych 30sec na zwykłym Athlonie64. Niestety synchronizacja na prawdziwym systemie wieloprocesorowym kosztuje. A jak to wygląda z X2? @Sulaco, Waldi: Jak długo wykonywał wam się 3 test?

No właśnie. Widać że postrzegasz C++ jako C z obiektami. Ja nie mówie żeby definiować od razu własne klasy ale programować funkcjonalnie i korzystać z kilku standartowych obiektów C++. std::string jest przecież dużo bardziej prostsze niż napisy w stylu języka C. Z tego co widze ludzie którzy najpierw zaczynali w C (cały czas chodzi oczywiście mi o pure C) mają większe problemy ze zrozumieniem niektórych rzeczy podczas późniejszego programowania w C++. EDIT: Widze że post jest nieco spóźniony. Tak to jest jak mnie ktoś cały czas odrywa od komputera. :wink:

Oczywiście że na początek 100x lepszy od C jest C++. - jest prostszy: np żeby bawić się napisami w C trzeba zrozumieć wskaźniki, w C++ jest std::string - uczy dobrych zasad programowania. Przecież C konkretnie olewa typ danych. Nie wiem dlaczego ludzie postrzegają C++ jako C z obiektami. :mur: W C++ można programować funkcjonalnie i to lepiej niż w C!

Jak to nie ma, przecież Venice E3 oficjalnie coś takiego obsługuje. A na 4x512MB 200MHz 2T to ja sobie jade na Winchesterze. Wszystko w pełni stabilnie.

@KGB: Nie zapominaj że Dothan ma 2MB cache L2. W internecie rzeczywiście można spotkać pełno sprzecznych testów Centrino. Najlepiej byłoby mieć takiego w domu i wtedy porównać. :D

W drugim teście wykorzystuje metode, która wykonuje tylko operacje atomowe. Bez dodatkowej synchronizacji pomiędzy procesorami. Chciałem sprawdzić jak to w praktyce wygląda. Niestety ta metoda jest polecana w niektórych książkach i artykułach. :mur: Także nie zdziwcie się jak trafi się wam wielowątkowy programik, który działa na jednordzeniowcu a na dualcore nie. :wink: Jeżeli czyta to jakiś programista C++ niech zapamięta: "volatile nie nadaje się do synchronizacji wątków". Trzeba więc skorzystać z funkcji systemowych albo napisać własne w ASM :wink: Ja wybrałem to drugie bo procedury systemowe są niestety wolne :/ i tą metode stosuje w teście 3. Jak widać działa więc jest wszystko dobrze. Niestety te problemy to tylko wierzchołek góry lodowej. Pisanie programu wielowątkowego, w którym wątki muszą się często synchronizować to masakra. Najgorsze jest unikanie zakleszczeń. Nieraz trzeba zmienić algorytm bo nie jest możliwe zapewnienie poprawnej synchronizacji.