Sortuj
Funkcja komentowania została wyłączona. Do dyskusji zapraszamy na forum.
- Karty graficzne
- Procesory
- Smartfony
- Tablety
- Laptopy
- Płyty główne i pamięć RAM
- Nośniki danych: SSD, HDD i inne
- Obudowy i zasilacze
- Chłodzenie
- Internet i sieci
- Monitory i projektory
- Drukarki i skanery
- Myszki, klawiatury
- Oprogramowanie
- Gry i konsole
- Multimedia i gadżety
- Dźwięk
- Zestawy komputerowe
- Technologie i wydarzenia
- Inne
Nie sądzę, by ktokolwiek podejmował decyzję zakupową na podstawie wyników z tego typu aplikacji, nie sądzisz?
Oj, zdziwiłbyś się. Fakt faktem jest to jednak rodzaj dewiacji, a nie norma, więc chyba nie powinno zostać uwzględnione.
Jeden scenariusz nikogo nie zadowoli - nawet wybierając jeden język jak C++ byłyby krzyki, że tylko użyty kompilator X, a nie Clang, GCC, Intel C++ Compiler, Microsoft Visual C++ Compiler... ten problem będzie niezależnie od wybranego języka... już nie mówiąc o samym niezadowoleniu z wybrania danego języka, a nie innego. Jeśli jednak chcecie pogodzić największą grupę osób to język C++ i GCC powinien załatwić sprawę. Jako, że jest to rozwinięcie języka C to testując ten język testujecie tak naprawdę 1wszy i 3ci najpopularniejszy język programistyczny http://www.tiobe.com/index.php/content/pap...tpci/index.html a wykorzystanie GCC zachęci nie tylko programistów C/C++, a i użytkowników Linuxa gdzie jest to główny i podstawowy kompilator (używany nie tylko przez programistów - a przykładowo przez osoby budujące sobie wydajniejsze jądra Linuxa (GCC jest zdaje się jedynym kompilatorem potrafiącym skompilować jądro Linuxa bez modyfikacji)).
Po pierwsze to nie jest temat o grach. Po drugie jeśli test jest zależny od CPU, to min i avg będą rosły o tyle samo. Czyli np. po podkręceniu z 3000 na 3200 MHz o około 5-6,6%.
Inna sprawa: powiedz, po co Ci to?
A jak inaczej ustalisz, do jakiego punktu procesor ogranicza kartę graficzną?
Nie, nie jest to prawda, że będzie cały czas rosło o tyle samo, przy pewnej wartości powinno przestać rosnąć w ogóle, a procesor wówczas przestaje być ograniczeniem.
http://www.anandtech.com/show/7189/choosin...eptember-2013/7 - coś jak tu, tylko ten sam procesor, różne takty.
Tutaj przeszkodą jest ilość pamięci RAM. My używaliśmy do wszystkich testów 8 GB i zdjęcie testowe było tak przygotowane, by wszystkie operacje zmieściły się w pamięci RAM. Ale teraz przesiądziemy się na 16 GB, więc i procesory będą dłużej to wszystko wykonywały.
Małe pliki są małym obciążeniem, przez co testu kończą się szybciej, nim się na dobre zaczęły.
Wiesz, na tej zasadzie to znajdziemy milion zastosowań, które są bardzo wymagające. Pytanie tylko jak dużo osób to robi.
Dalej to będzie zastosowanie obejmujące Photoshopa?
Powtarzając się: kilkusekundowa procedura testowa nie pokazuje za dużo operacji, które cokolwiek wymagają od procesora.
Coś, co spowoduje, że Photoshop będzie mielił dane przez parę+ minut, wprowadzi jakąś zdrową rywalizację pomiędzy procesory - które w kilkusekundowym teście pracują na 100% pewnie przez całe 1-2s (o ile aż tyle), a reszta polega na leniwym czekaniu na operacje dyskowe, albo operacje jednowątkowe/nie do przyspieszenia.
Wbrew pozorom Photoshopa używa większość osób, ale tylko niewielka część ma go legalnie... niestety. Jest to też bardzo popularna podstrona z wynikami testów.
Jasne. Ale ile z tych osób robi cokolwiek, co bardziej obciąża system?
Do podstawowych operacji w PS wystarczy cokolwiek współczesnego (cpu) + 4GB ram - i wtedy to nie ma sensu nawet patrzeć na wyniki testów, bo do drobnych pierdołek będzie wystarczyć praktycznie wszystko.
Po pierwsze to nie jest temat o grach. Po drugie jeśli test jest zależny od CPU, to min i avg będą rosły o tyle samo. Czyli np. po podkręceniu z 3000 na 3200 MHz o około 5-6,6%.
Inna sprawa: powiedz, po co Ci to?
A jak inaczej ustalisz, do jakiego punktu procesor ogranicza kartę graficzną?
Nie, nie jest to prawda, że będzie cały czas rosło o tyle samo, przy pewnej wartości powinno przestać rosnąć w ogóle.
Oczywiście, że od pewnej wartości przestanie rosnąć, bo karta graficzna będzie już na limicie. Ale wystarczy że wówczas weźmiesz inne miejsce testowe i całe Twoje założenia poszły się... O to właśnie chodzi, że to o czym mówisz to mega uproszczenie, które nie ma żadnych szans na realizację. Polecam lekturę: http://pclab.pl/art51525.html
Sądzisz, że dużo osób tworzy zdjęcia HDR na podstawie zdjęć już zrobionych aparatem?
Tak choćby ja i do tego zdjęcia panoramiczne w Panorama Factory w pełnej rozdzielczości lustrzanki. Mieli taka panoramę kilka minut
Np. Haswell. Nie było takiego testu. Może w późniejszym terminie coś zrobiliście.
Przy Ivy tak samo było.
Do tego wydajność jednego wątku, tu najlepiej się sprawdza poczciwy PI.
Przy Haswellu był - nie dość, że 4,5 GHz to jeszcze na defie miałeś. IB? Również - na 4,5 GHz. Wydajność jednego wątku? Masz milion aplikacji w naszej procedurze, która tą wydajność sprawdza, więc?
Link poproszę
Przy Haswellu był - nie dość, że 4,5 GHz to jeszcze na defie miałeś. IB? Również - na 4,5 GHz. Wydajność jednego wątku? Masz milion aplikacji w naszej procedurze, która tą wydajność sprawdza, więc?
Link poproszę
Wszystko masz tutaj: http://pclab.pl/art53333.html
Sądzisz, że dużo osób tworzy zdjęcia HDR na podstawie zdjęć już zrobionych aparatem?
Tak choćby ja i do tego zdjęcia panoramiczne w Panorama Factory w pełnej rozdzielczości lustrzanki. Mieli taka panoramę kilka minut
Panoramę już kiedyś używałem w testach. Była to druga od końca popularna podstrona z wynikami testów.
Wiem - komentuje tylko, że jeden nie zadowoli nikogo - wręcz więcej osób będzie niezadowolonych z tego wyboru niż zadowolonych, więc lepiej wręcz zrobić 0 testów programistycznych niż je robić na małą skalę (mówię to jak dobrze wiesz jako programista). Jednak jeśli chcecie robić to radziłbym najpopularniejsze języki czyli C/C++, Java lub Obj-C (popularny tylko pod MacOS, ale i tak bardziej niż proponowana platforma .NET czyli C# czy ASP i to łącznie), tym bardziej, że nie programiści też się z takich testów mogą ucieszyć.
PS. Jak się ustosunkujesz to wcześniejszego mojego posta z dokładniejszymi opisami procedur testowych - pamiętasz może, że kiedyś się dopytywałem na Priv o szczegóły i nie dostałem do dziś odpowiedzi, a to bardzo ważne dla testów, aby były przejrzyste.
Makro VBA z użyciem np. tabel przestawnych, generowaniem wykresów, formatowaniem tekstu/liczb. Jako podstawę proponuję arkusz z kilkudziesięcioma tysiącami wierszy.
Ogólnie bardzo brakuje na stronie 'Zestaw testowy i procedura' testów właśnie opisu procedury testowej i/lub linku do szczegółowych danych na temat procedury testowej (w przypadku programów o ile można wraz z danymi używanymi do testów, bo w zależności od danych wejściowych inaczej może zachowywać się program).
Bardziej szczegółowo procedurę testów omówiliśmy przy dużym teście CPU: http://pclab.pl/art50000.html W każdym razie wszystkich szczegółów udostępniać na 100% nie będziemy. Chodzi rzecz jasna o konkurencję. Często nad niektórymi procedurami pracujemy tygodniami i wydajemy na to konkretne pieniądze. Te procedury są otwarte np. dla producentów sprzętu komputerowego.
W przypadku 3ds maxa używamy mental ray'a z tego względu że jest to ponoć najpopularniejszy renderer. W takich przypadkach opieramy się na opiniach osób, które z tego żyją. Zresztą np. procedurę do 3ds maxa mamy właśnie od profesjonalnego studia projektowego.
Użycie innych plików np. przy kompresji będzie miało oczywiście jakiś wpływ na uzyskane relacje, ale tak jest w KAŻDYM przypadku. W przypadku kompresji i tak stosujemy dwa typy plików. Kolejne rozszerzenia realnie nic nie wniosą do relacji między procesorami.
Makro VBA z użyciem np. tabel przestawnych, generowaniem wykresów, formatowaniem tekstu/liczb. Jako podstawę proponuję arkusz z kilkudziesięcioma tysiącami wierszy.
Mógłbyś nam podesłać przykładowy arkusz tego typu?
Inny przykład: czas uruchamiania się masz wirtualnych lub też sam test któregoś z podsystemu maszyny wirtualnej. Myślę, że w obecnie wiele osób ma doczynienia z maszynami wirtualnymi bo np. wciąż potrzebuje XP.
Osobiście zamienił bym AutoCADa na Mechanicala lub Inventora (ze wskazaniem na ten drugi).