Newsgroup: it.lavoro.informatica
Titolo: java vs c++

Dopo lunghe discussione con la banda java (rootkit e' il capogruppo 

eletto all'unanimita da me)

e dopo che essi mi hanno magnificato sulle prestazioni di java ho deciso 

di passare ai fatti.

Secondo la banda java il compilatore ma soprattutto il linker/loader 

pensa ad aggiustare il codice per l' ottimizzazione poco prima 

dell'esecuzione.

Va bene,dico io

Prendo atto che queste ottimizzazioni ci siano

Ma la domanda che rimane e' "quanto ottimizza?" e poi "le prestazioni di 

java sono effettivamente come o meglio di un C++? "





Questi test cercheranno di dare una risposta all'ultima domanda.

Per chi volesse avere il tar.gz del test mi scriva via email





Per i test uso una ubuntu 18.04 64bit dove ho installato l'ultima 

versione della jdk disponibile (11.0.1) mentre per il g++ uso gia quello 

di default installato (g++ 7.3.0)

Per g++ non uso le ottimizzazioni per il mio specifico processore ma una 

semplice ottimizzazione generica -O2,cosa che invece la jvm potrebbe fare.



Per il primo test si passa alla concatenazione di stringhe usando una 

semplice funzione rpt.

Prima di iniziare un appunto:

questi sono programmi di test quindi non  per la produzione.

Essendo di test mancano di alcuni controlli tipo quello sugli argomenti 

od assert varie per i check di debug

Preciso questo in quanto non voglio che la banda java si metta a rompere 

le scatole su cose forvianti tipo il check sugli argomenti.

Comunque i suggerimenti sono sempre ben accetti.



------rpt.java

class Rpt {



	static String rpt(String s,long n) {

		String t="";

		while(n-- != 0)

	 		t += s;

		return t;

	}



	public static void main(String[] args) {

		long loop=Long.parseLong(args[0]);

		String s=args[1];

		long n=Long.parseLong(args[2]);

		while(loop-- != 0)

			String r=rpt(s,n);

	}



};

-----







---- rpt.cpp

#include <iostream>

#include <sstream>



inline std::string rpt(const std::string& s,std::size_t n) {

	std::string t;

	t.reserve(s.size() * n);

	while(n--)

		t += s;

	return t;

}



template <typename T>

inline T convert(const char* s) {

	T n;

	std::istringstream os(s);

	os >> n;

	return n;

}



int main(int argc,char** argv) {

	++argv;

	auto loop=convert<std::size_t>(*argv++);

	const std::string s(*argv++);

	const auto n=convert<std::size_t>(*argv);

	while(loop--)

		rpt(s,n);

}

----



---- rpt.sh per compilare ed eseguire

#!/bin/sh

JAVA_HOME=/opt/jdk-11.0.1

PATH="$JAVA_HOME/bin:$PATH"

LD_LIBRARY_PATH="$JAVA_HOME/lib:$LD_LIBRARY_PATH"

rm -f a.out *.class *.o

javac -O rpt.java

g++ -std=c++11 -O2  rpt.cpp

time java Rpt 1000 "abc" 10

time ./a.out 1000 "abc" 10

----



Ed ecco i risultati sul mio laptop:



+ java Rpt 1000 abc 10



real	0m0,285s

user	0m0,431s

sys		0m0,056s

+ ./a.out 1000 abc 10



real	0m0,005s

user	0m0,005s

sys		0m0,000s










 Dopo lunghe discussione con la banda java 



ecalallà.



che ti avevo detto? prima di metterti a fare micro benchmark studia come 

si fanno.



ho pazienza e ti spiego la fallacità del tuo test. ti ricordi che ti 

avevo parlato della compilazione jit? e ti ricordi che ti avevo detto che 

avviene a runtime? ebbene, come parlare ai muri ci sei cascato con tutti 

e due i piedi: il test che hai fatto ha misurato anche il tempo di 

compilazione, che ovviamente in un programma con tempi di esecuzione di 

pochi millisecondi incide in modo esagerato.



per dire, è come se te avessi messo in competizione due auto sulla 

percorrenza di 100 metri, ma ad una gli fai fare la partenza lanciata 

mentre all'altra la fai partire da motore spento. al di la della 

insensatezza del test rispetto al mondo reale (non spiega le performance 

di java su larga scala) è chiaro stai prendendo lucciole per lanterne.



ma vediamo se faccio entrare qualcosa in quella zucca vuota :-)



intanto il tuo programma non compila. ma lasciamo perdere, non 

sottilizziamo sul perché altrimenti si fa notte.



questa è l'esecuzione con openjdk:



[marco@nuc ~]$ java -version

openjdk version "1.8.0_192"

OpenJDK Runtime Environment (build 1.8.0_192-b26)

OpenJDK 64-Bit Server VM (build 25.192-b26, mixed mode)

[marco@nuc ~]$ time java Rpt 1000 "abc" 10



real	0m0,122s

user	0m0,077s

sys	0m0,024s





questa invece è l'esecuzione con graalvm che, come vedi, ha un 

compilatore jit molto più performante:



[marco@nuc ~]$ java -version

openjdk version "1.8.0_192"

OpenJDK Runtime Environment (build 

1.8.0_192-20181024121959.buildslave.jdk8u-src-tar--b12)

GraalVM 1.0.0-rc9 (build 25.192-b12-jvmci-0.49, mixed mode)

[marco@nuc ~]$ time java Rpt 1000 "abc" 10



real	0m0,066s

user	0m0,059s

sys	0m0,018s





questa infine è l'esecuzione dell'immagine nativa costruita con la 

graalvm medesima, che precompila il bytecode eliminando la compilazione 

jit:



[marco@nuc ~]$ native-image Rpt

Build on Server(pid: 31849, port: 37275)

[rpt:31849]    classlist:   1,942.64 ms

[rpt:31849]        (cap):   1,427.11 ms

[rpt:31849]        setup:   3,146.09 ms

[rpt:31849]   (typeflow):   7,386.05 ms

[rpt:31849]    (objects):   4,491.89 ms

[rpt:31849]   (features):     132.54 ms

[rpt:31849]     analysis:  12,231.91 ms

[rpt:31849]     universe:     499.41 ms

[rpt:31849]      (parse):   1,899.96 ms

[rpt:31849]     (inline):   2,351.28 ms

[rpt:31849]    (compile):  14,066.93 ms

[rpt:31849]      compile:  19,050.48 ms

[rpt:31849]        image:   1,363.29 ms

[rpt:31849]        write:     155.75 ms

[rpt:31849]      [total]:  38,443.80 ms



[marco@nuc ~]$ time ./rpt 1000 "abc" 10



real	0m0,010s

user	0m0,003s

sys	0m0,007s



capisci la differenza? come vedi adesso il gap è assai più contenuto e, 

permettimi, un po' più vicino alla realtà. ammesso che questi test 

possano avvicinarsi alla realtà dei progetti su larga scala, dove 

rispetto alle performance ci sono tutt'altri problemi di quelli che vai a 

misurare con queste seghine.






 "le prestazioni di java sono effettivamente come o meglio di un C++? "



perfino un bambino dell'asilo sa che non è cosi e non puo essere cosi.



Ma l'ha sempre detto anche la IBM specificando comunque che in ottica 

mainframe la cosa è irrilevante.



java nelle intenzioni di IBM doveva sostituire COBOL su mainframe, SENZA 

RIUSCIRCI. Forse fra 50 anni.



-- 

Quando la dittatura è un dato di fatto, la rivoluzione diventa un diritto.

(Victor Hugo)


 permettimi, un po' più vicino alla realtà.



capisci proprio na beata fava.

c++ lanci e va compilato o no

java passa attraverso a n substrati(strus, hibernate, etc. etc.) che fa 

si che alla fine le performance siano inferiori

mentre c++ lo lanci e parla col mondo intero a velocità "macchina"...



...poi ad ognuno piace pensare di non aver sbagliato nella vita, ma la 

cosa piu grande che ho notato è che

mentre la mia generazione si metteva sopra il problema e lo analizzava 

per quello che era

la vs generazione , specialmente java, si ficca dentro il problema 

diventane parte del problema stesso.



un linguaggio è un linguaggio....e va usato per quello che è...un 

linguaggio. Il problema vero è il "problem solving" e le energie spese 

per raggiungere gli obbiettivi e in questa ottica

c++ batte java alla grande



piaccia o non piaccia ai dilettanti di java!



 pochi millisecondi incide in modo esagerato.

Non solo, eseguendo il programma 'java' ha misurato anche il tempo di 

avvio della jvm.



Non sai come funziona il JIT, quindi non hai idea di come fare benchmark in Java.



Inoltre non sai neanche scrivere codice idiomatico in Java, e quindi ottieni risultati ridicoli.



Senza usare GraalVm, ma semplicemente aggiustando il tuo ridicolo benchmark ottengo 0.09 millisecondi per l'esecuzione della parte rilevante del tuo test, contro i 76 millisecondi tenendo il tuo bencchmark cosi' com'e'.



Quindi ricapitolando:



- non sai come funziona il JIT

- ti viene spiegato come funziona il JIT

- dopo le spiegazioni, non hai capito assolutamente nulla di come funziona il JIT

- probabilmente visto il benchmark che hai fatto, non hai idea di cosa sia una VM,

- non sai programmare in Java



Sull'ultimo punto faccio notare che la prima cosa che insegnano ad un programmatore junior e' che



t += s; 



dentro un loop, non si fa. Tu non sei manco a quel livello.



se ve lo faccio in cobol....java me lo mangio a colazione



 dentro un loop, non si fa. Tu non sei manco a quel livello.



aggiungo anche che questa parte:



		while(loop-- != 0)

			String r=rpt(s,n);



ovviamente la dichiarazione senza le graffe non compila. 

sicuramente ora verrà a lagnarsi perché sono pignolo, ma se il codice 

dice di averlo eseguito resta incomprensibile il motivo per cui l'ha 

copincollato sbagliato.



probabile abbia ripulito le graffe dopo il copia incolla, pensando di rendere il programma piu' figo, non sapendo nella sua ignoranza che e' una best practice lasciare le graffe anche per istruzione singole.


Il 20/11/18 00:58, rootkit ha scritto:


Ti basta questo ?



  java Rpt 10000000 abc 10



real	0m55,610s

user	0m41,052s

sys	0m15,367s

+ ./a.out 10000000 abc 10



real	0m18,158s

user	0m11,458s

sys	0m6,679s





ora voglio proprio vedere quali scuse troverai

A me non interessa che c++ sia 10000 volte piu veloce di java

Basta solo che lo sia e secondo me lo e'

Comunque il prossimo test sara numerico,penso di fare una classe complex 

per questi test

Spero che il tuo buon java mi permetta di usare i generic per 

parametrizzare il tipo del complex





C++ 1 - java 0

avanti un altro




Il 20/11/18 02:37, Dr.UgoGagliardelli ha scritto:


Se l'amplificatore e' abbastanza grande il tempo di lancio e' irrilevante

Per questo ho messo l'amplificatore (la variabile loop)






 



Delta,io lo so anche senza misurazione

Di programmi java in esecuzione ne  ho visti molti

Questi test sono appunto per sfatarne il mito




> semplice ottimizzazione generica -O2,cosa che invece la jvm potrebbe fare..


La funzione rpt e' uguale identica nei due linguaggi ed il test e' fatto 

per misurare la concatenazione di stringhe non per  cercare la rpt super 

mega figa.

Questo ho voluto fare

Ma se tu sei piu in gamba di me fai pure una rpt nuova in C++ ed in java

A parole sono capaci tutti

E postala








Il 20/11/18 15:26, rootkit ha scritto:


Cavolo,avevo proprio scritto che non volevo appigli inutili ed eccone uno

Perche non provi a compilare invece che fare polemiche ?




Il 20/11/18 15:58, Cicap ha scritto:


Un altro appiglio per fuorviare il discorso

E solo questione di gusti usare o no le graffe per una istruzione 

singola non una best practice

E comunque non mi interessa polemizzare su queste cazzate








 uno Perche non provi a compilare invece che fare polemiche ?



lol, ma secondo te se ho postato i miei risultati non ho provato a 

compilare? sei veramente il peggio.


 real	0m18,158s user	0m11,458s sys	0m6,679s



[marco@nuc ~]$ time java Rpt 10000000 abc 10



real	0m2,018s

user	0m1,987s

sys	0m0,088s



[marco@nuc ~]$ time ./a.out 10000000 abc 10



real	0m2,160s

user	0m2,156s

sys	0m0,004s



aggiungo un altro fattore 10:



[marco@nuc ~]$ time java Rpt 100000000 abc 10



real	0m18,623s

user	0m18,577s

sys	0m0,194s



[marco@nuc ~]$ time ./a.out 100000000 abc 10



real	0m21,290s

user	0m21,286s

sys	0m0,004s





mi spiace per te, ma i risultati del tuo mirabolante test divergono nella 

direzione sbagliata <grin>

a te l'onore di riferirlo anche all'altro cretino della banda.


 nuova in C++ ed in java A parole sono capaci tutti E postala



lol "a parole son capaci tutti". anche nei fatti: esiste lo StringBuffer. 


 E postala



Ma posta cosa, zuccone? Usa StringBuilder invece di + in un loop e hai finito.



Studia, zuccone, che di Java non sai assolutamente nulla.


 E comunque non mi interessa polemizzare su queste cazzate



https://google.github.io/styleguide/javaguide.html#s4.1.1-braces-always-used




Studia zuccone.


 parlare di graffe o sintassi varia.



non farti prendere la mano, lo so che le cava di bocca ma così si rompe 

il giochino :-)

non cerca altro che qualcuno lo tratti male così da fare l'offeso e 

andarsene cavandosela a buon mercato. invece no, voglio che continui a 

postare i suoi benchmark :-)



si ma poi, non gli viene in mente che ne es...ehm, lasciamo stare. Piu' divertente cosi' :)


Il 21/11/18 00:38, rootkit ha scritto:


Si,ed io sono qui a crederci

Da me su tre macchine diverse (2 laptop ed un desktop tutte con distro 

linux) c++ ha sempre stracciato java ed alla grande anche aumentando il 

numero a quello che hai specificato

Almeno abbi la compiacenza di postare l'os  quale java hai usato (se 

oracle od altro),la sua versione ed il compilatore c++ (quale 

compilatore e a che  versione?)

Ovviamente le opzioni sia di java che di c++ si spera che siano quelle 

per l'ottimizzazione




 E' allora ?

Sono consigli mica un obbligo

Io quasi mai uso le graffe per rinchiudere un singolo statement a meno 

che non vada contro la leggibilita

Tu scrivi pure come vuoi ma non mi rompere i cosiddetti su come devo 

scrivere il sw






Il 21/11/18 00:00, rootkit ha scritto:


Ed il compilatore ti ha dato errore sulla while ?




Il 21/11/18 01:03, rootkit ha scritto:


Ed in c++ esiste std::ostringstream che e' lo streambuffer di c++

Non l'ho usato in quanto piu lento


Il 21/11/18 02:22, Cicap ha scritto:


Ti  ho chiesto il codice non cosa usare

Che non abbia usato quello o quell'altro non significa che non li conosca

Ciao quaraquaquaaa






 per l'ottimizzazione



g++ -std=c++11 -O2 Rpt.cpp

javac e java senza alcuna opzione aggiuntiva.




 Non l'ho usato in quanto piu lento



e chi se ne frega? :-) quando scrivi in c++ segui le best practice del c+

+, quando scrivi in java seguirai le best practice di java.

in java le string sono immutabili, motivo per cui non è efficiente 

modificarle perché ogni operazione ne fa una copia nuova. per manipolare 

le stringhe si usa lo StringBuffer che è ottimizzato a basso livello per 

questo scopo.


 molto più potente.



fra l'altro ottieni numeri fra 10 e 25 volte superiori ai miei. non ti 

viene il sospetto di avere una macchina leggermente inadeguata a misurare 

performance? e che non sia l'hardware (probabilmente vetusto e scarso) a 

penalizzare l'uno piuttosto che l'altro?


 scrivere il sw



Libero di continuare a scrivere codice di merda. Che mi frega della tua ridicola carriera da peracottaro?



Lol quindi stai candidamente ammettendo che hai ottimizzato il benchmark per c++ a discapito di Java dove invece e' molto ma molto piu' perfomante.



ROTFL che zuccone...mai vista una cosa del genere :)



Cioe' se ti dico di rimpiazzare "t =+ s" con uno StringBuilder tu non sai ancora da che parte cominciare?



Oh guarda che se ammetti che "io di java non so nulla, mai scritto una riga" non ti mangia nessuno eh. Tanto e' chiaro a tutti, non capisco perche' continui a negare l'evidenza.


 Dopo lunghe discussione [...]



Se per te "discussione" (che non e` il plurale di "discussionA", per intenderci) e` una situazione in cui ti prendi a schiaffi da solo... 



Il solo titolo del tuo thread indica quanto tu non ci capisca un cazzo ne` di Java, ne` di C++, ne` di programmazione in generale.


 E comunque non mi interessa polemizzare su queste cazzate

Se fosse:

while(loop-- != 0)

     rpt(s,n);



oppure



while(loop-- != 0) {

     String r=rpt(s,n);

}



andrebbe bene, ma:



while(loop-- != 0)

     String r=rpt(s,n);



invece non va bene.


Il 22/11/18 00:52, rootkit ha scritto:


IL laptop  su cui scrivo non e' un granche , ma l'altro laptop e' buono

IL desktop poi e' molto performante con disco ssd per l'os

Comunque ci pensero e quando potro smontero i tuoi test






Il 22/11/18 10:23, Dr.UgoGagliardelli ha scritto:


Il compilatore non ha segnalato errore

r dovrebbe essere locale al loop

come usando le graffe




Il 22/11/18 02:29, Cicap ha scritto:


Ei quararquaqqq

Io li conosco gli streambuffer,ti ho scritto quello per poter criticare 

il tuo codice di merda che sicuramente scriverai

Criticare sono capaci tutti,fare pochi

Tu ed il tuo allegro compare invece che fare critiche,che per carita ci 

possono essere,ma costruttive, non  avete fatto altro che buttare merda 

sul sottoscritto

Io non sono perfetto,potrei anche avere delle sviste o fare degli errori 

come tutte quelle persone che fanno,che costruiscono qualcosa.

I quararaqqquaaa come te invece sono solo capaci a buttare merda sugli altri

Psicologicamente si tratta di individui meschini che non sono capaci a 

fare una mazza e quindi si sfogano in questo modo

Almeno rootkit ha comunque una certa preparazione, e quindi anche il mio 

rispetto per questo, la tua chissa dove sta



Il 22/11/18 04:35, 4ndre4 ha scritto:


Scrisse quello che affermo che non esistono compilatori c++ aderente 

agli std


Il 22/11/18 00:28, rootkit ha scritto:


Che e' irrilevante ed ora spiego perche

Immutabile significa che non si puo fare una cosa del genere:



s[0]='a'; // e' c++





Quando si esegue un append,se i progettisti hanno avuto un po di 

lungimiranza per le prestazioni avranno adottato la tecnica di 

espansione del buffer interno.

Tale tecnica,che si applica quando il buffer e' pieno, consiste  nel 

riallocare un buffer nuovo di una grandezza in funzione di una funzione 

alloc() e poi,ovviamente, copiare il vecchio buffer nel nuovo.

Ad esempio una tecnica e' quella di raddoppiare ogni volta il buffer 

indipendentemente dalla lunghezza della stringa contenuta nel buffer stesso.

Con questa tecnica si riduce il numero di riallocazioni/copia

Mi stupirei se i progettisti di java non avessero usato una tecnica 

simile almeno per le stringhe (in pratica quando si usa += che e' l'append)

In c++ esiste per i container sequenziali (come le stringhe) il metodo 

reserve per preallocare lo spazio.

Ti posso assicurare,in quanto avevo fatto dei test,che le prestazioni in 

pratica non cambiano.

Ovviamente le lib std dei vari produttori di lib c++ utilizzano una 

tecnica simile ,anche se lo std non specifica quale tecnica utilizzare.

E visto che java non e' da meno in prestazioni (parole tue) sara cosi 

anche per esso (ma lo ammetto,non ho fatto test su questo)

In  pratica l'utilizzo dello streambuffer e' come il metodo reserve() di 

c++.






 

Ma non e' cosi'. Non so che compilatore hai utilizzato, il mio, quello 

del jdk, me lo segnala come errore e non compila. Quindi chissa' che 

classe hai eseguito.


 IL desktop poi e' molto performante con disco ssd per l'os 



stai a vedè. è un nuc i3 che uso in casa per baloccarmi, il laptop di 

lavoro lo è molto di più. il disco ssd è standard da anni.


 come usando le graffe



qui è spiegato:

https://stackoverflow.com/questions/9206618/compiler-error-when-declaring-


a-variable-inside-if-condition-and-no-curly-braces


 espansione del buffer interno.



no. e ti spiego il perché.



supponimano il seguente caso:



String s = "enoquick";

String s1 = s;

s += " non sa una ceppa di java";



se i progettisti avessero avuto la "lungimiranza" come dici te 

significherebbe che s1, su cui ho salvato la reference originale 

dell'oggetto, risulterebbe mutata. il che ovviamente violerebbe la regola 

di immutabilità.



quindi credici, ogni volta che fai += su una stringa viene creata una 

nuova copia sia dell'oggetto che del buffer interno.





Lol, non sai proprio una sega di Java e neanche di strutture dati.



String  e' immutable. Punto. Se devi fare append, usi una struttura dati mutable (StringBuilder) e alla fnie la converti in String (toString).



Esistono poi strutture dati immutable particolarmente efficienti anche per operazioni di questo tipo, ma non sono nella JDK standard e sono francamente al di fuori della tua portata (livello meno di junior).



Qui non si critica la mancanza di perfezione, ma il fatto che sei un totale zuccone. Infatti nonostante i 9567453344564 tentativi di spiegarti le cose piu' semplici, sei ancora fermo al palo e ancora mi chiedi cosa e' uno stringbuilder (anzi no insisti con stringbuffer perche' sei uno zuccone).



Visto che hai bisogno di piu' guidance di uno junior allora ti mostro come rendere il test leggermente piu' idiomatico e molto piu' performante. Ovviamente so che non capirai:





StringBuilder sb = new StringBuilder(); 

for (int i = 0; i < n; ++i) {

  sb.append(s);

}

return sb.toString();



Ora critica pure se ci riesci, lol...









Scusa, non c'entra molto con la discussione, ma visto che lo avete 

scritto n volte, mi e' venuta una curiosita'.



Ma se fare

s += <qualcosa>

e' meno efficiente del codice che hai scritto sopra

(e addirittura sconsigliato dalle best practice se lo fai in un

ciclo)

allora quale e' la razionalita di non eliminare dal linguaggio la 

possibilita' di usare s+= <qualcosa> e costringere tutti a usare

il codice che hai scritto sopra

(o almeno rendere obsoleta la possibilita' "inefficiente" con vari 

warining in fase di compilazione, se proprio lo vuoi lasciare per motivi 

di compatibilita' con software datati) ?



Ciao,

Marco







---

Questa e-mail è stata controllata per individuare virus con Avast antivirus.

https://www.avast.com/antivirus






per compatibilita' e perche' fuori da cicli (o anche in cicli con I/O ad esempio) puo' risultare comodo.



Mettersi a sistituire tutti i 



String name = firstName + " " + lastName;



dentro il codice pensando di ottenere chissa' quali miglioramenti non ha alcun senso e anzi ne peggiorerebbe la leggibilita'.



In realta' io tendo ad usare String.format("%s %s", firstName, lastName)



e anzi spererei che una futura versione di Java aggiunga l'interpolazione ad es.

(ala Javascript)



`${firstName} ${lastName}`



ma in ogni caso e' questione di gusti. 



P.s. fare t += s dentro il ciclo di enoquick non e' una bad practice, e' proprio una cagata colossale. 


 vuoi lasciare per motivi di compatibilita' con software datati) ?



ma perché al netto di un uso improprio è comunque una sintassi comoda. 

non è che se lo usi per concatenare una stringa hai chissà quale impatto 

nelle prestazioni: certo che se lo metti in un loop dove ci passi milioni 

di volte la cosa è un po' diversa.


Il 23/11/18 02:46, Cicap ha scritto:


Sbagliato

Era da costruire una funziona rpt

Tu come rootkit le leggete le specifiche ?

Poveri project ḿangager se hanno programmatori come voi




Il 23/11/18 13:03, Marcoxxx ha scritto:


Che sia piu efficiente usare gli stream buffer direttamente e' tutto da 

dimostrare

Ho lasciato un post proprio su questo.

Magari ci faro un  post di comparazione se ne avro voglia e tempo

Purtroppo in questi gg sono abbastanza occupato (non con java per fortuna)



 



Questo sarebbe da verificare,magari con un altro bel test

Ma comunque se si comportasse cosi le prestazione decadrebbero alla 

grande e personalmente direi che i progettisti di java sarebbero un po 

immaturi se facessero cose del genere,cosa che comunque non credo.




 Questo sarebbe da verificare,magari con un altro bel test 



oppure leggendo un po' di documentazione basica.



per esempio qui: 
http://www.ntu.edu.sg/home/ehchua/programming/java/


j3d_string.html



nota bene il titolo: c'è scritto "tutorial", non "top secret". vuol dire 

che chiunque approcci il java dovrebbe prendersi la briga di stamparseli 

chiari in mente prima di mettersi seriamente a scrivere codice. poi se 

uno vuole semplicemente scrivere dei test farlocchi per proprio diletto 

liberissimo di farlo, ma non venga da me con la pretesa di dimostrarmi 

qualcosa che mi è già ben noto. 


 



Nel frattempo l'intera comunita' Java sospendera' quello che gia' sa e ha testato dopo decenni di esperienza su StrinogBuilder vs String concatenation, in attesa del benchmark dello zuccone enoquick.



lol ti ho mostrato lo snippet di codice con cui sostituire la parte bacata del tuo ridicolo benchmark, se non sai come wrapparlo in un metodo ti consiglio un corso base di programmazione (non di java che sarebbe troppo specifico).


 Questo sarebbe da verificare,magari con un altro bel test



Basta il debug, anche perche' se ti metti ad allestire un altro test, 

chissa' cosa salta fuori.


 nota bene il titolo: c'è scritto "tutorial", non "top secret".



ROTFL



La prossima sara' che bisogna verificare con un bel test, che se nel 

titolo c'e' scritto tutorial, non sia in effetti top secret!


 Tu come rootkit le leggete le specifiche ?



Nelle specifiche pero', non avevi detto che la funzione rpt doveva 

essere sbagliata per forza.


 come usando le graffe



ascolta, te lo dico con la massima simpatia, che figura pensi di fare ad 

insistere? quel codice non compila, punto. è un fatto oggettivo che 

chiunque può verificare e in diversi hanno verificato. se continui 

alimenti solo il già fondato dubbio che tu quel codice non l'hai nemmeno 

provato a compilare e che quei numeri tu li abbia semplicemente inventati.





Ovviamente che si stesse seguendo una specifica sua e' una goffa trovata  dell'ultimo minuto per uscire dal casino in cui si e' ficcato. Anche perche' mi rifiuterei di seguire specifiche che arrivano da un simile idiota.



Si cercava solamente di spiegargli l'abc della programmazione. Oh incredibile, non gli entra in quella zucca :D


 agli std



Mai detta una cosa del genere, imbecille.


 c++ batte java alla grande



Ha ha ha. Se pensi che per il "problem solving", C++ ti faciliti la vita piu` di Java, hai preso una bella cantonata. Ma tu sei un povero troll scemo, cosa cazzo ne vuoi capire :)




 Comunque ci pensero e quando potro smontero i tuoi test



Sarai anche cosi` intellettualmente onesto dal pubblicare un post in cui annunci di non essere riuscito a smontare i test di rootkit o questa sfida diventera` la tua Moby Dick che ti fara` diventare pazzo e finire negli abissi della scemenza?



Ma tu guarda in cosa perde tempo certa gente. Ma metterti su un libro a studiare, no, eh?




 Questi test sono appunto per sfatarne il mito



Tu non hai visto abbastanza.


 Si cercava solamente di spiegargli l'abc della programmazione. Oh incredibile, non gli entra in quella zucca :D



enoquick ha dimostrato *da anni* di essere uno che puo` solo essere preso per il culo. Ora si e` imbattuto in questa lotta personale C++ vs. Java (come se due linguaggi, poi, dovessero essere per forza antagonisti) e pretende di soddisfare il proprio confirmation bias con "benchmark" che ignorano totalmente gli usi specifici dei due linguaggi. Fosse anche che nel suo esempietto idiota, C++ stracci Java (e cosi` - come dimostrato - non e`), ce lo vogliamo aggiungere un bel chissenefotte?. Vagli a chiedere se in C++ esiste un equivalente di Spring che consenta di tirare su applicazioni enterprise con tutti gli strati di sicurezza facilmente configurabili, con un ORM affidabile e facilmente configurabile, con i pattern domain-driven gia` supportati, con la dependency-injection, le annotations, ecc.., ecc..., ecc...

Parla il cretino, ignorando tutto cio` che esiste al di la` delle sue minuscole conoscenze.




 il codice che hai scritto sopra



E perche` mai dovrebbero farlo? Perche` eliminare l'uso di un operatore in casi specifici? E` sicuramente meglio ottimizzare l'implementazione di quella operazione da parte del compilatore. Difatti, nelle moderne implementazioni, il compilatore traduce automaticamente (behind the scenes) concatenazioni multiple  di stringhe nell'uso di uno StringBuilder.



Esistono ragioni precise, poi, per cui le stringhe, in Java, sono immutable. E sono i classici motivi legati ai vantaggi di avere oggetti immutabili. 



https://www.javaworld.com/article/2072958/immutable-java-objects.html



 Purtroppo in questi gg sono abbastanza occupato (non con java per fortuna)



Ehhhhh, si vede!


 







Riferiro di questi test




 classe hai eseguito.







semplice

avevo tolto l'assegnazione,ecco spiegato il mistero




 



// inefficient codes

String str = "Hello";

for (int i = 1; i < 1000; ++i) {

    str = str + i;

}



If the contents of a String have to be modified frequently, use the 

StringBuffer or StringBuilder class instead.



Questa e' ovvia ma se permetti

    str = str + i;



non e' la stessa cosa di

str += i



Se fosse la stessa cosa sarebbe alquanto inefficiente ed i progettisti 

alquanto dei novellini

Cerca un esempio migliore la prossima volta




Il 24/11/18 10:41, Dr.UgoGagliardelli ha scritto:


Non significa niente, le ottimizzazioni del sistema vanno sempre avanti

il jdk11 dai pochi test fatti sembra piu performante di jdk8

MS ha ottimizzato le stringhe c++ (la std::basic_string) passando da 

visual studio 2015 a visualstudio 2017

E cosi; il mondo va avanti




Il 24/11/18 11:53, 4ndre4 ha scritto:


vai a leggerti i vecchi post su it.comp.lang.c++




 E cosi; il mondo va avanti



Ma tu resti indietro un bel po'.




 vai a leggerti i vecchi post su it.comp.lang.c++



Valli a leggere tu, imbecille. Magari e` la volta che smetti di scrivere cazzate.




 non e' la stessa cosa di str += i



continua, continua pure ad arrampicarti su per lo specchio. 


 immaturi se facessero cose del genere,cosa che comunque non credo.



LOL :D




 str += i



Questa e` da incorniciare. Ennesimo merdone pestato.


Il 24/11/18 10:58, rootkit ha scritto:


il mistero e' stato risolto




Il 24/11/18 10:44, Dr.UgoGagliardelli ha scritto:


sempre in coppia mi raccomando




 



Persino un novellino di C sa che a = a + b e' ben diverso 

concettualmente da a += b

Un compilatore moderno poi puo trasformare facilmente a=a + b in  a+=b 

ma e' ovviamente un discorso di ottimizzazione.

Si vede che i progettisti di java prendono  per  i fondelli chi usa sto 

linguaggio


Il 24/11/18 17:41, 4ndre4 ha scritto:


sempre in coppia mi raccomando

Dovete essere sempre in 2 a buttare merda sugli altri

Uno non basta

Dopo questa ho capito solo una cosa

O sei in malafede o tu di c/c++ non sai una cippa

a te la risposta


Il 24/11/18 12:22, 4ndre4 ha scritto:


sempre  in coppia mi raccomando

occorre essere sempre in 2 a buttare merda sugli altri

Per sicurezza,magari uno da solo non c'e la fa




 



Mi sai che non hai ancora capito bene

Te lo ripeto a bella parole

NON HAI SEGUITO LE SPECIFICHE



M raccomando,gia che ci sei fai anche la versione di rpt in c++ 

ottimizzata per benino,magari usando i thread per un bel parallelismo 

(sono magnanimo,ti do pure un suggerimento su cosa usare)






Il 24/11/18 12:14, 4ndre4 ha scritto:


ed ecco i rinforzi

Mi raccomando, non  si sa mai




Il 24/11/18 17:12, 4ndre4 ha scritto:


Non ho bisogno di cercarli,lo ricordo bene.

La figura del piffero che hai fatto non ha prezzo




 



<!-----

E perche` mai dovrebbero farlo? Perche` eliminare l'uso di un operatore 

in casi specifici? E` sicuramente meglio ottimizzare l'implementazione 

di quella operazione da parte del compilatore. Difatti, nelle moderne 

implementazioni, il compilatore traduce automaticamente (behind the 

scenes) concatenazioni multiple  di stringhe nell'uso di uno StringBuilder.

---->





Io vi do un consiglio

Prima di postare almeno mettetevi d'accordo

Sai,poi possono nascere incongruenze come queste



IL post sopra e' copyright del tuo compare,quello che lavora (dice lui) 

in inghilterra










 essere sbagliata per forza.



dove e' sbagliata ?

Non fa correttamente il lavoro da svolgere ?




 linguaggio



specialmente chi lo usa senza saperne un cazzo ma ha l'arroganza di 

spiegarlo a loro :-)









No, e' la storia ad essere sempre la stessa. E' quindi ragionevole e 

piu' che probabile che una cazzata susciti reazioni analoghe da parte di 

soggetti distinti.

Poi non e' neanche difficile che ad un'osservazione centrata, ci sia 

qualcuno che dichiari di essere d'accordo, quotando o rimarcando.

Ad esempio non ti fai remore a rimarcare le farneticazioni 

dell'innominabile, seguendo il tuo ragionamento, devo arguire che siete 

in coppia?



chiedere almeno scusa per l'insistenza e l'ostinazione a negare l'evidenza, pare brutto?


 

Sara' difficile, se neanche si compila.

Quindi, come tu stesso hai ammesso e hai anche insistito (predicando 

l'equivalenza del blocco con le graffe e senza o la fola delle stringhe 

immutabili), o i risultati dei tuoi benchmark erano falsi o hai eseguito 

qualcosa che non seguiva le specifiche che tu stesso hai ipotizzato.

Permettimi anche di diffidare di chi allestisce benchmark scrivendo 

programmi in un linguaggio che non conosce.



Quello che dice 4ndre4 e' corretto solo che non si applica ai cicli ovviamente (o si applica, ma non nella maniera che ti aspetti).



String s = a + b;



Il compilatore ti genera bytecode che fa uso di StringBuilder.



Anche in "while(true) s += i;"



fa la stessa cosa solo che traduce in una cosa simile a 



while(true) s = new StringBuilder(a).append(b).toString();



E quindi entrambe le nostre affermazioni sono corrette, mentre tu sei talmente ignorante che anche se ti si spiega per filo e per segno una cosa cosi' banale, continui a pesatare merdoni.



Una domanda, chi e' il pazzo che ti paga per programmare?


 (sono magnanimo,ti do pure un suggerimento su cosa usare)



A differenza tua, zuccone, io non mi vanto di essere esperto in linguaggi e piattaforme che non conosco.


 Alla faccia della coerenza





Perche' sei una capra zuccona e non hai capito nulla. Che sorpresa.



Se ti fossi degnato di sistemare il benchmark introducendo StringBuilder, avresti notato il netto gain di performance. E magari l'avresti finito di sparare cazzate a gogo. 



Ma siccome sei uno zuccone, insisti :D


 delle ottimizzazioni per conto suo.



ma perché non è affatto garantito che il compilatore possa capire che gli 

convenga farlo :-)



nel tuo caso, ad esempio, come fa a sapere il compilatore se l'istruzione 

viene chiamata una volta o milioni di volte? non lo sa, infatti quella 

istruzione probabilmente non la ottimizza. d'altra parte per il 

compilatore è una singola concatenazione e istanziare uno StringBuffer 

per una singola concatenzione costa esattamente come fare una copia della 

stringa medesima. cui prodest? :-)



ma tu a differenza del compilatore sai bene che quel metodo è destinato 

ad essere invocato milioni di volte. quindi ti fai furbo, crei uno 

StringBuffer di dimensioni adeguate e riusi sempre lo stesso, così togli 

l'overhead di dover creare e distruggere milioni di istanze. e così ti ho 

svelato anche il "trucco" per merito del quale i miei risultati in java 

hanno una tendenza migliore del tuo c++ al crescere delle iterazioni :-)




Il 25/11/18 04:37, Cicap ha scritto:


Scrivere per una volta

 >>>> Il compilatore non ha segnalato errore r dovrebbe essere locale al 

loop

 >>>> come usando le graffe



la chiami insistenza ?



Ma sai che significa la parola insistenza ?


Il 24/11/18 17:11, 4ndre4 ha scritto:


aspetta ancora un po che poi arriveranno i rinforzi per rinforzare la 

tua tesi




Il 25/11/18 04:58, Cicap ha scritto:


Se il compilatore java fa cosi visto che s non e' condivisa e' alquanto 

inefficiente

Il problema non sono io,sono i progettisti del linguaggio che hanno 

fatto pessime scelte



 tua tesi



Mi sa che sei stato gia` smerdato abbastanza. La mia tesi l'hai rinforzata tu stesso.




 Non ho bisogno di cercarli,lo ricordo bene.



Stai sognando. Le figure di cazzo le fai tu, non io.




 fatto pessime scelte



Il "compilatore java fa". 



Non hai neanche proprieta` di linguaggio quando parli di materia tecnica. Non capisci neanche quali siano le ragioni e i vantaggi di certe decisioni tecniche e sputi merda a casaccio?



Fammi capire: le decisioni di gente del calibro di James Gosling (PhD in Computer Science alla Carnegie Mellon), Guy Steele (BA in matematica applicata ad Harvard, PhD in Computer Science al MIT, professore di Computer Science alla Carnegie Mellon), Joshua Bloch (PhD in Computer Science alla Carnegie Mellon), e molti altri come loro, tutti con carriere prestigiose in Sun, Oracle, Google, Amazon, etc., dovrebbero essere messe in discussione da un anonimo, insignificante cretino come te, laureato in scorregge alla Universita` delle Minchiate, su uno sperduto newsgroup ai margini della galassia? 



E poi fai l'offeso e parli di complotti contro di te quando ti si da` dell'imbecille?




 Fammi capire: le decisioni di gente del calibro di James Gosling (PhD in Computer Science alla Carnegie Mellon), Guy Steele (BA in matematica applicata ad Harvard, PhD in Computer Science al MIT, professore di Computer Science alla Carnegie Mellon), Joshua Bloch (PhD in Computer Science alla Carnegie Mellon), e molti altri come loro, 



Dai diciamoglielo, che Mercoledi' alla festa vengono anche gli americani.


 Dai diciamoglielo, che Mercoledi' alla festa vengono anche gli americani.



E` da un mese che sia Gosling che Steele mi chiedono se possono partecipare al piano contro enoquick, e io continuo a prendere tempo. Inutile spiegargli che contro i test di enoquick non c'e` PhD conseguito al MIT che tenga. D'altronde, non avevano previsto che uno si mettesse si`, sul suo laptop potentissimo, a fare test e sgamare le magagne di un linguaggio per SmartTV. Ora devono correre ai ripari. Gli ho detto di venire - e di sincronizzare gli orologi.




Il 25/11/18 10:14, 4ndre4 ha scritto:


Era una ipotesi,nel caso quello che ha scritto il quaraquara sia 

vera,cosa che non  credo




 



E gia,perche pensi che al compilatore c++ gliene freghi qualcosa se 

quella concatenazione e' in un ciclo?

Eppure non si ha un degrado di performance (il motivo l'avevo spiegato)

Devo appurare che il tipo std::string sia scritto meglio della 

controparte string java (che tra l'altro e' pure builtin quindi 

ottimizzabile a livello di c)?

Io fino a quando non provo con dei test non ci credo.

Sono come Tommaso




 



Non mi sono mai vantato di essere un esperto di java

Anzi,ho sempre ammesso che e' un linguaggio che uso poco.

Comunque impara c++, potresti apprendere cose interessanti (per un 

informatico)

Se vuoi ovviamente




 programmi in un linguaggio che non conosce.





Non saro un super esperto del linguaggio,ma comunque contavo anche su 

critiche costruttive,invece che ricevere merda a palate

Se il benchmark che ho costruito non ti va bene (a parte l'errore che e' 

stata una vista ed ho gia spiegato precedentemente i motivi)

basta spiegare il perche

E' ad esempio saltato fuori,da Cicap,che per non alimentare polemiche 

non lo chiamero piu,almeno fino a riprova contraria quaraquaqua,l'uso di 

StringBuilder come alternativa per un codice piu ottimizzato

Io non credo che serva lo StringBuilder,ma e' comunque da verificare

Se hai altro da dire fallo




Il 25/11/18 10:01, 4ndre4 ha scritto:


Probabilmente si,visto che c++ non lo conosci,non potevi essere tu




 ottimizzabile a livello di c)?



appura quello che ti pare :-) alla fine sei te quello che vuole 

dimostrare qualcosa a me (che java fa cacare, in sostanza) mica 

viceversa. se io ti descrivo talune caratteristiche e best practice di 

scrittura codice in java è per puro spirito di discussione, mica perché 

vinco qualche cosa. magari fino ad un certo punto posso anche provare una 

puntina di frustrazione nel vedere che dico fischi e l'interlocutore 

capisce fiaschi, ma fino ad un certo punto, visto che oramai è lampante 

meni il can per l'aia perché hai finito da tempo gli argomenti.


 Se hai altro da dire fallo



Quello che c'era da dire e' stato detto, in varie forme e da piu' persone.

Devo forse ripeterlo per poi sentirmi dire che c'e' una cospirazione 

contro di te?



Te li rinfresco, per quanto me li ricordi:

- char in c++ e' un byte, in Java 2, quindi un oggetto string in c++ non 

e' direttamente confrontabile con un oggetto String in c++.

- la classe String in Java e' immutabile, quindi l'operatore + o += crea 

una nuova istanza di String, non e' cosi' in C++

- StringBuilder e String implementano entrambi CharSequence ma il primo, 

non essendo immutabile, assomiglia di piu' a string di c++ a meno della 

dimensione di char

- in Java esistono contenitori di byte (come ByteBuffer) piu' 

assimilabili a string di c++

- lanciare un programma Java equivale a istanziare una nuova jvm che poi 

esegue il programma Java, non e' il caso di un programma c++

- il JIT di Java e' configurabile ed e' capace di produrre 

automaticamente istruzioni inline, in c++ glielo devi dire

- l'ottimizzazione di un programma Java dipende sostanzialmente dal 

programmatore, se e' bravo il programma va piu' forte, quindi per 

confrontare due programmi scritti in Java e c++, e' essenziale che il 

programmatore sia bravo in tutti e due i linguaggi

- per ottenere dei benchmark affidabili bisogna essere capaci












 vera,cosa che non  credo



E se fosse vera?




 Probabilmente si,visto che c++ non lo conosci,non potevi essere tu



C++ e` un linguaggio che ho studiato sui libri di Stroustrup, Lippman, Josuttis, Alexandrescu, Sutter et al. e col quale ho scritto software sotto vari flavour di Unix, da SCO a AIX, a HP-UX, sia con gcc che con Visual Age, Visual C++ e C++ Builder. Al contrario di te, stupido chiacchierone da bar, lo conosco piu` che bene. Tanto bene da sapere che ha campi di applicazione specifici che diventano ogni giorno piu` di nicchia. Smettila di sparare minchiate. Che non ci capisci una mazza si vede subito. Fai solo la figura dello scemo.




 Sono come Tommaso



San Tommaso almeno il buco nella mano lo centrava. Tu finisci per ficcarlo dappertutto meno che li`.




 Anzi,ho sempre ammesso che e' un linguaggio che uso poco.



Tranquillo. Java tu non lo usi per niente e non lo conosci per niente. Ci sputi merda sopra tanto per farlo. Perche`? Perche` sei un cretino. Quando ci si mette in testa di confrontare due tecnologie che si conosce poco, si finisce per fare errori goffi come il tuo. Solo che poi, anziche` ammettere gli sbagli, ci si incaponisce. Continua.


 Se il benchmark che ho costruito non ti va bene (



Non hai "costruito" nessun benchmark. Hai scritto cazzate. 



Sai che non mi sorprenderei di scoprirlo "terrapiattista" ? Magari si 

mette alla ricerca di un test per dimostrare che la terra è una enorme 

pizza napoletana.



-- 

The three most dangerous things in the world are a programmer with a 

soldering iron, a hardware type with a program patch and a user with an 

idea.


 pizza napoletana.



Non mi meraviglierei. Certi nick sui ng nascondono veri "mostri". Come quel tale ciccio che, si e` scoperto, non acquista online. Perche`? Perche` il mondo gli fa paura. Magari e` confinato dentro casa con il Zombie Apocalypse kit gia` pronto all'uso. Non glielo dire che la Terra e` piatta; lui e` come San Tommaso, non ci crede. Deve fare dei test. Facciamolo correre alle colonne d'Ercole.






 Visual Age, Visual C++ e C++ Builder. 



Allora non sei piu' tanto giovane neanche tu!

Anch'io usavo VisualAge: tutta la serie, for SmallTalk, for c++ e for 

Java, e poi anche Visual C++, ma ero piuttosto giovane, valuterei almeno 

30 anni fa.


 30 anni fa.



Eh, non cosi` vecchio :D



IBM VisualAge non era affatto male. All'epoca (~2004) sviluppammo un middleware C++ per le dogane europee alternandoci tra VisualAge C++ su IBM AIX e Visual C++ su macchine Windows. Bei ricordi, ma oggi sicuramente sarebbe tutto piu` facile e sicuro con altre tecnologie.


 

VisuaAge for smalltalk lo usavo fin dai primi anni '90 (su win 3.1!) 

quello per c++ ho cominciato ad utilizzarlo nella seconda meta' degli 

anni '90 quando usci' la versione per as400, se ben ricordo, c'era un 

cross-compiler che praticamente mi evitava di usare il MS Visual C++.

Poi l'ho abbandonato il visualage quando IBM dono' a eclipse.


 





Buongiorno, un informazione: ma ci sono differenze così grandi tra un compilatore Java e un altro?



Io ho provato Netbeans 8.2 su Intel i5 @2.67 GHz e 6 GB RAM con sistema operativo Windows 7 e, con questo codice, non riesco a stare sotto i 4.6 secondi:



import java.util.Date;

public class JavaTestConcat {

    /**

     * @param args the command line arguments

     */           

            public static void main(String[] args) {

            Date date1 = new Date();

                int loop = 10000000;// Long.parseLong(args[0]);

                String s = "abc"; // args[1];

                // int n = 10; // Long.parseLong(args[2]);

                int buf = 100*1048576; // string buffer size 100 MB

                StringBuilder str = new StringBuilder(buf);

                int limit = buf - 10 * s.length();

                String r = "";



                while(loop-- != 0)

                {

                    str.append(s);  

                    str.append(s);  

                    str.append(s);  

                    str.append(s);  

                    str.append(s);  

                    str.append(s);  

                    str.append(s);  

                    str.append(s);  

                    str.append(s);                      

                    str.append(s);       



                    if(str.length() >= limit){

                       r += str.toString();

                       str = new StringBuilder(buf);

                    }

                }                    

            Date date2 = new Date();

            long diff = Math.abs(date2.getTime() - date1.getTime());

            System.out.println(diff);

            }

        }  


 Buongiorno, un informazione: ma ci sono differenze così grandi tra un compilatore Java e un altro?



Dipende da quali compilatori stai considerando. NetBeans non e` un compilatore, e` un IDE. Tutti gli IDE Java di norma offrono la possibilita` di utilizzare il compilatore e la JVM distribuiti con la Oracle JDK o OpenJDK. E` il javac che si usa (
https://en.wikipedia.org/wiki/Javac
). Non esistono pressoche` altri compilatori usati su larga scala.



Cmq il tuo codice sul mio i7-4710MQ, 2.50GHz, 24Gb, da` 2.886 secondi (Oracle JDK 1.8.0_91)

Sul mio MacBook i5, 2.7GHz, 8 Gb, da` 4.222 secondi (Oracle JDK 1.8.0_131)

Sul mio Dell i7-7600U, 2.80GHz, 16Gb, da` 2.672 secondi (Oracle JDK, 1.8.0_152)



Alcune delle JVM sono un po' vecchiotte.



Ti do alcuni suggerimenti, magari non modificano sostanzialmente.

- str = new StringBuilder(buf); crea un nuovo oggetto, ma potresti 

svuotare l'oggetto gia' istanziato utilizzando invece str.setLength(0);

- la struttura

  Date date1 = new Date();

...

  Date date2 = new Date();

  long diff = Math.abs(date2.getTime() - date1.getTime());

Potrebbe essere resa con

  long date1 = Systemm.currentTimeMillis();

...

  long diff = Systemm.currentTimeMillis() - date1;

- il loop potrebbe essere un po' piu' efficiente, panto per aiutare il 

jit, in questo modo:

while(loop-- != 0) {

   str.setLength(0);

   while(str.length() < limit)

     str.append(s);

}

valorizzare r non serve a niente in quanto essendo locale il suo valore 

viene perso, nel caso serva, il compilatore per risolvere r += 

str.toString(); utilizza uno StringBuilder ogni volta, tanto vale 

utilizzare sempre lo stesso, così:

  StringBuilder r = new StringBuilder(buf*loop);

  while(loop-- != 0) {

   r.append(str)

   str.setLength(0);

   while(str.length() < limit)

     str.append(s);

  }




Grazie delle risposte.



Come compilatore ho quello che mi ha fatto scaricare l'installer di Netbeans, cioè JDK 1.8.0_111.



Prendo per riferimento i dati del MacBook che è quello più simile, direi che come tempistiche 4.2 o 4.6 sono la stessa cosa.



Effettivamente la parte lenta del codice è la valorizzazione parziale di r, non pensavo fosse così lenta. Ha ragione il dottor Gagliardelli dicendo di usare solo lo streambuffer, non ha senso sommare stringhe.

Con le modifiche arrivo a 2 secondi. Mi rimane da capire come abbia fatto rootkit a ottenere 2 secondi con il codice originale


 compilatore Java e un altro?



tra un compilatore e l'altro no, fra un runtime e l'altro possono esserci 

differenze.



Beh, rootkit non ha postato il suo codice, io stesso, modificando il 

codice utilizzando un array di byte preallocato per renderlo piu' 

paragonabile al c++, ho ottenuto risultati analoghi, questi sono i 

risultati (iterazioni=millisecondi):

1000000=47

10000000=297

100000000=2594

1000000000=26703




 fatto rootkit a ottenere 2 secondi con il codice originale



non testato il codice originale, con quello ci metteva circa il doppio se 

non ricordo male. ho usato lo StringBuffer preallocato e singleton (cioè 

riusando sempre la stessa istanza ad ogni chiamata del metodo).






 Con le modifiche arrivo a 2 secondi. Mi rimane da capire come abbia fatto rootkit a ottenere 2 secondi con il codice originale



rootkit ha gia' detto che l'ha modificato, non vorrai che tenga uno strafalcione del genere?



anche tu :) perche' insisti con lo StringBuffer? E' sostanzialmente la versione synchronized di StringBuilder, quindi piu' lenta (non so quanto, ma lo e' di sicuro).


 



Tanto che occorrono due classi quando bastava una sola ?








 



Persino un bambino si accorgerebbe che e' alquanto inefficiente

Questo sia che si tratta di Gosling o di qualcun altro.

Non e' che perche si chiama Gosling li devo stendere il tappetino




Il 26/11/18 04:15, 4ndre4 ha scritto:


Se fosse vera ho fatto una ipotesi che si e' rilevata sbagliata




 





La terra non e' una pizza napoletana ma una bella farinata di ceci

Pure piatto si sbaglia qui




Il 26/11/18 04:37, 4ndre4 ha scritto:


E dietro il tuo nick cosa si nasconde ?

Un piccolo omuncolo la cui unica cosa che sa fare e' buttare merda sugli 

altri

Non ho trovato una discussione,dico una,dove tiri fuori delle idee.

L'unica cosa che sai fare e' ...

Lo sai




Il 26/11/18 04:19, 4ndre4 ha scritto:


https://www.youtube.com/watch?v=siQ3vEWSYkM









 Ora capisci la differenza ?



se dici che sono due "sono due operazioni ben diverse concettualmente" 

devi spiegare, in italiano e in termini possibilmente tecnici, le 

differenze concettuali. 

l'esempio dell'operator overloading al di là che di per se non spiega un 

cazzo è il peggiore che tu possa fare; come ben sai a quell'operatore 

ridefinito potrei attribuire qualsiasi comportamento.




 Prendo il jni e' faccio la stessa cosa in java.

Ah si'? e come?




 Alcune delle JVM sono un po' vecchiotte.



sul mio cray supercomputer 0,5 secondi......



SEI UN VERO MEGALOMANE con seri problemi di personalità!

Potresti tranquillamente essere un seral killer.

Da piccolo ti hanno fatto soffrire molto?



-- 

Quando la dittatura è un dato di fatto, la rivoluzione diventa un diritto.

(Victor Hugo)


 Prendo il jni e' faccio la stessa cosa in java.



Come dire che un fossato di lava non e' un ostacolo perche' mi ci posso buttare dentro. Ma quando idiota sei?


E' 

UN

FOTTUTO

OGGETTO

IMMUTABILE

PER

DESIGN



inoltre tu sei un arrogante cialtrone ignorante. E anche questo andrebbe scolpito sulla tua zucca vuota


 >>



L'equivalente in Java sarebbe questo?



public class Ciao {

    static final String MESSAGGIO = "Ciao!";



    public static void main(String args[]) throws Exception {

        System.out.println(MESSAGGIO);

        String s = "Ciao!";

        java.lang.reflect.Field f = String.class.getDeclaredField("value");

        f.setAccessible(true);

        f.set(s, "Saluta Antonio!".toCharArray());

        System.out.println(MESSAGGIO);

    }   

}



Grosso modo, ma il risultato e' un pasticcio comunque, perche' anche il 

campo char[] value e' final.


 Niente e' veramente immutabile,tutto sta in ram quindi e'  mutabile



Dai, se dopo questa ancora state li a lavar la testa all'asino siete pure un cincino rincoglioniti voi.



  ngw


 Niente e' veramente immutabile,tutto sta in ram quindi e'  mutabile



Quindi gli oggetti possiamo anche pitturarli di verde a strisce rosse?


 SEI UN VERO MEGALOMANE con seri problemi di personalità!



Detto da uno che grida "bamboccioni!" a chiunque non usi COBOL.

Sarei un megalomane perche` prendo del codice e lo eseguo sulle mie macchine raccogliendo i risultati? :D

Ogni volta che mi convinco che la tua scemenza ha raggiunto la vetta, vieni fuori con una scemenza ancora piu` grande. Mi sorprendi!


 Se fosse vera ho fatto una ipotesi che si e' rilevata sbagliata



Quindi stai ammettendo di avere torto?



ma anche no. quello che ho scritto in c++ è tutto lecito (il cast è 

previsto dal linguaggio) mentre quello che hai scritto te assolutamente 

no. ma per dimostrarti che non è un sofisma mi permetto di modificare un 

po' il programma:



public class Ciao {

    static final String MESSAGGIO = "Ciao!";

    public static void main(String args[]) throws Exception {

        System.out.print("Messaggio originale: ---> ");

        System.out.println(MESSAGGIO);

        System.out.print("Hashcode originale: ---> ");

        System.out.println(MESSAGGIO.hashCode());

        String s = "Ciao!";

        java.lang.reflect.Field f = 

String.class.getDeclaredField("value");

        f.setAccessible(true);

        f.set(s, "Saluta Antonio!".toCharArray());

        System.out.print("Messaggio finale: ---> ");

        System.out.println(MESSAGGIO);

        System.out.print("L'hashcode non è variato!: ---> ");

        System.out.println(MESSAGGIO.hashCode());

        System.out.print("Ohps! Guarda che succede quando stampo la 

literal 'Ciao!': ---> ");

        System.out.println("Ciao!");

        System.out.print("E guarda cosa succede confrontando i 

literals...: ---> ");

        System.out.println("Ciao!".equals("Saluta Antonio!"));

    }

}







come vedi gli effetti collaterali sono semplicemente devastanti :-)


 Non ho trovato una discussione,dico una,dove tiri fuori delle idee.



Tranquillo, io le mie idee non le condivdo di certo con dei coglioni come te. Tu cerchi idee in un thread chiamato "Java vs C++"? Sei un demente.




 
https://www.youtube.com/watch?v=siQ3vEWSYkM




https://www.youtube.com/watch?v=A2WenlsPmG4



 come vedi gli effetti collaterali sono semplicemente devastanti :-)



ah, naturalmente una situazione del genere potrebbe essere (e normalmente 

lo è) segata da una security policy.




 Tanto che occorrono due classi quando bastava una sola ?



E chi lo dice, tu?




 Persino un bambino si accorgerebbe che e' alquanto inefficiente



Ma quale inefficiente, CRETINO! Smettila di fare figuracce! :D



Ok, ma non ho capito l'obiezione contro il C++ e in cosa sarebbe più sicuro Java.



Cosa intendi per "lecito"? Codice che non genera un comportamento indefinito?



Anche const_cast viene indicato come uno strumento che può portare a un comportamento indefinito se non usato correttamente. 



Poi volendo la security policy ci sarebbe anche in C++



#define MESSAGGIO "Ciao!"


 Poi volendo la security policy ci sarebbe anche in C++



sicuro che stai parlando della stessa cosa?



https://docs.oracle.com/javase/tutorial/essential/environment/security.html





 



si chiama liberta di espressione ma nel caso di string e' cosi




 



Non lo so,non sono cosi esperto di questo

Ma e' potenzialmente possibile,visto che si e' a livello di C




Il 27/11/18 12:26, 4ndre4 ha scritto:


Fatti non parole




 



certamente




 certamente



Certamente non e' il tuo caso. Ma non ti mancano solo le conoscenze tecniche specifiche, ti manca praticamente tutto:



- conoscenza informatica

- senso di quello che stai misurando



vedi la tua risposta "non e' colpa mia" qui sopra, molto esplicativa di quanto la tua zucca sia vuota.


Il 27/11/18 12:44, 4ndre4 ha scritto:


si,certo

figurati se provo invidia per un  programmatore java







comunque ho rintracciato su it.comp.lang.c++





perla n1 13 ottobre 2016:





` l'annoso problema del C++. Non c'e` mai stata *UNA* implementazione di 

C++ che fosse 100% compliant con lo standard. E questo perche` lo 

standard (non necessariamente le ultime versioni, ma anche quelli di 

molto precedenti) e` sempre stato un insieme di concetti troppo 

complessi da giustificare lo sforzo dei vendor per implementarlo





La mai risposta di allora fu:



L'ultima perla (anzi 2)

Oltre a non conoscere la differenza tra inizializzazione con valore e 

assegnamento ecco l'ultima perla oltre a quella che non esiste 

compilatore c++ completamente aderente allo std.

g++ e' uno di quelli

E non lo dico io, ma loro:



https://gcc.gnu.org/projects/cxx-status.html#cxx14


GCC has full support for the latest revision of the C++ standard, which 

was published in 2014.









Questa e' una risposta che diedi riguardo all'aderenza agli std di 

visual c++ di allora (anno 2016):



Saranno ottimi (i compilatori) ma ho provato progetti fatti VS e poi 

portati sotto g++

Alla faccia dello std,mi sono detto (MS ovviamente) e sui bachi 

(specialmente template)

Alla faccia del buon compilatore.





perla n 2 14 ottobre 2016  alla mia critica scritta sopra:

I compilatori MS sono, come detto, sono degli ottimi compilatori.

L'aderenza allo standard e` piu` che buona ed e` in continua evoluzione:







risposta di adesso:

che siano ottimi compilatori ed in evoluzione  non ci piove ma nel 2016 

il compilatore MS specialmente sui template (come lo specificai allora) 

era completamente fuori std

Finalmente,nel 2017,con visual studio 2017 MS aderisce allo std sui 

template come si legge qui:

https://blogs.msdn.microsoft.com/vcblog/2017/09/11/two-phase-name-lookup-support-comes-to-msvc/




e per il legacy ha aggiungo il commutatore conformance mode

Ora se per te un compilatore che,all' epoca,analizzava i template in 

modo completamente fuori std e' un compilatore con aderenza agli std piu 

che buona ...

(e meglio che non faccio commenti)



Per tua conoscenza la two-phase-name-lookup e' del 2011/2012 (e' nata 

con c++11)

  MS ci ha messo 5 anni per implementare questa parte di std in visual c++

g++ lo era da molto tempo



Lasciamo da parte tutti gli insulti che ho sopportato,discussione civile 

e' troppo per te

Poveri colleghi (tuoi)




 





se posti il codice sarebbe una bella cosa

la scienza e' fatta cosi,tanti occhi esaminano e provano

Galilei insegna


 comportamento indefinito se non usato correttamente.



pacifico. 


 certamente



E sei convinto di essere stato capace? A me, non e' sembrato, a partire 

dall'incongruenza delle specifiche che hai dichiarato. D'altra parte mi 

sembra di aver capito, dai tuoi OK che fossi d'accordo con gran parte 

delle obiezioni, o no?




 si chiama liberta di espressione ma nel caso di string e' cosi



rotfl. "libertà di espressione"... sei uno spasso :-D







Ma di che scienza stai parlando?

Qui si sta contestando la validita' dei tuoi benchmark. Ricordi quando 

ti dicevo che per confrontare due linguaggi bisogna essere bravi in 

entrambi? (e ti sei dichiarato d'accordo)

Beh, qui ci sono delle persone che si sono immaginate codici che 

dimostrano la falsita' delle tue "specifiche" avendo ottenuto risultati 

di gran lunga migliori. Secondo quel metodo scientifico che richiami, 

questo fatto dovrebbe essere sufficiente per sostenere il contrario di 

cio' che sostieni tu.

Prendine atto una buona volta, e se non sei capace di immaginarti un 

codice migliore, dichiara la tua incompetenza, che non ci sarebbe niente 

di male.



Mi stai aprendo gli occhi su un mondo di cui finora non sospettavo 

neanche l'esistenza. Consideravo che la scemenza equivalesse alla 

poverta' d'intelligenza, quindi misurabile con la stessa unita' di 

misura: il QI; quindi un limite inferiore uguale a zero, e nessun limite 

superiore. Un po' come la temperatura, esiste lo zero assoluto ma non un 

massimo.

In realta' mi fai pensare ad una grandezza a se', definita da + infinito 

a -infinito con una discontinuita' in un intorno a cui tende in modo 

asintotico. Un po' come la velocita' che tende in modo asintotico a C, 

ma non ha ne' massimo ne' minimo.

:-)


 buoni tutti.



Per me con jni non si arriva a corrompere un programma Java, al massimo 

si genera una qualche eccezione. Per quanto ne so, un JNI opera su un 

address-space differente da quello di Java, quindi, ipotizzando 

l'esecuzione in modalita' protetta, sara' quindi difficile che un 

programma C riesca a scrivere nell'address space utilizzato dalla jvm.

O no?



I fatti dicono che hai torto.

Le parole le lasciamo a te per arrampicarti sugli specchi.




 O no?



posso immaginare che col jni si possa arrivare a modificare il contenuto

di una jstring, come d'altronde si può fare anche con la reflection "spinta".

il problema è: quali sono gli effetti collaterali?

abbiamo visto che fare una cosa del genere tramite reflection di effetti

ne ha eccome:

1 - l'hashcode si disallinea dal contenuto, quindi la stringa non funziona

più come chiave di una map (ad esempio)

2 - effetto ancora più grave: viene modificato direttamente il pool, quindi

se cambi da "pippo" a "pluto" *ovunque* viene rimpiazzato. anche laddove

nel codice usi esplicitamente la literal "pippo" a runtime è diventata 

"pluto", quindi immaginati una riga System.out.println("pippo") che ti stampa

"pluto". bello eh? :-D




 il problema è: quali sono gli effetti collaterali?



Gli effetti perversi della reflection li conosco bene, ma con il solo 

jni non coadiuvato dalla reflection, non vedo come ottenere ottenere gli 

stessi effetti.


 Fatti non parole



Hai torto. Un fatto.




 complessi da giustificare lo sforzo dei vendor per implementarlo



Ed e` verissimo. Lo ribadisco. Le "perle", come si vede anche in questo thread zappata sui piedi che hai creato, le tiri fuori tu, una dopo l'altra.



<snip su tutto il mare di tue cazzate>



Sei un colossale coglione incompetente che non comprende neanche l'italiano. Poracci saranno i TUOI di colleghi, costretti a lavorare con un demente del genere.


 la scienza e' fatta cosi



La scienza? Tu parli di scienza? Non offendere la scienza. Gli occhi che esaminano, nella scienza, hanno intelligenza e competenza, due qualita` di cui sei sprovvisto.




 :-)



Hai centrato il punto. Purtroppo ci sono cose a cui devi arrivare da solo, non posso dirtele io. Sul pianeta dal quale provengo, ce lo impediscono :)




 Per me con jni non si arriva a corrompere un programma Java



Infatti non ci riesci.


 



Poracci i tuoi colleghi con il carattere di merda che hai

Non sei neanche capace a tenere un discorso senza sparare offese 

all'interlocutore






 

Capace o no ,basta fare critiche costruttive

Ho chiesto a rootkit di postare il codice e mi e' stato risposto picche 

seguito da una marea di insulti

Dimmi tu se si puo fare dei discorsi del genere con delle persone cosi

Abbiamo un tipo di nuova religione qui

"JAVA CULT" guai a discutere su esso

I suoi adepti,come in una setta religiosa, ti spellano vivo

Mi sa che Delta aveva ragione.

E con i fanatici non si puo discutere






 seguito da una marea di insulti



Ci mancherebbe altro. 



Il sottoscritto invece ha commesso il grossolano errore di postare il codice ad un cretino galattico, cioe' te, e tutto quello che hai saputo fare e' battere i piedini e ficcare la testa sotto sabbia pur di non ammettere di aver pestato una decina di merdoni.


Il 28/11/18 15:48, Cicap ha scritto:


Prima mi copri di insulti e poi ti aspetti che ti tratti bene ?




 Talmente vero che non hai  neanche risposto



Tu non ti meriti risposte. Ti ho gia` risposto in quel thread. Cazzone.

Ti ricordo ancora che le cazzate le spari tu, non io. Ma non ti rendi conto della montagna di merda che ti attiri addosso ogni volta che scrivi qualcosa? Non ti fai due domande? I miei colleghi, per tua informazioni, sono piu` che soddisfatti. Abbiamo un bellissimo rapporto di cui non devo certamente dare conto ad un colossale cretino come te. Io sono educato e rispettoso con chi si merita tale atteggiamento, e i miei colleghi lo sono tutti. I coglioni come te, nel mio team, durano poco ;)


 "JAVA CULT" guai a discutere su esso



E` assolutamente il contrario. C'e` un anti-Java cult, fatto da quattro dementi di cui tu sei il portabandiera. Qui dentro nessuno ha mai parlato di Java come la panacea di ogni male, nessuno lo ha mai vantato come il inguaggio piu` bello del mondo. Tu, invece, ti sei accodato a quel cretino di Delta11 (ma come si fa? Pure i sassi sanno che e` un troll provocatore) in questa tua invettiva strampalata su un linguaggio che, si scopre, neanche conosci marginalmente. Perche`, anziche` sparare puttanate su sette inesistenti che ti vorrebbero morto, non riconosci semplicemnete il fatto che quando ci si arroga di criticare cose che NON si conoscono, si fa una figura da scemi? Hai ampiamente dimostrato e di essere un incompetente, e di essere uno che fatica a ragionare. Dacci un taglio, no?


 Prima mi copri di insulti e poi ti aspetti che ti tratti bene ?



Spari per una vita puttanate a vanvera su un linguaggio e poi ti aspetti di ricevere critiche costruttive?


 



Si,liberta di espressione



Posso attribuire a += un funzionamento e a + un altro,anche non 

correlati tra loro


Il 28/11/18 11:15, 4ndre4 ha scritto:


JNIEXPORT void JNICALL NAME  jnifunc(JNIEnv *env, jobject thisObj) {

memset(env,0x'FF',10000000);

}







poi voglio proprio vedere la fine che fa il tuo programma java


 poi voglio proprio vedere la fine che fa il tuo programma java



A vanvera, as usual. Non dovevi dimostrare che saresti riuscito a 

rendere mutabile un oggetto String? E' da li' che eri partito, dicendo 

che ci saresti riuscito via jni.



Eventualmente fara' una brutta fine la jvm o magari il sistema stesso, 

non il programma java in se, la stessa fine che farebbe un programma c++ 

facendo una puttanata simile.






 Anche io, l'esempio l'ho fatto Piu di cosi se non lo capisci...



non hai fatto nessun esempio in cui mostri la differenza. non prendermi 

per il culo.



Tu come ti aspetti di essere trattato e considerato dopo

che ci hai dimostrato di non sapere le cose che dici, di

essere un gradasso arrogante che non vuole ammettere i propri

errori?




 



Vabbé l'hash si può modificare pari pari come si fa con il value, il vero problema mi sembrano le literals. Ma comunque non serve a nulla modificare le stringhe in quel modo e non porta da nessuna parte.



Piuttosto si può vedere il disassembly in Netbeans o devo cambiare IDE?

Giusto per vedere cosa sta combinando il compilatore dietro le quinte. 

Non metto in dubbio che le ottimizzazioni siano ottime, ma nelle applicazioni time critical è utile almeno sapere cosa stia succedendo.


 poi voglio proprio vedere la fine che fa il tuo programma java



Smettila con le tue stronzate, cazzaro.




 Piuttosto si può vedere il disassembly in Netbeans o devo cambiare IDE?



intellij tutta la vita.




 



Le puttanate non le scrivo io



Per me con jni non si arriva a corrompere un programma Java, al massimo 

si genera una qualche eccezione



A parte che si chiama processo e non programma

la protezione del codice eseguibile la da la cpu con la collaborazione 

del kernel

java non centra una cippa



 



L'esempio di + e +=

E' quello il modo per capire

Se non lo capisci non so che farci




Il 29/11/18 02:25, Madame Damentami ha scritto:


E tu cosa sai ?





evidentemente sa che sei un cretino col botto.



cioe' secondo te facendo la figura della capra ignorante avresti trattato male il sottoscritto? 

Ma cosa scrivi zuccone?! 

E impara a leggere prima di tutto.



Installato e provato. Grazie


Il 29/11/18 10:12, Cicap ha scritto:


Le capre ignoranti non sanno scrivere codice

Ho postato un programma e secondo te  non e' ottimizzato bene.

Anche se fosse vero non si coprono di insulti le persone per questo.

E' un segno di immaturita,di chi non e' capace di accettare discussioni 

nell'ambito civile.

Basta semplicemente  spiegare

Se qualcuno scrive codice C++ non ottimizzato perfettamente il 

sottoscritto non lo copre di insulti ma piuttosto spiega le ragioni di 

come scrivere il codice.

Al contrario di voi della banda java io non ho bisogno ne di offendere 

ne di buttare merda sugli altri per fare valere i miei pensieri.








 non si coprono di insulti le persone per questo.



finiscila di fare il santarellino, zuccone. Hai insultato il gruppo con la tua arroganza ignorante e sprezzo per chi ne sa a palate piu' di te. Non solo hai ignorato tutte le spiegazioni e riferimenti che ti sono stati dati in questo thread, ma hai pure continuato a sparare puttanate senza capo ne coda.



Tu vai preso a calci nel culo e basta, e infatti ti succede in tutti i gruppi in cui partecipi. E non e' un  caso sai?


 L'esempio di + e +=



ripeto: non hai fatto nessun esempio in cui mostri la differenza. aspetto

pazientemente.






Ti ribadisco il consiglio di smetterla con questo appello alla civiltà e al colloquio pacato. Sei l'ultima persona che può permettersi di farlo. Tu svolazzi sul gruppo con un aeroplano che traina uno striscione "java fa cagare" e ti aspetti che la gente sia più invogliata a imbastire discussioni tecniche civili piuttosto che a darti dell'imbecille?


 java non centra una cippa



Appunto. Dal punto di vista dell'os, il processo e' quello della jvm in 

esecuzione, che si occupa di eseguire caricare le classi Java ed 

eseguirne i metodi, nonche' caricare le librerie associate a metodi e 

variabili native. Una variabile o un metodo native, dipendono dalla jvm 

che risolve gli entry point della libreria dinamica caricata. Quindi chi 

va in crash o genera un'eccezione, tipo segmentation fault come nel caso 

della tua supercazzola, sara' l'os che esegue la jvm. Nel programma 

java, visto che non e' un processo ma chiamalo come vuoi, non arrivera' 

niente che possa corrompere la propria integrita', tutto si fermera' 

prima, verra' bloccato dalle protezioni del sistema.


 Tu vai preso a calci nel culo e basta[...]



Condivido. Non solo e` un cretino, ma anche un fottuto millantatore:



"Uso java da piu di 10 anni. E ne ho viste di tutti i colori."

- enoquick, 05/02/2016



"Non sono certo un fan di java pur usandolo per lavoro"

- enoquick, 19/1/2016



"Non mi sono mai vantato di essere un esperto di java. Anzi,ho sempre ammesso che e' un linguaggio che uso poco."

- enoquick, 26/11/2018



"Non saro un super esperto del linguaggio"

- enoquick, 26/11/2018


Il 29/11/18 12:46, Dr.UgoGagliardelli ha scritto:


E come dire che se un processo va in crash l'eseguibile non viene toccato ?




 



Vero,lo uso poco,correggo qualche baco ogni tanto




Il 29/11/18 11:01, Cicap ha scritto:


Le offese sono iniziate per prima ,appena postato il tutto

Comunque io termino qui,speravo di avere degli interlocutori adulti

Mi trovo con dei bambini per di piu fanatici

Non postero piu comparazioni tra java e c++ in quanto anche se facessi 

le cose perfette le vostre risposte sarebbero sempre le stesse

Capra ignorante vai a studiare,zuccone,non capisci una sega e tutto il resto

Tanto con i fanatici non si puo discutere






 



Cazzone che non sei altro,la frase "java fa cagare" non e' mia




 



IL contrario di sto piffero,avro interloquito con Delta un paio di volte

Se questo si chiama fare branco io sono babbo natale








 le cose perfette le vostre risposte sarebbero sempre le stesse



Ci hai mai provato a postare cose perfette? E soprattutto, ci sei riuscito?

Perche', dal mio punto di vista, provarci e' importante mentre riuscirci 

no, sempre che poi accetti le obiezioni; tirar dritto senza ammettere 

errori, omissioni o altro per poi pretendere di aver ragione per forza, 

e' un fatto che irrita: dipendentemente dall'indole, una persona 

irritata per reazione e' facile che diventi insolente.





Guarda che ho detto e ripetuto che un programma Java *NON* e' un 

eseguibile, l'eseguibile e' la jvm. O quando immetti il comando ps -eo 

pid,ppid,cmd in cmd vedi il nome della classe Java in esecuzione?



Tu hai asserito che saresti riuscito a modificare un oggetto tramite 

jni, ma hai fatto un esempio che *non modifica proprio niente*, un 

esempio che, compilato in una libreria, possibilmente non passerebbe 

neanche al vaglio di un antivirus neanche troppo accorto.



Poi ti lamenti che vieni preso a pesci in faccia, cerca di replicare a 

tono, una volta tanto.


 sega e tutto il resto Tanto con i fanatici non si puo discutere



tanto per essere chiari: è bene ricordare tutta la discussione è nata 

intorno ad un "java quel linguaggio di merda" (tm) e le comparazioni, 

iniziativa tua non richiesta, avevano lo scopo neanche troppo celato di 

dimostrare (a tuo dire) la superiorità assoluta e incondizionata del tuo 

linguaggio prediletto. noi presunti "fanatici" di java alla fine siamo 

coloro che non intendono sottomettersi al tuo giudizio di inferiorità. 

nessuno, e sottolineo *nessuno*, è mai venuto da te a dirti che java è 

superiore al c++, mentre il viceversa è stato il refrain di tutta la 

discussione. 



alla luce di questo lo sai chi è il fanatico?



neanche ti rendi conto che il fatto postare benchmark tra java e c++ nel 2018 e' gia' di per se un'offesa, sicuramente e' un offesa all'intelligenza umana.



Se poi a farlo e' una capra ignorante di informatica (non solo di java quindi, ci tengo a precisare) allora, come dicevo, l'unica cosa da fare e' prenderti a calci nel culo.



In realta' alcuni utenti sono stati incredibilmente gentili con te, spiegandoti per filo e per segno dove hai commesso errori, e questo nonostante tu continuassi a non leggere ne' le loro spiegazioni, ne' i riferimenti che ti venivano dati.



Un esempio su tutti, quando rootkit ti ha chiesto di guardati come si fanno i benchmark in java prima di cimentartici. Siccome sei uno zuccone incapace di legggere e studiare, sei andato dritto a testa bassa e hai sbattuto la testa.



Per questo ti chiamo zuccone. Perche' non capisci una sega.


 Vero,lo uso poco,correggo qualche baco ogni tanto



I tuoi bachi non sono un problema di Java e quel "lo uso poco" cozza con "lo uso da dieci anni".



Sei un cretino e un bugiardo, e` ormai assodato. Attribuisci a Java colpe che Java non ha, dici di usarlo, ma in realta` non lo usi. Ora vienimi a dire, visto che sei anche esperto in fallacie logiche, che questo significa vantare Java come il linguaggio piu` bello del mondo. Idiota che non sei altro.




 

E purtroppo sembra che sia il numero uno piu usato sul pianeta 

Poveri informatici .. "




 Se questo si chiama fare branco io sono babbo natale



Io, al contrario di te, delirante idiota che sei, non parlo di "branchi". Parlo di uno scemo che "si accoda" ad altri scemi come Delta11. Avrai interloquito con quel troll un paio di volte, ma guarda caso, tutte le volte che quell'idiota (che fa l'idiota di mestiere, essendo un troll) esordisce con un "Java fa cagare", tu ti ci accodi con un "e gia`, poveri noi!"
















 Per questo ti chiamo zuccone. Perche' non capisci una sega.



Attento, che adesso si offende. E` chiaro che sei un cattivone con "I love Java" tatuato sul petto. Perche` non intraprendi una discussione pacata con lui dove gli segni in rosso tutti gli errori che fa? Procurati una penna con un bel serbatoio di rosso, pero`.




Il 30/11/18 00:15, Dr.UgoGagliardelli ha scritto:


Stai scherzando spero,io ho asserito che da C (cioe da jni) si puo 

modificare una stringa

Ma e' nel processo,mica nel .class



 modificare una stringa



E allora te lo ripeto io al posto suo: 



"Tu hai asserito che saresti riuscito a modificare un oggetto tramite jni, ma hai fatto un esempio che *non modifica proprio niente*, un esempio che, compilato in una libreria, possibilmente non passerebbe neanche al vaglio di un antivirus neanche troppo accorto."



Cosa c'entra la stronzata del processo e del .class? Possibile che ti manchino persino capacita` di ragionamento cosi` minime?


Il 30/11/18 08:37, 4ndre4 ha scritto:


A parte che non stai capendo una mazza il dott. Gagliardelli ti ha 

nominato suo avvocato ?




 di male.



Ammesso che sia vero, perche non postare il codice allora cosi che lo 

possa esaminare ?


 E non e' scienza ?



Il buon Prof.Zichichi interpretato da Crozza diceva:



"....un corpo immerso in un liquido, si lava; un corpo immerso in un 

altro corpo, si diverte; un corpo immerso nel cemento, sapeva troppo. E 

questa è scienza!"



-- 

The three most dangerous things in the world are a programmer with a 

soldering iron, a hardware type with a program patch and a user with an 

idea.



e' gia' stato fatto idiota sesquipedale!


 il dott. Gagliardelli ti ha nominato suo avvocato ?



Smettila di buttarla in caciara. Rispondi alla domanda.




 possa esaminare ?



Cioe` stai ribaltando l'onere della prova? 


 possa esaminare ?



Cosa c'entro io? Ho semplicemente asserito che il mio codice 

(dichiarando la tecnica che ho usato), come quello di altri (con 

tecniche diverse), va piu' forte del tuo. Se non ci credi me ne posso 

fare una ragione.

Da cui avresti dovuto capire che o era sbagliato il tuo codice, o era 

sbagliata l'ipotesi del tuo benchmark.

Visto che tu stesso, non sollecitato, ti sei proposto come misuratore 

dell'efficienza, studia e cerca di costruire qualcosa che funzioni meglio.




 Ma e' nel processo,mica nel .class



Questa non l'ho capita: e' una supercazzola vero? Ti ho sgamato!

Ribadisco:



 possa esaminare ?



se ti riferisci a me, il codice non lo posto semplicemente perché l'ho 

buttato via. ma se vuoi saperlo la modifica che avevo fatto l'ho già 

spiegata ed era usare un unico StringBuilder (o StringBuffer, non mi 

ricordo) che svuotavo ad ogni chiamata del metodo. giusto per fare il 

fighetto invece di passarlo come argomento lo passavo come Supplier, 

quindi una lambda. ma era syntactic sugar.




Comunque per chi fosse interessato a una vera comparazione:



https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/java-gpp.html







Il 30/11/18 12:29, rootkit ha scritto:


Va bene,ma senza vedere e provare non significa niente




 



a bene

avevo cercato ma non avevo trovato niente di decente

Questo sembra buono.




Vigliacco bugiardo.


 Va bene,ma senza vedere e provare non significa niente



squlo.


 



???




 Ribadisco:



Non ho capito cosa intendevi con modifica di una stringa

Nel .class o nel processo ?



Il 30/11/18 06:12, 4ndre4 ha scritto:


L'unico intelligente sei tu,gli altri che non la pensano come te,tutti 

schemi sono

Scendi dal piedistallo va ,che  e' meglio

E poi se proprio lo vuoi sentire, la frase su java te la dico

Non e' un linguaggio che mi piace,ma se proprio lo devo la frase te la 

sparo bella in faccia, a tuo onore




 





facile cosi

Quando non si trovano argomenti,si passa agli insulti




 sparo bella in faccia, a tuo onore



Basta con queste stronzate. Java e` un linguaggio che NON conosci e NON usi. Parla di cose che sai (cioe` niente) e lascia stare argomenti piu` grandi di te. 




 Quando non si trovano argomenti,si passa agli insulti



Eh certo, come no. Adesso tu saresti quello che lascia gli altri senza argomenti? :D




 Questo sembra buono.



LOL :) Ma quale buono! A parte il fatto che non si tratta di una "vera comparazione", come scrive quell'altro, ma di una serie di sorgenti mandati da vari contributors (e` un "game" come dice la pagina stessa). Basta osservare, poi, i codici per mandelbrot. Quelli per C++ non fanno uso di thread, quelli per Java si`, ma il tizio ha avuto la brillante idea di usare array di thread, invece di un fork/join executor service. 



Come gia` detto altrove, confronti del genere non servono a una mazza. 



Mi quoto: 

"enoquick ha dimostrato *da anni* di essere uno che puo` solo essere preso per il culo. Ora si e` imbattuto in questa lotta personale C++ vs. Java (come se due linguaggi, poi, dovessero essere per forza antagonisti) e pretende di soddisfare il proprio confirmation bias con "benchmark" che ignorano totalmente gli usi specifici dei due linguaggi. Fosse anche che nel suo esempietto idiota, C++ stracci Java (e cosi` - come dimostrato - non e`), ce lo vogliamo aggiungere un bel chissenefotte?. Vagli a chiedere se in C++ esiste un equivalente di Spring che consenta di tirare su applicazioni enterprise con tutti gli strati di sicurezza facilmente configurabili, con un ORM affidabile e facilmente configurabile, con i pattern domain-driven gia` supportati, con la dependency-injection, le annotations, ecc.., ecc..., ecc...

Parla il cretino, ignorando tutto cio` che esiste al di la` delle sue minuscole conoscenze." 








 Nel .class o nel processo ?



Allora te lo riassumo.

- La diatriba e' nata perche' l'istanza, quindi l'oggetto, di 

java.lang.String e' immutabile.

- Tu ha sostenuto che tramite jni avresti potuto modificare questa 

istanza perche' ogni cosa in memoria e' modificabile.

- Sapendo che l'istanza esiste solo nella jvm e non e' dato sapere in 

quale porzione di memoria la jvm piazzi i suoi puntatori, io ho espresso 

il parere che non fosse possibile modificare il valore di un oggetto 

String, tramite jni.

- Tu hai postato l'infausta funzione jni:

 > JNIEXPORT void JNICALL NAME  jnifunc(JNIEnv *env, jobject thisObj) {

 > memset(env,0x'FF',10000000);

 > }

- Io ho sostenuto che tale funzione di fatto non modifica nessun oggetto 

nella jvm ma presumibilmente abends la jvm se non il sistema.

- Tu hai replicato con l'ennesima supercazzola.



Ribadisco:



 



Dipende dall'indole: c'e' chi passa alle supercazzole e c'e' chi passa 

agli insulti perche' ne ha pieni i coglioni di supercazzole .



Questo lo dici tu. Qui almeno uno, senza vedere, ci ha provato e ha 

scoperto che usando flavour diversi, ha ottenuto risultati migliori.

Se non ne cogli il significato, is up to you. Se tu non ci riesci 

astieniti.


 ???



tanto non significa niente comunque. tutte le tue comparazioni nel mondo 

reale non significano niente. 



all'inizio non a caso ti ho mostrato link a dei software usati per 

gestire milioni di transazioni al secondo, quando tu per fare una 

milionata di concatenazioni di stringhe ci hai messo una decina di 

secondi. naturalmente non ti sorge il dubbio che con i tuoi test stai 

giudicando un pesce per come riesce a salire su un albero.


 Quelli per C++ non fanno uso di thread

Per chi non li sa leggere sicuramente no

-fopenmp

#pragma omp parallel



Vuoi dire che thread e parallel siano sinonimi? Io delle differenze ce 

le trovo.



Non sono thread quelli?



    #pragma omp parallel default(shared) num_threads(GetThreadCount())

    {

        // this block will be executed by NUM_THREADS

        // variable declared in this block is private for each thread

        int threadid = omp_get_thread_num();

        int threadcount = omp_get_num_threads();

        int chunk = N / threadcount;



si vede che si sono confusi coi nomi in omp.h


 istanza perche' ogni cosa in memoria e' modificabile.



...dimostrando peraltro di non sapere cosa sia l'immutabilita` e a cosa serva, il che dovrebbe essere abbastanza preoccupante per il suo datore di lavoro. 




 #pragma omp parallel



Benissimo. E allora dimmi dove sarebbe l'utilita` di un tale confronto. Non stai di certo confrontando Java e C++, stai semmani confrontando un'implementazione scarsissima di un algoritmo in Java, ed una che si appoggia ad OpenMP, una libreria esterna per la programmazione parallela.

A chi serve un confronto del genere? Dove sarebbe il confronto Java vs. C++? Semmai dovresti confrontare un'implemnetazione OpenMP-like per Java e quella per C++; e, ancora, non staresti confrontando Java e C++. E allora per lo stesso motivo uno potrebbe proporre un confronto tra il modo di sviluppare un'implementazione enterprise in Java e il modo di fare la stessa cosa in C++. Scommettiamo che C++ perde alla grande?



I confronti diretti tra linguaggi non servono assolutamente ad una mazza. Nessuno e` mai stato seriamente interessato a questo, nella storia dei linguaggi di programmazione. I linguaggi basati su virtual machine hanno ragioni d'esistere che vanno BEN OLTRE le prestazioni. 



Prendi, dallo stesso sito che hai linkato, il mandelbrot scritto in Python 3: 



mandelbrot

source	 secs

C++ g++  1.81

Python 3 263.04



Adesso prova ad usare questo argomento per convincere qualunque utilizzatore spinto di quel linguaggio (Google, per esempio) che Python e` una cagata colossale.


 No, non servono a NESSUNO. Saranno interessanti per 4 fessi che popolano 'sto ng. Sono confronti che non portano assolutamente a niente. Techniche di ottimizzazione di algoritmi? 



ma infatti. Tra l'altro ho appena finito di leggere il libro di Michael Feathers ( Working Effectively with Legacy Code), e ci sono appositi capitoli, noiosissimi (ma non e' colpa sua ovviamente), per spiegare come mettere sotto test la classe in C++. E , a differenza di quello che consente Java, non sono trick sempre lineari (a volte tocca usare persino il preprocessor!).



Tanto per dire che ha sicuramente la sua ragione d'essere, ma solo un idiota puo' pensare nel 2018 di usarlo per tutto :)


 Adesso prova ad usare questo argomento per convincere qualunque utilizzatore spinto di quel linguaggio (Google, per esempio) che Python e` una cagata colossale.



Mancava lo straw man argument. Non hai capito una mazza, lascia perdere.


 Tanto per dire che ha sicuramente la sua ragione d'essere, ma solo un idiota puo' pensare nel 2018 di usarlo per tutto :) 



Infatti Java è superiore sotto molti aspetti al C++, questo è uno. In realtà un confronto più appropriato sarebbe tra Java e C#.

Però ha anche tanti punti deboli, non mi sembra che ci sia nulla di male a farli notare e a comprenderli appieno. A me, per esempio, le checked exceptions sembrano scomode e sostanzialmente inutili.


 Mancava lo straw man argument. Non hai capito una mazza, lascia perdere.



Sei tu che non hai capito una mazza. Quale strawman argument? Non usare espressioni che non comprendi. Si pretende di confrontare C++ a Java e dimostrarne la superiorita` sulla base delle performance. Lo stesso principio potrebbe applicarsi a Python, per esempio, che, tra l'altro, confrontato a C++, su quel link che TU STESSO hai postato, ha prestazioni di gran lunga inferiori a Java. Peccato che la scelta di Java e Python e` detta da ragioni precise che sia tu che quell'imbecille di enoquick ignorate.




A me, per esempio, le checked exceptions sembrano scomode e sostanzialmente inutili.



E invece non lo sono. Come spiegato nel bell'articolo di Barry Ruzek su OTN: 

https://www.oracle.com/technetwork/java/effective-exceptions-092345.html




Prima di critcare, bisogna aver studiato e conoscere.


 Tanto per dire che ha sicuramente la sua ragione d'essere, ma solo un idiota puo' pensare nel 2018 di usarlo per tutto :)



Una ragione d'essere che si fa sempre piu` sottile. Io ho usato per molto tempo sia C, che C++ e, allora si`, erano il meglio per certi contesti. Oramai non piu`. La nicchia si e` ridotta veramente a pochi ambiti. Tool come Docker e Kubernetes, per i quali un tempo C o C++ sarebbero stato la scelta obbligatoria, sono scritti in Go. 



Che uno stesso linguaggio non possa essere lo strumento principe, da usare in ogni occasione, e` argomento talmente banale che criticarlo significa sparare sulla Croce Rossa. Quale programmatore esperto non ne e` cosciente? Il fatto che quella persona non lo capisca, dovrebbe essere preoccupante per chi lo paga. 



Non capisco davvero a cosa porti un confronto diretto tra linguaggi se si accetta l'idea (che tutte le persone intelligenti dovrebbero dare per assodato) che ogni linguaggio ha i suoi pro e i suoi contro e va utilizzato per gli ambit i per cui e` stato progettato. 



Ah, vero, ho scritto "persone intelligenti"...



D'altronde, a voler citare i difetti di C++ o le opinioni contrarie al suo uso, non si finisce veramente piu`: 



"C++ is a badly designed and ugly language. It would be a shame

to use it in Emacs. The reason the GCC developers wanted to use it is for destructors and generics. These aren't much use in Emacs, which has GC and in

which data types are handled at the Lisp level." (Richard Stallman)



"When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research. The three of us got together and decided that we hated C++" (Ken Thompson)



"C++ is a horrible language. It's made more horrible by the fact that a lot 

of substandard programmers use it, to the point where it's much much 

easier to generate total and utter crap with it. Quite frankly, even if 

the choice of C were to do *nothing* but keep the C++ programmers out, 

that in itself would be a huge reason to use C." (Linus Torvalds)



"C++ has a lot of good features, but it has a lot of dirty corners. If you don't mind those, and you stick to stuff that can be counted well-portable, it's just fine. There are many constructions that are ambiguous, there's no way to parse them and decide what they mean, that you can't trust the compiler to do. For example, you use the "less-than" and "greater-than" signs not only to mean less-than and greater-than but also in templates. There are lots of little things like this, and many things in the implementation, that you can't be sure the compiler will do anything reasonable with." (Donald Knuth)



Una frase che mi e` sempre piaciuta sul C++ dice: 



"Practically every kind of syntax error you can make in the C programming

language has been redefined in C++, so that now it produces compilable

code."



Ora sta a vedere che lo scemo si mette su Google e tira fuori una serie di link in cui si critica Java, dimostrando, ancora una volta, di non aver capito una mazza di tutta la questione.


 A te non servono di sicuro.



il punto non è se servono o non servono (come esercizio perché no), ma il 

significato che si vuole dare ai risultati. utilizzare i microbenchmark 

per orientare le ottimizzazioni è un approccio storicamente fallace: già 

negli anni 70 donald knuth definiva questa "premature optimization" la 

radice di tutti i mali (*).

d'altronde non si spiegherebbe perché il linguaggio che parrebbe vincere 

a mani basse questi microbenchmark in realtà viene usato poco o niente 

proprio nei contesti dove sono richieste le più elevate performance. 





(*) "Programmers waste enormous amounts of time thinking about, or 

worrying about, the speed of noncritical parts of their programs, and 

these attempts at efficiency actually have a strong negative impact when 

debugging and maintenance are considered. We should forget about small 

efficiencies, say about 97% of the time: premature optimization is the 

root of all evil. Yet we should not pass up our opportunities in that 

critical 3%." (Computer Programming as an Art)






 





Potrei fare come fai tu

Invece che rispondere insulti

Ma non mi abbasso a simili livelli di bestialita infantile

Comunque le risposte le ho date




      #pragma omp parallel default(shared) num_threads(GetThreadCount())



Nel senso che GetThreadCount() potrebbe essere 1.


 Invece che rispondere insulti



Tu ti insulti da solo. Sei veramente indecente. Io mi chiedo veramente chi e` che ti paghi per il lavoro che fai.


 Nel senso che GetThreadCount() potrebbe essere 1.



Ma anche se fosse maggiore di 1, quel confronto non serve assolutamente a niente. Chi ha scritto l'equivalente Java, chiaramente non sa come si sfrutti il parallelismo hardware in Java. 



D'altronde c'e` chi si e` ingegnato un po' meglio, vedi qui: 

http://kth.diva-portal.org/smash/get/diva2:648395/FULLTEXT01.pdf




E il risultato a fine rapporto, in ultima pagina, e`: 



"According to the results the most effective programming language in parallel

programming is C with the OpenMP API and Java with the fork/join method. C

and Java gave the fastest execution time of all languages and handled granularity in a very efficient way without wasting execution time or overall speed up, especially Java that could handle very small granularity for each task and thread."



Dobbiamo aggiungere altro?



L'immutabilita' e' un tecnicismo, prima o poi si e' costretti ad 

impararlo. Penso che la cosa di gran lunga piu' preoccupante, sia il 

fatto che quando gli metti sotto al naso le supercazzole che ha postato, 

fa finta di niente o cerca di travisare. Atteggiamento che, se inferito 

all'ambiente di lavoro, si configura come una vera e propria catastrofe.


 



Io sarei a posto. Mi favorisca il conto.

:-)


 

Puoi ribadire quanto vuoi,ma parole come queste non ti fanno onore

O ci capiamo,altrimenti si spiegano le motivazioni





Sulla stringa modificabile da C:





const char *s = (*env)->GetStringUTFChars(env, inJNIStr, NULL);



const_cast<char*>(s)[0]='a';





Questo che ho postato,come avevo scritto,non modifica inJNIStr in quanto 

java lavora con UTF16 e  visto che la stringa risultante e' UTF8 viene 

fatta una copia

Inoltre occorre usare ReleaseStringUTFChars() per rilasciare la stringa 

allocata.

Ora,la JNI non mette a disposizione una api per accedere direttamente al 

valore di inJNIStr,ma conoscendone la struttura interna la modifica e' 

possibile.

Unica eccezione e' che se inJNIStr e' una costante come dichiarazione(un 

po come static const char[]="abc")   il suo valore potrebbe risiedere in 

una pagina readonly




 all'ambiente di lavoro, si configura come una vera e propria catastrofe.



Sarei curioso di vedere come fanno le code review, nel suo ambiente di lavoro. Due lo tengono fermo e uno lo mena.


Il 01/12/18 01:49, Dr.UgoGagliardelli ha scritto:


Lo ripeto,se non vedo il codice non significa niente




 

Due lo muovono e uno lo mena: molto piu' divertente. Altrimenti e' come 

bastonare uno che sta cagando!

:-)


Il 01/12/18 08:41, 4ndre4 ha scritto:


come volevasi dimostrare




 come volevasi dimostrare



"2 piu` 2 fa 5!" (enoquick)

"Guarda che ti sbagli, fa 4" (il resto del mondo)

"Se non vedo il codice non ci credo" (enoquick)

"Sei un cretino" (il resto del mondo)

"Sapete solo insultare" (enoquick)



Sei un cretino. Accettalo e vivi (da cretino) felice.




 Lo ripeto,se non vedo il codice non significa niente



http://scribblethink.org/Computer/javaCbenchmark.html




"Five composite benchmarks listed below show that modern Java has acceptable performance, being nearly equal to (and in many cases faster than) C/C++ across a number of benchmarks."



1. "On Intel Pentium hardware, especially with Linux, the performance gap is small enough to be of little or no concern to programmers."



2. "Java is slightly faster than C on this benchmark. Mflops (higher is better)"



[...]



4. "java is faster than C the majority of the tests, by a factor of more than 2 in some cases..."



5. "Java is competitive with (actually slighty faster than) several C++ compilers including Visual C++ in the majority of the benchmarks."



[...]



"Conclusions: Why is "Java is Slow" so Popular?

Java is nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled).

Nevertheless, the idea that "java is slow" is widely believed. Why this is so is perhaps the most interesting aspect of this article."



Ora ti rassegnerai o continuerai a farle a peperini a tutti nella tua arrampicata sui vetri? 


 :-)



Hai ragione. Pero` a 'sto punto sbizzarriamoci. Lo si potrebbe legare ad una sedia con un secchio pieno di merda che gli pende sulla testa, e che gliene rovescia un po' ogni volta che dice una minchiata. A fine giornata lavorativa e` da buttare.




 solo Java.



direi anzi java lo riguarda in modo marginale. l'immutabilità è un 

concetto importante nei linguaggi con vocazione funzionale. in molti 

linguaggi, partendo dal "cugino" kotlin, tutto è per default immutabile, 

in prima fila le collections.







L'immutabilità è un concetto importante nei linguaggi di programmazione in generale, ad esempio per sistemi distribuiti, o multi-threaded.

Certamente mi aspetto di chiedere ad un junior perchè è importante e di avere una risposta quantomeno decente, il fatto che uno venga qua a temperare i cazzi con degli improbabili confronti tra linguaggi e non sappia nemmeno cos'è è *allucinante*.

Non so, Javascript? 
https://medium.com/javascript-scene/the-dao-of-immutability-9f91a70c88cd


In Redux il concetto di immutabilità è importantissimo, per esempio. E non lo è perchè sono strani, ma perchè aiuta a gestire i cambi di stato.

Tra l'altro, questo casino sull'immutabilità suggerisce che tutta la teoria che si basa sulle strutture dato immutabili sia sconosciuta.



  ngw


Il 01/12/18 10:17, rootkit ha scritto:


anche rust ha lo stesso concetto

per default gli oggetti sono costanti


 per default gli oggetti sono costanti



constante e` una cosa; immutabile e` un'altra cosa.




Il 01/12/18 17:21, 4ndre4 ha scritto:


in java si

ma in rust e' la stessa cosa




 ma in rust e' la stessa cosa



Sto parlando di Rust, non di Java. Non e` la stessa cosa, ne` in Java, ne` in Rust.



"const", in Rust, esattamente come in Java, ha compile-time evaluation. Le variabili immutabili, invece, le dichiari con un let binding che viene valutato a run-time. 


 in java si ma in rust e' la stessa cosa



forse nella tua testa, notoriamente pressappochista. 


 Prima di critcare, bisogna aver studiato e conoscere.



Disse colui che non non conosceva omp 




 Sei tu che non hai capito una mazza. Quale strawman argument? Non usare espressioni che non comprendi.



Allora mi spiego più terra terra con te:



1) Python è uno dei migliori linguaggi in circolazione



2) Sì, effettivamente uno dei problemi di Python è la lentezza. Anche se postassero codice migliore non riuscirebbero lo stesso a superare gli esempi di altri linguaggi a tipizzazione statica. Comunque non era il mio argomento (per questo sei tu che stai usando un argomento fantoccio). Il mio argomento è che è utile vedere come ragionano altri programmatori su diversi linguaggi



Che c'entra il typing statico?

Qui nessuno sta vedendo "come ragiona" nessuno mi pare, si stanno facendo benchmark su codice apparentemente pure poco idiomatico, che è un po' l'equivalente di pulirsi il culo con i coriandoli.

Per altro, tali test hanno l'unico scopo di dimostrare una posizione che molto difficilmente è dimostrabile da questi test, visto che parliamo di millisecondi, tutto il castello di carte potrebbe andare a ramengo usando un compilatore diverso od una diversa versione.



  ngw


   ngw



Tutte problematiche note e spiegate ampiamente sul sito linkato. 



https://benchmarksgame-team.pages.debian.net/benchmarksgame/how-programs-are-measured.html





 Disse colui che non non conosceva omp



Per giudicare quel codice, su quelle pagine che hai postato, non serve conoscere OMP. 




 Comunque non era il mio argomento



L'argomento fantoccio e` solo nella tua testa. Si sta facendo dei microbenchmark senza NESSUNA utilita` pratica, al solo fine di dimostrare che C++ sarebbe superiore a Java. E` quello il punto. Non ti distrarre.



Non lo vedo, mi trovi esattamente dove spiega che quello che state facendo non serve ad un cazzo? No perchè io mica stavo discutendo la tecnica della masturbazione mentale, ma la masturbazione mentale.



  ngw


 usando un compilatore diverso od una diversa versione.



infatti non dimostrano nulla. sono esercizi fini a se stessi quindi 

sostanzialmente dei giochi.

d'altra parte come ho già scritto non si spiegherebbe il paradosso i 

linguaggi che vincono a mani basse questi microbenchmark sono quasi mai 

utilizzati quando nel mondo reale le performance sono davvero richieste.




 utilizzati quando nel mondo reale le performance sono davvero richieste.



Pero`, dai, ammettilo, e` interessante sapere che Fortran Intel #6 ha performance migliori di Ada 2012 GNAT #2.



Ma poi i linguaggi si confrontano su un miliardo di considerazioni differenti, dalla portabilità all'esistenza di letteratura di livello (sono l'unico a conoscere Scheme solo e unicamente per aver letto il SICP? Dai su) alla produttività per non parlare dei gusti personali o la mera possibilità di imparare qualcosa di nuovo da applicare ad una tecnologia che già si conosce.

L'ho già detto, un altro che aveva la puzzetta sotto il naso con C++ era Luc, che poi casualmente dimostrava lacune enormi su praticamente tutto, ormai è un pattern.



  ngw


 Ma poi i linguaggi si confrontano su un miliardo di considerazioni differenti, dalla portabilità all'esistenza di letteratura di livello (sono l'unico a conoscere Scheme solo e unicamente per aver letto il SICP? 



Gran bel libro!


 



A tutto c'e' un limite: quanto dev'esser grande il secchio!

:-)


 Bel libro! Se non lo hai gia` letto, ti consiglio "Refactoring" di Fowler. E` appena uscita la nuova versione: 
https://www.amazon.co.uk/Refactoring-Improving-Existing-Addison-Wesley-Technology/dp/0134757599/ref=sr_1_1?ie=UTF8&qid=1543666449&sr=8-1&keywords=refactoring






stavo giusto aspettando la versione kindle su amazon :)