Newsgroup: it.lavoro.informatica
Titolo: java vs c++ - output binario (rivisto)

Tempo e' passato dall' ultimo post e nel frattempo qualcuno della banda 
java ha sostenuto che il programma java non e' ottimizzato a dovere.
IL Dott. Gagliardelli ha sostenuto che usare FileWriter/BufferedWriter 
non e' una scelta felice ma occorre usare l'accoppiata 
FileOutputStream/BufferedOutputStream per i file binari.
Inoltre,sempŕe il dottore,ha affermato che la dimensione del buffer e' 
importante per le prestazioni.
In base a queste considerazioni ho rivisto il programma java.
Ora il programma java lavora con buffer size scelto dall'utente (0 per 
il default) e in modalita BufferedOutputStream (B) o modalita 
BufferedWriter (C od altro).
Per  il programma C++ non ho ritenuto farvi modifiche,ritengo che il 
buffer di default sia appropriato.
Nel frattempo approfittando della pausa Natalizia, oltre ad altro, ho 
aggiornato il mio desktop da Ubuntu 14.04 a 18.04 per cui posso usare g++8
Per java rimane sempre jdk8
Ho eseguito una sola passata in quanto le esecuzioni per java sono molte
 
--- java ---
import java.io.*;
 
public class Ounf {
	static final long mb = 1024 * 1024; //1MB
     public static void main(String args[]){
		final long bytes=Long.parseLong(args[0]) * mb;
		final String filename=new String(args[1]);
		final int buffsize=Integer.parseInt(args[2]);
		final boolean binary=args[3].equals("B")  ? true : false;
		try {
			if (binary) {
				FileOutputStream fw=new FileOutputStream(filename);
				BufferedOutputStream bw=buffsize == 0
					? new BufferedOutputStream(fw)
					: new BufferedOutputStream(fw,buffsize)
				;
				long n=bytes;
				while(n-- != 0)
					bw.write(65); //write A
				bw.close();
				fw.close();
			}
			else {
				FileWriter fw = new FileWriter(filename);
				BufferedWriter bw = buffsize == 0
					? new BufferedWriter(fw)
					: new BufferedWriter(fw,buffsize)
				;
				long n=bytes;
				while(n-- != 0)
					bw.write(65); //write A
				bw.close();
				fw.close();
			}
		}
		catch(Exception e) {
			System.out.println(e.getMessage());
			System.exit(1);
		}
     }
}
---
-- c++--
#include <iostream>
#include <fstream>
#include <sstream>
#include <cstdio>
#include <stdexcept>
 
template <typename T>
inline T convert(const char* s) {
	T n;
	std::istringstream os(s);
	os >> n;
	return n;
}
 
 
static constexpr long mb=1024 * 1024; //1MB
 
int main(int argc, char** argv) {
	++argv;
	const auto bytes = convert<long>(*argv++) * mb;
	const std::string filename(*argv++);
	const auto use_stdio=convert<int>(*argv) ? true : false;
	try {
		if (use_stdio) {
			auto f=::fopen(filename.c_str(),"wb");
			if(!f)
				throw std::runtime_error(filename + std::string(": cannot open in 
output"));
			auto  n=bytes;
			while(n--) {
				if (::fputc('b',f) == EOF)  {
					fclose(f);
					throw std::runtime_error(filename + std::string(": write error"));
				}
			}
			fclose(f);
		}
		else {
			std::ofstream f(filename,std::ios::binary);
			if (!f.is_open())
				throw std::runtime_error(filename + std::string(": cannot open in 
output"));
			f.exceptions(std::ofstream::failbit|std::ofstream::badbit);
			auto  n=bytes;
			while(n--)
				f.put('a');
		}
	}
	catch (const std::exception& e) {
		std::cerr << e.what() << std::endl;
		return 1;
	}
}
---
 
 
-- script di lancio --
#!/bin/bash
JAVA_HOME=/opt/jdk1.8.0_192
export PATH="$JAVA_HOME/bin:$PATH"
export LD_LIBRARY_PATH="$JAVA_HOME/lib:$LD_LIBRARY_PATH"
rm -f a.out *.class *.o
javac -version
javac  -O Ounf.java
g++-8 --version
g++-8 -std=c++17 -Wall -O2  ounf.cpp
 
for i in 1
do
	for mod in  B C
	do
		for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
		do
			rm -f tmp*
			sync
			time java Ounf  1024 tmpjava $sz $mod
		done
	done
	rm -f tmp*
	sync
	time ./a.out 1024 tmpios 0
	sync
	rm -f tmp*
	time ./a.out 1024 tmpstdio 1
done
 
-- esecuzione
+ JAVA_HOME=/opt/jdk1.8.0_192
+ export 
PATH=/opt/jdk1.8.0_192/bin:/home/l/xbm52/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/opt/ora11/product/11.2.0/client_2/bin
+ 
PATH=/opt/jdk1.8.0_192/bin:/home/l/xbm52/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/opt/ora11/product/11.2.0/client_2/bin
+ export LD_LIBRARY_PATH=/opt/jdk1.8.0_192/lib:
+ LD_LIBRARY_PATH=/opt/jdk1.8.0_192/lib:
+ rm -f a.out Ounf.class '*.o'
+ javac -version
javac 1.8.0_192
+ javac -O Ounf.java
+ g++-8 --version
g++-8 (Ubuntu 8.2.0-1ubuntu2~18.04) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
+ g++-8 -std=c++17 -Wall -O2 ounf.cpp
+ for i in 1
+ for mod in B C
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava tmpstdio
+ sync
+ java Ounf 1024 tmpjava 0 B
 
real	0m24,246s
user	0m23,804s
sys	0m0,396s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 512 B
 
real	0m27,427s
user	0m24,980s
sys	0m2,461s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 1024 B
 
real	0m26,070s
user	0m24,725s
sys	0m1,340s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 2048 B
 
real	0m25,406s
user	0m24,521s
sys	0m0,868s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 4096 B
 
real	0m25,027s
user	0m24,337s
sys	0m0,651s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 8192 B
 
real	0m24,287s
user	0m23,762s
sys	0m0,432s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 16384 B
 
real	0m24,490s
user	0m24,010s
sys	0m0,492s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 32768 B
 
real	0m24,595s
user	0m24,034s
sys	0m0,477s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 65536 B
 
real	0m24,420s
user	0m24,102s
sys	0m0,328s
+ for mod in B C
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 0 C
 
real	0m24,718s
user	0m24,281s
sys	0m0,476s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 512 C
 
real	0m25,402s
user	0m24,940s
sys	0m0,516s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 1024 C
 
real	0m25,408s
user	0m24,979s
sys	0m0,480s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 2048 C
 
real	0m25,426s
user	0m24,935s
sys	0m0,540s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 4096 C
 
real	0m25,360s
user	0m24,886s
sys	0m0,520s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 8192 C
 
real	0m24,686s
user	0m24,291s
sys	0m0,452s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 16384 C
 
real	0m24,778s
user	0m24,354s
sys	0m0,476s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 32768 C
 
real	0m25,193s
user	0m24,710s
sys	0m0,532s
+ for sz in 0 512 1024 2048 4096 8192 16384 32768 65536
+ rm -f tmpjava
+ sync
+ java Ounf 1024 tmpjava 65536 C
 
real	0m24,770s
user	0m24,386s
sys	0m0,448s
+ rm -f tmpjava
+ sync
+ ./a.out 1024 tmpios 0
 
real	0m8,197s
user	0m7,713s
sys	0m0,463s
+ sync
+ rm -f tmpios
+ ./a.out 1024 tmpstdio 1
 
real	0m3,161s
user	0m2,602s
sys	0m0,551s
 
Si possono fare queste considerazioni.
Non esiste differenza in questo caso tra usare la modalita C o B
La size del buffer per java oltre a 1024 e' irrilevante
Notare il grosso miglioramento delle performance degli stream C passando 
da g++4.8 a g++8 + la  nuova libc.
 
+ ./a.out 1024 tmpstdio 1 <-- vecchia esecuzione con g++4.8
 
real    0m7.461s
user    0m6.740s
sys    0m0.516s
 
 

 Si possono fare queste considerazioni.
 
Le uniche considerazioni che si possono fare e` che sei un cretino che si ostina a fare esperimentini che non servono ad una ceppa.

 LOL :)
 
Ma perche', questa bella assegnazione:
 
final boolean binary=args[3].equals("B")  ? true : false;
 
non ti fa tenerezza?
 
per non parlare del modificatore final ... chissa' a cosa pensava che 
potesse servire?

 potesse servire?
 
Ai fini pratici a niente in questo caso.
Solo abitudine c++ a dichiarare const cio' che non viene modificato
Per grossi programmi puo fare la differenza in manutenibilita
Ma io aspetto una risposta.
 

 
 
Vuoi un consiglio ?
Se devi scrivere un grosso file binario sotto linux e vuoi usare gcc/g++ 
usa c oppure c++ con gli stream c
Per il resto rimando al mittente
 
 

 final boolean binary=args[3].equals("B")  ? true : false;
 
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA

 Vuoi un consiglio ?
 
Da te? Sei serio?

 non ti fa tenerezza?
 
no via, non me ne far vedere più. è un macellaio.
 

 punti tu e` una caccola, non la luna.
 
è un *cane* di programmatore, ogni riga di codice è uno stupro. ma lui 
dice che non bisogna attaccarsi a questo. non è che si sopravvaluta, è 
che ancora nessuno l'ha preso a selciate probabilmente perché ogni volta 
si dilegua prima che gli altri si rendano conto di che razza di macellaio 
sia.


eheh anche senza cercare di leggere il codice, saltano subito agli occhi i commenti, i nome delle variabili, persino il nome della classe principale. 
 
Ounf
 
Ma che cazzo e'??
 
ROTFL

 è un *cane* di programmatore
 
Condivido, e continuo a chiedermi chi e` che gli dia lavoro.

 ROTFL
 
e questa coglionata l'hai vista?
 
final boolean binary=args[3].equals("B")  ? true : false;
 
e dire che l'operatore ternario non è una javata, c'è anche in c/c++.
 
sorvolando sulla worst practice di confrontare una variabile 
evidentemente nullable e una costante stringa chiamando l'equals della 
variabile, quando il contrario costa uguale.
 
lui invita ovviamente a non far caso a questo ma guardare alla sostanza. 
peccato che la cialtronaggine sia sostanza. codice scritto col culo  
produce programmi mal funzionanti. 

 e dire che l'operatore ternario non è una javata, c'è anche in c/c++.
 
Non solo. In C++ ci sono anche true e false, per cui lui un codice del genere lo scriverebbe anche in C++. Non puo` neanche appellarsi alla scusa di non conoscere Java. Vogliamo sorvolare sul fatto che `final` farebbe la differenza, a suo dire, in `grossi programmi`?

 farebbe la differenza, a suo dire, in `grossi programmi`?
 
a dimostrazione che se fa una cosa tutto sommato buona basta fargli 
aprire bocca per capire che è una pura coincidenza.

                  fw.close();
 
non usare lo statement try-with nel 2019 è uno scempio
 
fra l'altro da java8 in poi le API di accesso al filesystem son 
migliorate tanto...

 non usare lo statement try-with nel 2019 è uno scempio
 
eh ma ci vorrebbe un refactory pesante, e poi lui vuole uscire con 
 
System.exit(1); 
 
se no, sono guai.

Il 13/01/19 08:46, Cicap ha scritto:

Avanti ragazzi, migliorate il codice
Fate vedere che sapete fare qualcosa invece che solo sparare puttanate.
 

 Fate vedere che sapete fare qualcosa invece che solo sparare puttanate.
 
Fai vedere *TU* che sai far qualocsa invece che solo sparare puttanate. Rispondi alla domanda che ti ho fatto nell'altro thread. Fai vedere che capisci un minimo di tecnologia, invece che solo sparare puttanate.
 

 Avanti ragazzi, migliorate il codice
 
*++argv per tre volte
 
Risparmi un'istruzione

 
 
Spero non sia vero......;o)
 
-- 
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.

 > SOGEI
 
SOGEI??? Davvero? Questo spiegherebbe molte cose! Nel 2005 la mia azienda fu letteralmente supplicata da SOGEI di prendere in mano il software di Gestione Garanzie - un sistema commissionato dall'UE a tutti i paesi dell'Unione - che avevano iniziato i loro dipendenti, facendo porcate una dopo l'altra. Si erano completamente incartati. Erano arrivati al punto che i tizi di Bruxelles li guardavano in cagnesco, scuotendo la testa e dicendogli che non ce l'avrebbero mai fatta. Preso in mano il progetto, lo riscrivemmo da zero in pochi mesi e l'Italia fu il primo paese a completare i test di conformita` comunitari. Ci forzarono persino ad usare il C e non C++, perche` non erano capaci di leggere codice C++. Che vergogna. Spiegherebbe molte cose.


I limiti di Sogei sono ben visibili nei software che hanno il coraggio 
di distribuire. Inoltre ad oggi abbiamo tempi di risposta, per le 
fatture elettroniche, di 3/4 giorni (GIORNI!!).


 
 
Ti vergogni a farci sapere dove lavori?
 

Il 14/01/19 09:58, Madame Damentami ha scritto:

Non sono in Italia ed ho una piccola azienda di sw
 
 

Il 13/01/19 11:38, Giuspi ha scritto:

Esempio ?
 
 

Il 13/01/19 05:15, rootkit ha scritto:

Risposta non solo a te ma per tutti quelli che sanno solo criticare,ma 
intanto di loro codice o suggerimenti non ho visto una mazza.
Intanto nessuno che sa trovare il problema delle java performance ?
Avanti,fatemi vedere che sapete fare qualcosa invece che sparare puttanate.
Dimostratemi un programma di creazione di un file binario in java che 
possa almeno reggere il confronto con C++.
Strano che non vi siete attaccati al fatto che se il numero di argomenti 
passati e' errato sia il programma java che c++ vanno in crash
oppure che se  un argomento non e' valido si potrebbe avere un bel crash 
od una esecuzione impredicibile.
Continuate pure a guardare il dito che punta alla luna invece che la 
luna stessa.
Un gg se capita faro vedere mio codice (in c++) per la produzione poi 
vediamo se mi dai dello stupratore del codice.
Ma tanto, sono sicuro che non cambierete idea,potrei scrivere il codice 
piu perfetto di questo mondo ma il tutto non cambiera' in quanto siete 
pure faziosi.
 
 

 Risposta non solo a te ma per tutti[...]
 
Non c'e` nessuna faziosita`. Non sei cosi` importante. Sei solo un colossale incompetente, un arrogante, viscido, presuntuoso paraculo, vile e bugiardo. Ti sei messo in testa di confrontare un linguaggio C++ con un linguaggio che NON conosci, prendendo per culo, parlando di bande, giocando a fare la vittima... poi starnazzi "fatemi vedere!! migliorate il codice!!"? 
I tuoi esperimentini idioti non hanno ALCUN valore; non meritano nessun commento; non meritano nessun suggerimento. Se vuoi lezioni di programmazione, fai un corso. Io non devo di certo dar conto a te, un colossale idiota incompetente, di cio` che so o non so fare.
Fatti un favore e TACI. 

 Non sono in Italia ed ho una piccola azienda di sw
 
Non ti sbilanci, eh? 
Specifica che tipo di software sviluppi e con quali tecnologia. O ti vergogni anche di questo?
 

Il 14/01/19 14:41, 4ndre4 ha scritto:

tutto quello che si trova e con qualunque linguaggio capiti
Ma poi,saranno anche affari miei.
Fammi un favore,non rompere i marroni,non devo certo dare spiegazioni su 
cosa faccio o non faccio.
Ho gia scritto sin troppo.
 
 

 Ho gia scritto sin troppo.
 
L'unica cosa giusta che tu abbia mai scritto. Sarebbe bene che smettessi.
 

 fatture elettroniche, di 3/4 giorni (GIORNI!!).
 
LOL :)