W dniu 2015-11-16 o 17:18, Pszemol pisze:
> Porównaniem Samsunga Galaxy Note 5 do Fiata
> a Apple iPhone 6S+ do Ferrari narobisz sobie
> dużo wrogów na tej grupie :)

Dlaczego? Fiaty potrafią być piękne a nawet bardzo szybkie.
Że nie mają inne logo?
Daruj sobie.

> p.s. Jak tam Twój iPhone5C?

Działa. Jak normalny telefon. Ferrari też potrafi jeździć ;-)
Ma czasem humory przy aktualizacjach i coś nie lubi skypa.
Ani bateria nie trzyma dłużej niż inne telefony w domu, ani płynnością
działania nie odstaje od Lumii 1020. Ma badziewiasty aparat foto.
Brak mu przycisku "wstecz" i to debilne odrzucanie rozmowy "powerem"
Aplikacje potrafią być bardziej dopracowane niż na innych platformach To
jest plus. Ale czasem mnogość funkcji zaczyna być męcząca.
To przecież tylko telefon. :-) Czasem dostrzegam ascezę WP jako zaletę.

z

PS. Mogę zrobić test. Moja Lumia 1020 bije na głowę każdego ajfona na
świecie. Pod względem robienia zdjęć jest to najlepszy, najbardziej
wypasiony produkt Nokii. Nawet najlepszy najbardziej wypasiony ajfon nie
dorasta jej do pięt. Nie ma szans.
Fajny test? Tak samo merytoryczny i nie patrzący na cenę sprzętu.
Tylko po co komu taki test? :-)

do góry

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.

do góry

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?

do góry

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_m
emory_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.

do góry

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.

do góry

Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:n2d094$6rk$...@d...me...
"J.F." <j...@p...onet.pl> wrote in message
>>> Wciaz jednak mozesz wlasnorecznie ubic aplikacje usuwajac jej
>>> karte z
>>> Task Manager czy jak to sie zowie plus oczywiscie Cofnij do skutku
>>> plus
>
>> Cofnij nie zamyka. Pomijajac pomysl, zeby sie cofac do skutku, to
>> na
>> pierwszej stronie owszem, zwija, zapamietujac jednak otwarta strone
>> i
>> wszystkie inne otwarte karty/strony.

>To cofanie do skutku jest boskie...
>Widziałem kilku już użytkowników androida którzy mieli jakąś
>drgawkę na palcu przytkniętym do guzika cofnij i w jakimś
>transie naciskali w nieskończoność to cofnij sto razy zamiast
>nacisnąć Home button :-) Skąd się to u nich bierze??? :-)

Z przyzwyczajenia.
Wszystkie aplikacje zamyka, czy tam "minimalizuje", tylko ta jedna nie
:-)
A wlasciwie to minimalizuje, tylko jak widac - co sie, k*, trzeba
natapac :-)

Ale na Apple lepiej ? Jest jakies rozroznienie miedzy zamknieciem a
minimalizacja ?


J.

do góry

Użytkownik "Sebastian Biały" napisał w wiadomości grup
dyskusyjnych:n2d487$179$...@n...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.

do góry

Użytkownik "Sebastian Biały" napisał w wiadomości grup
dyskusyjnych:n2d563$2aa$...@n...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.

do góry

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_m
emory_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.

do góry

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.

do góry