Procesory Intel kontra Apple A znów stanęły do rywalizacji, czyli „tradycji” stało się zadość. Jak niemal co roku za sprawą „upgradu” iPhone’a przeprowadziłem test praktyczny możliwości urządzeń z iOS i macOS. Tym razem za sprawą Łukasza Banaszaka test jest znacznie bogatszy, bo w szranki stanęły również jego iPad Pro 12″ i MacBook Air 2015 i5.
Procesory Intel kontra Apple A, jak testowaliśmy.
Możliwości „multimedialne” jak zwykle przetestowałem za pomocą projektu w iMovie. Film zawierający klipy wideo z kamery sportowej (2560 × 1440 piksli, 30 fps) oraz z iPhone (1080p 30 fps i 720p 240 fps) z efektami, napisami i „obrazem w obrazie” eksportowałem do pliku 1080p.
W drugim teście użyłem mojego programu Faqt, a w zasadzie jego pliku bazy danych. Na komputerze test wykonał FileMaker Pro Advanced 14, a na iOS FileMaker Go.
Procesory Intel kontra Apple A, co testowaliśmy.
W teście multimedialnym w szranki stanęły:
- iPad Pro (A9X, 2 rdzenie CPU 2,26 GHz, 12 rdzeni GPU; 4 GB RAM)
- iPhone 7 Plus (A10 Fusion, 2+2 rdzenie CPU 2,34 GHz, 6 rdzeni GPU; 3 GB RAM)
- iPad Air 2 (A8X, 3 rdzenie CPU 1,5 GHz, 8 rdzeni GPU; 2 GB RAM)
- iPhone 6s Plus (A9, 2 rdzenie CPU 1,85 GHz , 6 rdzeni GPU; 2 GB RAM)
- MacBook Air 2013 (i7, 2 rdzenie 1,7 GHz, GPU HD 5000; 8 GB RAM)
- MacBook Air 2015 (i5, 2 rdzenie 1,6 GHz, GPU HD 6000; 8 GB RAM)
W teście FileMakera rywalizowały:
- iPad Pro (A9X, 2 rdzenie CPU 2,26 GHz, 12 rdzeni GPU; 4 GB RAM)
- MacBook Air 2013 (i7, 2 rdzenie 1,7 GHz, GPU HD 5000; 8 GB RAM)
oraz niewidoczny na filmie
- iPhone 7 Plus (A10 Fusion, 2+2 rdzenie CPU 2,34 GHz, 6 rdzeni GPU; 3 GB RAM)
Przebieg testów możecie zobaczyć w serwisie YouTube:
Wyniki nie były zaskoczeniem. W renderowaniu i eksporcie pliku wideo urządzenia z procesorami Apple A zdeklasowały Intela:
- iPad Pro (A9X, 2 rdzenie CPU 2,26 GHz, 12 rdzeni GPU; 4 GB RAM): 52 sek.
- iPhone 7 Plus (A10 Fusion, 2+2 rdzenie CPU 2,34 GHz, 6 rdzeni GPU; 3 GB RAM): 59 sek.
- iPad Air 2 (A8X, 3 rdzenie CPU 1,5 GHz, 8 rdzeni GPU; 2 GB RAM): 75 sek.
- iPhone 6s Plus (A9, 2 rdzenie CPU 1,85 GHz, 6 rdzeni GPU; 2 GB RAM): 76 sek.
- MacBook Air 2013 (i7, 2 rdzenie 1,7 GHz, GPU HD 5000; 8 GB RAM): 163 sek.
- MacBook Air 2015 (i5, 2 rdzenie 1,6 GHz, GPU HD 6000; 8 GB RAM): 177 sek.
Za to test „obliczeniowy”, czyli pod FileMaker procesory Apple A bardzo pozytywnie nas zaskoczyły, bo już dogoniły Intela, a A10 z iPhone 7 Plus przegonił nawet A9x iPada Pro.
- iPhone 7 Plus (A10 Fusion, 2+2 rdzenie CPU 2,34 GHz): 28 sek.
- MacBook Air 2013 (i7, 2 rdzenie 1,7 GHz): 29 sek.
- iPad Pro (A9X, 2 rdzenie CPU 2,26 GHz): 36 sek.
Widać, że w renderingu plików wideo dużą rolę, odgrywają układy graficzne mocno rozbudowane w procesorach A.
Zobaczcie filmy z poprzednich testów:
- Test wydajności: Intel i7 kontra ARM Apple A8 i A7
- A7 szybszy od Intela! iPhone 5s i 5 kontra MacBook Air porównanie szybkości
Jeżeli chcecie samodzielnie przetestować wydajność swoich urządzeń w renderingu iMovie, to możecie pobrać użyty w testach projekt (otwiera się w iMovie na iOS oraz w iMovie na macOS). Uwaga: zajmuje on ponad 750 MB. Test-iMovie-2017.iMovieMobile
Skoro sa takie szybkie i wydajne, to czy jest mozliwosc podpiecia iPhona 7+ do monitora tak aby zastapil mi moj domowy komputer?
Nie, to urządzenie jest do czegoś innego. Znaczy możesz podpiąć, ale nie można obsługiwać jak komputer.
Dziękuję za testy. Kwestia chyba czasu (za kilka lat) jak Apple wprowadzi swoje procesory do Maców, do tego dotykowy ekran i ogromna baza aplikacji z iOS zadziała z macOS. Tylko programiści tworzący aplikacje na macOS będą mieli dużo roboty bo muszą odnowa aplikacje robić pod ARM, niby tylko kompilacja ale chyba nie jest to takie proste. Przy okazji zabije hackintosha swoimi procesorami ARM, będą jeszcze działać te na Intelu.
Nie gniewaj się, ale nie masz racji. Procesor nie jest przeszkodą. Xcode może kompilować do bitcode, a bit code w App Store można prze-kompilować na inny procesor bez udziału programisty nawet. Nie po to Apple robi komputery, aby przerabiać je na iPady. To interfejs robi różnicę.
Pamiętaj: co jest do wszystkiego to jest do niczego…
Ekran dotykowy i Mac OS to nie sprawdzi. Zobacz na case study Surface pro 4 bądź Surface Studio. Korzystam z iPada Pro od grudnia i cenię sobie ten precyzyjny minimalizm, wynikający ze specyfiki IOS.
Dlaczego to się nie sprawdzi?
Oczywiście dzisiejszy interfejs Mac OS, nie jest zoptymalizowany do obsługi dotyku, ale nieraz szybciej byłoby kliknąć palcem w główny ekran a nie w wąziutki ekranik nazwany Touch Bar. Dotykając głównego ekranu, nie odrywamy od niego wzroku. Przewijanie zdjęć, działa dużo lepiej na dotykowym ekranie.
Przykładowo, dzisiejsze skrypty galerii (do powiększania zdjęć) na stronach internetowych przystosowane są do dotyku, działają na zasadzie click&drag. Owszem, można klikać i przewijać gładzikiem w Macu, ale wówczas coraz bardziej zbliżamy się kursorem do którejś krawędzi gładzika i ponownie musimy kliknąć i przesunąć kursor na drugą część ekranu, żeby dalej móc klikać i przeciągać.
Przykład: https://tympanus.net/Development/DraggableDualViewSlideshow/
Touch Bar tego nie rozwiązuje, bo elementy strony nie mogą być obsługiwane Touch Barem.
Widać, że masz bardzo złe nawyki. Pewnie pierwszy raz z myszką spotkałeś się na Windows?
Gładziki w Maczkach są idealne, ekran dotykowy w komputerach to śmieszna i męcząca fanaberia. Pracuj sobie z rękami w powietrzu godzinę lub dwie…
I jeszcze drobny szczegół… Adobe, Autodesk i jeszcze kilku innych graczy robiących duże aplikacje. Jeśli taka zmiana nastąpi (a jestem pewien, że tak) to na pewno nie w sektorze „Pro”. Myślę, że przetestują na zwykłych zjadaczach komputerów 🙂
Jeśli chodzi o cześć sprzętową to Apple ARM jest na duży plus, tylko na minus jest pod kątem oprogramowania tego, developerów którzy musieliby przekompilować aplikacje, interfejs jest bez zmian. Apple musiałoby dodać nowe biblioteki tworzenie w języku Swift i może już bez Objective-C. Programiści musieliby się uczyć Swift zmienając swoje przezwyczajenia z objC.
Eeee… no ale to już mamy z głowy… na razie barierę stwarza specyfika interfejsu iOS oraz niedobory pamięci (nie chodzi o RAM, ale o brak stronicowania w iOS).
Dokładnie 😉 , IOS i iPad Pro mają pewne ograniczenia ale to idealne narzędzie do obróbki filmów i zdjęć i przy okazji do poważnej pracy. Test również pokazuje, jak duża moc obliczeniowa, drzemie w iPadzie Pro z IOS na pokładzie.
Idealne narzędzie do obróbki filmów i zdjęć? Bez urazy, ale chyba dla hipsterów, którzy potrzebują foci na insta.
Nawet Lightroom, program Adobe do obróbki zdjęć, jest bardzo ograniczony w stosunku do desktopowej wersji. O Photoshopie nie wspomnę.
Porównanie iMovie do Final Cut X, to też nieporozumienie. Oczywiście można zrobić podstawową ograniczoną korektę zdjęć, czy prosty montaż filmu, ale do nadal zabawka a nie urządzenie dla Profesjonalistów.
Pisanie, że to narzędzie do poważnej pracy jest grubą przesadą.
Cały zysk z mocy procesora marnuje interfejs iOS, który wydłuża niemiłosiernie większość prac, które można zrobić na Mac OS.
Zależy co się robi i jakie się ma przyzwyczajenia, i czy potrafi się „przełączać” swoje nawyki.
I oczywiście wiadomo, że iOS nie nadaje się domwszytakiego.
To prawda, przyzwyczajenia drugą naturą człowieka.
Problem w tym, że każdą rzecz wykonam szybciej na Macu, nawet jak miałbym się zmierzyć z osobą która jest iPad only i przestawiła się na pracę tylko na iPadzie.
Kilka zadań jest takich, które faktycznie można szybciej zrobić na iOS, np. zrzut ekranu i wstawienie go apką w makietę urządzenia. Zrobienie filmiku i udostępnienie do na YT (chociaż to jest porównywalne). Dużo zadań jest takich, że coś co robisz w Macu 2 kilka sekund, na iOS zajmuje minuty albo nie da się części zadań wykonać w ogóle.
Obsługa plików to jest największy problem. Nie chodzi mi tylko o brak Findera w iOS, ale ogólnie o brak okien dialogowych i możliwość składowania plików w jakimś folderze. Można co prawda importować pliki z zewnętrznych dysków w chmurze np. z Drobboxa albo iClouda, ale już nie można ich tam zapisywać. Każda Apka ma swoją przestrzeń do trzymania danych.
Robi się z tego taki idiotyzm, że nawet natywna chmura iCloud i aplikacja Pages od Apple nie potrafi zapisywać plików w chmurze tak jak sobie je ustawiłem w Macu.
W Macu w katalogu iCloud miałem katalog dokumenty w którym były umowy i oferty (wersje .pages + .pdf) oraz luźne dokumenty Pages. W momencie gdy chciałem otworzyć je w Pages na iOS, musiałem wskazać inne miejsce „poza katalogiem Pages” po czym program Pages zduplikował ten dokument i skopiował go do katalogu Pages! Każde otwarcie dokumentu, który nie leżał w katalogu iCloud>Pages powodowało jego duplikowanie. Teraz mam oferty edytowane w katalogu iCloud>Pages a oferty zapisane w PDF muszę trzymać w osobnym katalogu!.
Edytując jakiś dokument, nie mogę zrobić „zapisz jako” i wskazać miejsca np. do Dropboxa.
Otwarcie jakiegoś PDFa z Dropboxa automatycznie powoduje jego kopiowanie do magazynu aplikacji którą go otwieram. Otwierając PDFa w kilku aplikacjach otrzymuję kilka kopii tego samego pliku. Póki nie rozwiążą problemu z obsługą plików, chociaż na takim podstawowym poziomie, to słabo widzę zastosowanie iPada jako narzędzia do efektywnej pracy.
Zrobiłem ten test na MacBooku Pro 13 z 2015 roku (bazowy model czyli dwurdzeniowy i5 2,7 Ghz, pseudoGPU 6100) i moje wyniki są jakieś absurdalne. Dla ustawień eksportu jak na filmie (wysoka jakość, kompresja szybsza) mój komputer „z mięśniem” uzyskał…249 sekund!!! Masakra. Spróbowałem jeszcze raz, to samo. Stwierdziłem, że sprawdzę inne ustawienia. Wybrałem taką samą kompresję, ale jakość ProRes (najwyższą). I co? Było szybciej (poniżej 220 sekund). Jestem lekko zszokowany.
216 sekund plik wynikowy 412MB, (1080p, wysoka, szybka) na Mac Pro 2013 3,5 GHz 6-Core Xeon E5 / 64 GB ram / 1TB SSD / D500. OS X 10.11.6. Jak dla mnie całkowicie nie jest zoptymalizowany iMovie do tego sprzętu. iMovie zabierał w czasie renderingu niespełna 1GB ramu, + 2GB na proces VTDecoderXPCService. Obciążenie ogólne na 35% pracy na 6 rdzeniach procesora. Mak robi to jakby przez sen 🙂 Za to taki FCX ruszy 12 rdzeni (z wirtualnymi) na 100%, zeżre choć ramu i zmusi do pracy dwie D500.