È stata interpretata come un netto cambio di rotta rispetto alle politiche commerciali di Apple, a parere di molti spesso al limite del bacchettonismo , la vicenda che qualcuno ha addirittura definito come lo sbarco della pornografia su App Store. Il protagonista è Hottest Girls applicazione il cui nome parla chiaro: mette a disposizione migliaia di foto di giovani più o meno discinte, ha fatto registrare il sold out. E si è fatta espellere.
Chi ha già testato l’applicazione, venduta al prezzo di due dollari, sembra disposto a giurare che le immagini proposte non sarebbero molto più scandalose di quanto è possibile vedere in TV: qualche capezzolo e molto softcore, nudo – per così dire – artistico. Una volta installata sul dispositivo, l’applicazione propone un set di quattro immagini, ognuna delle quali può essere ingrandita e, se particolarmente apprezzata, salvata nella propria galleria di immagini.
Dopo le prime 4 immagini si passa a quelle successive, che verranno scaricate dal server e visualizzate sul display del dispositivo. Il sistema, oltre a fornire alcune sezioni tra cui quelle dedicate alle bellezze bionde, brune, asiatiche e in costume, offre anche un servizio di rating delle immagini, utile a carpire meglio i gusti dei numerosi utenti che hanno acquistato il servizio e ad indirizzare il corso degli update che verranno distribuiti gratuitamente in futuro.
Comunque, nonostante l’applicazione sia normalmente comparsa sull’App Store, la sua repentina rimozione ha dato vita ad un piccolo giallo: vi sarebbe stato un ripensamento da parte dell’azienda californiana. A dissipare ogni possibile dubbio è stato l’ideatore dell’applicazione, secondo il quale le vendite sarebbero state sospese per l’eccesso di domanda da parte degli utenti. Ciò avrebbe sovraccaricato letteralmente i server legati all’applicazione, rendendo necessario lo stop onde evitare ulteriori disagi.
Nonostante ciò, dell’applicazione non sembra essere rimasta alcuna traccia: secondo i più maligni nella rimozione ci sarebbe lo zampino di Apple, ipotesi che sarebbe confermata da una nota inviata dalla Mela per chiarire quanto successo. A quanto pare, dopo aver ottenuto l’inserimento dell’applicazione, stando al parere di Apple, gli sviluppatori avrebbero pilotato dal loro server contenuti non ammessi dal regolamento imposto dall’azienda.
Difficile ipotizzare quale sarà il destino dell’applicazione, dal momento che non è dato sapere con precisione quali possano essere i contenuti non graditi ad Apple. In molti potrebbero pensare ad immagini più pruriginose di una bella donna ammiccante, ma dall’introduzione del sistema di parental control sul firmware 3.0 appena rilasciato, problematiche del genere dovrebbero essere superate.
Vincenzo Gentile
leggi i 82 commenti
-
e i virus?
campo libero ai virus su Android quindi, ottimo.-
Re: e i virus?
ps. strano che Google non ci abbia pensato, Chrome è davvero ben fatto dal punto di vista sicurezza.. sono io ad essere poco informato? :-| -
Re: e i virus?
Linux normale lavora sugli eseguibili da sempre... eppure non soffre di virus come soffre windows (penso che i virus per linux si possano contare sulle dita di una mano, e probabilmente sono già stati resi tutti inoffensivi)Dato che android ha sotto un sistema linux, rimane quella sicurezza intrinseca (sempre che non abbiano fatto stupidate) di un sistema Linux per PC....Quandi che venga eseguito codice compilato invece che codice per macchina virtuale cambia veramente poco in termini di sicurezza...(ps: esistono i virus scritti in java.....)
-
-
Mi sa che c'è confusione...
Non vorrei sbagliarmi ma mi era sembrato di capire che le applicazioni Dalvik possano accedere a librerie di codice C/C++ compilato, tramite JNI. E' un pò diverso da come è raccontato nell'articolo..Dal sito...http://developer.android.com/sdk/ndk/1.5_r1/index.html#overviewPlease note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.-
Re: Mi sa che c'è confusione...
sono piuttosto i componenti nativi a non avere una libreria per l'acXXXXX all'api di sistema mentre tramite jni dalvik riesce a comunicare con i componenti nativia ben guardare però mi sembra sensato, google vuole mantenere il software per android il più portabile possibile-
Re: Mi sa che c'è confusione...
- Scritto da: pabloski
sono piuttosto i componenti nativi a non avere
una libreria per l'acXXXXX all'api di sistema
mentre tramite jni dalvik riesce a comunicare con
i componenti nativi
a ben guardare però mi sembra sensato, google
vuole mantenere il software per android il più
portabile possibileSì ma solo tra un device Android e l'altro.Non vogliono invece la portabilità tra Android e i sistemi Unix o Java suoi cugini, ragion per cui1) non hanno usato una JVM come tutte le altre e non supportano i vari JSR e2) benché il kernel sia Linux la libc di Android non è compatibile con quella Linux.La ragione ufficiale sono le performance ed il voler confinare la GPL nel kernel e nei driver ed usare altre licenze per le applicazioni. La sensazione però è che Google abbia paura che la gente si possa compilare su Android tutte le applicazioni Java o Linux che ci sono in giro.Che faccia male allo store? ;-)
-
-
-
E' la possibilità che conta
Come da titolo, l'importante è che si possa fare, sta allo sviluppatore poi decidere COSA fare...Il bello dell'open è proprio questo: non ci sono catene :-)-
Re: E' la possibilità che conta
Come da titolo, l'importante è che si possa fare,
sta allo sviluppatore poi decidere COSA
fare...
Il bello dell'open è proprio questo: non ci sono
catene
:-)...E liberarsi dai pesi morti come giava :D -
Re: E' la possibilità che conta
quoto in pieno; alla fine trovo giusto che si sia aperta questa strada. Per come la vedo io in buona parte del codice le prestazioni non sono un grosso problema, soprattutto nella parte che si occupa dell' interazione con l' utente che un' operazione impieghi 1ms o 100ms ad eseguire spesso non è percettibile per l' utente e dunque non fa differenza (andate a vedere lo storico della quota idle del vostro proXXXXXre/i in una tipica sessione desktop se non ci credete).Esistono tuttavia piccole porzioni di codice in cui effettivamente ogni microsecondo è importante, ed è lì che l' NDK casca a fagiolo, permettendo di realizzare soluzioni perfettamente ottimizzate al caso specifico, senza overhead che in quel contesto sarebbero dannosi.E poi fintanto che parliamo di C/C++ siamo a posto, c'è l' unico inconveniente di dovere compilare per architetture diverse, ma non mi pare che questo sia mai stato un problema su linux/unix/bsd...-
Re: E' la possibilità che conta
Bhe, se guardiamo proprio il millisecondo è un problema :-)Linux e co se la cavano sempre compilando tutto in assembly "universale".... che ha il difetto di non sfruttare mai al 100% la potenza di ogni singola macchina (ognuna differente)Per questo il C si è imposto nel mondo open :-) Hai il sorgente e puoi compilartelo da solo in assembly specifico per la tua macchina, ottenendo la massima ottimizzazione :-)-
Re: E' la possibilità che conta
Bhe, se guardiamo proprio il millisecondo è un
problema
:-)
Linux e co se la cavano sempre compilando tutto
in assembly "universale".... che ha il difetto di
non sfruttare mai al 100% la potenza di ogni
singola macchina (ognuna
differente)Che beep stai farneticando?Quale parte di./configuremakemake installnon ti è chiara?
Per questo il C si è imposto nel mondo open :-)
Hai il sorgente e puoi compilartelo da solo in
assembly specifico per la tua macchina, ottenendo
la massima ottimizzazione
:-)Questa è buona la prima ;)-
Re: E' la possibilità che conta
Guarda che quando istalli un sistema Linux mica lo compili XD è già compilato con le CFLAGS universali XDXD Se vuoi puoi anke metterti le CFLAGS del tuo proXXXXXre... a patto di compilarti tutto XDhttp://it.wikipedia.org/wiki/CFLAGS -
Re: E' la possibilità che conta
Guarda che quando istalli un sistema Linux mica
lo compili XD è già compilato con le CFLAGS
universali
XDXD
gentoo ti dice niente? -
Re: E' la possibilità che conta
Sto parlando di sistemi linux "normali" non di quelli fatti per i nerd che ti compilano anche la tua vita XDXDXDLo so che esistono quelli che lo fanno... ma è da pazzi usarli... ore per istallare ogni cosa..... -
Re: E' la possibilità che conta
Sto parlando di sistemi linux "normali" non di
quelli fatti per i nerd che ti compilano anche la
tua vita
XDXDXD
Lo so che esistono quelli che lo fanno... ma è da
pazzi usarli... ore per istallare ogni
cosa.....Sbaglio o l'hai detto tu questo:"Il bello dell'open è proprio questo: non ci sono catene" ;) -
Re: E' la possibilità che conta
Lo so, ed è bello che ci sia la possibilità di farlo (non ho detto che devono toglierli) ma rimane il fatto che compilare ogni minima cosa è assurdo, poichè non ne vale la pena (è utile a mio dire solo epr certe cose)Detto questo, la mia opinione, per fortuna, non è abbastanza potente da bandire un sistema operativo XDXDXD -
Re: E' la possibilità che conta
- Scritto da: Andreabont
Detto questo, la mia opinione, per fortuna, non è
abbastanza potente da bandire un sistema
operativo
XDXDXDmmm non capisco il senso del bandire....come ho detto questo problema i sistemi operativi closed ce l'hanno ancorpiù
-
-
Re: E' la possibilità che conta
assembly universale? intendi il C?se è per questo windows fa uso massiccio del c++ che è molto molto più lento del canzi linux è il sistema operativo che meglio sfrutta tutte la potenza dei proXXXXXri su cui gira-
Re: E' la possibilità che conta
Non sto parlando di ottimizzazione del programma compilato (e certo che è meglio Linux XDXDXD) sto parlando di come il programma viene compilato dal compilatore....Per girare un programma (che non sia interpretato) deve essere tradotto in assembly (linguaggio macchina).... e purtroppo l'assembly non è molto universale.... i comandi principale si... ma ci sono comandi specifici per ogni CPUEsempio: esistono CPU in grado di fare nativamente il prodotto tra due numeri... altre non ci riescono e devono ricorrere ad una successione di somme.... nella prima ci sarà il comando di moltiplicazione, nella seconda solo quello di addizione....E Linux, per evitare problemi di compatibilità, è compilato in quell'assembly "universale", senza sfruttare i comandi specifici....Se lo vuoi ancora più ottimizzato (si, non è assembly ottimizzato e già strabatte windows XDXDXD) devi compilarti il kernel a manina lavorando sulle CFLAGS (http://it.wikipedia.org/wiki/CFLAGS) per dire al compilatore di generare assembly per la tua specifica macchina... -
Re: E' la possibilità che conta
Non sto parlando di ottimizzazione del programma
compilato (e certo che è meglio Linux XDXDXD) sto
parlando di come il programma viene compilato dal
compilatore....
Per girare un programma (che non sia
interpretato) deve essere tradotto in assembly
(linguaggio macchina).... e purtroppo l'assembly
non è molto universale.... i comandi principale
si... ma ci sono comandi specifici per ogni
CPUTu hai le idee un po' confuse... -
Re: E' la possibilità che conta
Idee confuse ti posso assicurare che non ne ho, massimo nn ne ho voglia di spiegare tutto nel minimo dettaglio e i mei mex risultano oscuri XDXDXDSto facendo ingegneria informatica, e se permetti so come funziona un computer XDXDEsistono linguaggi di alto e basso livello (con tutti gli step intermedi)Il C di quasi basso livello giusto un gradino sopra l'assembler e il puro binario....Il java è ad esempio di alto livello, poichè prima di arrivare al procesore passa una svariata serie di traduzioni (che provocano rallentamento).Non parliamo dei linguaggi interpretati, che non vengono nemmeno compilati e il pc deve interpretarli e eseguire in tempo reale....L'assembler è questo: (stralcio)movq%fs:40, %raxmovq%rax, -8(%rbp)xorl%eax, %eaxmovl$.LC0, %edicallputsmovl$.LC1, %edimovl$0, %eaxcallprintfleaq-64(%rbp), %rdicallgetsmovl$.LC2, %edicallputsEd è quello che viene "letto" dalla CPU.... questi comandi sono quelli "universali", capibili da ogni CPU (in questo caso in architettura 64 bit)... ma potrei compilarlo in un assembler specifico per il mio proXXXXXre, a questo punto altri pc protrebbero non riuscire ad eseguirlo..... -
Re: E' la possibilità che conta
Naturalmente (inizio a specificare, altrimenti nn so che succede XD)L'assembler si preoccuperà di chiudere la "pila" XD compilando l'assembly in linguaggio macchina... e naturalmente se l'assembly è "universale" (ovvero per una determinata struttura, esempio 32 bit o 64 bit) avremo in risultato un linguaggio macchina leggibile da ogni CPU avente quella struttura.... altrimenti sarà leggibile solo da quel tipo specifico di proXXXXXre... e altri potrebbero non leggerlo.... -
Re: E' la possibilità che conta
scusa ma.. hai qualche statistica per valutare
quanto un programma "generico" (cioe' che non sia
pesantemente matematico oppure multimediale)
compilato utilizzando le ottimizzazioni per una
specifica variante di un'architettura vada piu'
veloce di una compilazione generica (ad es.
compilare per 486/Pentium I/Xeon/Core2 invece che
per
generic-x86)?No, lui è un ingeNiere la sua parola è legge :D
da ultimo: qui si parla di ARM.. quindi ci sono
ben poche varianti all'instruction set tra i vari
"siliconari" e, soprattutto, poche istruzioni
"evolute" stile x86 (per fortuna ;-)
)Questo a scuola non l'hanno ancora spiegato ;) -
Re: E' la possibilità che conta
- Scritto da: pippO
scusa ma.. hai qualche statistica per valutare
quanto un programma "generico" (cioe' che non
sia
pesantemente matematico oppure multimediale)
compilato utilizzando le ottimizzazioni per una
specifica variante di un'architettura vada piu'
veloce di una compilazione generica (ad es.
compilare per 486/Pentium I/Xeon/Core2 invece
che
per
generic-x86)?
No, lui è un ingeNiere la sua parola è legge :D
da ultimo: qui si parla di ARM.. quindi ci sono
ben poche varianti all'instruction set tra i
vari
"siliconari" e, soprattutto, poche istruzioni
"evolute" stile x86 (per fortuna ;-)
)
Questo a scuola non l'hanno ancora spiegato ;)infatti sono un ingeNiere informatico pure io (anche se non c'e' proprio molto di cui vantarsi :-D ) e queste cose le ho imparate in piccola parte a scuola (si' qualcosa si impara anche li' ;-) ) e in gran parte in 6 anni di lavoro nel settore Linux embedded ;-) -
Re: E' la possibilità che conta
infatti sono un ingeNiere informatico pure io
(anche se non c'e' proprio molto di cui vantarsi
:-D ) e queste cose le ho imparate in piccola
parte a scuola (si' qualcosa si impara anche li'
;-) ) e in gran parte in 6 anni di lavoro nel
settore Linux embedded
;-)In che zona sei, se non sono indiscreto? -
Re: E' la possibilità che conta
Guarda, non è che dico di sapere tutto, sia mai... non si finisce mai di imparare.... Però mi stava dicendo che non e capivo niente.... e quindi ho soltanto specificato di essere nel settore... poi ho detto "sto facendo" quindi sono proprio il primo che sta imparando...Non ho mai detto che "so tutto", ma non si può nemmeno dire che "non so niente" .... un pò meno estremismo nelle valutazioni non sarebbe male XDps: si scrive "Ingegnere" non "IngeNiere" XD -
Re: E' la possibilità che conta
- Scritto da: Andrea
da ultimo: qui si parla di ARM.. quindi ci sono
ben poche varianti all'instruction set tra i vari
"siliconari" e, soprattutto, poche istruzioni
"evolute" stile x86 (per fortuna ;-)
)Ne sei sicuro? Dai un occhio alla pagina di wikipedia sull'architettura ARM.Tra una CPU e l'altra cambiano un sacco di cose. Giusto per farti un esempio, angstrom (e il vecchio OpenZaurus) su Zaurus sono da 2 a 10 volte più veloci del S.O. originale Sharp sugli Zaurus, semplicemente perché hanno una libreria di emulazione della FPU, mentre sulla CPU originale ogni istruzione FPU provoca un'eccezione che la manda in emulazione FPU.Alcune CPU sono multicore, altre hanno istruzioni SIMD, praticamente ogni CPU ha valori di cache diversi, alcune hanno MMU, altre no, alcune sono superscalari, altre no, molte hanno una modalità "16 bit" che è più lenta ma consuma molta meno energia (e si può switchare a caldo), alcune sono in-order, altre out-of-order, ecc. ecc.Credo che il panorama ARM sia, ad oggi, molto più complesso di quello x86.Bye. -
Re: E' la possibilità che conta
- Scritto da: Shu
Terzo: la semplicità di programmazione si paga in
velocità di esecuzione. Gestire un array di long
non ridimensionabile in C significa semplicemente
scrivere dei valori in certe locazioni di
memoria, una, massimo due, istruzioni assembler.
Gestire una ArrayList in Java significa ereditare
da una decina di classi/interfacce, quindi per
ogni acXXXXX avere diverse indirezioni tra un
metodo e l'altro, avere controllo delle
eccezioni, e naturalmente compilazione e
"mantenimento in RAM" di tutto il codice (perché
anche le classi base sono scritte in
Java).
Molto comodo, sicuro (niente buffer overflow),
veloce da sviluppare, ma anche pesantissimo,
dell'ordine delle 100-1000 volte più
lento.
Nella maggior parte dei casi non è
importantissimo, nemmeno in un contesto embedded
(non si lavora quasi mai con milioni di elementi,
quindi si aspetta magari 1-2 secondi), ma in
alcuni casi è
fondamentale.Non mi sembra corretto confrontare un array con un List (ArrayList). Se mi serve un array non ridimensionabile utilizzo array anche in java e non certamente un ArrayList -
Re: E' la possibilità che conta
- Scritto da: Thescare
- Scritto da: Shu
Non mi sembra corretto confrontare un array con
un List (ArrayList). Se mi serve un array non
ridimensionabile utilizzo array anche in java e
non certamente un
ArrayList Quoto! -
Re: E' la possibilità che conta
Non mi sembra corretto confrontare un array con
un List (ArrayList). Se mi serve un array non
ridimensionabile utilizzo array anche in java e
non certamente un
ArrayList
Quoto!Beh, allora è solo dieci volte più lento? :D -
Re: E' la possibilità che conta
- Scritto da: pippO
Non mi sembra corretto confrontare un array
con
un List (ArrayList). Se mi serve un array non
ridimensionabile utilizzo array anche in java
e
non certamente un
ArrayList
Quoto!
Beh, allora è solo dieci volte più lento? :DDati?Io ho trovato questo http://www.stefankrause.net/wp/?p=6 -
Re: E' la possibilità che conta
Non mi sembra corretto confrontare un array
con
un List (ArrayList). Se mi serve un array
non
ridimensionabile utilizzo array anche in
java
e
non certamente un
ArrayList
Quoto!
Beh, allora è solo dieci volte più lento? :D
Dati?
Io ho trovato questo
http://www.stefankrause.net/wp/?p=6Quello che ha fatto il benchmark della malloc?(rotfl)(rotfl)(rotfl)Riprova sarai più fortunato :D -
Re: E' la possibilità che conta
Io ti ho fornito dei dati. Se me li vuoi contestare trova altre prove che contraddicono quelle da me fornite. Se ti interessa avere una conversazione costruttiva. Se ti interessa solo trollare, la discussione da parte mia finisce qui. -
Re: E' la possibilità che conta
- Scritto da: Thescare
Io ti ho fornito dei dati. Se me li vuoi
contestare trova altre prove che contraddicono
quelle da me fornite. Se ti interessa avere una
conversazione costruttiva. Se ti interessa solo
trollare, la discussione da parte mia finisce
qui.Ti hanno già risposto, e comuque quello è l'unico testo che trovi al riguardo, immagino di sapere perchè... :D -
Re: E' la possibilità che conta
- Scritto da: Thescare
Dati?Per esempio questi:http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=javaxint&lang2=gcc&box=1Bye. -
Re: E' la possibilità che conta
- Scritto da: Shu
- Scritto da: Thescare
Dati?
Per esempio questi:
http://shootout.alioth.debian.org/u32q/benchmark.p
Bye.http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=java&lang2=gcc&box=1Non mi sembra ci sia tutta questa differenza(a parte l'occupazione di memoria) -
Re: E' la possibilità che conta
- Scritto da: Thescare
- Scritto da: Shu
http://shootout.alioth.debian.org/u32q/benchmark.p
http://shootout.alioth.debian.org/u32q/benchmark.p
Non mi sembra ci sia tutta questa differenza(a
parte l'occupazione di
memoria)Tenendo presente che stiamo parlando di software per sistemi embedded (telefonini) con, mediamente, 128 MB di RAM, una occupazione di 20-30 volte superiore ti sembra poco?Significa, tra le altre cose, che devi fare un programma in C di massimo 2 MB, altrimenti non entra nemmeno nella RAM del telefono (40-60MB).Nei benchmark, invece, i due che sono più veloci del C, lo sono praticamente solo perché sono completamente composti da metodi static e da variabili static final (quindi costanti). Il resto è da 2 a 3 volte più lento.Su benchmark che comunque sono fatti per essere eseguiti in loop e quindi JIT-ati.In ogni caso non sto affatto dicendo che Java faccia schifo (sebbene abbia visto di molto meglio), ma semplicemente che per forza è più lento di un compilato in particolari compiti.Bye. -
Re: E' la possibilità che conta
I link di cui abbiamo discusso parlavano di j2se e non della versione me, di cui sinceramente conosco ben poco e non mi azzardo a parlare. Naturalmente hai ragione, ci sono situazioni in cui il java è migliore del c ed altre in cui il c è migliore del java. Come dicevo nell'altra risposta sono linguaggi progettati per usi differenti, con i relativi svantaggi e vantaggi. -
Re: E' la possibilità che conta
A parte il discorso prestazionale credo che ogni linguaggio sia stato progettato per uno scopo. Quindi ci sono scenari in cui è meglio utilizzare Java, altri in cui è meglio utilizzare c/c++ ed altri in cui è preferibile utilizzare tex anche se sono tutti turing completi e quindi equivalenti -
Re: E' la possibilità che conta
DAVLIK NON E' JAVA ne a livello di bytecode, ne a
livello di runtime. Se ci metti dentro un file
java col cavolo che
parte...Allora giava fa schifo pure a quelli di google :D -
Re: E' la possibilità che conta
- Scritto da: Whishper
- Scritto da: Shu
- Scritto da: Whishper
http://developer.android.com/guide/practices/desig
Alcune di queste cose, un compilatore con
ottimizzatore le fa prima che il programma venga
eseguito, mentre una macchina JIT non ha tempo
di
farlo.
Verissimo! Chi ti dice che il compilatore java
normale (javac) non le faccia? Le fa!! Il
compilatore davlik in tutta onestà non lo
so..No, non le fa, visto che è Google stessa a dire di ottimizzare a mano...
Stime prese dove?Era semplicemente per dire che essendo un linguaggio basato su una virtual machine, con strutture dati ad alto livello, con diversi livelli di astrazione e tutto il resto, a meno di errori pacchiani di programmazione, è sempre e comunque più lento di uno compilato.In cambio dà certe garanzie e facilitazioni.Bye. -
Re: E' la possibilità che conta
- Scritto da: Shu
- Scritto da: Whishper
- Scritto da: Shu
- Scritto da: Whishper
http://developer.android.com/guide/practices/desig
Alcune di queste cose, un compilatore con
ottimizzatore le fa prima che il programma
venga
eseguito, mentre una macchina JIT non ha tempo
di
farlo.
Verissimo! Chi ti dice che il compilatore java
normale (javac) non le faccia? Le fa!! Il
compilatore davlik in tutta onestà non lo
so..
No, non le fa, visto che è Google stessa a dire
di ottimizzare a
mano...
Stime prese dove?
Era semplicemente per dire che essendo un
linguaggio basato su una virtual machineDefinire, please. Tenendo conto che può essere eseguito su Java(TM) Chips...Poi, leggiti:http://en.wikipedia.org/wiki/Java_performanceSi parla che nei videogiochi, area in cui java non è mai andata forte, si parla di 5-15% Più lento di C. Ma si dice che in molti casi Java è più veloce di C e C++.Sembra fantascenza? Immagina del codice pesante. (Per codice pesante intendo quello che itera molte volte su di se stesso, è li che contano le performances. Se è pesante perché è programmato coi piedi, non c'è linguaggio che tenga). Non avrebbe senso ottimizzare una riga di codice che gira 2 volte in tutto. Avrebbe senso farlo su del codice che viene eseguito 1 miliardo di volte? Altroché. E qui interviene il JIT. Se il codice ci mette tanto in assoluto, ha senso perdere magari un secondo per ottimizzarlo come si deve? Altroché, se l'ottimizzazione ti fa risparmiare ore alla fine. Che ottimizzazioni sono possibili?1) Ottimizzazioni statiche. Naah...! Quelle le ha già fatte javac. Non c'è più nulla da ottimizzare. E sono le stesse che può fare anche il C2) Ottimizzazioni dinamiche. Qui c'è MOLTO che si può fare. Le fa il JIT, e il C/C++ se le sogna, perché il C non si può automodificare. Inoltre, vengono applicate ottimizzazione PLATFORM DEPENDANT, quelle per intenderci che si possono fare in C solo istruendo il compilatore a farlo, e che sono difficilissime da 'indovinare' a parte ovviamnente dire qual'è il proXXXXXre ESATTO e si può così sfruttarlo alla grande.E questo da la possibilità a Java di andare come il C++ ottimizzato. La differenza è che deplyare java è infinitamente più facile che deployare il C++ ottimizzato
, con
strutture dati ad alto livello, con diversi
livelli di astrazione e tutto il resto, Perché, il C++ non ha le stesse features? Poraccio...
a meno di
errori pacchiani di programmazione, Che programmare in assembly non porti ad errori di programmazione, è da (rotfl). Senza offesa, ma l'hai sparata VERAMENTE grossa...
è sempre e
comunque più lento di uno
compilato.Bella forza! Questo cmq non giustifica alcunché
In cambio dà certe garanzie e facilitazioni.
Bye.Bye -
Re: E' la possibilità che conta
2) Ottimizzazioni dinamiche. Qui c'è MOLTO che si
può fare. Le fa il JIT, e il C/C++ se le sogna,
perché il C non si può automodificare.E con questa ti sei giocato la già poca credibilità che avevi!Il codice automodificante esiste da quando esistono i computer! -
Re: E' la possibilità che conta
XD, dato che siamo nel discorso vorrei precisare solo una cosuccia :-)Si, è vero, se si usa la Java real machine il problema è trascurabile... essendo in pratica codice nativo hardware (anche se non conosco bene le specifiche)Ma se usi la compilazione JIT, su macchina virtuale, come spesso accade, bhe, in questo caso è più veloce di una non-JIT, ma rimane sempre che in tempo reale deve essere tradotta in assembly del processore ed eseguita... è sempre leggermente meno performante di un assembly già compilato..... (almeno in apertura)Ma siamo andando leggermente off-topic su dei dettagli troppo tecnici e spesso non così rilevanti.... :-) -
Re: E' la possibilità che conta
Certo. E' vero. Ma mi fanno girare parecchio...
quelli che alimentano queste false superstizioni
sulla lentezza di
java.Già è vero TUTTI i generatori di frattali giava che ho provato erano delle lepri :D -
Re: E' la possibilità che conta
Idee confuse ti posso assicurare che non ne ho,
massimo nn ne ho voglia di spiegare tutto nel
minimo dettaglio e i mei mex risultano oscuri
XDXDXD
Sto facendo ingegneria informatica, e se permetti
so come funziona un computer
XDXDEcco dov'è il problema ;)
L'assembler è questo: (stralcio)
movq%fs:40, %rax
movq%rax, -8(%rbp)
xorl%eax, %eax
movl$.LC0, %edi
callputs
movl$.LC1, %edi
movl$0, %eax
callprintf
leaq-64(%rbp), %rdi
callgets
movl$.LC2, %edi
callputs
Ed è quello che viene "letto" dalla CPU....
questi comandi sono quelli "universali", capibili
da ogni CPU (in questo caso in architettura 64
bit)... ma potrei compilarlo in un assembler
specifico per il mio proXXXXXre, a questo punto
altri pc protrebbero non riuscire ad
eseguirlo.....Questo è il tuo secondo problema: NON c'è solo l'x86 nel mondo reale... -
Re: E' la possibilità che conta
Ma infatti di solito il kernel "precompilato" viene distribuito sia per il 32 che per il 64 bit... ma non viene distribuito mica per ogni singolo modello di proXXXXXre.... XDXDXDXD -
Re: E' la possibilità che conta
ma si.se intendi, "non viene distribuito per ogni singolo proXXXXXre prodotto", allora ok...altrimenti si. -
Re: E' la possibilità che conta
Ti racconto una piccola storiella.Ho installato un Ubuntu su di una VM vmware perché ospitasse un server (qua non occorre pigliare per i fondelli, stavo faceno un esperimento...)Funzionava alla perfezione.Metto in produzione e non parte. Motivo? Durante l'installazione, Ubuntu aveva visto il mio modello di CPU (un AMD Sempron) e aveva deciso di installare un Kernel altamente ottimizzato per la mia piattaforma. "Ovviamente" non si è accorto che stavo installando un un sistema virtuale. Altrettanto ovviamente, mettendo in produzione la VM non partiva perché alla prima istruzione specifica eseguita dava errore 'istruzione inesistente nella CPU'Ovviamente ho risolto tutto semplicemente sostituendo il pacchetto del kernel con compilata con istruzioni generiche, e ha funzionato anche in produzione. -
Re: E' la possibilità che conta
- Scritto da: Andreabont
Ma infatti di solito il kernel "precompilato"
viene distribuito sia per il 32 che per il 64
bit... ma non viene distribuito mica per ogni
singolo modello di proXXXXXre....Tranne che per amd64 (per cui c'è ancora solo una implementazione), per x32 ci sono il kernel generico (586, ormai il 486 non viene più supportato), l'ottimizzato generico/Intel (686), e quello per AMD.Alcune funzioni possono essere ottimizzate. Per esempio le CPU VIA hanno hardware di crittografia che può essere usato dai moduli crittografici del kernel.In generale, poi, alcuni software possono essere compilati ottimizzati per MMX, SSE, HT, MTRR, ecc. nelle varie versioni.Bye. -
Re: E' la possibilità che conta
- Scritto da: Andreabont
L'assembler è questo: (stralcio)
movq%fs:40, %rax
movq%rax, -8(%rbp)
xorl%eax, %eax
movl$.LC0, %edi
callputs
movl$.LC1, %edi
movl$0, %eax
callprintf
leaq-64(%rbp), %rdi
callgets
movl$.LC2, %edi
callputs
Ed è quello che viene "letto" dalla CPU....
questi comandi sono quelli "universali", capibili
da ogni CPU (in questo caso in architettura 64
bit)... ma potrei compilarlo in un assembler
specifico per il mio proXXXXXre, a questo punto
altri pc protrebbero non riuscire ad
eseguirlo.....Allora... con ordine...Il compilatore C genera quell'assembler (ma solo se siamo su un x86!), che poi l'assemblatore traduce in linguaggio macchina. Questo finisce nei file .o e viene poi messo insieme dal linker in un eseguibile.Le distribuzioni distribuiscono gli eseguibili. Anche rimanendo nel mondo x86 ci sono tante CPU con tante istruzioni macchina diverse. A meno di ricompilarsi le applicazioni a partire dai sorgenti (es: Gentoo) certe istruzioni non saranno mai sfruttate.Gran parte della confusione è che Andreabont usa CPU come sinonimo di CPU di famiglia x86, e data la sua età lo posso anche capire dato che difficilmente avrà visto qualcosa di diverso (ma a ingegneria informatica insegnano solo Intel e AMD?). Risolto questo equivoco il suo discorso sostanzialmente fila.Certo che quando l'avevo visto scrivere di assembly universale mi era venuto in mente prima il p-code degli anni settanta e poi il bytecode Java degli anni 90 e con quelle cose in mente il suo post sembrava un po' delirante... -
Re: E' la possibilità che conta
A Padova solo 68K (non so adesso, ma fino a pochissimo tempo fa si, giuro!) -
Re: E' la possibilità che conta
A parte equivoci sulle architetture, per "assembly universale" io intendo tutte quelle istruzioni che sono comuni alla maggior parte dei processori. escludendo quelle che invece sono specifiche a solo una cerchia ristretta...Forse ho usato il termine sbagliato, ma non sapevo come chiamarlo :-)Comq so che a livello di processore viene compilato in linguaggio macchina... ma l'assemby rispecchia molto meglio il linguaggio macchina con termini abbastanza comprensibili (scrivere i comandi in esadecimale è terribile XD) e per questo che parlavo di assebly. -
Re: E' la possibilità che conta
- Scritto da: Andreabont
A parte equivoci sulle architetture, per
"assembly universale" io intendo tutte quelle
istruzioni che sono comuni alla maggior parte dei
processori. escludendo quelle che invece sono
specifiche a solo una cerchia
ristretta...
Forse ho usato il termine sbagliato, ma non
sapevo come chiamarlo
:-)
Comq so che a livello di processore viene
compilato in linguaggio macchina... ma l'assemby
rispecchia molto meglio il linguaggio macchina
con termini abbastanza comprensibili (scrivere i
comandi in esadecimale è terribile XD) e per
questo che parlavo di
assebly.Si, ma antelucano non parlava di queste (pur tuttavia importanti) 'piccole differenze', ma del fatto che il set di istruzioni può variare radicalmente nel caso di architettura differenti (come ad esempio nel caso i386 vs ARM vs Motorola 68k vs ecc.ecc) -
Re: E' la possibilità che conta
Certo che quando l'avevo visto scrivere di
assembly universale mi era venuto in mente prima
il p-code degli anni settanta e poi il bytecode
Java degli anni 90 e con quelle cose in mente il
suo post sembrava un po'
delirante...Già gli manca un pochino di esperienza ;) -
Re: E' la possibilità che conta
certamente hai ragione e non è una questione di assembly universale quanto piuttosto di compilare per architetture vecchie....attualmente i kernel che vengono forniti con le distribuzioni ( e ovviamente tutti gli applicativi, driver, ecc... ) sono compilati per le architetture i686 e cioè l'architettura P6ciò però non significa che linux è vincolato a quell'architettura....puoi benissimo prendere tutti i sorgenti e compilare il software per l'architettura nehalempoi non dimentichiamo che ci sono programmi particolari che portano con sè vari versioni delle librerie usate, ognuna compilata per una specifica architetturain linea di principio hai ragione, ma non vedo come questo possa essere legato a linux, visto che ancora oggi windows 7 è compilato per le architetture i586 e non hai nessunissima possibilità di ricompilarlo per ottimizzarlo -
Re: E' la possibilità che conta
Ma nulla, era tutto partito dal fatto di come si poteva ottimizzare "al massimo" un programma XDUn discorso onestamente privo di utilità concreta, se proprio non vuoi andare a ricompilarti tutto (però in windows non puoi XD)
-
-
-
-
Re: E' la possibilità che conta
L'importante che non ci siano standard, che ognuno faccia quello che gli paree che non esistono compatbilità...Boh si vede che la lezione non l'avete ancora imparata-
Re: E' la possibilità che conta
L'importante che non ci siano standard, che
ognuno faccia quello che gli paree che non
esistono
compatbilità...Quale standard?Il giava di compile once and debug everywhere? :D-
Re: E' la possibilità che conta
Non che la scrittura in codice nativo sia totalmente immune a questi problemi.Ricordo l'unico (credo) programma che rilasciai anni fa, come freeware in Internet. Usava, per una determinata funzione, delle standard API Win32. Da Win2000 a WinXP, quella parte ha smesso di funzionare. Magari, con una Virtual Machine, il problema non ci sarebbe stato: con Java, finora, non mi è mai capitata nemmeno una volta di differenze di funzionamento tra una piattaforma e l'altra.-
Re: E' la possibilità che conta
Magari, con una Virtual Machine, il problema non
ci sarebbe stato: con Java, finora, non mi è mai
capitata nemmeno una volta di differenze di
funzionamento tra una piattaforma e
l'altra.Nemmeno tra le varie ennemila versioni mobile/server/pc? -
Re: E' la possibilità che conta
- Scritto da: pippO
Magari, con una Virtual Machine, il problema non
ci sarebbe stato: con Java, finora, non mi è mai
capitata nemmeno una volta di differenze di
funzionamento tra una piattaforma e
l'altra.
Nemmeno tra le varie ennemila versioni
mobile/server/pc?Ma di che parli?JavaSE 6 e JavaEE 5 e Java ME?Apparte la ME che non ho ancora avuto modo di vedere le altre 2 sono sempre basate sulla JVM6.
-
-
Re: E' la possibilità che conta
- Scritto da: pippo
L'importante che non ci siano standard, che
ognuno faccia quello che gli paree che non
esistono
compatbilità...
Quale standard?
Il giava di compile once and debug everywhere? :DIn effetti Java è uno standard. Chiunque può implementare una JVM compatibile (ce ne sono diverse). Esiste anche una suite di test com MIGLIAIA di test che servono agli implementatori per capire se e dove sbagliano nell'aderenza agli standard.Ovvio che nelle implementazioni ci possono essere poi bachi, come in tutti i software. La lotta fra chi "vende" le JVM sta appunto nel dare l'implementazione + veloce e con - bachi (come kinder! :D)In ogni caso io il java lo compilo su di una macchia (windows-amd)e lo eseguo su di un'altra (linux-intel) e non ho MAI avuto problemi di compatibilità.Se poi tu ti riferisci a problemi di compatibilità nei giochetti java da cellulare, allora il problema la non è di java ma di chi sviluppa i giochi usando delle librerie NON STANDARD implementate solo su quello specifico cellulare.-
Re: E' la possibilità che conta
Se poi tu ti riferisci a problemi di
compatibilità nei giochetti java da cellulare,Che è l'ultimo mercato rimasto a programmatori giava :D
allora il problema la non è di java ma di chi
sviluppa i giochi usando delle librerie NON
STANDARD implementate solo su quello specifico
cellulare.Strano pensavo che i produttori di cell usassero lo stesso giava uguale per tutti, non è cosi? :@ -
Re: E' la possibilità che conta
- Scritto da: pippO
Se poi tu ti riferisci a problemi di
compatibilità nei giochetti java da cellulare,
Che è l'ultimo mercato rimasto a programmatori
giava
:DChe io sappia, il mercato principale per Java sono le applicazioni web e le applicazioni enterprise
allora il problema la non è di java ma di chi
sviluppa i giochi usando delle librerie NON
STANDARD implementate solo su quello specifico
cellulare.
Strano pensavo che i produttori di cell usassero
lo stesso giava uguale per tutti, non è cosi?
:@E' così. Java è sempre lo stesso. Il PROBLEMA è che certi produttori mettono nel telefono delle librerie non standard, implementate in codice nativo, e spingono gli sviluppatori ad usarle. (principalmente si tratta di sviluppatori non java che si prestano a questa bestemmia). Da notare come una libreria RICHIAMABILE da java, non vuol dire che sia Java. Ovviamente se installi la applicazione su di un altro tipo di telefono, la libreria potrebbe non esserci, e quindi l'applicazione non funziona. Se fosse Java, la si potrebbe usare ovunque e funzionerebbe ovunque nello stesso modo. Non avrebbe alcun senso fosse altrimenti.L'operazione di Android ha proprio questo difetto: introducendo la possibiltà di scrivere codice nativo, offre allo sviluppatore di scrivere librerie che hanno la potenzialità di NON FUNZIONARE. -
Re: E' la possibilità che conta
L'operazione di Android ha proprio questo
difetto: introducendo la possibiltà di scrivere
codice nativo, offre allo sviluppatore di
scrivere librerie che hanno la potenzialità di
NON
FUNZIONARE.Grazie, se scrivo:printf("hello, world"); Funziona ovunque!Ma se faccio qualcosa di diverso auguri? :D -
Re: E' la possibilità che conta
- Scritto da: pippO
L'operazione di Android ha proprio questo
difetto: introducendo la possibiltà di scrivere
codice nativo, offre allo sviluppatore di
scrivere librerie che hanno la potenzialità di
NON
FUNZIONARE.
Grazie, se scrivo:
printf("hello, world"); Funziona ovunque!
Ma se faccio qualcosa di diverso auguri? :DNon l'ho capita.Non è vero che se scrivi printf funziona ovunque. La riprova? Fino a ieri, su Android non funzionava.Facciamo una prova. Scrivi il tuo printf. Compilamenlo e mandamelo. Lo eseguirò su due sistemi operativi. Windows e Linux. Ti facilito la vita, userò la stessa architettura (i386). Scommettiamo che in uno dei due non andrà? -
Re: E' la possibilità che conta
Facciamo una prova. Scrivi il tuo printf.
Compilamenlo e mandamelo. Lo eseguirò su due
sistemi operativi. Windows e Linux. Ti facilito
la vita, userò la stessa architettura (i386).
Scommettiamo che in uno dei due non
andrà?./configuremakemake installE gira anche su architetture dove di jvm non se ne vede l'ombra ;) -
Re: E' la possibilità che conta
- Scritto da: pippO
Facciamo una prova. Scrivi il tuo printf.
Compilamenlo e mandamelo. Lo eseguirò su due
sistemi operativi. Windows e Linux. Ti facilito
la vita, userò la stessa architettura (i386).
Scommettiamo che in uno dei due non
andrà?
./configure
make
make install
E gira anche su architetture dove di jvm non se
ne vede l'ombra
;)Hai capito benissimo quello che dicevo...Qua non si sta parlando di applicazioni in cui l'utente deve compilarsi i sorgenti, si parla di applicazioni pronte per il deploySo che Linux gira su più architetture, ricompilandolo...Però è anche vero che ci sono applicazioni che su certe piattaforme vanno, su altre no -
Re: E' la possibilità che conta
./configure
make
make install
E gira anche su architetture dove di jvm non se
ne vede l'ombra
;)Ti stai accanendo contro Java senza motivo.Pur preferendo sempre il c/C++ standard non vedo motivi per fare il detrattore di java che e' l'unico vero linguaggio totalmente Cross-platform. -
Re: E' la possibilità che conta
Ti stai accanendo contro Java senza motivo.
Pur preferendo sempre il c/C++ standard non vedo
motivi per fare il detrattore di java che e'
l'unico vero linguaggio totalmente
Cross-platform.(rotfl)(rotfl)(rotfl)Si dopo che hai fatto:./configuremakemake install Per compilare la jvm per la tua cpu... -
Re: E' la possibilità che conta
- Scritto da: pippO
Facciamo una prova. Scrivi il tuo printf.
Compilamenlo e mandamelo. Lo eseguirò su due
sistemi operativi. Windows e Linux. Ti facilito
la vita, userò la stessa architettura (i386).
Scommettiamo che in uno dei due non
andrà?
./configure
make
make install
E gira anche su architetture dove di jvm non se
ne vede l'ombra
;)Pensa tu che c'e' gente che si fregia di usare .net che nemmeno e' cross-platform.......Java e' un linguaggio potente, cross-platform e non vedo motivi per parlarne male.
-
-
-
Re: E' la possibilità che conta
in pratica aprire la possibilità allo sviluppo di codice nativo vuol dire non avere standard?quindi windows e tutti i suoi applicativi sono una completamente fuori standard-
Re: E' la possibilità che conta
Credo che per standard si intendesse la possibilità di far girare lo stesso programma su varie architetture.In effetti sul mio telefono Nokia Windows non ci va...Le midlet Java che scrivo e faccio girare sul mio computer invece sì.
-
-
-
