On 2015-11-14 14:52, Pszemol wrote:

Tak, tak, Samsung 4-rdzeniowy, 4-giga ram a wciąż Note 5
wolniejsza od iPhone z 2-giga ramu i 2-rdzeniowym procem.

Tak tak, bardzo pouczający test. Widocznie nie zwuażyles że sprawdzany był stopień reaktywności GUIa nie predkośc CPU czy pamięci. I to sprawdzany dość kiepsko. Zaryzykuje że gdyby nie kilku imbecyli w Google i Apple i producentów oprogramowania na obie platformy responsywnośc tą mozna by bylo podnieść znacznie wyżej. Wygoda obsługi wspołczesnych systemów operacyjnych związana jest z jakością softu a dopiero w drugiej kolejności z prędkościami hardware.

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message news:n27gts$m5p$1node2.news.atman.pl...

On 2015-11-14 14:52, Pszemol wrote:

Tak, tak, Samsung 4-rdzeniowy, 4-giga ram a wciąż Note 5
wolniejsza od iPhone z 2-giga ramu i 2-rdzeniowym procem.

Tak tak, bardzo pouczający test. Widocznie nie zwuażyles że sprawdzany był stopień reaktywności GUIa nie predkośc CPU czy pamięci. I to sprawdzany dość kiepsko. Zaryzykuje że gdyby nie kilku imbecyli w Google i Apple i producentów oprogramowania na obie platformy responsywnośc tą mozna by bylo podnieść znacznie wyżej. Wygoda obsługi wspołczesnych systemów operacyjnych związana jest z jakością softu a dopiero w drugiej kolejności z prędkościami hardware.

Chcesz powiedzieć, że konieczność załadowania ponownie do pamięci
aplikacji już raz uruchomionej 20 sekund wcześniej w Androidzie nie
jest dla Ciebie istotną wadą tego systemu i nie sprawia dla Ciebie
żadnej różnicy jeśli chodzi o przyjemność użycia takiego telefonu ?
Do czego służy w Androidzie te 4G ramu jeśli te kilka apek się nie mieści
i trzeba je ponownie z pamięci masowej ładować do ram po 20 sekundach?

On 2015-11-14 15:48, Pszemol wrote:

Tak, tak, Samsung 4-rdzeniowy, 4-giga ram a wciąż Note 5
wolniejsza od iPhone z 2-giga ramu i 2-rdzeniowym procem.

Tak tak, bardzo pouczający test. Widocznie nie zwuażyles że sprawdzany
był stopień reaktywności GUIa nie predkośc CPU czy pamięci. I to
sprawdzany dość kiepsko. Zaryzykuje że gdyby nie kilku imbecyli w
Google i Apple i producentów oprogramowania na obie platformy
responsywnośc tą mozna by bylo podnieść znacznie wyżej. Wygoda obsługi
wspołczesnych systemów operacyjnych związana jest z jakością softu a
dopiero w drugiej kolejności z prędkościami hardware.

Chcesz powiedzieć, że konieczność załadowania ponownie do pamięci
aplikacji już raz uruchomionej 20 sekund wcześniej w Androidzie nie
jest dla Ciebie istotną wadą tego systemu i nie sprawia dla Ciebie
żadnej różnicy jeśli chodzi o przyjemność użycia takiego telefonu ?

Odnosze się do "Samsung 4-rdzeniowy" vs sprawdzanie szybkości klikania. Jedno z drugim ma mniej wspolego niż się wydaje.

Do czego służy w Androidzie te 4G ramu jeśli te kilka apek się nie mieści
i trzeba je ponownie z pamięci masowej ładować do ram po 20 sekundach?

Jaką dajesz gwarancję że wersja iOS jest taka sama jak androidowa pod względem rozmiaru w ram, metod otwierania bibliotek dzielonych, komunikacji z OS, itd? Jak można ocneniać procesory kiedy problem leży w budowie OS i budowie aplikacji?

Ja nie twierdzę że coś jest lepsze od czegoś, ale rozbawiła mnie koncepcja że klikanie w gui ma być dowodem na badziewnośc cpu ... responsywność gui zależy przede wszystkim od umiejetnosci programistow apliakcji, potem os a na szarym końcu cpu.

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message news:n27jer$old$1node2.news.atman.pl...

On 2015-11-14 15:48, Pszemol wrote:

Tak, tak, Samsung 4-rdzeniowy, 4-giga ram a wciąż Note 5
wolniejsza od iPhone z 2-giga ramu i 2-rdzeniowym procem.

Tak tak, bardzo pouczający test. Widocznie nie zwuażyles że sprawdzany
był stopień reaktywności GUIa nie predkośc CPU czy pamięci. I to
sprawdzany dość kiepsko. Zaryzykuje że gdyby nie kilku imbecyli w
Google i Apple i producentów oprogramowania na obie platformy
responsywnośc tą mozna by bylo podnieść znacznie wyżej. Wygoda obsługi
wspołczesnych systemów operacyjnych związana jest z jakością softu a
dopiero w drugiej kolejności z prędkościami hardware.

Chcesz powiedzieć, że konieczność załadowania ponownie do pamięci
aplikacji już raz uruchomionej 20 sekund wcześniej w Androidzie nie
jest dla Ciebie istotną wadą tego systemu i nie sprawia dla Ciebie
żadnej różnicy jeśli chodzi o przyjemność użycia takiego telefonu ?

Odnosze się do "Samsung 4-rdzeniowy" vs sprawdzanie szybkości klikania. Jedno z drugim ma mniej wspolego niż się wydaje.

Do czego służy w Androidzie te 4G ramu jeśli te kilka apek się nie mieści
i trzeba je ponownie z pamięci masowej ładować do ram po 20 sekundach?

Jaką dajesz gwarancję że wersja iOS jest taka sama jak androidowa pod względem rozmiaru w ram, metod otwierania bibliotek dzielonych, komunikacji z OS, itd? Jak można ocneniać procesory kiedy problem leży w budowie OS i budowie aplikacji?

Ja nie twierdzę że coś jest lepsze od czegoś, ale rozbawiła mnie koncepcja że klikanie w gui ma być dowodem na badziewnośc cpu ... responsywność gui zależy przede wszystkim od umiejetnosci
programistow apliakcji, potem os a na szarym końcu cpu.

Ale my tu nie o ocenie CPU tylko o ocenie smartfona z super hiper CPU.
Bo ten CPU to jest duma serii Galaxy, że taki cacy, 4-rdzeniowy...
I co z tego skoro iPhone z 2-rdzeniowym A9 i połową rozmiaru RAMu
przy codziennej pracy z telefonem wychodzi znacznie szybszy?

On 2015-11-14 16:34, Pszemol wrote:

Ale my tu nie o ocenie CPU tylko o ocenie smartfona z super hiper CPU.
Bo ten CPU to jest duma serii Galaxy, że taki cacy, 4-rdzeniowy...

Puśc na nim obliczenia wtedy możesz oceniać cpu.

I co z tego skoro iPhone z 2-rdzeniowym A9 i połową rozmiaru RAMu
przy codziennej pracy z telefonem wychodzi znacznie szybszy?

Bo jest bardziej *responsywny*. Szybkośc a responsywanośc to dwie różne rzeczy. Nietechniczni najczęsciej uzywają slowa "szybkość" nie zdając sobie sprawy że chodzi im o responsywność. Osiagnięcie tego drugiego wymaga wysilenia się programistów, więc łatwiej jest pakować szybsze cpu do telefonów i pisać aplikacje byle jak. Dotyczy to też osów.

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message news:n27kg5$pct$1node2.news.atman.pl...

On 2015-11-14 16:34, Pszemol wrote:

Ale my tu nie o ocenie CPU tylko o ocenie smartfona z super hiper CPU.
Bo ten CPU to jest duma serii Galaxy, że taki cacy, 4-rdzeniowy...

Puśc na nim obliczenia wtedy możesz oceniać cpu.

A kto w telefonie robi obliczenia numeryczne?
Mam Ci coś jeszcze skompilować w FORTRANIE 77 pod iOS? :-)

Swoją drogą, czy ktoś zrobił już taki kompilator? :-)))))

I co z tego skoro iPhone z 2-rdzeniowym A9 i połową rozmiaru RAMu
przy codziennej pracy z telefonem wychodzi znacznie szybszy?

Bo jest bardziej *responsywny*. Szybkośc a responsywanośc to dwie różne rzeczy. Nietechniczni najczęsciej uzywają slowa "szybkość" nie zdając sobie sprawy że chodzi im o responsywność. Osiagnięcie tego drugiego wymaga wysilenia się programistów, więc łatwiej jest pakować szybsze
cpu do telefonów i pisać aplikacje byle jak. Dotyczy to też osów.

Zgadzamy się w 100%. Niedawno miałem interview z kandydatem
na programistę C# w naszej firmie... Ale miałem ubaw jak gostek
na pytanie co zrobi w programie aby zabezpieczyć się przed błędem
alokacji pamięci odburknął "za mało pamięci to nie mój problem,
niech sobie klient wstawi więcej pamięci do peceta" :-)) Ha, ha, ha :-)
Facio wczytywać chciał pół bazy danych z dysku do pamięci i tam
szukać stringów w buforach "bo szybciej" :-))) Brute Force Rulez!!

On 2015-11-14 17:06, Pszemol wrote:

Puśc na nim obliczenia wtedy możesz oceniać cpu.

A kto w telefonie robi obliczenia numeryczne?

Prawie każda gra. Mapy. Odtwarzanie filmów. De facto jednak wielordzeniowe cpu pakuje sie do telefonów nie dlatego że liczymy coraz więcej tylko dlatego że programiści są coraz bardziej leniwi i tępi.

Mam Ci coś jeszcze skompilować w FORTRANIE 77 pod iOS? :-)

Nie.

Swoją drogą, czy ktoś zrobił już taki kompilator? :-)))))

Bez wątpienia bo sa translatory z Fortrana na cokolwiek, więc nie wykluczone że i na Objective-C czy co tam ostatnio Apple oglosił za modne.

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message news:n27naf$sa0$1node2.news.atman.pl...

On 2015-11-14 17:06, Pszemol wrote:

Puśc na nim obliczenia wtedy możesz oceniać cpu.

A kto w telefonie robi obliczenia numeryczne?

Prawie każda gra. Mapy. Odtwarzanie filmów. De facto jednak wielordzeniowe cpu pakuje sie do telefonów nie dlatego że liczymy coraz więcej tylko dlatego że programiści są coraz bardziej leniwi i tępi.

Otóż to! I zamiast pomyśleć używają cpu-żernych i pamięcio-żernych
rozwiązań tylko po to aby łatwo i szybko byle co naskrobać i sprzedać.

Mam Ci coś jeszcze skompilować w FORTRANIE 77 pod iOS? :-)

Nie.

Swoją drogą, czy ktoś zrobił już taki kompilator? :-)))))

Bez wątpienia bo sa translatory z Fortrana na cokolwiek, więc nie wykluczone że i na Objective-C czy co tam ostatnio Apple oglosił
za modne.

Chyba Swift, oglądałem tutorial na lynda.com, całkiem fajnie wygląda.

On Sat, 14 Nov 2015 10:06:58 -0600, "Pszemol" <Pszemol@PolBox.com> wrote:

Facio wczytywać chciał pół bazy danych z dysku do pamięci i tam
szukać stringów w buforach "bo szybciej" :-))) Brute Force Rulez!!

A słyszałes o in-memory-database? Nody MySQL cluster przechowują tabele wyłącznie w ram a dysk jest im poprzedni tokio do startu i zatrzymania.

--
Marek

"Marek" <fake@fakeemail.com> wrote in message news:almarsoft.6708209682337074530news.neostrada.pl...

On Sat, 14 Nov 2015 10:06:58 -0600, "Pszemol" <Pszemol@PolBox.com> wrote:

Facio wczytywać chciał pół bazy danych z dysku do pamięci i tam
szukać stringów w buforach "bo szybciej" :-))) Brute Force Rulez!!

A słyszałes o in-memory-database? Nody MySQL cluster przechowują tabele wyłącznie w ram a dysk jest im poprzedni tokio do startu i zatrzymania.

Nie, nie słyszałem... teraz mi powiedziałeś o tym  :-)

On Sun, 15 Nov 2015 06:28:56 -0600, "Pszemol" <Pszemol@PolBox.com> wrote:

Nie, nie słyszałem... teraz mi powiedziałeś o tym  :-)

Co to za firma, gdzie osoba nie znająca takich oczywistości  bierze udział w merytorycznej ocenie podczas rekrutacji?

--
Marek

"Marek" <fake@fakeemail.com> wrote in message news:almarsoft.4774506372774758408news.neostrada.pl...

On Sun, 15 Nov 2015 06:28:56 -0600, "Pszemol" <Pszemol@PolBox.com> wrote:

Nie, nie słyszałem... teraz mi powiedziałeś o tym  :-)

Co to za firma, gdzie osoba nie znająca takich oczywistości bierze udział w merytorycznej ocenie podczas rekrutacji?

:-) to firma, w której nie zezwala się na otwieranie DAO
i ładowanie mega-giga-bajtów do ram po co aby tam
w ramie, na piechotę, robić wyszukiwanie stringami, bo
w "ramie szybciej, wie pan, nanosekundy a hdd milisekundy".

Użytkownik Sebastian Biały heby@poczta.onet.pl ...

Jaką dajesz gwarancję że wersja iOS jest taka sama jak androidowa pod względem rozmiaru w ram, metod otwierania bibliotek dzielonych, komunikacji z OS, itd? Jak można ocneniać procesory kiedy problem leży w budowie OS i budowie aplikacji?

A jakie to ma znaczenie z punktu widzenia uzytkownika?

"Budzik" <budzik61@poczta.o.n.e.t.pl.nie.spam.oj> wrote in message news:XnsA552AF9E75CA5budzik61pocztaonetpl127.0.0.1...

Użytkownik Sebastian Biały heby@poczta.onet.pl ...

Jaką dajesz gwarancję że wersja iOS jest taka sama jak androidowa pod
względem rozmiaru w ram, metod otwierania bibliotek dzielonych,
komunikacji z OS, itd? Jak można ocneniać procesory kiedy problem
leży w budowie OS i budowie aplikacji?

A jakie to ma znaczenie z punktu widzenia uzytkownika?

On zdaje się ten test zrozumiał jako test procesora...
A chodziło o test szybkości całego telefonu.

On 2015-11-14 18:22, Pszemol wrote:

Jaką dajesz gwarancję że wersja iOS jest taka sama jak androidowa pod
względem rozmiaru w ram, metod otwierania bibliotek dzielonych,
komunikacji z OS, itd? Jak można ocneniać procesory kiedy problem
leży w budowie OS i budowie aplikacji?

A jakie to ma znaczenie z punktu widzenia uzytkownika?

On zdaje się ten test zrozumiał jako test procesora...

Tak, film wyraźnie mówił od odczuwalnym komforcie pracy a w poście przeczytałem o 4 rdzeniach vs 2 rdzenie. I *tylko* tego się czepiam. Że wnioski błędne.

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message news:n27s62$14m$1node2.news.atman.pl...

On 2015-11-14 18:22, Pszemol wrote:

Jaką dajesz gwarancję że wersja iOS jest taka sama jak androidowa pod
względem rozmiaru w ram, metod otwierania bibliotek dzielonych,
komunikacji z OS, itd? Jak można ocneniać procesory kiedy problem
leży w budowie OS i budowie aplikacji?

A jakie to ma znaczenie z punktu widzenia uzytkownika?

On zdaje się ten test zrozumiał jako test procesora...

Tak, film wyraźnie mówił od odczuwalnym komforcie pracy a w poście przeczytałem o 4 rdzeniach vs 2 rdzenie. I *tylko* tego się czepiam. Że wnioski błędne.

Przykro mi że Cię zmyliłem :-) Moje intencje były porównać
jak sprawnie i szybko działają oba telefony z punktu widzenia
użytkownika, gdzie przełączanie między aplikacjami często
determinuje sposób używania telefonu (jeśli jest łatwy iwygodny).

O procesorach było w kontekście takim, że Androidowcy często
chwalą się procesorem i liczbą jego rdzeni jak jakimś wyjatkowym
osiągnięciem i wytykają posiadaczom iPhonów że ich telefony
są "gorsze" bo mają procki z mniejszą liczbą rdzeni...

Tak jak słusznie zauważył kol. Budzik, użytkownik ma w nosie
to, *dlaczego* jego iPhone jest szybszy od Galaxy Note - ważne
jest że jest szybszy a reszta jak procesory jest już tylko dla nas,
elektroników ważna :-)

On 2015-11-14 18:56, Pszemol wrote:

O procesorach było w kontekście takim, że Androidowcy często
chwalą się procesorem i liczbą jego rdzeni jak jakimś wyjatkowym
osiągnięciem i wytykają posiadaczom iPhonów że ich telefony
są "gorsze" bo mają procki z mniejszą liczbą rdzeni...

Android jest napisany przez ludzi nie mających pojecia o tym że user końcowy nie jest programistą. Zaprzepaszczono już chyba na zawsze koncepcje responsywnego i w miare otwartego systemu operacyjnego projektując to samo co jest popularne od lat 80tych czyli event driven system w którym odpowiedzialnośc za user experience spoczywa na programiście finalnego produktu (a jest on zazwyczaj leserem). Jestem na to zły na google bo mieli szansę zmienić coś na lepsze a spieprzyli po staremu. Apple przykladał wieksza wagę do responsywności czego efekty widać do dzisiaj, czyli szerszy usmiech na twarzy konsumenta. I nawet jesli to ściema bo aplikacje nie są szybsze, to okazalo się ze ściema się sprzedaje lepiej niż pieprzenie googla o hardware.

Google równiez spieprzył po staremu problem update kernela. Spieprzył sterowniki. Spieprzył deployment core. Spieprzył *wszystko* co ważne z punktu widzenia designu OS i to chyba głównie z powodu wyboru monolitycznego kernela. Apple też spieprzyło ale tam z powodu tylko kilku zamknietych hardware nie jest to takie widoczne. Natomiast ikonki ładne. Tak. Ikonki.

Użytkownik "Sebastian Biały"  napisał w wiadomości grup dyskusyjnych:n27tkq$2mq$1@node2.news.atman.pl...

Google równiez spieprzył po staremu problem update kernela. Spieprzył sterowniki. Spieprzył deployment core. Spieprzył *wszystko* co ważne z punktu widzenia designu OS i to chyba głównie z powodu wyboru monolitycznego kernela. Apple też spieprzyło ale tam z powodu tylko kilku zamknietych hardware nie jest to takie widoczne. Natomiast ikonki ładne. Tak. Ikonki.

Nigdy nie programowałem pod androida, ale jeśli miałbym porównywać iOS i Windows to ten pierwszy to po prostu koszmar developera.

Użytkownik "Ghost"

Google równiez spieprzył po staremu problem update kernela. Spieprzył sterowniki. Spieprzył deployment core. Spieprzył *wszystko* co ważne z punktu widzenia designu OS i to chyba głównie z powodu wyboru monolitycznego kernela. Apple też spieprzyło ale tam z powodu tylko kilku zamknietych hardware nie jest to takie widoczne. Natomiast ikonki ładne. Tak. Ikonki.

Nigdy nie programowałem pod androida, ale jeśli miałbym porównywać iOS i
Windows to ten pierwszy to po prostu koszmar developera.
-- -
http://developer.xamarin.com/guides/cross-platform/xamarin-forms/ :-)

On 2015-11-14 20:19, Ghost wrote:

Nigdy nie programowałem pod androida, ale jeśli miałbym porównywać iOS i
Windows to ten pierwszy to po prostu koszmar developera.

Nie o to chodzi. Nie o jakośc narzedzi biega a o całościowy projekt OSa. Kolesie przed google ktorzy robili androida tak naprawdę wzieli kernel monolityczny (na Boga, dlaczego???) a że pierwszy z brzegu był Linux to mamy pozamiatane w kwestii sterowników bo jest taki sam burdel z gatunku "no... trzeba przekompilować". Wygenerowało to równiez masę zależności które dotarły aż do GUI. Zarowno w Androidzie, Windowsie, iOSie itd można napisać kiepską aplikacje ktora jest nieresponsywna i "psuje user experience". Android jest pełny takich aplikacji bo OS nijak nie wymusza grzecznych zachowań, w dodatku częsc googlowych ma takie cechy. W iOSie przynajmniej soft systemowy jest pisany grzeczniej ale ten od userów ... A w windowsie ... no cóż "swapuje, trzeba poczekać". Innymi słowy wszyscy gracze na rynku popełnili te same błędy. A człek myślał że za 10tym razem koło wyjdzie wreszcie okrągłe.

Mam androida bo wymagam tylko działania mapy i dzwonienia. Nic mnie więcej nie obchodzi, a to głownie dlatego ze od kliknięcia do reakcji upływa bywa ze i 3 sekundy, co jest *skandaliczne* i powoduje podnoszenie ciśnienia. I winni są wszyscy, od pierdoły wybierającego kernel, przez sztab programistów z lat 80tych piszących dalvika po współczesne pakowanie coraz to szybszego cpu bo inaczej się nie da.

On Sat, 14 Nov 2015 22:27:52 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

Kolesie przed google ktorzy robili androida tak naprawdę wzieli

kernel

monolityczny (na Boga, dlaczego???) a że pierwszy z brzegu był

Linux to

Nie przesadzaj z tą monolitycznością, Linux współcześnie nie  jest taki monolityczny jak był 20 lat temu  Większość sterownikĂłw moĹźe być w modułach, do Androida wybrali jedynie monolityczną konfigurację (jako moĹźliwą) ale to nie oznacza, Ĺźe Linux (kernel) jako taki jest jedynie monolityczny.

--
Marek

On 2015-11-15 00:13, Marek wrote:

Nie przesadzaj z tą monolitycznością, Linux współcześnie nie  jest taki
monolityczny jak był 20 lat temu

Chyba żartujesz. Gołe jądro to kilka MB kodu który nie ma nic wspólnego z mikrojadrem. Moduły? Bez przesady a gdzie ABI do nich stabilne przez kilka lat?

 Ĺźe Linux (kernel) jako taki jest jedynie
monolityczny.

Albo jest mikro albo monolit. Mozna jeszcze być hybrydą, ale to nie rozwiązuje problemu ABI do sterowników.

Mam androida bo wymagam tylko działania mapy i dzwonienia. Nic mnie
więcej nie obchodzi, a to głownie dlatego ze od kliknięcia do reakcji
upływa bywa ze i 3 sekundy, co jest *skandaliczne* i powoduje
podnoszenie ciśnienia. I winni są wszyscy, od pierdoły wybierającego
kernel, przez sztab programistów z lat 80tych piszących dalvika po
współczesne pakowanie coraz to szybszego cpu bo inaczej się nie da.

No dobrze, co z tym teraz mozemy zrobic: narzekac, korzystac czy jedno i drugie? ;]
Jest jak jest i chyba do tej pory nie bylo idelanego systemu, kazdy mial swoje przypadlosci łącznie z WinCE, PalmOS czy Symbianem. Jak nie calkowicie system to sposob promocji przekladajacy sie na ilosc dostepnych aplikacji itd. Nawet przyjmujac pszemolowy punkt widzenia, ze iOS jest objawieniem niezwyklym to caly ekosystem zamyka sie w dwoch aktualnych urzadzeniach, ktore sa metro-cacuszkami nie oferujac wielu ficzerow dostepnych w konkurencyjnych ekosystemach. Wg mnie juz od dluzszego czasu pogon za dodatkowa moca obliczeniowa jest bez sensu. Zdecydowanie wolalbym prace nad wydluzeniem czasu pracy czy lepsza czytelnoscia ekranu w mocno naslonecznionych miejscach. Jak dla mnie przelomem jest ostatnia propozycja Motoroli w zakresie wzmocnienia ekranu. Droptesty traca jakikolwiek sens. Mam nadzieje, ze inni producenci podlapia ten trend. Dobra sprawa jest tez rozwijanie jakosci foto, zreszta widac to po tym jak kompakty mocno poszly w odstawke i trend sie nasila.

"atm" <_@vp.pl> wrote in message news:5647c245$0$639$65785112news.neostrada.pl...

Nawet przyjmujac pszemolowy punkt widzenia, ze iOS jest
objawieniem niezwyklym to caly ekosystem zamyka sie w dwoch aktualnych urzadzeniach, ktore sa metro-cacuszkami nie oferujac
wielu ficzerow dostepnych w konkurencyjnych ekosystemach.

Chcesz telefony bardziej męskie, w kolorze wojskowego moro? :-)
Jakich ficzerów nie oferując? Odbiornika FM-radio???

Wg mnie juz od dluzszego czasu pogon za dodatkowa moca obliczeniowa jest bez sensu. Zdecydowanie wolalbym prace nad wydluzeniem czasu pracy czy lepsza czytelnoscia ekranu w mocno naslonecznionych miejscach.

Jedno drugiemu nie przeszkadza - można wydłużać czas pracy
i jakość/czytelność ekranu w nasłonecznionych miejscach.

Swoją drogą ja nie narzekam na tą czytelność w iPhone4.
Twierdzisz, że ją popsuł Apple w następnych generacjach iPhone?
Bo to, że popsuł czas pracy na jednym ladowaniu baterii to się
zgodzę - pod iOS7 iPhone4 pracuje ciut krócej niż pracował pod iOS6.

Jak dla mnie przelomem jest ostatnia propozycja Motoroli
w zakresie wzmocnienia ekranu. Droptesty traca jakikolwiek sens.

No chyba że te z tarasów widokowych Statuły Wolności
lub Eifel Tower :-)

Mam nadzieje, ze inni producenci podlapia ten trend.

Ja też :-)

Dobra sprawa jest tez rozwijanie jakosci foto, zreszta widac
to po tym jak kompakty mocno poszly w odstawke i trend sie nasila.

Ktoś jeszcze kompakty kupuje?
Chyba tylko te z wbudowanym GSM :-)

On 2015-11-15 13:47, Pszemol wrote:

"atm" <_@vp.pl> wrote in message
news:5647c245$0$639$65785112news.neostrada.pl...

Nawet przyjmujac pszemolowy punkt widzenia, ze iOS jest
objawieniem niezwyklym to caly ekosystem zamyka sie w dwoch aktualnych
urzadzeniach, ktore sa metro-cacuszkami nie oferujac
wielu ficzerow dostepnych w konkurencyjnych ekosystemach.

Chcesz telefony bardziej męskie, w kolorze wojskowego moro? :-)
Jakich ficzerów nie oferując? Odbiornika FM-radio???

Wodoszczelnosc / upadkoodpornosc / dowolny kolor i material / slot kart pamieci lub jego brak / wymienna bateria lub wbudowana / glosniki stereo na froncie itd A i radio byc moze ktos do tej kolekcji dorzuci, ja z niego nigdy nie korzystalem; jest tez pilot uniwersalny w moim LG.

Wg mnie juz od dluzszego czasu pogon za dodatkowa moca obliczeniowa
jest bez sensu. Zdecydowanie wolalbym prace nad wydluzeniem czasu
pracy czy lepsza czytelnoscia ekranu w mocno naslonecznionych miejscach.

Jedno drugiemu nie przeszkadza - można wydłużać czas pracy
i jakość/czytelność ekranu w nasłonecznionych miejscach.

A prosze bardzo - jestem za.

Swoją drogą ja nie narzekam na tą czytelność w iPhone4.
Twierdzisz, że ją popsuł Apple w następnych generacjach iPhone?
Bo to, że popsuł czas pracy na jednym ladowaniu baterii to się
zgodzę - pod iOS7 iPhone4 pracuje ciut krócej niż pracował pod iOS6.

Apple startuje w wyscigu, w ktorym sam sobie umiescil poprzeczke i bije brawo: najcienszy telefon swiata ;\ Po co oni tak odchudzaja tego iPhone'a? Zobacz ile ludzi placze w sieci z powodu malej pojemnosci baterii.

Jak dla mnie przelomem jest ostatnia propozycja Motoroli
w zakresie wzmocnienia ekranu. Droptesty traca jakikolwiek sens.

No chyba że te z tarasów widokowych Statuły Wolności
lub Eifel Tower :-)

Gosc zrzucal ta Motke z 1 czy 2 pietra. Wyswietlacz prztrwal ale wysiadla elektronika lub bateria.

Mam nadzieje, ze inni producenci podlapia ten trend.

Ja też :-)

Dobra sprawa jest tez rozwijanie jakosci foto, zreszta widac
to po tym jak kompakty mocno poszly w odstawke i trend sie nasila.

Ktoś jeszcze kompakty kupuje?
Chyba tylko te z wbudowanym GSM :-)

"atm" <_@vp.pl> wrote in message news:56488492$0$22844$65785112news.neostrada.pl...

On 2015-11-15 13:47, Pszemol wrote:

"atm" <_@vp.pl> wrote in message
news:5647c245$0$639$65785112news.neostrada.pl...

Nawet przyjmujac pszemolowy punkt widzenia, ze iOS jest
objawieniem niezwyklym to caly ekosystem zamyka sie w dwoch aktualnych
urzadzeniach, ktore sa metro-cacuszkami nie oferujac
wielu ficzerow dostepnych w konkurencyjnych ekosystemach.

Chcesz telefony bardziej męskie, w kolorze wojskowego moro? :-)
Jakich ficzerów nie oferując? Odbiornika FM-radio???

Wodoszczelnosc / upadkoodpornosc / dowolny kolor i material / slot kart pamieci lub jego brak / wymienna bateria lub wbudowana / glosniki stereo na froncie itd A i radio byc moze ktos do tej kolekcji dorzuci, ja z niego nigdy nie korzystalem; jest tez pilot uniwersalny w moim LG.

Jeśli przez dowolny kolor masz na myśli kolor czarny, to prawie jest.
A jeśli narzekasz że nie ma iPhone w kolorze zielonym lub niebieskim
to jesteś bardziej metro- niż Ci się wydaje :-)

Wg mnie juz od dluzszego czasu pogon za dodatkowa moca obliczeniowa
jest bez sensu. Zdecydowanie wolalbym prace nad wydluzeniem czasu
pracy czy lepsza czytelnoscia ekranu w mocno naslonecznionych miejscach.

Jedno drugiemu nie przeszkadza - można wydłużać czas pracy
i jakość/czytelność ekranu w nasłonecznionych miejscach.

A prosze bardzo - jestem za.

Swoją drogą ja nie narzekam na tą czytelność w iPhone4.
Twierdzisz, że ją popsuł Apple w następnych generacjach iPhone?
Bo to, że popsuł czas pracy na jednym ladowaniu baterii to się
zgodzę - pod iOS7 iPhone4 pracuje ciut krócej niż pracował pod iOS6.

Apple startuje w wyscigu, w ktorym sam sobie umiescil poprzeczke i bije brawo: najcienszy telefon swiata ;\ Po co oni tak odchudzaja tego iPhone'a? Zobacz ile ludzi placze w sieci z powodu malej pojemnosci baterii.

Nie wiem własnie - może łatwiej go wtedy (wy)giąć?

Jak dla mnie przelomem jest ostatnia propozycja Motoroli
w zakresie wzmocnienia ekranu. Droptesty traca jakikolwiek sens.

No chyba że te z tarasów widokowych Statuły Wolności
lub Eifel Tower :-)

Gosc zrzucal ta Motke z 1 czy 2 pietra. Wyswietlacz prztrwal ale wysiadla elektronika lub bateria.

Nie wiem co gorsze... Smartfony z pękniętym szkłem przed LCD
ciągle działają, mimo że nieestetycznie wyglądają.

On 2015-11-15 00:22, atm wrote:

No dobrze, co z tym teraz mozemy zrobic: narzekac, korzystac czy jedno i
drugie? ;]

Narzekać i troche uzywać. Google ma dośc pieniedzy aby zmieniąc design przynajmniej kernela. Z reszta bylem pewien że ostatnie dziury na poziomie OSa i kłopoty z aktualizacją wymusza rozwiązanie, ale zapomnialem że w google też pracują marketoidy. I nie da się.

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message news:n2891h$djd$1node2.news.atman.pl...

Innymi słowy wszyscy gracze na rynku popełnili te
same błędy. A człek myślał że za 10tym razem
koło wyjdzie wreszcie okrągłe.

Ja tu widzę chłopie szansę dla Ciebie!
Zrób system, Tobie wyjdzie okrągłe!
Mówię poważnie...

Mam androida bo wymagam tylko działania mapy i dzwonienia. Nic mnie więcej nie obchodzi, a to głownie dlatego ze od kliknięcia do reakcji upływa bywa ze i 3 sekundy, co jest *skandaliczne* i powoduje podnoszenie ciśnienia. I winni są wszyscy, od pierdoły wybierającego kernel, przez sztab programistów z lat 80tych piszących dalvika po współczesne pakowanie coraz to szybszego cpu bo inaczej się nie da.

Nie wierzę że 3 sekundy... co masz za sprzęt?

On 2015-11-15 13:39, Pszemol wrote:

Ja tu widzę chłopie szansę dla Ciebie!
Zrób system, Tobie wyjdzie okrągłe!
Mówię poważnie...

Napisanie kernela i OSa tego poziomu przekracza kilkukrotnie długośc zycia programisty. Tak że ironia nietrafiona.

Nie wierzę że 3 sekundy... co masz za sprzęt?

Rózne. Ze 3 telefony, ze 2 tablety. Wszystkie tanie. Mają taka wadę że jeśli system robi "Bardzo Ważne Aktualizacje" to cała reszta aplikacji dziala znacznie wolniej co powoduje lagi w uzywaniu. Najlepiej widać to na moim staruszku Tracer OVO 1.2. Jesli coś się aktualizauje nie jesteś w stanie przewijać ekranów. Lagi mają do 3 sekund, co jest absolutnie absurdalne.

To nie dlatego że hardware jest gówniany. To dlatego że kernel + os + aplikacje sa do dupy. Patrze na to z punktu widzenia programisty i nie ma uzasadnienia dlaczego to jest az takie dziadowskie. To jest dziadowskie wyłacznie dlatego że nikt z tych misiów od Androida nie zaprojektował całości responsywnie. Zaprojektowali byle jak i nie ma odwrotu.

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message news:n2a0vm$74p$1node1.news.atman.pl...

On 2015-11-15 13:39, Pszemol wrote:

Ja tu widzę chłopie szansę dla Ciebie!
Zrób system, Tobie wyjdzie okrągłe!
Mówię poważnie...

Napisanie kernela i OSa tego poziomu przekracza kilkukrotnie
długośc zycia programisty. Tak że ironia nietrafiona.

Nie miałem na myśli Twojej roli jako pojedynczego kodera.
Miałem na myśli Ciebie w roli pomysłodawcy i grupy
koderów których sobie zatrudnisz aby pracowali pod Twoje
dyktando. Myślisz, że jak byś stworzył kompatybilną
alternatywę dla obecnego jądra Androida to Google nie
byłoby Twoim produktem zainteresowane?

Nie wierzę że 3 sekundy... co masz za sprzęt?

Rózne. Ze 3 telefony, ze 2 tablety. Wszystkie tanie. Mają taka wadę że jeśli system robi "Bardzo Ważne Aktualizacje" to cała reszta aplikacji dziala znacznie wolniej co powoduje lagi w uzywaniu. Najlepiej widać to na moim staruszku Tracer OVO 1.2. Jesli coś się aktualizauje nie jesteś w stanie przewijać ekranów. Lagi mają do 3 sekund, co jest absolutnie absurdalne.

A ja, rozpieszczony, myślałem że mój stary iPhone4 jest dziś powolny :-)

To nie dlatego że hardware jest gówniany. To dlatego że kernel + os + aplikacje sa do dupy. Patrze na to z punktu widzenia programisty i nie ma uzasadnienia dlaczego to jest az takie dziadowskie. To jest dziadowskie wyłacznie dlatego że nikt z tych misiów od Androida nie zaprojektował całości responsywnie. Zaprojektowali byle jak i nie ma odwrotu.

No przykre jest że dzisiejsi softwarowcy stosują tylko brute-force method.

On 2015-11-15 14:39, Pszemol wrote:

dyktando. Myślisz, że jak byś stworzył kompatybilną
alternatywę dla obecnego jądra Androida to Google nie
byłoby Twoim produktem zainteresowane?

Nie byłoby z wielu wzgledów. Na przykład sytuacja gdy jest kłopot z aktualizacją urządzeń jest na rękę producentom. Oni wola sprzedać nowe niż czekać aż rozpadną się stare. Dziury w sofcie mobile podnoszą sprzedaż i myślę że google o tym wie.

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message news:n2ag00$mp0$1node1.news.atman.pl...

On 2015-11-15 14:39, Pszemol wrote:

dyktando. Myślisz, że jak byś stworzył kompatybilną
alternatywę dla obecnego jądra Androida to Google nie
byłoby Twoim produktem zainteresowane?

Nie byłoby z wielu wzgledów. Na przykład sytuacja gdy jest kłopot z aktualizacją urządzeń jest na rękę producentom. Oni wola sprzedać nowe niż czekać aż rozpadną się stare. Dziury w sofcie mobile podnoszą sprzedaż i myślę że google o tym wie.

Zapachniało teorią spiskową dziejów...

Użytkownik "Pszemol"  napisał w wiadomości grup dyskusyjnych:n2bf16$5ma$1@dont-email.me...
"Sebastian Biały" <heby@poczta.onet.pl> wrote in message

On 2015-11-15 14:39, Pszemol wrote:

dyktando. Myślisz, że jak byś stworzył kompatybilną
alternatywę dla obecnego jądra Androida to Google nie
byłoby Twoim produktem zainteresowane?

Nie byłoby z wielu wzgledów. Na przykład sytuacja gdy jest kłopot z aktualizacją urządzeń jest na rękę producentom. Oni wola sprzedać nowe niż czekać aż rozpadną się stare. Dziury w sofcie mobile podnoszą sprzedaż i myślę że google o tym wie.

Zapachniało teorią spiskową dziejów...

Niekoniecznie.
-producent na pewno woli sprzedac nowe, niz ponosic koszty na utrzymanie starych,
-jak widac w przykladach - do "flagowcow" upgrady sa, a do innych niekoniecznie,
-na razie sprzet sie produkuje coraz to lepszy, a producent tez chce sie pochwalic wodotryskami, a nie udoskonalac produkt bez zysku,
-udoskonalac to mozna w nieskonczonosc, a tu trzeba w pewnym momencie powiedziec "dosc - to wypuszczamy, reszta w nastepnej wersji".

J.

"J.F." <jfox_xnospamx@poczta.onet.pl> wrote in message news:5649ebe0$0$639$65785112news.neostrada.pl...

Użytkownik "Pszemol"  napisał w wiadomości grup dyskusyjnych:n2bf16$5ma$1@dont-email.me...
"Sebastian Biały" <heby@poczta.onet.pl> wrote in message

On 2015-11-15 14:39, Pszemol wrote:

dyktando. Myślisz, że jak byś stworzył kompatybilną
alternatywę dla obecnego jądra Androida to Google nie
byłoby Twoim produktem zainteresowane?

Nie byłoby z wielu wzgledów. Na przykład sytuacja gdy jest kłopot z aktualizacją urządzeń jest na rękę producentom. Oni wola sprzedać nowe niż czekać aż rozpadną się stare. Dziury w sofcie mobile podnoszą sprzedaż i myślę że google o tym wie.

Zapachniało teorią spiskową dziejów...

Niekoniecznie.
-producent na pewno woli sprzedac nowe, niz ponosic koszty na utrzymanie starych,
-jak widac w przykladach - do "flagowcow" upgrady sa, a do innych niekoniecznie,
-na razie sprzet sie produkuje coraz to lepszy, a producent tez chce sie pochwalic wodotryskami, a nie udoskonalac produkt bez zysku,
-udoskonalac to mozna w nieskonczonosc, a tu trzeba w pewnym
momencie powiedziec "dosc - to wypuszczamy, reszta w nastepnej wersji".

Sam zauważasz, że o flagowce producent dba lepiej niż o te z dolnej
półki - a dba dlatego, że chce zbudować im dobrą reputację, choćby
też przez dbanie i ponoszenie kosztów na utrzymanie starych flagowców.
Tylko krótkowzroczny producent dba tylko o nowe.

On Sun, 15 Nov 2015 14:22:38 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

Napisanie kernela i OSa tego poziomu przekracza kilkukrotnie

długośc

zycia programisty. Tak Ĺźe ironia nietrafiona.

Nie potrzeby pisać OSa, to napisze społeczność. A nawet nie musi pisać bo większość już jest napisana.

--
Marek

Użytkownik "Sebastian Biały"  napisał w wiadomości grup dyskusyjnych:n2891h$djd$1@node2.news.atman.pl...

On 2015-11-14 20:19, Ghost wrote:

Nigdy nie programowałem pod androida, ale jeśli miałbym porównywać iOS i
Windows to ten pierwszy to po prostu koszmar developera.

Nie o to chodzi. Nie o jakośc narzedzi biega a o całościowy projekt OSa.

Nie pisałem o narzędziach.

On Sat, 14 Nov 2015 19:13:22 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

to zły na google bo mieli szansę zmienić coś na lepsze a spieprzyli

po

staremu.

Ale co mogli zrobić? Przejęli Androida jak już był praktycznie gotowy (w sensie designu systemu i jego core'a) to już za późno żeby przerobić design osa.

--
Marek

On 2015-11-15 00:06, Marek wrote:

to zły na google bo mieli szansę zmienić coś na lepsze a spieprzyli

po

staremu.

Ale co mogli zrobić? Przejęli Androida jak już był praktycznie gotowy

Mieli wiele lat. W tym czasie napisanie kernela od zera jest jak najbardziej wykonalne, nawet w kilkuosobowym zespole. Tym bardziej że 80% kernela linuxa jest zbędne. Z reszta sa kernele typu mikrojadro. No i nikt nie twierdzi że sterowniki musza być napisane w C albo że ABI musi być co tydzień inne.

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message news:n29if0$ihn$2node2.news.atman.pl...

Mieli wiele lat. W tym czasie napisanie kernela od zera jest jak najbardziej wykonalne, nawet w kilkuosobowym zespole. Tym bardziej że 80% kernela linuxa jest zbędne. Z reszta sa kernele typu mikrojadro. No i nikt nie twierdzi że sterowniki musza być napisane w C albo że ABI musi być co tydzień inne.

A w czym jeśli nie C? W asemblerze mieli pisać, jak w latach 80-tych?

On 2015-11-15 13:48, Pszemol wrote:

Mieli wiele lat. W tym czasie napisanie kernela od zera jest jak
najbardziej wykonalne, nawet w kilkuosobowym zespole. Tym bardziej Ĺźe
80% kernela linuxa jest zbędne. Z reszta sa kernele typu mikrojadro.
No i nikt nie twierdzi że sterowniki musza być napisane w C albo że
ABI musi być co tydzień inne.

A w czym jeśli nie C? W asemblerze mieli pisać, jak w latach 80-tych?

Myslisz tak samo jak misie od Androida. Przecież sterownik musi być w C. A h... nie musi. Może być równie dobrze w tym ich dalviku czy co tam obecnie mają. Nie, nie mówie tego dlatego że jestem ignorantem. Wręcz przeciwnie, programowanie sterowników w tym do kernela Linuxa nie jest mi obce. To jest możliwe i sensowne. To że tego nie robimy ani w Linuxie ani w Windowsie to wynika z faktu że cały swiat OSów jest najzwyczajniej dziadowski w każdym calu. I dlatego rownież że wszystkie wiodące OSy są oparte o monolity.

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message news:n2a15q$17n$1node2.news.atman.pl...

On 2015-11-15 13:48, Pszemol wrote:

Mieli wiele lat. W tym czasie napisanie kernela od zera jest jak
najbardziej wykonalne, nawet w kilkuosobowym zespole. Tym bardziej Ĺźe
80% kernela linuxa jest zbędne. Z reszta sa kernele typu mikrojadro.
No i nikt nie twierdzi że sterowniki musza być napisane w C albo że
ABI musi być co tydzień inne.

A w czym jeśli nie C? W asemblerze mieli pisać, jak w latach 80-tych?

Myslisz tak samo jak misie od Androida. Przecież sterownik musi być w C. A h... nie musi. Może być równie dobrze w tym ich dalviku czy co tam obecnie mają. Nie, nie mówie tego dlatego że jestem ignorantem. Wręcz przeciwnie, programowanie sterowników w tym do kernela Linuxa nie jest mi obce. To jest możliwe i sensowne. To że tego nie robimy ani w Linuxie ani w Windowsie to wynika z faktu że cały swiat OSów jest najzwyczajniej dziadowski w każdym calu. I dlatego rownież że wszystkie wiodące OSy są oparte o monolity.

Ciągle zachęcam Cię abys jednak spędził trochę czasu na poprawienie
tego świata - bo słuchanie geniusza który WIE jak poprawić świat
i zrobiłby to gdyby tylko mógł jest dla mnie frustrujące :-) Weź i zrób!

UĹźytkownik "Sebastian Biały"  napisał w wiadomości grup dyskusyjnych:n2a15q$17n$1@node2.news.atman.pl...

On 2015-11-15 13:48, Pszemol wrote:

Mieli wiele lat. W tym czasie napisanie kernela od zera jest jak
najbardziej wykonalne, nawet w kilkuosobowym zespole. Tym bardziej Ĺźe
80% kernela linuxa jest zbędne. Z reszta sa kernele typu mikrojadro.
No i nikt nie twierdzi że sterowniki musza być napisane w C albo że
ABI musi być co tydzień inne.

A w czym jeśli nie C? W asemblerze mieli pisać, jak w latach 80-tych?

Myslisz tak samo jak misie od Androida. Przecież sterownik musi być w C. A h... nie musi.

No ale wypadałoby, żeby to co napierdala przez 80% jednak było, przynajmniej w C.

On 2015-11-15 14:32, Ghost wrote:

Myslisz tak samo jak misie od Androida. Przecież sterownik musi być w
C. A h... nie musi.

No ale wypadałoby, żeby to co napierdala przez 80% jednak było,
przynajmniej w C.

Przez 99% czasu to napierdala DMA. Które gówno obchodzi kto je skonfigurował i czy się to odbyło przez *port=0x10 czy przez POKE port,16.

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message news:n2a1o5$1mh$1node2.news.atman.pl...

On 2015-11-15 14:32, Ghost wrote:

Myslisz tak samo jak misie od Androida. PrzecieĹź sterownik
musi być w C. A h... nie musi.

No ale wypadałoby, żeby to co napierdala przez 80%
jednak było, przynajmniej w C.

Przez 99% czasu to napierdala DMA.

W jakich scenariuszach używają tego DMA?

On 2015-11-15 14:45, Pszemol wrote:

Myslisz tak samo jak misie od Androida. PrzecieĹź sterownik
musi być w C. A h... nie musi.

No ale wypadałoby, żeby to co napierdala przez 80%
jednak było, przynajmniej w C.

Przez 99% czasu to napierdala DMA.

W jakich scenariuszach używają tego DMA?

Sa 3 przypadki tak z grubsza:
a) urządznie wymaga powolnego odpytywania. Choćby przyciski na obudowie. Tam może dzialać dowolnie wolny kod bo odpytania są tanie

b) urządzenie wymaga przesyłania ciagłych obszarów pamięci poprzez bezustanne smeranie po rejestrach. Takie urzadzenie jest błedne z definicji ponieważ opiera się o pooling. Stosowane powszechnie w latach 80-tych. Pierwsze DMA na komputerach osobistych to okolice blitterów gfx i muzyki.

c) urzadzenie które posiada kanaly DMA. Dotyczy to wszelikich urządzeń masowych takich jak dzwiek, zapisy na dysk/flash, grafika, sieć. W tych przypadkach sterownik inicjuje tylko DMA a reszta dzieje się w tle. Nie istnieje powód dla ktorego sterownik przyjmując przerwanie musi być w C. Może być tak samo w czymkolwiek wliczając w to maszynę wirtualną. Rozwiązuje to problemy ABI.

Obecnie linux jest systemem w którym ABI jest niestabilne i całość Androida cierpi z tego powodu bo głupia naprawa sterownika pociąga za sobą *łaskawe* skompilowanie kernela przez producenta lub gra w rosyjską ruletkę przez communisty czy binarny modul nie uszkodzi systemu (i czy nie zawiera wirusa).

a) i c) nie wymagają od sterownika żadnej prędkości. b) jest bledem hardwareowym i raczej go nie napotkasz we współczesnym sprzęcie.

Już od dawna szybkośc sterownika nie ma za wiele wspólnego z szybkością hardware. Sterownik ustawia jakieś porty i dalej robi się DMA. Do tego nie trzeba C. Nie widze powodu dla którego sterownik dzwięku nie mozna napisać w Javie która w tle translowana jest z bytecode do natywnego kodu jeśli komuś bez sensu zależy na hiper prędkości tych kilkudziesięciu outb.

On Sun, 15 Nov 2015 15:03:18 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

Już od dawna szybkośc sterownika nie ma za wiele wspólnego z

szybkością

hardware. Sterownik ustawia jakieś porty i dalej robi się DMA. Do

tego

nie trzeba C. Nie widze powodu dla którego sterownik dzwięku nie

mozna

napisać w Javie która w tle translowana jest z bytecode do

natywnego

kodu jeśli komuś bez sensu zależy na hiper prędkości tych kilkudziesięciu outb.

Ta jasne, a wtedy DMA 99% czasu czeka na robotę bo driver szybciej nie może go konfigurować.

--
Marek

On 2015-11-15 16:04, Marek wrote:

Ta jasne, a wtedy DMA 99% czasu czeka na robotę bo driver szybciej nie
może go konfigurować.

1. Dlaczego zakladasz że driver translowany z Javy do x86 miałby byc wolny?

2. Dlaczego zakaldasz że DMA jest aż tak dziadowskie że wymaga 100% cpu aby go co nanosekunde na nowo konfigurować? Nie docedniasz współczesnych DMA.

On Sun, 15 Nov 2015 16:06:52 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

1. Dlaczego zakladasz że driver translowany z Javy do x86 miałby

byc wolny?

MoĹźe odwrĂłcę pytanie, przedstaw argumenty dlaczego taki kilkuset megabajtiwy driver (VM + bytecode translowany na x86) miałby być szybki, bo realnie w obecnych warunkach  tak by to wyglądało. To, Ĺźe nie ma bytecodu niewiele zmienia. No chyba, Ĺźe masz na myśli jakąś arch. ze sprzętową Javą. np. procesor Warszawa :-)

2. Dlaczego zakaldasz Ĺźe DMA jest aĹź tak dziadowskie Ĺźe wymaga 100%

cpu

aby go co nanosekunde na nowo konfigurować? Nie docedniasz

współczesnych

DMA.

Nie o to chodzi, byłoby niedociążone więc nie wykorzystane w pełni. DMA działa "odtąd-dotąd" i po wykonaniu zlecenia generalnie nic nie robi. Obawiam się Ĺźe w takim modelu driver  po złoĹźeniu zlecenia, zanim by cpu zmienił kontekst juĹź byłby wykonane. Poza tym nie wszystko sa się zrobić tylko uĹźywając DMA.

--
Marek

On 2015-11-15 23:29, Marek wrote:

1. Dlaczego zakladasz że driver translowany z Javy do x86 miałby

byc wolny?
Może odwrócę pytanie, przedstaw argumenty dlaczego taki kilkuset
megabajtiwy driver (VM + bytecode translowany na x86)

Jesli translowany to po co VM?

miałby być szybki,
bo realnie w obecnych warunkach  tak by to wyglądało.

Już Ci pisałem. Drivery nie musza być szybkie. To nie czasy poolingu.

To, Ĺźe nie ma
bytecodu niewiele zmienia. No chyba, że masz na myśli jakąś arch. ze
sprzętową Javą. np. procesor Warszawa :-)

Pokaż przykład hardware w ktorym musisz wykonywać algorytmikę w sterowniku. I nie, w steorwnikach kart graficznych też wykonuje się jak najmniej algortymiki.

Nie o to chodzi, byłoby niedociążone więc nie wykorzystane w pełni. DMA
działa "odtąd-dotąd" i po wykonaniu zlecenia generalnie nic nie robi.
Obawiam się Ĺźe w takim modelu driver  po złoĹźeniu zlecenia, zanim by cpu
zmienił kontekst już byłby wykonane.

Nie. Obecne CPU przy tak kiepsko kosnstuowanym DMA były by obciążone non-stop po pare procent. Nie są.

Poza tym nie wszystko sa się zrobić
tylko używając DMA.

Jesli coś nie wymaga DMA to słuzy do trywializmów typu odczyt przycisków etc.

On Mon, 16 Nov 2015 18:34:36 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

Jesli translowany to po co VM?

MĂłwiąc VM miałem nie  tylko na myśli interpreter ale całe stawowsko (klasy), to będzie musiało być dodane do translacji, bo driver na pewno  będzie korzystał z wielu klas. Wyjdzie spora binarka z niepotrzebnie załączonym statycznym kodem. Takich rozwiązań się unika podobnie jak statycznego linkowania bo to pamięciowo niewydajne.

Pokaż przykład hardware w ktorym musisz wykonywać algorytmikę w sterowniku. I nie, w steorwnikach kart graficznych też wykonuje się

jak

najmniej algortymiki.

Każdy driver to algorytmika, bo ma wejście (zdarzenie) oraz wyjście (parametry dla DMA) w funkcji zdarzenia czyli DMA=f(we).

Nie. Obecne CPU przy tak kiepsko kosnstuowanym DMA były by

obciążone

non-stop po pare procent. Nie są.

? To zależy pod metody liczenia obciążenia.

Jesli coś nie wymaga DMA to słuzy do trywializmów typu odczyt

przyciskĂłw

Byłbym bardzo ostrożny w głoszeniu takich tez.

--
Marek

On 2015-11-17 10:29, Marek wrote:

Jesli translowany to po co VM?

MĂłwiąc VM miałem nie  tylko na myśli interpreter ale całe stawowsko
(klasy), to będzie musiało być dodane do translacji, bo driver na pewno
będzie korzystał z wielu klas.

Nie. Drivery nie robia wiele więcej nad zapis/odczyt rejestrów. Nie potrzebuja przetwarzać xmla, nie potrzebują tworzyć okienek, nie potrzebują renderować stron www. Składają się głównie z konfigurowania rejestrów i mmu/iommu. Czasem dostarczają funkcjie wyższego poziomu ale prawie nigdy problem postprocessingu pixeli nie jest w kręgu zainteresowań sterownika touchscreena. Kod dzielony prawie nie wystepuje. Możesz sobie zerknąć ile kodu dzielą różne domeny urządzeń w linuxie.

Wyjdzie spora binarka z niepotrzebnie
załączonym statycznym kodem.

Dlaczego nie dzielonym przez MMU między różne sterowniki skoro już chcesz ten xml przetwarzać? Dzielenie stron wspólnego kodu w ram jest dośc oczywistym rozwiązaniem. I zbędnym - steorwniki nie potrzebują za wiele klas utility.

Takich rozwiązań się unika podobnie jak
statycznego linkowania bo to pamięciowo niewydajne.

Nie wiem skąd się wziął statyczny kod.

sterowniku. I nie, w steorwnikach kart graficznych też wykonuje się

jak

najmniej algortymiki.

Każdy driver to algorytmika, bo ma wejście (zdarzenie) oraz wyjście
(parametry dla DMA) w funkcji zdarzenia czyli DMA=f(we).

To jest tyle algorytmiki ile kot napłakał.

Nie. Obecne CPU przy tak kiepsko kosnstuowanym DMA były by

obciążone

non-stop po pare procent. Nie są.

? To zależy pod metody liczenia obciążenia.

Metoda liczenia jest taka że kiedy mój procesor zajmuje się wyświetlaniem filmów, nagrywaniem dzwięku itp zagadnieniami to obsługa przez sterowniki jest niezauważalną częscią całego procesu. Innymi słowy twoje wizje dotyczące tego ile czasu zajmuje kod sterownika nie można sensownie udowodnić w praktyce. Nie, sterowniki nie zajmuja istotnej częsci CPU. Zdecydowanie calość CPU pochłaniana jest przez user space i algorytmy ktore tam banglają. Na dowolnym systemie współczesnym i współczesnym sprzęcie. Czasy kiedy trzeba bylo przerzucać bufro obrazu przez ISA za pomoca in/out juz mineły.

Jesli coś nie wymaga DMA to słuzy do trywializmów typu odczyt

przyciskĂłw
Byłbym bardzo ostrożny w głoszeniu takich tez.

Te tezy wynikają z wielu obserwacji kodu róznych sterowników. Współczesnych.

On Tue, 17 Nov 2015 18:04:38 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

Nie. Drivery nie robia wiele więcej nad zapis/odczyt rejestrów. Nie potrzebuja przetwarzać xmla, nie potrzebują tworzyć okienek, nie potrzebują renderować stron www.

Jasne, czego dowodem jest ~1.5MB moduł drivera nvidi, rorfl!
Idealistyczna wizja idealnych driverów gadających z idealnym sprzętem.
BTW, wiesz czemu ten driver ma takie rozmiary?

--
Marek

On 2015-11-17 22:36, Marek wrote:

Nie. Drivery nie robia wiele więcej nad zapis/odczyt rejestrów. Nie
potrzebuja przetwarzać xmla, nie potrzebują tworzyć okienek, nie
potrzebują renderować stron www.

Jasne, czego dowodem jest ~1.5MB moduł drivera nvidi, rorfl!

Nie, to nie jest dowód na renderowanie stron www przez nvidię w sterowniku. Ani na otwieranie okienek w sterowniku. Na nic to nie jest dowód. Nawet jeśli machnołeś się G->M.

Swoją drogą 1.5MB moduł? Dość niewielki. Do jednej z kart, bodaj national instruments, sterownik miał gdzieś koło 300MB na windowsie a karta machała kilkoma I/O i czytała wejścia analogowe. Tak, ten ładowany w kernel. Nie, nie mam ochoty analizować jak kiepskich programistów tam zatrudniali. Ale binarka (.sys czy coś tam) po oglądnięciu luzem w hex edytorze miała bardzo dużo mediów (nerdy jak ja widzą to po prostu w ascii i hexach).

Idealistyczna wizja idealnych driverów gadających z idealnym sprzętem.
BTW, wiesz czemu ten driver ma takie rozmiary?

Jak kiedys opowiadał kolega który takowe pisał dla m.in. wiodącej firmy półprzewodnikowej: "czlowieku, nie masz pojęcia jak zjebany jest to hardware, workaround na workaroundzie, kod zamknięty chyba głównie ze wstydu". Może coś w tym jest.

On Wed, 18 Nov 2015 20:35:17 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

> Jasne, czego dowodem jest ~1.5MB moduł drivera nvidi, rorfl!

Nie, to nie jest dowód na renderowanie stron www przez nvidię w sterowniku. Ani na otwieranie okienek w sterowniku. Na nic to nie

jest

dowód. Nawet jeśli machnołeś się G->M.

 A czy ja prĂłbuje udowodnić jakieś renderowanie stron?? W czym miałbym się machnąć, napisałem wyraĹşnie 1.5MB (słownie: półtora megabajta). Driver, ktĂłry ma tyko zajmować się IO. A pardon, 1.5 MB to było 10 lat temu, bardziej współczesna wersja modułu ma juĹź11MB, w tym:

$ objdump -h -j .text /lib/modules/3.2.0-4-686-pae/updates/dkms/nvidia.ko

/lib/modules/3.2.0-4-686-pae/updates/dkms/nvidia.ko: file format elf32-i386

Sections: Idx Name Size VMA LMA File off Algn 1 .text 005decf8 00000000 00000000 00000060 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE ~ 6MB sam .text, takĹźe poprawili jeszcze wynik. Sekcja .data teĹź niczego sobie, prawie 2MB.

Jak kiedys opowiadał kolega który takowe pisał dla m.in. wiodącej

firmy

półprzewodnikowej: "czlowieku, nie masz pojęcia jak zjebany jest to hardware, workaround na workaroundzie, kod zamknięty chyba głównie

ze

wstydu". Może coś w tym jest.

Bingo, wyciągnij teraz z tego wnioski jakie są szanse na "kompaktowe" drivery. Szczerze wątpię, że mikrokernel by coś tu dramatycznie w "produkowanych" driverów przez dostawców zmienił....

--
Marek

On Mon, 16 Nov 2015 18:34:36 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

Jesli coś nie wymaga DMA to słuzy do trywializmów typu odczyt

przyciskĂłw

Cały wywĂłd opierasz na jakimś idealistycznym, wyseparowanym driverze, ktĂłry tylko konfiguruje DMA i nie komumikuje się z innymi funkcjami  jądra. Tak w Ĺźyciu nie ma, Ĺźe driver nie korzysta z innyvh zasobĂłw kernela (choćby głupie printk).

--
Marek

On 2015-11-17 11:57, Marek wrote:

Jesli coś nie wymaga DMA to słuzy do trywializmów typu odczyt

przyciskĂłw
Cały wywód opierasz na jakimś idealistycznym, wyseparowanym driverze,
który tylko konfiguruje DMA i nie komumikuje się z innymi funkcjami
jądra.

Nie ma takiej potrzeby. Wymień funkcje z którymi ma się komunikować. I przypominam że rozmawiamy o mikrojądrze.

Tak w Ĺźyciu nie ma, Ĺźe driver nie korzysta z innyvh zasobĂłw
kernela (choćby głupie printk).

I jak rozumiem zakładasz że robi miliard printk na sekunde skoro to ma mieć jakiekolwiek znaczenie wydajnościowe lub funkcjonalne?

Nie, sterownik:

a) nie musi gadać z jądrem. Z mikrojadrem nie ma o czym gadać jak zostanie zainicjowany. Mikrojądro zajmuje się MMU, odpalaniem procesów, IPC i przerwaniami. I pi x drzwi tyle. Nic z tych rzeczy nie jest potrzebne sterownikowi do *ciagłej* komunikacji. Jesli milion razy na sekundę próbujesz obsługiwać przerwanie to masz buga. Taki był wiele razy z ACPI w kernelu linuxa i nikt nie myślał jak przyspieszyć sterownik tylko naprawiano buga.

b) nie musi nic printować, a szczególnie wydajnie printować. Nikogo z klientów androida nie interesują oopsy i dmesg. To tylko dla nerdów. Przeciętny sterownik nie pisze więcej niż kilka linijek.

On Tue, 17 Nov 2015 18:10:31 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

Nie ma takiej potrzeby. Wymień funkcje z którymi ma się

komunikować. I

przypominam że rozmawiamy o mikrojądrze.

pierwsze z brzegu
- alokacja pamięci na własne zasoby, wcale to nie musi być operacja jednorazowa
- komunikacja statystyczno-konfiguracyjna, analogia proc/sysf. Userspace/kernel będzie chciał z driverem wymieniać takie informacje. PowyĹźsze nie są oczywiacie overkillem  ale nie wyobraĹźam siebie drivera bez statystyk oraz konfiguracji "on the fly".
To czasami może być więcej kodu niż podstawowy kod funkcyjny drivera.

--
Marek

On 2015-11-17 22:24, Marek wrote:

Nie ma takiej potrzeby. Wymień funkcje z którymi ma się

komunikować. I

przypominam że rozmawiamy o mikrojądrze.

pierwsze z brzegu
- alokacja pamięci na własne zasoby, wcale to nie musi być operacja
jednorazowa

Mało który sterownik allokuje w trakcie pracy, poza inicjacją. Po drugie mało która allokacja przelacza kontekst na kernel. Wdepniecie w niezaalokowaną strone pamięci *nie* musi przełaczać w tryb kernela, przerwania/wyjątki sprzętowe mają czasem dostateczne uprawnienia aby doallokować MMU. Całość zależy od CPU i budowy jadra. Przy czym jak mówie - sznse na to że sterownik allokuje pamięc w trakcie pracy przez kernel sa bliskie zeru. Prędzej będzie miał pool allokator jesli już jest tak kiepsko napisany.

- komunikacja statystyczno-konfiguracyjna, analogia proc/sysf.

Komu to potrzebne? IPC występuje tylko miedzy wysokopoziomowym OS a driverem. Kernel nie zajmuje się takimi pierdołami. On tylko zestawia połączenia, przełącza procesy i zarządza MMU. Przypominam: to mikrokernel. Nie ma w nim nic co jest zbędne, choćby po to aby była możliwa weryfikacja formalna jądra. *NIC* co zbędne.

Userspace/kernel będzie chciał z driverem wymieniać takie informacje.

Nie, kernel nie. User space tak. Koszt przełaczenia do drivera taki sam jak do kernela. Przy dwóch rdzeniach byc może zerowy nawet przy intensywnym korzystaniu.

PowyĹźsze nie są oczywiacie overkillem  ale nie wyobraĹźam siebie drivera
bez statystyk oraz konfiguracji "on the fly".

Oczywiście. iPhone nie odpalił by się nawet gdyby sterowniki nie allokowały milion razy na sekundę pamięci i nie printowały statystyk co milisekundę na podpietym terminalu tekstowym Wyse. Tak, to ironia. Bo tylko wtedy miało by to znaczenie.

To czasami może być więcej kodu niż podstawowy kod funkcyjny drivera.

Tak, ponieważ patrzysz na sterowniki Linuxa. Pisane przez nerdów i dla nerdów. To tak nie działa w mobile. Tam chodzi o to żeby pornole się szybko odtwrzały i można bylo wysłać smsa do ziomala. Nie jest potrzebny kprintf ani konfiguracje przez kernelowanie kompila.

UĹźytkownik "Sebastian Biały"  napisał w wiadomości grup dyskusyjnych:n2a3bv$9gm$1@node1.news.atman.pl...

On 2015-11-15 14:45, Pszemol wrote:

Myslisz tak samo jak misie od Androida. PrzecieĹź sterownik
musi być w C. A h... nie musi.

No ale wypadałoby, żeby to co napierdala przez 80%
jednak było, przynajmniej w C.

Przez 99% czasu to napierdala DMA.

W jakich scenariuszach używają tego DMA?

Sa 3 przypadki tak z grubsza:
a) urządznie wymaga powolnego odpytywania. Choćby przyciski na obudowie. Tam może dzialać dowolnie wolny kod bo odpytania są tanie

Przyciski na obudowie czytane przez DMA???

On 2015-11-15 16:19, Ghost wrote:

W jakich scenariuszach używają tego DMA?

Sa 3 przypadki tak z grubsza:
a) urządznie wymaga powolnego odpytywania. Choćby przyciski na
obudowie. Tam może dzialać dowolnie wolny kod bo odpytania są tanie

Przyciski na obudowie czytane przez DMA???

Nie. To jeden z przypadków gdy *jest* sterownik i nie wymaga się od niego szybkości. Zapewniam że punkt b) też nie ma DMA.

Uważaj, po cienkiej lini kroczysz próbując łapać za słowa.

UĹźytkownik "Sebastian Biały"  napisał w wiadomości grup dyskusyjnych:n2a8l4$8aq$2@node2.news.atman.pl...

On 2015-11-15 16:19, Ghost wrote:

W jakich scenariuszach używają tego DMA?

Sa 3 przypadki tak z grubsza:
a) urządznie wymaga powolnego odpytywania. Choćby przyciski na
obudowie. Tam może dzialać dowolnie wolny kod bo odpytania są tanie

Przyciski na obudowie czytane przez DMA???

Nie. To jeden z przypadków gdy *jest* sterownik i nie wymaga się od niego szybkości.

Pytanie było o DMA, nie sterowniki.

Uważaj, po cienkiej lini kroczysz próbując łapać za słowa.

Zadałem pytanie z powodu autentycznego zaskoczenia, skoro odczytujesz to jako łapanie za słówka i straszysz, to znaczy, że nie czujesz się niezbyt pewnie.

UĹźytkownik "Sebastian Biały"  napisał w wiadomości grup dyskusyjnych:n2a1o5$1mh$1@node2.news.atman.pl...

On 2015-11-15 14:32, Ghost wrote:

Myslisz tak samo jak misie od Androida. Przecież sterownik musi być w
C. A h... nie musi.

No ale wypadałoby, żeby to co napierdala przez 80% jednak było,
przynajmniej w C.

Przez 99% czasu to napierdala DMA.

I w twoim świecie gdy chodzi DMA procesor stoi?

On 2015-11-15 16:18, Ghost wrote:

Przez 99% czasu to napierdala DMA.

I w twoim świecie gdy chodzi DMA procesor stoi?

W tym *tasku* tak. Odpalasz dma i odchodzisz. Przyjdzie przerwanie albo zapytasz za jakiś czas czy już. De facto to definicja DMA.

Oczywiście w tle ktoś może oglądać pornola i cieżko dekodować pixele. Więc zdefiniujmy że rola sterownika zazwyczaj kończy się po zainicjowaniu DMA. Nasętpnym razem zostanie zawołany jak już DMA zakończy. Czy cpu stoi zalezy od innych czynników.

Jesli procesor nie ma innych tasków do roboty to fizycznie jest zatrzymywany na chwile lub dłuzej, zależy od CPU.

UĹźytkownik "Sebastian Biały"  napisał w wiadomości grup dyskusyjnych:n2a8i3$8aq$1@node2.news.atman.pl...

On 2015-11-15 16:18, Ghost wrote:

Myslisz tak samo jak misie od Androida. Przecież sterownik musi być w C. A h... nie musi.

No ale wypadałoby, żeby to co napierdala przez 80% jednak było, przynajmniej w C.

Przez 99% czasu to napierdala DMA.

I w twoim świecie gdy chodzi DMA procesor stoi?

W tym *tasku* tak. Odpalasz dma i odchodzisz.

Misiek, właśnie postawiłeś tezę, że sokoro jest DMA, to cały system operacyjny może być powolny. Jesteś pewien, że masz w ogóle zielone pojęcie o wydajności procesów?

On 2015-11-15 23:00, Ghost wrote:

I w twoim świecie gdy chodzi DMA procesor stoi?
W tym *tasku* tak. Odpalasz dma i odchodzisz.

Misiek, właśnie postawiłeś tezę, że sokoro jest DMA, to cały system
operacyjny może być powolny.

Gowsno prada nie postawiłem takiej tezy. Pozstawilem antytezę do twojego bzdurnego twierdzenia że procesor musi zapierdalać kiedy dziala DMA. Nie musi.

Jesteś pewien, że masz w ogóle zielone
pojęcie o wydajności procesów?

Jesli powiem Ci że w praktyce programuje procesory na poziomie hardwareowym z DMA to wystarczy taka odpowiedź czy muszę kupić iPhone i zapuscić bokobrody żeby być bardziej wiarygodny?

UĹźytkownik "Sebastian Biały"  napisał w wiadomości grup dyskusyjnych:n2d487$179$2@node2.news.atman.pl...

On 2015-11-15 23:00, Ghost wrote:

I w twoim świecie gdy chodzi DMA procesor stoi?
W tym *tasku* tak. Odpalasz dma i odchodzisz.

Misiek, właśnie postawiłeś tezę, że sokoro jest DMA, to cały system
operacyjny może być powolny.

Gowsno prada nie postawiłem takiej tezy. Pozstawilem antytezę do twojego bzdurnego twierdzenia że procesor musi zapierdalać kiedy dziala DMA. Nie musi.

No niestety, ale to ty maja tezę, ze "wypadałoby, żeby to co napierdala przez 80% jednak było,
przynajmniej w C" wyskoczyłeś z "Przez 99% czasu to napierdala DMA."

Jesteś pewien, że masz w ogóle zielone
pojęcie o wydajności procesów?

Jesli powiem Ci że w praktyce programuje procesory na poziomie hardwareowym z DMA to wystarczy taka odpowiedź czy muszę kupić iPhone i zapuscić bokobrody żeby być bardziej wiarygodny?

Wystarczy jak zaczniesz pisać z sensem.

On 2015-11-16 20:28, Ghost wrote:

Wystarczy jak zaczniesz pisać z sensem.

PoniewaĹź najwidoczniej oboje mamy probelmy z rozumieniem rzeczy oczywistych to pass.

UĹźytkownik "Sebastian Biały"  napisał w wiadomości grup dyskusyjnych:n2dd4c$k5r$2@node1.news.atman.pl...

On 2015-11-16 20:28, Ghost wrote:

Wystarczy jak zaczniesz pisać z sensem.

PoniewaĹź najwidoczniej oboje mamy probelmy z rozumieniem rzeczy oczywistych to pass.

Pewnie macie racje. Oboje :-)

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message news:n2dd4c$k5r$2node1.news.atman.pl...

On 2015-11-16 20:28, Ghost wrote:

Wystarczy jak zaczniesz pisać z sensem.

PoniewaĹź najwidoczniej oboje mamy probelmy
z rozumieniem rzeczy oczywistych to pass.

On je rozumie - on się tylko droczy bo lubi napierdalanki.
Nie tylko z Tobą to robi. To jest attention whore.

UĹźytkownik "Pszemol"  napisał w wiadomości grup dyskusyjnych:n2f8lf$sh1$1@dont-email.me...

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message
news:n2dd4c$k5r$2node1.news.atman.pl...

On 2015-11-16 20:28, Ghost wrote:

Wystarczy jak zaczniesz pisać z sensem.

PoniewaĹź najwidoczniej oboje mamy probelmy
z rozumieniem rzeczy oczywistych to pass.

On je rozumie - on się tylko droczy bo lubi napierdalanki.
Nie tylko z Tobą to robi. To jest attention whore.

Wypraszam sobie, pederasto. "To" robię tylko z Żoną.

On 2015-11-17 14:07, Pszemol wrote:

On je rozumie - on się tylko droczy bo lubi napierdalanki.

Jak na razie od 24h tylko prostuje stereotypy. Napierdalanki wyglądają jednak inaczej.

Nie tylko z Tobą to robi. To jest attention whore.

Nie, kiedyś nad tym myślałem i raczej nie. Mam jednak odruch że jesli ktoś pieprzy to prostuje. Społecznie.

On Sun, 15 Nov 2015 14:25:54 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

Myslisz tak samo jak misie od Androida. Przecież sterownik musi być

w C.

A h... nie musi. Może być równie dobrze w tym ich dalviku czy co

tam

obecnie mają. Nie, nie mówie tego dlatego że jestem ignorantem.

Wręcz

No tego nie załapałem a raczej wyczuwam prowokację. Przecież Dalvik (VM) to user space, jego aplikacje to warstwa jeszcze wyżej. Jak wyobrażasz sobie wydajny i bezpieczny driver w najwyższej warstwie?

--
Marek

On 2015-11-15 15:39, Marek wrote:

No tego nie załapałem a raczej wyczuwam prowokację. Przecież Dalvik (VM)
to user space, jego aplikacje to warstwa jeszcze wyĹźej. Jak wyobraĹźasz
sobie wydajny i bezpieczny driver w najwyĹźszej warstwie?

Pewnie tak samo jak twórcy mikrokerneli. Tam drivery nie banglają w trybie kernela. Moga sobie banglać ja jednej z wyższych warstw. Nie wiem czy user space, warstw może być wiele.

https://en.wikipedia.org/wiki/Microkernel

" [...] Device drivers frequently perform direct memory access (DMA), and therefore can write to arbitrary locations of physical memory, including various kernel data structures. Such drivers must therefore be trusted. It is a common misconception that this means that they must be part of the kernel. In fact, a driver is not inherently more or less trustworthy by being part of the kernel.[...]"

Ponadto nic nie przeszkadza aby MV puscic w trybie kernela.

Dnia Sun, 15 Nov 2015 15:43:00 +0100, Sebastian Biały napisał(a):

On 2015-11-15 15:39, Marek wrote:

No tego nie załapałem a raczej wyczuwam prowokację. Przecież Dalvik (VM)
to user space, jego aplikacje to warstwa jeszcze wyżej. Jak wyobrażasz
sobie wydajny i bezpieczny driver w najwyższej warstwie?

Pewnie tak samo jak twórcy mikrokerneli. Tam drivery nie banglają w trybie kernela. Moga sobie banglać ja jednej z wyższych warstw. Nie wiem czy user space, warstw może być wiele.
https://en.wikipedia.org/wiki/Microkernel
" [...] Device drivers frequently perform direct memory access (DMA),

Takze zwykle in/out czy dostep do pamieci innego procesu wymagaja
wyzszych uprawnien.

and therefore can write to arbitrary locations of physical memory, including various kernel data structures. Such drivers must therefore be trusted. It is a common misconception that this means that they must be part of the kernel. In fact, a driver is not inherently more or less trustworthy by being part of the kernel.[...]"

Ale procesor moze wymagac pracy w trybie uprzywilejowanym.

Ponadto nic nie przeszkadza aby MV puscic w trybie kernela.

A Dalvik czy inny Java VM ma w ogole funkcje niskopoziomowe ? In, out, zapis pod dowolny adres w pamieci ?

J.

On 2015-11-15 22:55, J.F. wrote:

Pewnie tak samo jak twórcy mikrokerneli. Tam drivery nie banglają w
trybie kernela. Moga sobie banglać ja jednej z wyższych warstw. Nie wiem
czy user space, warstw może być wiele.
https://en.wikipedia.org/wiki/Microkernel
" [...] Device drivers frequently perform direct memory access (DMA),

Takze zwykle in/out czy dostep do pamieci innego procesu wymagaja
wyzszych uprawnien.

Nieprawda że dłubanie po hardware wymaga jakiś mitycznych wysokich uprawnień. Od wieków stosujemy IOMMU:

https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit

Pozwala to za *przyzwoleniem* kernela przemapować wszelą przestrzeń adresową gfx dowolnemu procesowi i od tej pory może on sobie dlubać wprost po rejestrach gfx. Na przykład procesowi sterownika karty grafiki. Jeśli piszesz ekstremalnie szybki system operacyjny to możesz przydzielić wszystkim procesom uprawnienia i kazdy sobie może grzebać. Twój (kernela) wybór.

Ponadto nic nie przeszkadza aby MV puscic w trybie kernela.

A Dalvik czy inny Java VM ma w ogole funkcje niskopoziomowe ?

Nie musi. Ewentualnie zdefiniuj co masz na myśli. Obecnie w zupelnosci wystarczy zapis pod wskazany adres pamięci (IOMMU) i obsluga przerwań. Obie rzeczy zaaltwia mikrokernel.

In, out, zapis pod dowolny adres w pamieci ?

Może. Kwestia MMU. Tak, potrafi to każdy procesor z MMU. Głównie dlatego że w normalnym swiecie (a więc poza x86) procesory nie mają separowanej przestrzeni IO. Wszystko jest pamięcią i można ją wrzucić w dowolną przestrzeń wirtualną. Na x86 też już 30 lat temu odchodzimy od inout na rzecz IO w przestrzeni pamięci.

W przypadku mikrokernela każdy sterownik posiada własny proces i w nim przemapowany swój IO. Koszt przełaczenia się między userem a driverem jest identyczny jak w monolitach między userem a kernelem.

Użytkownik "Sebastian Biały"  napisał w wiadomości grup dyskusyjnych:n2d563$2aa$1@node2.news.atman.pl...
On 2015-11-15 22:55, J.F. wrote:

Pewnie tak samo jak twórcy mikrokerneli. Tam drivery nie banglają w
trybie kernela. Moga sobie banglać ja jednej z wyższych warstw. Nie wiem
czy user space, warstw może być wiele.
https://en.wikipedia.org/wiki/Microkernel
" [...] Device drivers frequently perform direct memory access (DMA),

Takze zwykle in/out czy dostep do pamieci innego procesu wymagaja
wyzszych uprawnien.

Nieprawda że dłubanie po hardware wymaga jakiś mitycznych wysokich uprawnień. Od wieków stosujemy IOMMU:
https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit

A dostepne w telefonach ?

Pozwala to za *przyzwoleniem* kernela przemapować wszelą przestrzeń adresową gfx dowolnemu procesowi i od tej pory może on sobie dlubać wprost po rejestrach gfx. Na przykład procesowi sterownika karty grafiki.

Czekaj czekaj - bo na ile rozumiem, to dziala odwrotnie - pozwala zwirtualizowac adresy uzywane przez urzadzenie IO, np gfx.
Urzadzenie siega do pamieci pod adres np C2000000, a IOMMU podmienia mu go np na  A8000000.

Do rejestrow urzadzenia/gfx nadal trzeba sie dostawac, ale jesli to ARM, to nie ma wydzielonych instrukcji, sa mapowane do pamieci, i tu zwykle MMU/protekcja pamieci wystarczy.

Jeśli piszesz ekstremalnie szybki system operacyjny to możesz przydzielić wszystkim procesom uprawnienia i kazdy sobie może grzebać. Twój (kernela) wybór.

No ale z reguly nie chcesz, bo ani te procesy nie wiedza jak tam grzebac, ani nie chca grzebac sie w szczegoly roznych GFX, a namieszac moga, jak zaczna ustawiac urzadzenie w sposob niezsynchronizowany z innymi.

Ponadto nic nie przeszkadza aby MV puscic w trybie kernela.

A Dalvik czy inny Java VM ma w ogole funkcje niskopoziomowe ?

Nie musi. Ewentualnie zdefiniuj co masz na myśli. Obecnie w zupelnosci wystarczy zapis pod wskazany adres pamięci (IOMMU) i obsluga przerwań. Obie rzeczy zaaltwia mikrokernel.

In, out, zapis pod dowolny adres w pamieci ?

Może. Kwestia MMU. Tak, potrafi to każdy procesor z MMU. Głównie dlatego że w normalnym swiecie (a więc poza x86) procesory nie mają separowanej przestrzeni IO.

Ale mi chodzi o to, czy Dalvik w ogole przewiduje operacje np "zapisz pod adres C2000000 w pamieci".
W pamieci rzeczywistej, albo wirtualnej ale procesora, a nie pamieci przewidzianej przez Dalvik dla procesu w javie.

Tudziez np funkcje poproszenia kernela o odpowiednie zamapowanie tego C20000xxx.

W przypadku mikrokernela każdy sterownik posiada własny proces i w nim przemapowany swój IO. Koszt przełaczenia się między userem a driverem jest identyczny jak w monolitach między userem a kernelem.

Jeszcze jakies inne rozkazy zostaja, typu np zablokowanie przerwan, sterowanie nimi, operacje atomowe itp.

J.

On 2015-11-16 20:48, J.F. wrote:

Nieprawda że dłubanie po hardware wymaga jakiś mitycznych wysokich
uprawnień. Od wieków stosujemy IOMMU:
https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit

A dostepne w telefonach ?

CPU do telefonów potrafi zrobić Apple. Jaki problem dodać dowolny hardware? Do ARMów w zasadzie nie trzeba - tam nie ma separowanej magistrali IO wiec nie ma potrzeby kombinowania z IOMMU. Tym bardziej że gfx jest de facto częścią wszystkich cpu stosowanych w mobile.

Pozwala to za *przyzwoleniem* kernela przemapować wszelą przestrzeń
adresową gfx dowolnemu procesowi i od tej pory może on sobie dlubać
wprost po rejestrach gfx. Na przykład procesowi sterownika karty grafiki.

Czekaj czekaj - bo na ile rozumiem, to dziala odwrotnie - pozwala
zwirtualizowac adresy uzywane przez urzadzenie IO, np gfx.
Urzadzenie siega do pamieci pod adres np C2000000, a IOMMU podmienia mu
go np na  A8000000.

Działa w dwie strony ponieważ gfx zazwyczaj posiada pamięć sherowaną pomiędzy hardware i cpu. Uzycie IOMMU i MMU pozwala widzieć pamięć gfx czy czegotam chcesz bez żadnych "uprawnień kernela".

Do rejestrow urzadzenia/gfx nadal trzeba sie dostawac, ale jesli to ARM,
to nie ma wydzielonych instrukcji, sa mapowane do pamieci, i tu zwykle
MMU/protekcja pamieci wystarczy.

Tak, jesli mamy procesor bez udziwnień to zwykłe MMU tez się może nadać. Ponadto w cpu w mobile mogą być inne rozwiązania, np. gfx jest na stale w jakimś obszarze pamięci fizycznej i już.

Jeśli piszesz ekstremalnie szybki system operacyjny to możesz
przydzielić wszystkim procesom uprawnienia i kazdy sobie może
grzebać. Twój (kernela) wybór.

No ale z reguly nie chcesz, bo ani te procesy nie wiedza jak tam
grzebac, ani nie chca grzebac sie w szczegoly roznych GFX, a namieszac
moga, jak zaczna ustawiac urzadzenie w sposob niezsynchronizowany z innymi.

Dlatego obcina się część wydajności rozbiąc silne separacje. Teraz trzeba policzyć ile kosztuje switch miedzy procesami. Stawiam że prawie nic w porównaniu z javascriptem na facebooku. Ponieważ procesy, przy masowej komunikacji, najzwyczajniej w świecie sharują pamięć RAM. Więc znowu, rola sterownika sprowadza się do inicjacji hardware.

Ale mi chodzi o to, czy Dalvik w ogole przewiduje operacje np "zapisz
pod adres C2000000 w pamieci".

Nie musi. Wystarczy że może (a musi) wołać metody natywne. I wtedy w javie widzisz os.raw.memory.write( address, value ) czy coś w ten deseń.

W pamieci rzeczywistej, albo wirtualnej ale procesora, a nie pamieci
przewidzianej przez Dalvik dla procesu w javie.

Co to za różnica, MMU przemapowalo Ci hardwareowy zestaw rejestrów GFX pod adres 0x123456 i sobie po nich smerasz. Sterownik wie co i gdzie należy przemapować. Może to zgłosic na inicjacji.

Tudziez np funkcje poproszenia kernela o odpowiednie zamapowanie tego
C20000xxx.

Tak.

Jeszcze jakies inne rozkazy zostaja, typu np zablokowanie przerwan,
sterowanie nimi, operacje atomowe itp.

To wszystko to są trywializmy. Przecież nikt nie mówi że API/ABI sterownika zaczyna się od main(argc,argv). naprawde, nie ma roznicy czy porty hardware smerane sa przez kod maszynowy czy przez ten sam kod maszynowy wygenerowany z dalvika.

Użytkownik "Sebastian Biały"  napisał w wiadomości grup dyskusyjnych:n2dcv5$k5r$1@node1.news.atman.pl...
On 2015-11-16 20:48, J.F. wrote:

Nieprawda że dłubanie po hardware wymaga jakiś mitycznych wysokich
uprawnień. Od wieków stosujemy IOMMU:
https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit

A dostepne w telefonach ?

CPU do telefonów potrafi zrobić Apple. Jaki problem dodać dowolny hardware?

Zaden, ale jesli (nie wiem) telefon sie dalo zrobic bez, to moze nie ma potrzeby dokladac :-)

Pozwala to za *przyzwoleniem* kernela przemapować wszelą przestrzeń
adresową gfx dowolnemu procesowi i od tej pory może on sobie dlubać
wprost po rejestrach gfx. Na przykład procesowi sterownika karty grafiki.

Czekaj czekaj - bo na ile rozumiem, to dziala odwrotnie - pozwala
zwirtualizowac adresy uzywane przez urzadzenie IO, np gfx.
Urzadzenie siega do pamieci pod adres np C2000000, a IOMMU podmienia mu
go np na  A8000000.

Działa w dwie strony ponieważ gfx zazwyczaj posiada pamięć sherowaną pomiędzy hardware i cpu. Uzycie IOMMU i MMU pozwala widzieć pamięć gfx czy czegotam chcesz bez żadnych "uprawnień kernela".

Tak, ale to bedzie np pamiec video. Czy pamiec obiektow graficznych do wykorzystania.

A sterowac tym gfx trzeba przez inne rejestry - tak, zeby wiedzial ze zostalo do nich zapisane, bo przeciez nie bedzie stale zawartosci pamieci sprawdzal.

A w tym IOMMU nie pomoze. Chyba, ze jakos sprytnie w dwie strony bedzie dzialalo.

Jeśli piszesz ekstremalnie szybki system operacyjny to możesz
przydzielić wszystkim procesom uprawnienia i kazdy sobie może
grzebać. Twój (kernela) wybór.

No ale z reguly nie chcesz, bo ani te procesy nie wiedza jak tam
grzebac, ani nie chca grzebac sie w szczegoly roznych GFX, a namieszac
moga, jak zaczna ustawiac urzadzenie w sposob niezsynchronizowany z innymi.

Dlatego obcina się część wydajności rozbiąc silne separacje. Teraz trzeba policzyć ile kosztuje switch miedzy procesami. Stawiam że prawie nic w porównaniu z javascriptem na facebooku.

Mozliwe, tym niemniej switch sie wydluza, jak trzeba zachowac rejestry (a przybywa ich), przestawic MMU, byc moze przestawic IOMMU itd.

Ale mi chodzi o to, czy Dalvik w ogole przewiduje operacje np "zapisz
pod adres C2000000 w pamieci".

Nie musi. Wystarczy że może (a musi) wołać metody natywne. I wtedy w javie widzisz os.raw.memory.write( address, value ) czy coś w ten deseń.

i wydajnosc dalej spada :-)

W pamieci rzeczywistej, albo wirtualnej ale procesora, a nie pamieci
przewidzianej przez Dalvik dla procesu w javie.

Co to za różnica, MMU przemapowalo Ci hardwareowy zestaw rejestrów GFX pod adres 0x123456 i sobie po nich smerasz. Sterownik wie co i gdzie należy przemapować. Może to zgłosic na inicjacji.

No wlasnie o to chodzi - albo z poziomu kodu Dalvika musze miec dostep do tego umowionego adresu w pamieci procesora, albo kernel musi wiedziec jak mapowac aby ten dalvikowy kod dobrze trafial .

Jeszcze jakies inne rozkazy zostaja, typu np zablokowanie przerwan,
sterowanie nimi, operacje atomowe itp.

To wszystko to są trywializmy. Przecież nikt nie mówi że API/ABI

Oczywiscie, ale moge wymagac wiekszych uprawnien.

sterownika zaczyna się od main(argc,argv). naprawde, nie ma roznicy czy porty hardware smerane sa przez kod maszynowy czy przez ten sam kod maszynowy wygenerowany z dalvika.

Ale sam dalvik moze nie przewidywac np operacji atomowych, bo i po co to na poziomie abstrakcji Javy.

J.

On 2015-11-16 21:48, J.F. wrote:

CPU do telefonów potrafi zrobić Apple. Jaki problem dodać dowolny
hardware?

Zaden, ale jesli (nie wiem) telefon sie dalo zrobic bez, to moze nie ma
potrzeby dokladac :-)

Dalo się zrobić bez ale ma kłopoty funkcjonalne z update. Jesli istniał by motywator ekonomiczny to wszystko jest możliwe. Ale nie ma.

pomiędzy hardware i cpu. Uzycie IOMMU i MMU pozwala widzieć pamięć gfx
czy czegotam chcesz bez żadnych "uprawnień kernela".

Tak, ale to bedzie np pamiec video. Czy pamiec obiektow graficznych do
wykorzystania.
A sterowac tym gfx trzeba przez inne rejestry - tak, zeby wiedzial ze
zostalo do nich zapisane, bo przeciez nie bedzie stale zawartosci
pamieci sprawdzal.

Te rejstry leżą obok w pamięci od 0x400000 w górę. W czym problem?

A w tym IOMMU nie pomoze. Chyba, ze jakos sprytnie w dwie strony bedzie
dzialalo.

IOMMU pozwala na dowolne machloje głównie dlatego że powstalo do duzych systemów. Do systemów małych, szczególnie typu SoC mozna wprost zaprojektować hardware tak aby załatwiało to w całości MMU. Nie widze żadnych przeszkód aby IOMMU w SoC nie istniało a system dalej mapowal wszelkie rejestry i pamięc jakiegoś hardware w dowolne miejsce dowolnego procesu.

Mozliwe, tym niemniej switch sie wydluza, jak trzeba zachowac rejestry
(a przybywa ich), przestawic MMU, byc moze przestawic IOMMU itd.

I tutaj bingo: im mniejszy driver tym mniej do przestawiania w MMU. To kwestia napisania tak kernela aby switch kontekstu do drivera dzwięku był minimalistyczny. Kilka stron z rejestrami hardware, troszkę sharowanej pamięci i do widzenia. Tak, cache pewnie się z lekka uszkodzi, ale te kilkaset instrukcji sterownika to raczej duzych szkod nie poczyni.

Ponadto jak mówie - CPU pożerają głównie aplikacje z userlandu. Drivery nic nie robią bo czekają na przerwanie albo nikt ich nie chce w tej chwili.

Ale mi chodzi o to, czy Dalvik w ogole przewiduje operacje np "zapisz
pod adres C2000000 w pamieci".

Nie musi. Wystarczy że może (a musi) wołać metody natywne. I wtedy w
javie widzisz os.raw.memory.write( address, value ) czy coś w ten deseń.

i wydajnosc dalej spada :-)

Nie, ponieważ JIT kompiluje to do natywnego mov. To że coś w javie ma skomplikowany zapis nie oznacza że po translacji do kodu maszynowego dalej ma skomplikowany zapis.

No wlasnie o to chodzi - albo z poziomu kodu Dalvika musze miec dostep
do tego umowionego adresu w pamieci procesora, albo kernel musi wiedziec
jak mapowac aby ten dalvikowy kod dobrze trafial .

Żaden problem. To dość proste zagadnienie.

Jeszcze jakies inne rozkazy zostaja, typu np zablokowanie przerwan,
sterowanie nimi, operacje atomowe itp.

To wszystko to są trywializmy. Przecież nikt nie mówi że API/ABI

Oczywiscie, ale moge wymagac wiekszych uprawnien.

Te uprawnienia ma proces drivera nadane przez kernel. W czym problem?

Na marginesie: wszelkie problemy z MMU i IOMMU tak naprawdę występują rowniez w kernelu. To jest *dokładnie* to samo zagadnienie. Ja tylko mówie że nie ma problemu aby przenieść drivery razem z ich hardware do osobnych procesów. Nawet jesli to będzie kosztowac całe 0.1%[*] czasu CPU na machanie MMU. A przeniesienie do osobnych procesów - żeby nie zgubić o co w tej dyskusji chodzi - ma za zadanie umożliwić ich aktualizację bez względu na dziadostwo prezentowane przez wytwórców telefonów.

sterownika zaczyna się od main(argc,argv). naprawde, nie ma roznicy
czy porty hardware smerane sa przez kod maszynowy czy przez ten sam
kod maszynowy wygenerowany z dalvika.

Ale sam dalvik moze nie przewidywac np operacji atomowych, bo i po co to
na poziomie abstrakcji Javy.

Ale nie musi na poziomie Javy. Wystarczy że na poziomie fake "pakietu" os.driver.* znajdzie się zbiór metod "writeAtomic64BitLongInteger( ptr, value ); itd. ktore translują się wprost do czego tam na aktualnej arch trzeba. Atomowośc jakiejś operacji jest okreslana przez sterownik. Tak, to oznacza że kod sterownika jest pisany głównie z użyciem wywołań do jakiegoś os.driver i nie wygląda ładnie. Ale mało ktory sterownik wygląda ładnie.

[*] Jest kilka prac z tej dziedziny, np: http://choices.cs.illinois.edu/ExpCS07.pdf

PS. Nie na darmo współczesne CPU mają kilka rdzeni - to powoduje że nie trzeba robić switcha kontekstu za każdym razem kiedy wołasz driver.

On 2015-11-16 21:48, J.F. wrote:

A sterowac tym gfx trzeba przez inne rejestry - tak, zeby wiedzial ze
zostalo do nich zapisane, bo przeciez nie bedzie stale zawartosci
pamieci sprawdzal.

Hardware jest czuły na zapis do jakiegoś konkretnego rejestru. Ba, jest czuły na odczyty również jesli to jest potrzebne (np kolejne odczyty rejestru zwracają następne wartości próbek z przetwornika audio). Hardware to nie cpu ;)

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message news:n2dcv5$k5r$1node1.news.atman.pl...

Dlatego obcina się część wydajności rozbiąc silne separacje. Teraz trzeba policzyć ile kosztuje switch miedzy procesami. Stawiam
że prawie nic w porównaniu z javascriptem na facebooku.

Mobilny Facebook jest w Javascript?????

On 2015-11-17 14:10, Pszemol wrote:

Dlatego obcina się część wydajności rozbiąc silne separacje. Teraz
trzeba policzyć ile kosztuje switch miedzy procesami. Stawiam
że prawie nic w porównaniu z javascriptem na facebooku.

Mobilny Facebook jest w Javascript?????

Kto napisał mobilny?

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message news:n2fn4b$hm6$2node2.news.atman.pl...

On 2015-11-17 14:10, Pszemol wrote:

Dlatego obcina się część wydajności rozbiąc silne separacje. Teraz
trzeba policzyć ile kosztuje switch miedzy procesami. Stawiam
że prawie nic w porównaniu z javascriptem na facebooku.

Mobilny Facebook jest w Javascript?????

Kto napisał mobilny?

Jakoś miałem dziwne wrażenie, że mówimy o sprzęcie mobilnym.
Patrz temat wątka :-)) Tak czy inaczej facebook to jedna z gorszych
aplikacji jakie miałem nieprzyjemność używać od długiego czasu.
Wcale bym się nie zdziwił że jej kulawość wynika z używania JavaS.

On 2015-11-17 18:23, Pszemol wrote:

Dlatego obcina się część wydajności rozbiąc silne separacje. Teraz
trzeba policzyć ile kosztuje switch miedzy procesami. Stawiam
że prawie nic w porównaniu z javascriptem na facebooku.

Mobilny Facebook jest w Javascript?????

Kto napisał mobilny?

Jakoś miałem dziwne wrażenie, że mówimy o sprzęcie mobilnym.

Ale kto przeszkadza oglądać facebooka, allegro, gazete i inne strony zasrane JS za pomocą zwykłej przeglądarki?

Wcale bym się nie zdziwił że jej kulawość wynika z używania JavaS.

I tego nie wykluczam. Ale żeby byla jasność: te promile CPU które spedzamy w sterownikach sa niczym wobec miliona debili piszących codziennie algorytmy O(N^3) w JS. Wiec nie marwiłbym się ze wywłaszczanie i smeranie po portach jest na chwile obecną problemem.

On Sun, 15 Nov 2015 15:43:00 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

Pewnie tak samo jak twórcy mikrokerneli. Tam drivery nie banglają w trybie kernela. Moga sobie banglać ja jednej z wyższych warstw. Nie

wiem

czy user space, warstw może być wiele.
https://en.wikipedia.org/wiki/Microkernel

No ale co z przełączaniem kontekstu, driver w userspace raczej tego będzie wymagał a to jest niewydajne.
Ile znasz mikrokerneli OSĂłw uĹźywanych w w kompuerach powszechnego uĹźytku?

--
Marek

On 2015-11-15 23:07, Marek wrote:

https://en.wikipedia.org/wiki/Microkernel

No ale co z przełączaniem kontekstu, driver w userspace raczej tego
będzie wymagał a to jest niewydajne.

Koszt przełaczenia user->kernel a koszt przelaczenia user->driver jest identyczny. Kto tak okrótnie Cie oszukał że filesystem musi być w kernelu? Albo w driverze? Albo że driver i filesystem nie mogą być w jednym procesie?

Ile znasz mikrokerneli OSĂłw uĹźywanych w w kompuerach powszechnego uĹźytku?

Przecież już pisałem - wszystko dziadostwo a google nie wykorzystało szansy. Jak bedziesz ocenial przydatność mikrokerneli na podstawie popularności to zajdziesz tam gdzie wszystkie marketoidy w dużych korpo.

On Mon, 16 Nov 2015 18:56:24 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

Koszt przełaczenia user->kernel a koszt przelaczenia user->driver

jest

identyczny.

A czasem  nie user->kernel->driver?
To już nie kernel zarządza przełączeniem kontekstu?

Przecież już pisałem - wszystko dziadostwo a google nie

wykorzystało

szansy. Jak bedziesz ocenial przydatność mikrokerneli na podstawie popularności to zajdziesz tam gdzie wszystkie marketoidy w dużych

korpo.

No to wyciągnij z tego wioski, widać inaczej się nie da, już bez marketoidów świata nie zbudujesz.

--
Marek

On 2015-11-17 10:44, Marek wrote:

Koszt przełaczenia user->kernel a koszt przelaczenia user->driver

jest

identyczny.

A czasem  nie user->kernel->driver?

Nie.

To już nie kernel zarządza przełączeniem kontekstu?

Zarzadzanie przełaczanime kontekstu nie wymaga przełaczenia kontekstu do kernela i nazad. Przepina się go bezpośrednio między procesami. Przepinasz kontekst do kernela (nie zawsze) jeśli potrzebujesz coś ciezkiego, jak prosisz o np. allokacje strony w pamięci. Gadanie user->driver nie wymaga kernela (IPC robi się np. na pamięci dzielonej).