Newsgroup: it.lavoro.informatica
Titolo: java vs c++ - threads - creazione e distruzione senza pool thread

 
Questo test vuole misurare il tempo totale di creazione e distruziome 
dei threads senza un pool thread (oggetto di un prossimo test).
 
I thread main  dei due programmi creano un certo numero di 
threads,numero impostabile da command line e come nelle corse 
automobiliste i thread rimangono fermi al nastro di partenza.
Alla fine della creazione di tutti i thread il main  abbassa la bandiera 
dello start ed attende la fine.
In java l'attesa della fine da parte del main e' automatica,in c++ no 
quindi occorre codice aggiuntivo per l'attesa.
La misurazione e' fatta sul mio desktop (Ubuntu 14.04) con cpu a 4core 1 
thread per core
Per java il jdk1.8 e per c++ il g++ 4.8 che comunque supporta c++11
Per la creazione dei thread mi sono avvalso di componenti messi a 
disposizione dallo std dei due linguaggi e per  non influire sulle 
misurazioni il codice di esecuzione dei thread e' praticamente vuoto 
(solo il codice per gestire le attese)
Per il test vengono creati 30000 thread
 
//th.java
import java.util.concurrent.CountDownLatch;
 
class Th {
 
	static CountDownLatch latch = new CountDownLatch(1);
 
	static class MyRunnable  implements Runnable  {
         public void run()  {
			try {
				latch.await(); //attende sul nastro di partenza
			}
			catch(InterruptedException e) {
				System.out.print("InterruptedException");
			}
		}
	};
 
	public static void main(String[] args)  {
		long n=Long.parseLong(args[0]);
		while(n-- > 0) //crea i threads
			new Thread(new MyRunnable()).start();
		latch.countDown(); //fa partire i threads creati
	}
 
};
 
 
//th.cpp
#include <iostream>
#include <sstream>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <atomic>
 
#ifdef DISPLAY
static std::mutex g_display_mutex;
#endif
 
using mutex_t=std::mutex;
using cv_t=std::condition_variable;
using atomic_t=std::atomic<int>;
using thread_t=std::thread;
using lock_mutex_t=std::unique_lock<std::mutex>;
 
struct start {// per mettere i thread sul nastro di partenza
	mutex_t mutex;
	cv_t cv={};
	bool ready={};
};
 
struct wait_all { // per sapere quando tutti i thread hanno finito
	atomic_t counter={};
	mutex_t mutex;
	cv_t cv={};
};
 
static start g_start;
static wait_all g_wait_all;
 
class myrunnable {
	public:
		myrunnable() {}
		void operator()();
};
 
void myrunnable::operator()() {
	++g_wait_all.counter; //incrementa il numero di threads attivi
#ifdef DISPLAY
	g_display_mutex.lock();
	std::cout << "thread wait: " << std::this_thread::get_id() << std::endl;
	g_display_mutex.unlock();
#endif
	{ //il thread attende sul nastro di partenza
		lock_mutex_t lck(g_start.mutex);
		g_start.cv.wait(lck, []{return g_start.ready;});
		lck.unlock();
	}
#ifdef DISPLAY
	g_display_mutex.lock();
	std::cout << "start thread: " << std::this_thread::get_id() << std::endl;
	g_display_mutex.unlock();
#endif
 
	{ //fine - diminuisce il numero di thread e notifica al main
		--g_wait_all.counter;
		g_wait_all.cv.notify_all();
	}
}
 
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 threads_number = convert<std::size_t>(*argv);
	while (threads_number--)
		thread_t(myrunnable{}).detach();
 
#ifdef DISPLAY
	g_display_mutex.lock();
	std::cout << "START THREADS" << std::endl;
	g_display_mutex.unlock();
#endif
 
	{ //fa partire i threads
		g_start.ready = true;
		g_start.cv.notify_all();
	}
	{ //attende che tutti i threads finiscono
		lock_mutex_t lock(g_wait_all.mutex);
		g_wait_all.cv.wait(lock,[](){ return !g_wait_all.counter; });
	}
}
 
 
 
//th.sh
#!/bin/sh
JAVA_HOME=/opt/jdk1.8.0_192
PATH="$JAVA_HOME/bin:$PATH"
LD_LIBRARY_PATH="$JAVA_HOME/lib:$LD_LIBRARY_PATH"
rm -f a.out *.class *.o
javac -version
javac  -O th.java
g++ --version
g++ -std=c++11 -Wall -O2  -pthread th.cpp
 
for x in 1 2 3
do
	time java Th "$1"
	time ./a.out "$1"
done
 
 
//partenza
bash -x ./th.sh 30000
 
+ JAVA_HOME=/opt/jdk1.8.0_192
+ PATH=/opt/jdk1.8.0_192/bin:...
+ LD_LIBRARY_PATH=/opt/jdk1.8.0_192/lib:
+ rm -f a.out Th.class 'Th$MyRunnable.class' '*.o'
+ javac -version
javac 1.8.0_192
+ javac -O th.java
+ g++ --version
g++-4.8.real (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4
Copyright (C) 2013 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++ -std=c++11 -Wall -O2 -pthread th.cpp
+ for x in 1 2 3
+ java Th 30000
 
real	0m36.216s
user	0m10.460s
sys	0m0.768s
+ ./a.out 30000
 
real	0m0.630s
user	0m0.104s
sys	0m1.112s
+ for x in 1 2 3
+ java Th 30000
 
real	0m35.707s
user	0m10.272s
sys	0m0.732s
+ ./a.out 30000
 
real	0m0.641s
user	0m0.124s
sys	0m1.148s
+ for x in 1 2 3
+ java Th 30000
 
real	0m36.170s
user	0m10.408s
sys	0m0.736s
+ ./a.out 30000
 
real	0m0.640s
user	0m0.144s
sys	0m1.056s
 
 

 dei threads senza un pool thread (oggetto di un prossimo test).
 
Un test che, come al solito, non serve ad un beneamato cazzo. In Java, poi, si usano gli executors. 
 
http://kth.diva-portal.org/smash/get/diva2:648395/FULLTEXT01.pdf
 
 
"5.2 Summary
The programming language C as well as Java dominated the tests in terms of execution time while C++ and C dominated the overall speedup gained. The granularity tests showed that Java could handle small tasks while still keeping its overall speedup in comparison to the other three languages. In all of the tests the programming language C# performed the worst in terms of execution time, overall speedup and the amount of granularity the language could handle before the overhead of the tasks took over.
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."
 
Smettila di darti zappate sui piedi.

Il 09/12/18 11:39, 4ndre4 ha scritto:

la scritta "senza pool thread" ti dice niente ?
Come al solito non leggi mai bene quello che scrivo
 
 

 Come al solito non leggi mai bene quello che scrivo
 
Come al solito non capisci un cazzo: la "scritta" (?) "Un test che, come al solito, non serve ad un beneamato cazzo" non ti dice niente? A cosa serve creare thread a quel modo? A cosa serve testare qualcosa che nella pratica nessuno farebbe mai? Sei veramente un cretino.

Il 09/12/18 12:12, 4ndre4 ha scritto:

E si,quando java vince va tutto bene
Comunque se non ti piace sono affari tuoi e vatti a leggere il test con 
il pool cosi mi faccio 4 risate su cosa ti inventerai questa volta.

 il pool cosi mi faccio 4 risate su cosa ti inventerai questa volta.
 
http://kth.diva-portal.org/smash/get/diva2:648395/FULLTEXT01.pdf
 
 
"5.2 Summary 
The programming language C as well as Java dominated the tests in terms of execution time while C++ and C dominated the overall speedup gained. The granularity tests showed that Java could handle small tasks while still keeping its overall speedup in comparison to the other three languages. In all of the tests the programming language C# performed the worst in terms of execution time, overall speedup and the amount of granularity the language could handle before the overhead of the tasks took over. 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." 
 
IMBECILLE.

Il 09/12/18 13:30, 4ndre4 ha scritto:

Tu non hai capito una cosa:
NON ME NE FREGA NIENTE DI DOVE VAI A PRENDERE I TUOI DUBBI POST
I fatti,io faccio parlare i fatti.
Punto e basta
 

 E si,quando java vince va tutto bene 
 
ogni volta che java vince c'è un cretino a caso fra enoquick e delta11 
che muore.

 Punto e basta
 
I fatti sono quelli che ti sono stati messi davanti piu` e piu` volte. Fatti che ovviamente ignori perche` ti fa comodo. "Dubbi post"? Non conosci neanche l'italiano. Come qualcun altro ti ha ben definito, sei un sesquipedale IDIOTA. Perche` i benchmark zoppi di una scoreggia informatica come te dovrebbero essere piu` importanti di quelli di qualunque altro, specie di gente che ti passa sopra come uno schiacciasassi, e` qualcosa a cui puo` credere solo tua madre. Forse neanche lei.


Il 09/12/18 13:59, rootkit ha scritto:

E quando c++ vince chi e' che si suicida per la vergogna ?
 
 

 E quando c++ 
 
lo stesso cretino si masturba selvaggiamente.
 
 

 E quando c++ vince chi e' che si suicida per la vergogna ?
 
Nessuno. Perche` nessuno ha la pretesa che C++ e Java siano mutualmente esclusivi, ed uno debba necessariamente vincere sull'altro. E` questo il punto che non comprendi da sempre. Tu pensi ai tuoi interlocutori come dei faziosi integralisti perche` questo e` cio` che sei tu. Al contrario di te, invece, i tuoi interlocutori qui dentro, quelli che tu ritieni appartenere ad una "banda", tanto per legittimarti il ruolo di vittima, hanno un cervello e poco per cui vergognarsi.