Valve ogłosza powstanie SteamOS – systemu operacyjnego bazującego na Linuksie

Zastanawiam się czy taka dobra. Android też bazuje na Linuksie, a jakoś dla desktopów nie widzę korzyści. Ale …. racja, co by Valve nie wymyśliło to i tak będzie zmuszone robić to na desktopy i faktycznie skorzystamy wszyscy, oby ich polityka nie była taka jaką prowadzi Cannonical, który cokolwiek tworzy to tylko na swoją dystrybucję

Pewnie to oleją i wezmą gołe EGL, żeby mieć max wydajność :-P

hehe nie wydaje mi się żeby tak zrobili ale kto wie czas pokaże z niecierpliwością czekam na dalsze informacje na temat tego systemu i już szykuję partycję :D

Właściwie zarządzanie oknami im nie jest potrzebne, ani związana z tym wielozadaniowość. Elementy UI steam włączają się na desktopie dla pełnoekranowej aplikacji przez przechwytywanie kontekstu OpenGL.
Czego chcieć więcej niż tylko framebuffer i kontekst?

Cytat z OMG Ubuntu:

`Although not confirmed by Valve, we’ve been told that Steam OS is based on Ubuntu 12.04 LTS.`

Jeśli to prawda to mają jeszcze czas do namysłu co wybiorą. Precise ma wsparcie do 2017

To pewnie informacje oparte na ich repo w którym mieli różne biblioteki i tapety.
Tyle, że oni na stronie piszą, że zwiększyli wydajność wyświetlania grafiki i zminimalizowali lagi z dźwięku. Zatem mają chyba jakieś autorskie rozwiązania.

Owszem, ale nie napisali w stosunku do czego ;)

Jest kilka benchmarków wg. których przeportowane gry Valve działają na linuchu z większą liczbą klatek niż na winie

w sensie windowsie nie wine ^^.

Tak, ale PulseAudio ma dużo większe lagi niż Windows. Mogli je zlikwidować na rzecz czystej Alsy.
W takich systemach najlepiej by aplikacja z userspace przekazywała polecenia od razu do kernela, ewentualnie przez bibliotekę. Wysyłanie polecenia do innego procesu/demona i czekanie aż nastąpi jego kolejka jest bez sensu w systemach wymagających czasu rzeczywistego.

Jak mówili na LinuxCon – developerom potrzebne są narzędzia, a nie jakieś kołchoźniane licencje. Dlatego piszą debuger oparty na narzędziach LLVM (pewnie dlatego, że LLVM nie jest na GPL3).

Raczej dlatego, że LLVM jest lepiej radzi sobie z wektoryzacją, ma świeży przemyślany kod który łatwo rozwijać i o który łatwo oprzeć swoje rozwiązanie (dlatego LLVM jest wykorzystywany w sterownikach CUDA/OpenCL/OpenGL… przez Nvidię, AMD, Intela i innych jak i w przeglądarkach do kompilacji JavaScript). Ogólnie dziś jeśli ktoś chce oprzeć coś na kompilatorze robi to na LLVM niezależnie od licencji (programy GPL3, też wybierają LLVM, nie ze względu na licencje, a dlatego, że jest to lepsza opcja).

Wektoryzacja na podstawie dedukcji kompilatora jest gówniana ;-). Nie zyskujesz tyle ile powinieneś. Od 30 lat wmawia się ludziom papkę, że mogą pisać sobie tradycyjny kod C/C++, a kompilator zajmie się resztą. Za każdym razem to nie wypala. Tradycyjny C++ może pasuje, ale do tego co oferuje MIPS i 386.

Ms ostatnio to chce rozwiązać. Wprowadzić rejestry wektorowe do fastcall i typy wektorowe do C++. Działania wektorowe będą na normalnych operatorach i/lub argumentach do metod/funkcji. Nie będzie zgadywania czy ta pętla dobrze się rozkłada itp. Będzie miło jak w GLSL/OpenCL.

Która przeglądarka używa LLVM w JS? Jego JIT przecież nie jest najwyższych lotów. Pewnie 4x wolniejszy niż specjalizowane v8.

Mylisz 2 rzeczy . Wektoryzacja całego kodu, a działania na wektorach. Miło jak w OpenCL/GLSL jest jeśli działasz na wektorach macierzach itp. Wtedy nie obejdzie się bez ręcznego wykorzystania jednostek wektorowych (bo to i dla wydajności lepsze i ). Jednak wektoryzacja całości kodu to coś więcej, bo kompilator szuka rzeczy nie powiązanych ze sobą, aby powsadzać razem do SIMD i liczyć na raz, zamiast osobno. Cały kod się wektoryzuje i gdybyś tak chciał pisać to pisałbyś wszystko w ASM, a czytelnego kodu który łatwo rozwijać na oczy byś nie zobaczył. Dlatego poza wykorzystaniem jednostek wektorowych świadomie, ważne jest, aby kompilator też dobrze wektoryzował (bo aplikacje które ręcznie wykorzystują SIMD potrafią dodatkowo dostać kilkanaście % boost). Z tego powodu też w CUDA, OpenCL czy GLSL też liczy się to, aby kompilator kod wektoryzował (mimo gotowych typów wektorowych, bo nie wszystko wektor, co można wektoryzować).

Przykładowo Firefox od wersji 22 w wypadku kiedy nie używa się w JS kodu poza subset wyznaczony przez asm.js jest kompilowany nie przez Just-In-Time OdinMonkey, a przez Ahead-Of-Time LLVM, dzięki czemu właśnie deklasuje takie JIT z V8.

To bardzo miłe, ale tym zajmują się już procesory z kilkoma potokami ;-). Co jest bardziej MIMD (wliczając niejawne aliasy rejestrów). W praktyce używanie SIMD w całym programie ogranicza się do wektoryzacji pętli operujących na wektorach. Czyli zamiast dodać 2 tablice bezpośrednio operatorem, robi się pętle które iterują po każdym elemencie i kompilator musi się skapnąć o co chodzi. I ty mówisz, że to jest czytelne?

Za przykład z asm.js dziękuję. V8 chyba jednak i tak ostatecznie to dogonił.

Różne potoki zajmują się różnymi wątkami, a nie tym o czym mówię – nikt nie jest na tyle głupi, aby rozrzucać po różnych wątkach pojedyncze instrukcje, bo narzut jest większy niż zyski (czy raczej warto by powiedzieć tu straty). Żaden kompilator Ci tego też nie zrobi, bo przy nich pracują osoby kompetentne i nikt takiego błędu nie zrobi. Co do pętli i ograniczenia się do optymalizacji jej to chyba Ci się coś pomieszało. Auto-parallelism (automatyczne rozkładanie kodu na MIMD) się do tego właśnie ogranicza, czyli do pętli którą rozbija na wątki (czytaj zazwyczaj zmniejsza wydajność, bo straty związane z przełączeniem się wątków są olbrzymie), ale wektoryzacja kodu nie ma nic wspólnego z pętlami, automatyczna ma związek z optymalizacją obliczeń pakujące wiele obliczeń do SIMD na raz (rzadko/nigdy nie działa na faktycznych wektorach), a wektoryzacja ręczna ma związek z wektorami, ale nie tylko z nimi bo i z macierzami, z kolorem (w programach 2d) czy z akceleracją wyszukiwania w drzewie QBVH w wielu grach czy programach 3d (Q jest od Quad i specjalnie to drzewo powstało dla SIMD – każdy węzeł ma 4x dzieci, aby przeszukiwać je jednocześnie robiąc obliczenia dla całego węzła w SIMD). SIMD wykorzystuje się wszędzie – jednak ręcznie tylko w bardzo uzasadnionych sprawach, bo kod jest wtedy czytelny, a resztę robi właśnie automatyczna wektoryzacja.

Zestaw potoków (głównie kilka dekoderów instrukcji) jest po to by ciąg instrukcji jednego programu wykonywać równolegle (np 3 rozkazy na raz). Pod warunkiem, że opierają się na niezależnych danych. Dochodzą do tego dynamicznie przydzielanie jednostki wykonawcze. Są jeszcze aliasy rejestrów do wykonywania instrukcji po za kolejnością (sprzętowa optymalizacja kodu pod wewnętrzną architekturę).

Kompilator ma za zadanie tak ułożyć kod programu by zapewnić przepływ na wszystkich potokach jednocześnie. Czyli musi się starać liczyć około 3 rzeczy na raz na x86. Nie ma to nic wspólnego z wątkami systemu operacyjnego (także kijowymi). To wszystko nazywam MIMD (Wiele instrukcji – wiele danych)

Obecnie SIMD (jedna instrukcja – wiele danych) przydaje się do takich spraw w C++:

for (int x=0; x<100; x++) array1[x] += array2[x];

Czyli zamiast pojedynczo brać daną z array2 i dodawać do array1 bierze się w kodzie maszynowym po kilka danych wypełniając rejestry SIMD i wykonyje na raz na kilku dodawanie.
Zabawne, że nawet z takim prostym przykładem kompilatory mają problemy.

Micrsoft chciałby to zastąpić przez

array1 += array2;

Co jest jasne dla programisty i kompilatora i bardziej czytelne niż kod z czasów pojedynczego potoku wykonywanego tak jak programista przykazał.

W Haswell-ach prawdopodobnie będzie możliwe tak traktowanie wydajnie nawet tablic struktur danych.

Tylko trzeba poczekać, aż programiści upojeni OOP i zdarzeniami, przejdą na Data-driven programming.

Wcześniej miałem nadzieję, że się po prostu pomyliłeś i potokami napisałeś różne wątki programu. Jeśli jednak potwierdzasz, że chodziło Ci faktycznie o potokowość to jest to po prostu głupie. Procesory wielopotokowe nie potrafią wykonać wielu instrukcji na raz – wykonują tylko jedną w danym momencie – jedyna różnica jest taka, że jak jedna instrukcja się wykonuje (ALU liczy) to kolejna już może się przygotowywać (instrukcja pobrana jest z pamięci wtedy lub już nawet dekodowana, ale wykonywać na ALU może dopiero kiedy poprzednia już się wykona). Co więcej zabawa z potokami odbywa się już bezpośrednio na CPU i kompilator nie musi tu nic optymalizować… no poza przykładem który podałeś z pętlą, bo jeśliby skompilował normalnie to potoki byłyby co pętle czyszczone przez instrukcję skoku (dlatego kompilatory rozwijają pętle).

Co do przykładu z SIMD to jest to jeden z najgorszych przykładów jakie można sobie wyobrazić i ofc mozna zrobić optymalizacje przesuwając iterator co 4 i wrzucać sumę jako sumę wektora, ale ogólnie w takich wypadkach znacznie lepszym jest po prostu rozłożenie tego na wątki (ofc można by dalej korzystać z optymalizacji SIMD, ale to jest tu drugorzędna rzecz).

SIMD przydają się w operacjach na kolorze przykładowo kolor RGBA wrzucamy do wektora i możemy robić dodawanie, odejmowanie, mnożenie, dzielenie przez inny kolor/skalar i operacja na kolorze to tylko jedna instrukcja SIMD, a nie 4x działania na skalarach:
Czyli
kolor *= 0.8;
zamiast
kolor.r *= 0.8;
kolor.g *= 0.8;
kolor.b *= 0.8;
kolor.a *= 0.8;
Powyżej zmniejsza jasność i przezroczystość koloru do 80% – w wersji SIMD to jedna instrukcja, a w wersji bez SIMD to 4 instrukcje.
To ofc taki przykład, ale właśnie do takich rzeczy SIMD w prockach jest – kolor ma 4x elementy, wektory wykorzystywane w 3d mają 4x elementy, macierze stosowane w grafice 3D to 4x wektory po 4x elementy) – to jest przyczyną dlaczego w CPU (czy to ARM czy x86 SIMD są wielkości 4x elementowe (lub podzielne przez 4, aby można było liczyć kilka wektorów na raz)). Jednak to, że do właśnie takich działań SIMD w CPU są specjalnie wsadzane ich możliwości są dużo wyższe i da się optymalizować prawie wszystko (nie tak jak w potokach, gdzie po prostu skraca się czas odczytu instrukcji, a nie samego wykonania – w potokach czas wykonania tego wyżej przykładu skraca się do odczytania instrukcji i zdekodowania i wykonania jej 4x (zakładamy, że kolejne instrukcje nie musimy czytać i dekodować, bo robi się to wtedy kiedy poprzednia instrukcja działa) – ogólnie super, tylko z SIMD to samo robi się tak: odczytujemy instrukcje, dekodujemy instrukcje i wykonujemy ją tylko 1x (a nie 4x) więc mamy bardzo duże oszczędności po wektoryzacji)).

To co ty mówisz to jest pojedynczy potok. Tak było w 386. Dziś jest wiele dekoderów instrukcji i wiele ALU w jednym rdzeniu. Nawet w spisie instrukcji maszynowych nowoczesnego procesora jest opisane jakich jednostek wykonawczych używa, by można to było rozłożyć na wiele równoległych ciąg instrukcji. To co ja mówię jest od czasów Pentum 1 i ARM Cortex A8,
Tu do poczytania: http://en.wikipedia.org/wiki/Superscalar
A tu blok wykonawczy Haswella: http://images.anandtech.com/reviews/cpu/intel/Has…
Chcesz powiedzieć, że te wszystkie jednostki czekają na jedną instrukcję?

Co do reszty w pełni się zgadzam i przepraszam z mój wątpliwy przykład :-)
Twój przykład za to lepiej wrzucić do GPU na Fragment Shader.

Na koniec powinniśmy wspomnieć, że i tak najważniejsze jest to jak ułożymy struktury danych do cache. By w odróżnieniu od "nowoczesnych" programistów znajdowały się tam rzeczywiste sekwencje danych, a nie pełno wskaźników.

Chciałem to uprościć. Bo masz wiele ALU, ale zauważ, że są to tylko ALU liczb całkowitych i podobną ilość ich masz Vector INT ALU, więc dalej zależność o której mówiłem występuje. Za to zauważ, że ALU do mnożenia i dodawania liczb zmiennoprzecinkowych (FMA – float mul add) masz 2 – a w zasadzie jest to jeden FMA rozdzielony na 2 (jeden jest MUL (mnożenie), a drugi ADD (dodawanie)) – co więcej ten FMA jest jednostką wektorową o szerokości 256bit. Powyższy przykład mógłby robić się tylko na jednym ALU mnożenia liczb zmiennoprzecinkowych… a od tego, czy program byłby zwektowyzowany zależy to, czy będzie to 1x instrukcja na raz czy 4/8 liczb na raz liczone (zależnie czy liczby 32 czy 64bit). A dokładniej to 1x instrukcja w wersji niezwektoryzowanej, a do 16/32 w wersji zwektoryzowanej (poza FMA w Haskwellu jest jeszcze AVX2)

Co do przykładu to jeśli chcesz zmienić jasność i zapisać do pliku to Fragment Shader jest słabą opcją, szczególnie, że GPU może nie obsługiwać rozmiaru tekstury do jakiej chcesz rysować, więc zapis do tekstury i odczyt jej zawartości raczej odpada. Opcją lepszą jest OpenCL i kernele obliczeniowe, ale za dużo sprzętu jeszcze jest na rynku który tego nie obsługuje, dlatego trzeba robić 2x wersje – wektorową z instrukcjami CPU, i wektorowo w OpenCL.

Masz rację. Za to INT-y i typowe operacje procesora można już elastyczniej rozkładać.

I tak Michał ma więcej od ciebie i od nas wszystkich :P

Podobno testuje je na Linuksie w ramach OSWorld.pl.