Stampa

Effettua l'accesso o una nuova registrazione.
1 ora 1 giorno 1 settimana 1 mese Sempre
Inserisci il nome utente, la password e la durata della sessione.

[Id]

No, beh, non mi sono risposto da solo: ho delle cose da fare (debuggare) per la 2.2, ma sulla 2.2 non posso farle.
Chiaro che non mi metto con xcode a pretendere di debuggare il codice PS2, ma se devo lavorare su PS2 mi aspetto che Sony mi dia un debugger che funzioni. E questo su Android 2.2 non c'e' (per il codice nativo, almeno).

Scusa però: su 2.2 non potesti fare quello che stai facendo. Perché è una funzionalità accessibile solo a chi fa i firmware o sviluppa sul kernel (e servirebbe un terminale apposito, con un kernel con le info di debug, un gdbserver corretto e via discorrendo). Se la usi stai usando una funzionalità non documentata, che è stata ufficializzata solo con Android 2.3.

Se fai una cosa del genere su Apple rischi il ban. Di questi tempi danno un anno, l'ho visto succedere con un comic reader che ha usato usare l'USB link (limitato alla cartella dati dell'App) poche settimane prima che Apple ufficializzasse gli shared folders.

Commento 9 nel link che ho menzionato prima: "The bug has been accepted and assigned; I think that's an official statement right there".
E' un bug, punto e basta (e, lo so: nella 2.3 e' stato fixato).
Questo significa che IN TEORIA dovrei poter fare quello che sto facendo, senza che nessuno mi dia anni di galera o di ban, salvo che c'e' un bug, e quindi IN PRATICA non posso.

[Ziggybee]

C'è stato un official statement l'anno scorso che ha detto chiaramente che su 2.2 questo non è possibile per tutta una serie di motivi (che si riassumono nella mia frase sbrigativa: "Linux è fatto così"). Lo dicono anche nel thread della issue:

Released in NDK r5, unfortunately debugging threaded-code only works on Android 2.3 due to a platform bug that couldn't be fixed before.

Come nel discorso che facevamo nell'altro thread delle STL di iOS, io non sono totalmente d'accordo a classificare come bug tutto quello che apparentemente non funziona come dovrebbe. Certe limitazioni ad accettarle si fa prima, anche perché dietro di esse ci sono scelte consapevoli, a volte. In questo caso quello che nella issue è un bug, per chi lavora non da ieri su linux è una "feature" del kernel development e della sicurezza di linux.

In questo caso è semplicemente un limite nell'architettura del kernel di linux che su Android non era risolvibile senza un refactoring pesante dell'architettura o utilizzando una prassi del tutto standard ma molto più complessa da mettere in pratica con i device consumer (privilegi di root e kernel di debug, perché in alcuni casi serve anche quello!). Su PC non hai grossi problemi ma su i device mobili con l'hardware del negozio non ce la fai (poca RAM, principalmente, il rooting è un problema secondario). Anche per questo hanno deciso di non intervenire all'indietro sulla questione. Certe librerie (tipo la parte OpenGL SE 1.0) girano sul kernel e non sono debuggabili da fuori.

Non sono l'unico a dirti che non si dovrebbero usare i thread nativi per il codice utente con NDK. L'anno scorso lo scriveva pure ARM:

http://blogs.arm.com/software-enablement/238-10-android-ndk-tips/

ARM ha un sacco di info preziose sia per iOS che per Android, in particolare se devi fare performance computing.

Purtroppo c'è anche una scelta implementativa hardware alla base di tutti sti scazzi: le CPU ARM sono ottimizzate per il codice lightweight (questo non vuol dire che siano più veloci, vuol dire che sono più efficienti in generale) e spesso il supporto a basso livello di cose inefficienti non è sostenuto quanto si dovrebbe, dando per scontato che nessuno si andrebbe ad impelagare in acque così rognose.

Anche su iOS ci sono moltissime funzionalità che non danno problemi in Obj-C e sono rognose se provi a farle in C++, per gli stessi motivi. Se è managed (o quasi), gira meglio e nessuno dovrebbe fare altrimenti.

Il problema di Android, secondo me è un'altro: troppa trasparenza su cosa succede dietro il prodotto e troppa fiducia sul fatto che chi sviluppa sulla piattaforma o sia un semplice user che non andrà mai oltre Dalvik o sia un super-espertone che conosce a menadito come funziona lo sviluppo sul kernel di linux (che è di una rogna mostruosa).

Anche per questo stanno riportando quasi tutto in userspace: agli utenti sarà più facile fare molte cose. Il problema, al tendere, però sarà avere molte più applicazioni che possono incartare l'intero sistema con un semplice memory leak o un buffer overflow, come avviene su iOS. Anche qui non si parla di difetti: sono scelte. E' pur sempre un hardware limitato ed ha bisogno di scorciatoie per funzionare in maniera accettabile.

[Id]

C'è stato un official statement l'anno scorso che ha detto chiaramente che su 2.2 questo non è possibile per tutta una serie di motivi (che si riassumono nella mia frase sbrigativa: "Linux è fatto così"). Lo dicono anche nel thread della issue:

Released in NDK r5, unfortunately debugging threaded-code only works on Android 2.3 due to a platform bug that couldn't be fixed before.

Come nel discorso che facevamo nell'altro thread delle STL di iOS, io non sono totalmente d'accordo a classificare come bug tutto quello che apparentemente non funziona come dovrebbe. Certe limitazioni ad accettarle si fa prima, anche perché dietro di esse ci sono scelte consapevoli, a volte. In questo caso quello che nella issue è un bug, per chi lavora non da ieri su linux è una "feature" del kernel development e della sicurezza di linux.

Io invece tendo sempre a chiamare buggata una cosa che non funziona, e che in piu' per ammissione dello sviluppatore e' un bug.

Non serve NESSUN refactoring pesante di NIENTE e meno che mai dell'OS per compilare un gdbserver che funzioni su Android, tant'e' che - vedi il link che ho postato piu' sopra - sul git ufficiale di google ce n'e' un'altra versione, gia' buildata, che e' rotta anche quella ma in un altro modo (non parte senza bestemmie e va lanciata con adb shell - ma quando parte permette il debug di programmi multithreaded nativi).

E non riesco nemmeno a capire come un debugger rotto sia una feature del kernel development o della security di alcunche'.

Quanto al discorso "thread nativi" (o non nativi - perche' il gdbserver "standard" di Android 2.2 non riesce a steppare dentro nessun thread nativo o Java a prescindere), nel link che hai postato bene o male c'e' scritto il contrario di quel che dici, e cioe' c'e' scritto:

It is a good idea in general, but remember maxing out the load on your system may speed up the result at the expense of the second-to-second user experience. Even so, used sensibly threads can be very effective.

che non mi sembra un modo di sconsigliare - poi e' ovvio che su un processore debole, single core, forse che forse e' meglio limitarne il numero.
C'e' scritto che e' meglio usare i thread Java che quelli nativi; mi sta bene ed e' un buon consiglio, ma per una serie di ragioni non posso.
Inoltre, dire "preferite i thread Java a quelli nativi" implica che usare i thread nativi sia possibile ed anche sensato, a volte.

Neanche il discorso "scelta implementativa" regge davvero, altrimenti mica lo fixavano nella release dopo. Eddai.

[TheGentleman]

Non capisco come mai continui a tirare in mezzo il kernel.
Platform bug non è riferito a "linux", quanto al fatto che il gdbserver che viene shippato con l'ndk è compilato senza il supporto per threading.
L'altra bega è che una grossa parte dei device android che ho visto creano un utente per ogni applicazione installata. Se lanci gdbserver con un altro uid, non lo attacchi al processo (e questo è buona norma che rimanga così per tutti i sistemi del mondo).

Il codice nativo che metti nelle lib da far caricare a Dalvik (che dovrebbero implementare i metodi delle classi dichiarati con l'attributo "native") gira a livello utente, non a livello kernel.

Non è corretto dire che "OpenGL gira a livello kernel". Le implementazioni in genere interagiscono con i driver del chipset video usato. Sono questi a girare in kernel mode.

La pagina che hai linkato dice giustamente 2 cose sul threading: la prima è di usarlo con parsimonia e saggezza (regola base), la seconda è "There are fewer hazards and more language-level tools for managing access with the Java VM.". Ad esempio, la keyword synchronized.
È un suggerimento, perché credimi c'è un sacco di gente che non si pone l'idea di problemi di accesso e coerenza. A volte anche essendone consci, ci si dimentica, come avviene con la memoria (altrimenti tutto il codice del mondo sarebbe leak-free). Ma è come quando all'albero azzurro dicono ai bambini "o usate le forbici con la punta arrotondata, o vi fate aiutare dalla mamma".

Inoltre, voglio chiederlo: hai sufficiente conoscenza del runtime di Objective-C? Credi che sia codice managed? Credi che un'invocazione Objective-C sia meno dannosa in termini di cache miss rispetto ad un vector delle STL?
Su iOS non è possibile compilare con Objective-C con garbage collector, o almeno fino alla 4.0 non lo era. Sta tutto nel ricordarsi di invocare release quando serve, che non è molto diverso da ricordarsi di usare "delete" quando serve.

[Ziggybee]

Il fatto che non ci sia un garbage collector non vuol dire che non sia codice lightweight... Forse qualche volta ho scritto managed ma intendevo lightweight.

Objective C per iOS è (passami la semplificazione) come C# dopo che fai una passatina di ngen: codice macchina lightweight che non usa propriamente una virtual machine ma non è nemmeno codice nativo in senso stretto e si appoggia su un ibrido di runtime/ambiente d'esecuzione che rende alcune operazioni meno stressanti per la CPU, un po' meno efficienti rispetto al codice nativo ma molto più affidabili rispetto al codice JIT.

Gestire meglio la cache non vuol dire solo cache miss. Objective-C ha un grandissimo vantaggio: fondamentalmente è una porcata. La sua implementazione dell'object orientation è molto semplificata, demanda un sacco di cose all'utente (ad esempio come gestire la retention dei "puntatori" (ripassami la semplificazione)) e si prende delle licenze che sono proprio uno dei fulcri della sua maggiore efficienza nel contesto mobile. Questo rende l'esecuzione del codice migliore del C++ che ha una sovrastruttura che in molti casi è superflua.

Il compilatore di Apple semplifica molti aspetti rispetto a, che so, gcc, però molto spesso anche applicazioni banali (come parsare un XML) in C++ hanno degli impatti catastrofici sulle performance (si fa per dire, dato l'esempio) se vai sgargiulo di object orientation e librerie standard varie, specie rispetto a codice scolastico scritto in Obj-C come viene. A volte ci è capitato che per rendere codice C++ che si lasciava troppo andare all'object orientation ci siamo ritrovati a scrivere in C, senza usare quasi nulla nemmeno delle librerie standard, con codice scritto in ObjC che funzionava un po' meno bene del risultato finale C++ ma che avevamo reso accettabile in poche ore invece di giorni.

Il cache miss, se avviene, immagino avrà un impatto simile visto che sempre di istruzioni si parla. Il punto è che i due codici hanno "volumi" diversi e quindi in alcune situazioni, l'avere una footprint minore aiuta l'efficienza. Questo è vero anche per gli oggetti delle librerie di contorno: quelli di ObjC sono sensibilmente più piccoli di quelli C++ e fanno le cose con meno istruzioni. Tutta quella logica di gestione manuale di reference e allocazioni fa un favore grandissimo al compilatore, che riesce a districarsi meglio nelle ottimizzazioni perché il programmatore gli "marca" i punti di maggiore interesse.

Questo rimane comunque un problema contestuale: dipende dal tipo di codice che hai scritto e da come esso verrà eseguito. In generale io (ma anche chi è più bravo di me) in molte situazioni faccio una fatica enorme a scrivere codice efficiente E manutenibile. Certo se mi metto ad ottimizzare ogni singola manipolazione di variabili e inanello il codice come lo vorrebbe il compilatore le cose migliorano, ma spesso ObjC mi permette di far meglio ed in maniera più efficiente senza pensarci troppo. Senza contare che se poi ci deve lavorare qualcun'altro magari non si spara in bocca. Sin'ora l'unica parte in cui C++ si rivela impagabile è con OpenGL ma proprio perché non lo usi come se fosse C e allora non c'è codice che tenga, visto che prevedere il risultato di codice C sui compilatori ARM è molto prevedibile. Poi francamente il fatto che in un'app possano coesistere due tipi di oggetti fondamentalmente incompatibili tra di loro mi lascia sempre un po' inquieto perché in passato abbiamo pagato tanto a fare boxing e unboxing a nastro proprio per questo motivo...

Tu hai un'esperienza diversa?

[TheGentleman]

Tu hai un'esperienza diversa?

Si.
Non è difficile, prova a vedere l'assembly generato (o fare step-in via debugger) di una semplice chiamata tipo:

Codice: [Seleziona]

[array1 addObject:[array2 objectAtIndex:2]]

Poi possiamo anche riparlarne, anche se questo thread dovrebbe parlare di OpenGL ES su Android.

[Ziggybee]

Sono d'accordo nel tornare in topic ma ti faccio notare che hai scelto un caso che in letteratura è stranoto per essere limitante in performance rispetto ai linguaggi nativi (e non solo in ObjC, l'implementazione Java è altrettanto penosa, quella C# un po' meno ma perché per motivi di performance il runtime gestisce le allocazioni in maniera più diretta).

Se è per questo rilancio con insertObjects:atIndexes che è implementata dimmerda nella Foundation Library, secondo me. Su iOS, non avendo un reale management della memoria (che comunque in ObjC è piuttosto basico) tutti quei wrapping, boxing ed unboxing schiantano tutto.

La cosa che mi chiedo è perché nelle library di iOS alcune funzioni siano implementate a modino tenendo conto anche delle necessità delle CPU mobili e altre (tipo NSMutableArray) no.