sprzet (strona 325 z 338)

Nowe układy graficzne Movidiusa sprawią, że nie będziemy już wyłączali kamer w urządzeniach przenośnych?

Nowe układy graficzne Movidiusa sprawią, że nie będziemy już wyłączali kamer w urządzeniach przenośnych?

Do tej pory o firmie Movidius słyszeli praktycznie tylko eksperciz dziedziny komputerowego przetwarzania obrazu – niewielkikalifornijski startup od wielu lat pracuje nad własnymi czipami,które usprawnić miałyby przetwarzanie wideo. Największym jego jakdotąd sukcesem było opracowanie wspólnie z Toshibą procesora do obsługi stereoskopowej kamery dlasmartfonów. Teraz jednak startup znalazł się na ustach wszystkich zmobilnej branży, pozyskując 16 mln dolarów finansowania od funduszyinwestycyjnych na zbudowanie czipu, który pozwolić ma urządzeniom naobniżenie zużycia energii towarzyszącego przetwarzaniu obrazu o wielerzędów wielkości, a w konsekwencji, umożliwić budowanie kamer,których nigdy nie trzeba będzie wyłączać.Problem jest dobrze znany każdemu, kto dał sobie wmówić, żesmartfon stanowi dobry zamiennik dla kompaktowego aparatufotograficznego i nagle odkrywa, że po godzinie czy dwóch robieniazdjęć podczas imprezy poziom naładowania baterii spadł niemal dozera. Robienie zdjęć czy nagrywanie wideo jest jednym z najbardziejobciążających pod względem zużycia energii zadań, które realizuje sięza pomocą urządzeń przenośnych. A jeśli robienie i przetwarzaniepojedynczych zdjęć czy ujęć tak szybko „opróżnia”baterię, to czy można oczekiwać, by urządzenia takie jak Google Glassmożna było zastosować do pracy w warunkach wspomaganejrzeczywistości, gdzie kamera wideo musi działać non stop?[img=alwayson-opener]Rozwiązanie oferowane przez Movidiusa istnieje do tej pory tylkojako prototyp, o którym startup nikomu poza inwestorami za wielemówić nie chce. Wiemy jedynie, że ma być to koprocesor doprzetwarzania obrazu o zupełnie nowej architekturze, tak różniącejsię od obecnych czipów ARM, jak ARM-y różnią się od x86. Układzapewnić ma moc obliczeniową na poziomie kilkunastuteraflopsów, przy zużyciuenergii na poziomie kilkuset miliwatów i docelowo stać się częściączipów SoC, montowanych w urządzeniach przenośnych.Te obietnice brzmią bajkowo –ostatecznie najsilniejsze karty graficzne są w stanie dostarczyć dziśco najwyżej kilka teraflopsów, zużywając przy tym przynajmniejkilkaset watów mocy. A jednak inwestory, wśród których są AtlanticBridge, DFJ Esprit and Robert Bosch Venture Capital, Capital E i AIBSeed Capital Fund, zdecydowali się wyłożyć na ukończenie iwprowadzenie do produkcji czipu kilkanaście milionów. Przekonać ichmiały opowieści o nacisku na sprzętowe wspomaganie przetwarzaniarównoległego, dostępie do jednego ciągłego bloku pamięci iprogramowalności układu, wszystko to w cenie nie wyższej niż 5dolarów.[img=movidius-chip-architecture]Zapowiedziom technologicznegoprzełomu towarzyszyły zmiany personalne – nowym szefemMovidiusa został były wiceprezes Texas Instruments, Remi El-Ouazzane,odpowiedzialny tam za ARM-owe układy SoC z serii OMAP. Z jegokontaktami można się spodziewać, że producenci urządzeń mobilnychbędą się ustawiali w kolejce do biura kalifornijskiego startupu, tymbardziej, że czasu nie zostało wiele – nowe czipy od Movidiusapojawić się na rynku mają pod koniec tego roku, a zadebiutować wsmartfonach, tabletach (i zapewne wszelkiej maści sprytnychokularach) powinny już w rokuprzyszłym. W końcu nawet jeśli nie potrzeba nam wspomaganejrzeczywistości, to każdy sposób na osiągnięcie dłuższego czasu życiana jednym cyklu ładowania baterii jest przez konsumentów milewidziany, a dodatkową zaletą możliwości pozostawienia kamery w staniewłączonym jest szybkość robienia zdjęć, bez czekania, aż uruchomi sięprzetwarzająca obraz aplikacja.
Intel Atom na smartfonach: sztuczki z kompilatorem pozwoliły na manipulowanie wynikami benchmarku

Intel Atom na smartfonach: sztuczki z kompilatorem pozwoliły na manipulowanie wynikami benchmarku

Kilka tygodni temu w Sieci opublikowano zaskakujące wyniki testów wydajności smartfonów, wśród którychznalazł się model z procesorem Intel Atom Clover Trail (Lenovo K900).Z testów wynikało, że dwurdzeniowy CPU Intela pozostawił konkurencjębazującą na procesorach ARM (nawet tych czterordzeniowych) bez szans,i to nie tylko pod względem wydajności, ale i zużycia energii. Czyżbywięc na tym polu projektowana od początku z myślą oenergooszczędności architektura ARM przegrała w końcu z x86,architekturą projektowaną z myślą przede wszystkim o wydajności?Niekoniecznie, gdyż w grę wchodzą tu pewne software'owe…manipulacje.Exophase, jeden z czytelników serwisu AnandTech przyjrzał siębliżej benchmarkowi, który posłużył do uzyskania tych bolesnych dlaARM-ów wyników. To AnTuTu,rekompilacja kodu z lat 90, przygotowanego przez nieistniejący jużmagazyn Byte. Benchmark wygląda na dość solidny i kompleksowy,pozwala mierzyć wydajność pamięci, procesora, grafiki 2D i 3D, czyoperacji I/O na pamięci masowej i z bazami danych. Pod tym względemnie można mu niczego zarzucić. Problem tkwi gdzie indziej – wkompilatorach wykorzystywanych do zbudowania uruchamialnej wersji.[img=armwrestling-opener]Okazuje się, że wykorzystana w testach wersja benchmarkaskompilowana została dla procesorów Intel Atom za pomocą kompilatoraICC, podczas gdy wersję dla ARM skompilowano za pomocą GCC.Naszym starszym Czytelnikom mogą się już w tej sytuacji włączyćalarmowe lampki – pamiętają, jak podczas dochodzenia w sprawiewytoczonego przez AMD pozwu antymonopolowego przeciwko Intelowiokazało się, że kompilator Intela włącza optymalizacje tylko dlaprocesorów „Genuine Intel”, nie sprawdzając faktycznychmożliwości docelowego układu. Dla procesorów VIA, jedynych w którychmożna było zmienić ciąg CPUID, wystarczyła ta zmiana, by zwiększyćwydajność kodu kompilowanego przez ICC o nawet 30%. Choć tuoczywiście taka sytuacja wystąpić nie mogła (ICC generuje kod tylkona x86), to alarm jest poniekąd uzasadniony: skompilowana przez ICCwersja benchmarka otrzymała automatycznąwektoryzację kodu wynikowego, podczas gdy w kompilowanej zapomocą GCC wersji na ARM nie włączono rozszerzeńNEON (rozszerzeń ARM-a dla architektury SIMD). To prawda, GCC samo tych rozszerzeń nie włącza, ale wydaje się, żeskoro wersję na Atomy zbudowano za pomocą intelowskiego kompilatora,to wypadałoby wersję na ARM-y skompilować za pomocą kompilatora odpoczątku projektowanego z myślą o ARM, np. Keila,by z rozszerzeń NEON korzystać – w końcu są dostępne napraktycznie wszystkich nowoczesnych układach ARM, zarówno Cortex A9jak i Cortex A15. Problemy z kodem wygenerowanym przez ICC na tym sięnie skończyły – według Exophase kompilator celowo psuje wielekonstrukcji wykorzystanych w benchmarku. Na przykład jedna z pętli,która powinna zostać wykonana 32 razy, zostaje wykonana tylko raz, anastępnie zgłasza, że zadanie zostało ukończone.Zarówno w serwisach takich jak Slashdot, jak i na forach serwisówpoświęconych sprzętowi komputerowemu trwają dyskusje na temat tegoincydentu, który być może jest zwykłym zbiegiem okoliczności, ale byćmoże też jest częścią zamierzonych działań, mających na celuwykazanie wartości architektury x86 w urządzeniach przenośnych.Całkiem niedawno przecież Intel udostępnił kompletny zestawnarzędzi deweloperskich na Androida/x86, a tu nagle wypływająraporty uznanych analityków, wykazujące o ile Atom sprawuje sięlepiej od ARM-ów? Wątpliwości trudno będzie wyciszyć, szczególnie, żeudało się porównać, o ile zmieniły się wyniki poszczegónych testów.Między wykorzystaną w badaniach ABI Research wersją 3.3 AnTuTu ipoprzednią wersją 2.9.3, różnice są dramatyczne, i trudno je zrzucićna zwykły przypadek – dla testu wydajności RAM wynik Atoma (naMotoroli RAZRi) wzrósł o 292%, podczas gdy wynik ARM-owego procesora(w Samsungu Galaxy S4) wzrósł jedynie o 53%. Sprawa wygląda jeszczebardziej podejrzanie, gdy porówna się wyniki innych benchmarków,takich jak Quadrant, Linpack i Geekbench – tam przewaga układówARM w niektórych testach była nawet trzykrotna.[img=antutu-charge][join][img=arm-cpu1]A teraz ciekawostka – AnTuTu wydało nową wersję 3.3.2swojego benchmarka. Wyniki dla urządzeń z procesorami Intel Atom sąjuż znacznie skromniejsze, często nawet o 20-50%. Wniosek jestoczywisty – zamierzone lub nie błędy metodyczne mogą uczynićkażdy pomiar pozbawionym merytorycznego znaczenia. Szkoda tylko, żebłędy metodyczne nie pozbawiają jednocześnie takiego badaniaznaczenia marketingowego.