Multithreaded Applications

[DarthMoul]

Έχω κάνει δύο προγραμματάκια που υπολογίζουν το pi με σειρά Taylor. Το ένα είναι single threaded και το άλλο multithreaded. Το έκανα για να δοκιμάσω πόσο αποδίδει το Hyperthreading στην περίπτωση που χρησιμοποιηθεί από την εφαρμογή.
Το μηχάνημα της δοκιμής θα είναι ένα Quad Xeon MP. Αυτό σημαίνει ότι θα έχουμε 8 virtual CPUS. Το cpuinfo μας δίνει τα παρακάτω:

$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) MP CPU 3.00GHz
stepping : 6
cpu MHz : 2990.418
cache size : 512 KB
physical id : 0
siblings : 2
runqueue : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 5963.77

processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) MP CPU 3.00GHz
stepping : 6
cpu MHz : 2990.418
cache size : 512 KB
physical id : 1
siblings : 2
runqueue : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 5976.88

processor : 2
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) MP CPU 3.00GHz
stepping : 6
cpu MHz : 2990.418
cache size : 512 KB
physical id : 2
siblings : 2
runqueue : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 5976.88

processor : 3
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) MP CPU 3.00GHz
stepping : 6
cpu MHz : 2990.418
cache size : 512 KB
physical id : 3
siblings : 2
runqueue : 3
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 5976.88

processor : 4
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) MP CPU 3.00GHz
stepping : 6
cpu MHz : 2990.418
cache size : 512 KB
physical id : 0
siblings : 2
runqueue : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 5976.88

processor : 5
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) MP CPU 3.00GHz
stepping : 6
cpu MHz : 2990.418
cache size : 512 KB
physical id : 1
siblings : 2
runqueue : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 5976.88

processor : 6
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) MP CPU 3.00GHz
stepping : 6
cpu MHz : 2990.418
cache size : 512 KB
physical id : 2
siblings : 2
runqueue : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 5976.88

processor : 7
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) MP CPU 3.00GHz
stepping : 6
cpu MHz : 2990.418
cache size : 512 KB
physical id : 3
siblings : 2
runqueue : 3
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 5976.88

[DarthMoul]

Εδώ είναι η single threaded έκδοση του προγράμματος. Από το command line δέχεται μία αριθμητική παράμετρο που είναι ο αριθμός των δεκαδικών ψηφίων που θέλουμε να υπολογίσει.

#include <stdio.h>
#include <stdlib.h>

static long double ITER = 1;

long double pitest()
{
long double d, tsum1 = 0, tsum2 = 0;
for (d = 1; d < ITER; d = d + 4)
{
tsum1 = tsum1 + (1 / d);
tsum2 = tsum2 - (1 / (d + 2));
}
return (tsum1 + tsum2) * 4;
}

main(int argc, char *argv[])
{
int prec, i;
char fmt[60];
prec = atoi(argv[1]);
if (prec < 3)
prec = 3;
for (i = 0; i < prec; i++)
ITER *= 10;
ITER = ITER * 2 + 1;
sprintf(fmt,"\n %d digits precision Pi:%%1.%dLg\n",prec,prec + 1);
printf(fmt, pitest());
}

[DarthMoul]

Εδώ είναι ή multithreaded έκδοση. Δέχεται δύο αριθμητικές παραμέτρους. Η μία είναι ο αριθμός των δεκαδικών ψηφίων που θα υπολογίσει και η δεύτερη ο αριθμός των threads που θα ανοίξει:

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

#define MAX_THREADS 16

static long double ITER, sum[MAX_THREADS];
static int threads;

void pitest(int thread)
{
long double start, stop, d, tsum1 = 0, tsum2 = 0;
start = ((ITER - 1) / threads) * thread + 1;
stop = start + ((ITER - 1) / threads);

printf("\n Thread #%d start from: %10.0Lf ends to: %10.0Lf", thread, start, stop - 1);
fflush(stdout);

for (d = start; d < stop; d = d + 4)
{
tsum1 = tsum1 + (1 / d);
tsum2 = tsum2 - (1 / (d + 2));
}
sum[thread] = tsum1 + tsum2;
pthread_exit(NULL);
}

void *thread_start(void *nthread)
{
int thread;
thread = *((int *) nthread);
pitest(thread);
}

main(int argc, char *argv[])
{
pthread_t th[MAX_THREADS];
long double pi = 0;
int prec, i, nthread[MAX_THREADS];
char fmt[60];

prec = atoi(argv[1]);
threads = atoi(argv[2]);

if (prec < 3)
prec = 3;

if (threads < 1)
threads = 1;
else if (threads > MAX_THREADS)
threads = MAX_THREADS;

ITER = 1;
for (i = 0; i < prec; i++)
ITER *= 10;
ITER = ITER * 2 + 1;

for (i=0; i < threads; i++)
{
nthread[i] = i;
pthread_create(&th[i],NULL,thread_start, &nthread[i]);
}

for (i=0; i < threads; i++)
pthread_join(th[i], NULL);

for (i=0; i < threads; i++)
pi = pi + sum[i];

pi = pi * 4;
sprintf(fmt,"\n %d digits precision Pi:%%1.%dLg\n",prec,prec + 1);
printf(fmt, pi);
}

[DarthMoul]

Εδώ μετράμε την single threaded έκδοση για 9 δεκαδικά ψηφία:

$ cc -O2 pitest.c -o pitest
$ time ./pitest 9

9 digits precision Pi:3.141592653
14.390u 0.000s 0:14.39 100.0% 0+0k 0+0io 90pf+0w

14.39 seconds το αποτέλεσμα.

[DarthMoul]

Εδώ μετράμε την multithreaded για 9 ψηφία και 4 threads:

$ cc -O2 -D_REENTRANT pitest-mt.c -o pitest-mt -lpthread
$ time ./pitest-mt 9 4

Thread #0 start from: 1 ends to: 500000000
Thread #1 start from: 500000001 ends to: 1000000000
Thread #3 start from: 1500000001 ends to: 2000000000
Thread #2 start from: 1000000001 ends to: 1500000000
9 digits precision Pi:3.141592653
17.380u 0.000s 0:05.08 342.1% 0+0k 0+0io 143pf+0w

5.08 seconds

[DarthMoul]

Εδώ μετράμε την multithreaded για 9 ψηφία και 8 threads:

$ time ./pitest-mt 9 8

Thread #0 start from: 1 ends to: 250000000
Thread #2 start from: 500000001 ends to: 750000000
Thread #3 start from: 750000001 ends to: 1000000000
Thread #1 start from: 250000001 ends to: 500000000
Thread #4 start from: 1000000001 ends to: 1250000000
Thread #5 start from: 1250000001 ends to: 1500000000
Thread #6 start from: 1500000001 ends to: 1750000000
Thread #7 start from: 1750000001 ends to: 2000000000
9 digits precision Pi:3.141592653
28.930u 0.000s 0:03.63 796.9% 0+0k 0+0io 143pf+0w

3.63 seconds

[DarthMoul]

Και εδώ άλλη μία μέτρηση με 16 threads:

$ time ./pitest-mt 9 16

Thread #0 start from: 1 ends to: 125000000
Thread #1 start from: 125000001 ends to: 250000000
Thread #2 start from: 250000001 ends to: 375000000
Thread #3 start from: 375000001 ends to: 500000000
Thread #4 start from: 500000001 ends to: 625000000
Thread #5 start from: 625000001 ends to: 750000000
Thread #6 start from: 750000001 ends to: 875000000
Thread #7 start from: 875000001 ends to: 1000000000
Thread #8 start from: 1000000001 ends to: 1125000000
Thread #9 start from: 1125000001 ends to: 1250000000
Thread #10 start from: 1250000001 ends to: 1375000000
Thread #11 start from: 1375000001 ends to: 1500000000
Thread #12 start from: 1500000001 ends to: 1625000000
Thread #13 start from: 1625000001 ends to: 1750000000
Thread #14 start from: 1750000001 ends to: 1875000000
Thread #15 start from: 1875000001 ends to: 2000000000
9 digits precision Pi:3.141592653
28.530u 0.010s 0:03.70 771.3% 0+0k 0+0io 143pf+0w

3.70 seconds. Σχεδόν ίδια και πριν μια και δεν υπάρχουν άλλες διαθέσιμες CPUs ούτε πραγματικές, ούτε virtual.

Ακούω τα σχόλια σας.

[DarthMoul]

Μια και δεν σχολιάζει κανείς, θα σχολιάσω εγώ :045:

Το ζουμί όλου του παραπάνω είναι στα 4 και στα 8 threads. Εκεί βλέπουμε την ώθηση που μπορεί να δώσει το Hyperthreading στην εφαρμογή μας.
Έχουμε 5.08 sec στα 4 threads και 3.63 στα 8 threads. Συνεπώς:

3.63 / 5.08 * 100 = 71% του αρχικού χρόνου. Άρα το HyperThreading μας έδωσε ώθηση 29%. Όταν λοιπόν τρέχουμε μία single threaded εφαρμογή η οποία χρειάζεται t χρόνο για να ολοκληρωθεί, για να βρούμε πόσο χρόνο θα χρειαζόμασταν αν ήταν multithreaded θα πολλαπλασιάσουμε το t με το 0.71.
Έτσι βρίσκουμε ποιά είναι η πραγματική επίδοση του p4 στο συγκεκριμένο task,
αν τον εκμεταλευτούμε πλήρως.

Έχω κάνει άπειρες δοκιμές μέχρι τώρα και οι συντελεστές που έχω βρεί είναι από 0.69 ο μικρότερος, μέχρι 0.73 ο μεγαλύτερος. Συνεπώς το 0.71 που βρήκαμε εδώ νομίζω πως μπορούμε να το θεωρήσουμε ασφαλές.

[john_dr]

Ναι παραείναι πανεπιστημιακού επιπέδου για εμάς αυτά!!!
Πραγματικά ενδιαφέρον και προτείνω και σε άλλους που ίσως κάνανε το ίδιο με μένα πριν ( είδαν το thread τρόμαξαν με το κατεβατό και έκλεισαν το παράθυρο ) να ρίξουν μια ματιά.

Πάντως Θα είχε ενδιαφέρον να δούμε αν θα είχε διαφορές με 4 threads και το ΗΤ απενεργοποιημένο σε σχέση με 4 threads και το ΗΤ ενεργοποιημένο.
Μάλλον όμως θα είναι παραπλήσια τα αποτελέσματα. Απλά αναρωτιέμαι αν το λειτουργικό στην περίπτωση των 4 threads αδυνατώντας να διακρίνει ποια είναι πραγματική cpu και ποια virtual, μήπως τελικά χρησιμοποιεί τις 2 REAL cpus.
Εννοώ δηλαδή μήπως χρησιμοποιεί τελικά μόνο τα 2 μόνο chips = 4 cpus.
Αν το λειτουργικό δεν μπορεί να διακρίνει τις virtual από τις real cpus όταν θα έρθουν οι dual core πυρήνες θα γίνει πολύ λόγος για το αν τελικά το ΗΤ είναι πάντα 100% ωφέλιμο.

[Astakos]

Και ανησυχουσα μηπως δεν σε εβρισκα εδω....
Η intel ποση αυξηση στην αποδοση λεει οτι εχει σε multithreaded εφαρμογες?
Και κατι ακομα.Που το βρηκες το quad Xeon?Παιζει να εχεις και quad itanium2?

[DarthMoul]

Ναι παραείναι πανεπιστημιακού επιπέδου για εμάς αυτά!!!
Πραγματικά ενδιαφέρον και προτείνω και σε άλλους που ίσως κάνανε το ίδιο με μένα πριν ( είδαν το thread τρόμαξαν με το κατεβατό και έκλεισαν το παράθυρο ) να ρίξουν μια ματιά.

Πάντως Θα είχε ενδιαφέρον να δούμε αν θα είχε διαφορές με 4 threads και το ΗΤ απενεργοποιημένο σε σχέση με 4 threads και το ΗΤ ενεργοποιημένο.
Μάλλον όμως θα είναι παραπλήσια τα αποτελέσματα. Απλά αναρωτιέμαι αν το λειτουργικό στην περίπτωση των 4 threads αδυνατώντας να διακρίνει ποια είναι πραγματική cpu και ποια virtual, μήπως τελικά χρησιμοποιεί τις 2 REAL cpus.
Εννοώ δηλαδή μήπως χρησιμοποιεί τελικά μόνο τα 2 μόνο chips = 4 cpus.
Αν το λειτουργικό δεν μπορεί να διακρίνει τις virtual από τις real cpus όταν θα έρθουν οι dual core πυρήνες θα γίνει πολύ λόγος για το αν τελικά το ΗΤ είναι πάντα 100% ωφέλιμο.
Το λειτουργικό θα κατευθύνει το task, στην cpu πραγματική ή virtual, που έχει το μικρότερο βάρος. Το linux από τον kernel 2.4 και μετά είναι πλήρως ενημερωμένο για να δίνει προτεραιότητα στην πραγματική CPU. Τα windows δεν μας δίνουν sources και πληροφορίες αλλά έχω παρατηρήσει ότι κάνουν ακριβώς το ίδιο (τα XP).

Με το ΗΤ απενεργοποιημένο κερδίζεις 10 - 15%. Παραπάνω δεν έχει τύχει να δω, ότι και αν δοκίμασα.

[DarthMoul]

Και ανησυχουσα μηπως δεν σε εβρισκα εδω....
Η intel ποση αυξηση στην αποδοση λεει οτι εχει σε multithreaded εφαρμογες?
Και κατι ακομα.Που το βρηκες το quad Xeon?Παιζει να εχεις και quad itanium2?
Να είσαι σίγουρος ότι δεν το βρήκα σπίτι μου :002:
Έχω dual Itanium1 και πριν λίγες βδομάδες είχα dual Itanium2@1.4 αλλά τελείωσε η περίοδος δοκιμής και μου το πήραν :009:

[DarthMoul]

Θα κάνουμε δοκιμή με τα ίδια προγράμματα σε αυτό το σύστημα:

~/pitest-alpha$ psrinfo -v
Status of processor 0 as of: 08/01/04 08:02:12
Processor has been on-line since 04/05/2004 08:33:31
The alpha EV6.8CB (21264C) processor operates at 1000 MHz,
has a cache size of 8388608 bytes,
and has an alpha internal floating point processor.

Status of processor 1 as of: 08/01/04 08:02:12
Processor has been on-line since 04/05/2004 08:33:31
The alpha EV6.8CB (21264C) processor operates at 1000 MHz,
has a cache size of 8388608 bytes,
and has an alpha internal floating point processor.

Status of processor 2 as of: 08/01/04 08:02:12
Processor has been on-line since 04/05/2004 08:33:31
The alpha EV6.8CB (21264C) processor operates at 1000 MHz,
has a cache size of 8388608 bytes,
and has an alpha internal floating point processor.

Status of processor 3 as of: 08/01/04 08:02:12
Processor has been on-line since 04/05/2004 08:33:31
The alpha EV6.8CB (21264C) processor operates at 1000 MHz,
has a cache size of 8388608 bytes,
and has an alpha internal floating point processor.

[DarthMoul]

Αυτός είναι ένας Quad Alpha με ev68 core στο 1 GHz :055: :055: :055:
H έρευνα και η ανάπτυξη του έχει σταματήσει πλήρως από τα μέσα του 1998, και έχει ανακοινωθεί end of life για το 2006, από το 2001.
Είναι 6 χρόνια παλιότερος από τον Xeon και έχει το 1/3 της συχνότητας του.
Το λειτουργικό είναι Tru64 unix.

[DarthMoul]

Η single threaded έκδοση πρώτα και πάντα με 9 ψηφία:

~/pitest-alpha$ cc -O3 -arch host -fast pitest.c -o pitest
~/pitest-alpha$ time ./pitest 9

9 digits precision Pi:3.141592653

real 0m12.026s
user 0m12.014s
sys 0m0.002s

12.02 seconds.
O Xeon είχε 14.39

[DarthMoul]

Εδώ η multithreaded έκδοση με 4 threads όπως πριν:

~/pitest-alpha$ cc -O3 -fast -arch host -D_REENTANT -pthread pitest-mt.c -o pitest-mt
~/pitest-alpha$ time ./pitest-mt 9 4

Thread #0 start from: 1 ends to: 500000000
Thread #1 start from: 500000001 ends to: 1000000000
Thread #3 start from: 1500000001 ends to: 2000000000
Thread #2 start from: 1000000001 ends to: 1500000000
9 digits precision Pi:3.141592653

real 0m4.103s
user 0m12.036s
sys 0m0.004s

4.10 seconds.
Ο Xeon είχε 5.08.

[DarthMoul]

Και εδώ τα 8 threads:

~/pitest-alpha$ time ./pitest-mt 9 8

Thread #0 start from: 1 ends to: 250000000
Thread #1 start from: 250000001 ends to: 500000000
Thread #3 start from: 750000001 ends to: 1000000000
Thread #2 start from: 500000001 ends to: 750000000
Thread #4 start from: 1000000001 ends to: 1250000000
Thread #5 start from: 1250000001 ends to: 1500000000
Thread #6 start from: 1500000001 ends to: 1750000000
Thread #7 start from: 1750000001 ends to: 2000000000
9 digits precision Pi:3.141592653

real 0m4.082s
user 0m12.036s
sys 0m0.005s

4.08 seconds. Σχεδόν τα ίδια όπως και πριν μια και το σύστημα έχει μόνο 4 cpus και δεν είναι SMT όπως ο Xeon
Ο Xeon είχε κάνει 3.63 seconds.

[DarthMoul]

Νομίζω το παραπάνω μας δείχνει και τι τεχνολογία μας πουλάνε πανάκριβα. O Xeon MP@3.0 Ghz κυκλοφόρησε πριν 3-4 μήνες. Ο Alpha πριν 6 χρόνια. Λυπάμαι πολύ που το λέω, αλλά η Intel και η AMD δεν παράγουν τεχνολογία. Κάνουν κάποιες ελαφριές τεχνικές παρεμβάσεις για να την φέρουν στα μέτρα της αγοράς, την συσκευάζουν και την πουλάνε στα περίπτερα. Νομίζω πως είναι αρκετή απόδειξη για να λήξουν οριστικά threads με θέμα Intel vs AMD. Και οι δύο ψάχνουν κορόϊδα για να αδειάσουν πορτοφόλια. Δεν είναι τυχαίο άλλωστε που στην x86 αρχιτεκτονική, καμμία από τις δύο δεν έχει να παρουσιάσει ούτε μία καινοτομία. Νομίζω πως το pctechnology είναι ευκαιρία για όλους μας να μάθουμε, ώστε και καλύτερες αγορές να κάνουμε ανάλογα με τις ανάγκες μας, και να αξιοποιήσουμε καλύτερα τις μηχανές που έχουμε και να περάσουμε καλά που είναι το σημαντικότερο, χωρίς τριβές και λογομαχίες.

[john_dr]

Αυτό επιβεβαιώνει και κάτι που λέω. Ότι είναι πολύ παράξενο ότι ούτε η Intel ούτε η AMD δεν έχουν βγάλει έναν επεξεργαστή που να πατάει τον αντίστοιχο της άλλης εταιρίας κάτω. Ακόμα και αν είχαν χαλαρά το πάνω χέρι μια δεδομένη χρονική στιγμή. Κάποια στιγμή η Intel και τώρα η AMD. Τα ίδια και στις κάρτες γραφικών. Και εκεί όλος τυχαίως το Χ800 και η 6800 παίζουν περίπου στα ίδια επίπεδα.
Είναι φανερό ότι οι εταιρίες αποφασίζουν από κοινού τι θα βγάλουν έξω όταν είναι μόνο δύο και δεν απειλούνται από άλλους. Οι Χ800 και 6800 άλλωστε δεν νομίζω να είχαν δει το φως της μέρας σε τέτοιου είδους υλοποιήσεις αν δεν ήταν να θάψουν τις S3 και SiS με τα Deltachrome και Volari. Θα ήταν μεν ποιο γρήγορες από τις υπάρχουσες κάρτες γραφικών, αλλά όχι στον βαθμό που είναι σήμερα.

Ότι μας δίνουν μας το δίνουν με το σταγονόμετρο και εμείς μαλώνουμε για το ποια είναι η καλύτερη. Χαζοί με περικεφαλαία.

[DVD_GR]

η vector processing unit των alpha ειναι κατα ενα μερος παρουσα απο τους πρωτους αθλονες μετα απο συμφωνια των εταιρειων καμποσα χρονια πριν,εξου και το ισχυρο fpu τους σε σχεση τοτε με τον ανταγωνισμο.

[DarthMoul]

η vector processing unit των alpha ειναι κατα ενα μερος παρουσα απο τους πρωτους αθλονες μετα απο συμφωνια των εταιρειων καμποσα χρονια πριν,εξου και το ισχυρο fpu τους σε σχεση τοτε με τον ανταγωνισμο.Μου φαίνεται δύσκολο αυτό που λες. Η ταχύτητα στην FPU του Alpha οφείλετε στην απάλειψη των IEEE underflow checks μέχρι και τον ev56 πυρήνα και στην δυναμική ενεργοποίηση τους με έναν flag register από τον ev6 μέχρι και τον ev7z. Τουλάχιστον έτσι γράφει το "The Alpha Architecture Handbook".
Δηλαδή καμμία σχέση με τον Athlon. Ο Athlon πήρε από τον ev6 το socket A και από τον ev7 το IO7 το οποίο πετσόκοψε και μετονόμασε σε Hypertransport.

[Zeus]

πολυ ενδιαφέρον Post.
με βοήθησε να καταλάβω πως δουλεύουν και τα Threads στον προγραμματισμό. :023:

[hyperspaced]

Νομίζω το παραπάνω μας δείχνει και τι τεχνολογία μας πουλάνε πανάκριβα. O Xeon MP@3.0 Ghz κυκλοφόρησε πριν 3-4 μήνες. Ο Alpha πριν 6 χρόνια. Λυπάμαι πολύ που το λέω, αλλά η Intel και η AMD δεν παράγουν τεχνολογία. Κάνουν κάποιες ελαφριές τεχνικές παρεμβάσεις για να την φέρουν στα μέτρα της αγοράς, την συσκευάζουν και την πουλάνε στα περίπτερα.


Διαφωνώ μαζί σου. Κυκλωματικά, η ύπαρξη του Hyperthreading στοιχίζει και σε έρευνα και σε ανάπτυξη. Οι σύγχρονες απαιτήσεις στο λειτουργικό είναι να τρέχουν πολλές εφαρμογές παράλληλα. Επομένως, ένα κλασσικό σύστημα με έναν επεξεργαστή που δίνει 100% CPU load όταν έχουμε dependency στην εκτέλεση του μικροκώδικα (με συνέπεια οι άλλες εφαρμογές να 'κρεμάνε') δεν είναι λειτουργικό.

Με το Hyperthreading το σύστημα γίνεται αποδοτικότερο (σημ. όχι απαραίτητα γρηγορότερο). Αυτό πληρώνεις.

[DarthMoul]

Διαφωνώ μαζί σου. Κυκλωματικά, η ύπαρξη του Hyperthreading στοιχίζει και σε έρευνα και σε ανάπτυξη. Οι σύγχρονες απαιτήσεις στο λειτουργικό είναι να τρέχουν πολλές εφαρμογές παράλληλα. Επομένως, ένα κλασσικό σύστημα με έναν επεξεργαστή που δίνει 100% CPU load όταν έχουμε dependency στην εκτέλεση του μικροκώδικα (με συνέπεια οι άλλες εφαρμογές να 'κρεμάνε') δεν είναι λειτουργικό.

Με το Hyperthreading το σύστημα γίνεται αποδοτικότερο (σημ. όχι απαραίτητα γρηγορότερο). Αυτό πληρώνεις.
Μάλλον δεν κατάλαβες το πνεύμα μου. Το σχόλιο μου δεν έχει να κάνει με την απόδοση του SMT. Σε αυτό που γράφεις συμφωνώ 100% μαζί σου και αν ψάξεις λιγάκι παλαιότερα σχόλια μου θα το δεις.

[nivas]

Νομίζω το παραπάνω μας δείχνει και τι τεχνολογία μας πουλάνε πανάκριβα. O Xeon MP@3.0 Ghz κυκλοφόρησε πριν 3-4 μήνες. Ο Alpha πριν 6 χρόνια. ......
Έχω μία αντίρηση σχετικά με το είδος του benchmarking και τα συμπεράσματα που βγάζεις. Το benchmark το οποίο τρέχεις είναι pi και καθαρά μπορούσες να πεις ότι απευθήνονται σε συστήματα τα οποία χρησιμοποιούνται για εραυνητικούς σκοπούς και μάλιστα πολύ εξειδηκευμένους. Με αυτό το benchmark λοιπόν προσπαθείς να βγάλεις συμπεράσματα σχετικά με το πως αποδίδουν δυο επεξεργαστές στο πειβάλον του μέσου χρήστη???
Η προσωπική μου εμπειρία λέει ότι το CAD tool το οποίο χρησιμοποιώ στον sunblade 2000 με τον UltraSPARC III Cu 900 MHz, αποδίδει το ίδιο με ένα Linuxaki στον φτωχό P4 2.66 (από τους χειτότερους που έχουν βγει κατά την άποψή μου). Τώρα αν το πας σε εξάρτηση από τα περιφεριακά (HD, graphics, etc...) και άλλα τέτοια κοίτα τα specs του Sunblade.

[DarthMoul]

Έχω μία αντίρηση σχετικά με το είδος του benchmarking και τα συμπεράσματα που βγάζεις. Το benchmark το οποίο τρέχεις είναι pi και καθαρά μπορούσες να πεις ότι απευθήνονται σε συστήματα τα οποία χρησιμοποιούνται για εραυνητικούς σκοπούς και μάλιστα πολύ εξειδηκευμένους. Με αυτό το benchmark λοιπόν προσπαθείς να βγάλεις συμπεράσματα σχετικά με το πως αποδίδουν δυο επεξεργαστές στο πειβάλον του μέσου χρήστη???
Η προσωπική μου εμπειρία λέει ότι το CAD tool το οποίο χρησιμοποιώ στον sunblade 2000 με τον UltraSPARC III Cu 900 MHz, αποδίδει το ίδιο με ένα Linuxaki στον φτωχό P4 2.66 (από τους χειτότερους που έχουν βγει κατά την άποψή μου). Τώρα αν το πας σε εξάρτηση από τα περιφεριακά (HD, graphics, etc...) και άλλα τέτοια κοίτα τα specs του Sunblade.
To ζήτημα δεν είναι αυτό. Το ζήτημα είναι ότι έχεις να κάνεις με τεχνολογίες που έχουν 6 χρόνια απόσταση. Τα 6 χρόνια διαφορά έφεραν το ρολόι του Xeon στα 3 Ghz αλλά όχι και τις ανάλογες επιδόσεις. Η σύγκριση μένει αυστηρά σε επίπεδο CPU. Αν θέλεις να πάμε παραπέρα ανοίγουμε άλλο thread και συγκρίνουμε και τιμή/απόδοση ή TCO αν θέλεις. Η δημοτικότητα του Alpha στο scientific computing δεν περιόριζε τις δυνατότητες και την πρόσβαση του σε άλλους χώρους. Η αδυναμία των x86 έχει περιορίσει την πρόσβαση τους στα πολύ απαιτητικά περιβάλλοντα. Χωρίς αυτό να απαγορεύει στην Intel να γεμίζει το site της και τις διαφημίσεις της με την λέξη innovation πράγμα το οποίο δυστυχώς (για εμάς) δεν συμβαίνει.

[nivas]

To ζήτημα δεν είναι αυτό. Το ζήτημα είναι ότι έχεις να κάνεις με τεχνολογίες που έχουν 6 χρόνια απόσταση. Τα 6 χρόνια διαφορά έφεραν το ρολόι του Xeon στα 3 Ghz αλλά όχι και τις ανάλογες επιδόσεις. Η σύγκριση μένει αυστηρά σε επίπεδο CPU. Αν θέλεις να πάμε παραπέρα ανοίγουμε άλλο thread και συγκρίνουμε και τιμή/απόδοση ή TCO αν θέλεις. Η δημοτικότητα του Alpha στο scientific computing δεν περιόριζε τις δυνατότητες και την πρόσβαση του σε άλλους χώρους. Η αδυναμία των x86 έχει περιορίσει την πρόσβαση τους στα πολύ απαιτητικά περιβάλλοντα. Χωρίς αυτό να απαγορεύει στην Intel να γεμίζει το site της και τις διαφημίσεις της με την λέξη innovation πράγμα το οποίο δυστυχώς (για εμάς) δεν συμβαίνει.
Λέω κάτι πολύ απλό. Το πέρασμα μιας ισχυρής CPU σε άλλους χώρους από αυτούς που αρχικά στοχεύει σίγουρα μπορεί να γίνει με επιτυχία. Όταν όμως πας να βγάλεις συμπεράσματα για αυτό το πέρασμα να χρησιμοποιείς τα κατάληλα benchmarks και όχι αυτά τα οποία κρίνουν την CPU στο δικό της domain.
Τώρα αν θέλεις να ανοίξουμε συζήτηση σχετικά με το ποιος έχει innovative solutions παρόλο που δεν είμαι οπαδός καμιάς αρχιτεκτονικής(αν και λατρεύω τους RISC και με αυτούς ασχολούμε ερευνητικά) σου παραθέτω το εξής:

"Today the RISC/CISC debate is over. With the introduction of Pentium Pro, Intel proved to the world that an implementation of a CISC ISA could apply all the same techniques used in RISC processor."
Embedded computing. A VLIW approach to architecture, compilers and tools. by Joseph A. Fischer, Paolo Faraboschi, Cliff Young.
Αν δεν γνωρίζεις τι εστί Fischer κανε ένα search και θα καταλάβεις αν η άποψή του μετρά παραπάνω ή όχι από την δική σου και την δική μου.
Αλλά για να πω και την προσωπική άποψη θέλω να πω τα εξής.
Συχνά βλέπω στα forums debate σχετικά με τους RISC εναντίον των Intel που τουλάχιστον στους desktop cpus λέτε ότι εκφράζουν τους CISC. ΛΑΘΟΣ. Η pentium family, όπως ουσιαστικά λέει και ο Fischer, είναι RISC. Στο τελικό επίπεδο της microarchitecture του ISA τους υπάρχει ένα RISC instruction set. Προσπαθώντας να κάνουν target της σημερινές εφαρμογές η INTEL έχει βάλει ένα complex instruction set (π.χ. move string) σε υψηλότερο επίπεδο. Αυτό το complex instruction set όμως τελικά θα τρέξει σε ένα RISC ISA. Γιαυτό και ο Fischer λέει ότι το debate έχει τελειώσει.

[DarthMoul]

Λέω κάτι πολύ απλό. Το πέρασμα μιας ισχυρής CPU σε άλλους χώρους από αυτούς που αρχικά στοχεύει σίγουρα μπορεί να γίνει με επιτυχία. Όταν όμως πας να βγάλεις συμπεράσματα για αυτό το πέρασμα να χρησιμοποιείς τα κατάληλα benchmarks και όχι αυτά τα οποία κρίνουν την CPU στο δικό της domain.
Τώρα αν θέλεις να ανοίξουμε συζήτηση σχετικά με το ποιος έχει innovative solutions παρόλο που δεν είμαι οπαδός καμιάς αρχιτεκτονικής(αν και λατρεύω τους RISC και με αυτούς ασχολούμε ερευνητικά) σου παραθέτω το εξής:

"Today the RISC/CISC debate is over. With the introduction of Pentium Pro, Intel proved to the world that an implementation of a CISC ISA could apply all the same techniques used in RISC processor."
Embedded computing. A VLIW approach to architecture, compilers and tools. by Joseph A. Fischer, Paolo Faraboschi, Cliff Young.
Αν δεν γνωρίζεις τι εστί Fischer κανε ένα search και θα καταλάβεις αν η άποψή του μετρά παραπάνω ή όχι από την δική σου και την δική μου.
Αλλά για να πω και την προσωπική άποψη θέλω να πω τα εξής.
Συχνά βλέπω στα forums debate σχετικά με τους RISC εναντίον των Intel που τουλάχιστον στους desktop cpus λέτε ότι εκφράζουν τους CISC. ΛΑΘΟΣ. Η pentium family, όπως ουσιαστικά λέει και ο Fischer, είναι RISC. Στο τελικό επίπεδο της microarchitecture του ISA τους υπάρχει ένα RISC instruction set. Προσπαθώντας να κάνουν target της σημερινές εφαρμογές η INTEL έχει βάλει ένα complex instruction set (π.χ. move string) σε υψηλότερο επίπεδο. Αυτό το complex instruction set όμως τελικά θα τρέξει σε ένα RISC ISA. Γιαυτό και ο Fischer λέει ότι το debate έχει τελειώσει.

Τον γνωρίζω τον Fisher. Από τους θεμελιωτές της αρχιτεκτονικής EPIC. Συνεργάτης της HP στην δεκαετία του 80. Αργότερα που στο project προσχώρησε η Intel έγινε και συνεργάτης της Intel. Εξαιρετική μορφή.

Πότε τα είπε αυτά ο Fischer. Εννοώ το κομμάτι που έκανες quote πότε γράφτηκε; Από τότε που γράφτηκε έχει κάνει άλλο σχόλιο;

Από τα λίγα που ξέρω risc σημαίνει instuction set από στοιχειώδεις μικροεντολές, δεκάδες έως εκατοντάδες καταχωρητές, σταθερό μήκος μικροεντολής και σταθερό κόστος εκτέλεσης μικροεντολής σε σχέση με τις άλλες του ίδου unit. Από όλα αυτά ο Pentium δεν μου δίνει τίποτα και είναι cisc καραμπινάτος.

ΥΓ. Αν το multithreading δεν είναι το domain μιας SMT CPU τότε ποιό είναι; Αν με το SMT μετά δύσκολίας καλύπτει την αδυναμίας της στην FPU απέναντι σε έναν ανταγωνιστή 6 ετών που έχει το 1/3 της συχνότητας της, θα προτιμούσες να την συγκρίνουμε με κάτι πιο καινούργιο; Ακόμα και της ίδιας εταιρίας.

[hyperspaced]

Η pentium family, όπως ουσιαστικά λέει και ο Fischer, είναι RISC. Στο τελικό επίπεδο της microarchitecture του ISA τους υπάρχει ένα RISC instruction set. Προσπαθώντας να κάνουν target της σημερινές εφαρμογές η INTEL έχει βάλει ένα complex instruction set (π.χ. move string) σε υψηλότερο επίπεδο. Αυτό το complex instruction set όμως τελικά θα τρέξει σε ένα RISC ISA. Γιαυτό και ο Fischer λέει ότι το debate έχει τελειώσει.


Ναι, τελικά-τελικά όλα καταλήγουν σε κάτι, είτε αυτό λέγεται reduced set μικροκώδικας είτε ηλεκτρομαγνητικοί παλμοί. Έχεις αναρωτηθεί πόσοι κύκλοι χρειάζονται να 'σπάσει' ένα complex instuction σε ένα reduced; Εκεί παίζουν οι RISC. Κάθε εφαρμογή έχει τις απαιτήσεις της.
Συνήθως στους μικροελεγκτές χρησιμοποιούνται (99% των περιπτώσεων) RISC αρχιτεκτονικές λόγω της ισχύος σε χαμηλές ταχύτητες ρολογιού.

Στα PC έχουν κυριαρχήσει οι CISC για καθαρά λόγους ευκολίας ανάπτυξης κώδικα.

[nivas]

Τον γνωρίζω τον Fisher. Από τους θεμελιωτές της αρχιτεκτονικής EPIC. Συνεργάτης της HP στην δεκαετία του 80. Αργότερα που στο project προσχώρησε η Intel έγινε και συνεργάτης της Intel. Εξαιρετική μορφή.

Πότε τα είπε αυτά ο Fischer. Εννοώ το κομμάτι που έκανες quote πότε γράφτηκε; Από τότε που γράφτηκε έχει κάνει άλλο σχόλιο;

Από τα λίγα που ξέρω risc σημαίνει instuction set από στοιχειώδεις μικροεντολές, δεκάδες έως εκατοντάδες καταχωρητές, σταθερό μήκος μικροεντολής και σταθερό κόστος εκτέλεσης μικροεντολής σε σχέση με τις άλλες του ίδου unit. Από όλα αυτά ο Pentium δεν μου δίνει τίποτα και είναι cisc καραμπινάτος.

Δεν ξέρω αν κινδυνεύουμε να βγούμε oftopic αλλά μου αρέσει η κουβέντα και την συνεχίζω.
Συγνώμη που δεν έδωσα σωστή αναφορά. Το βιβλίο εκδόθηκε το 2005 από την elsevier. Φρεσκαδούρα δηλαδή.
Και βέβαια σου τα δίνει όλα αυτά ο Pentium (περισότερο ή λιγότερο) άλλο που εσύ δεν το ξέρεις γιατί το programmers view που έχει αποφασίσει να κάνει expose η Intel είναι ποιο κοντά στον CISC. Και φυσικά δεν το έχει επιλέξει για να δίνει τροφή στα δικά σου σενάρια σχετικά με RISC/CISC. Με αυτό τον τρόπο έχει μια απλή arch (RISC) όπου μπορεί να εφαρμόσει όλα τα αποτελέσματα των τόσων ετών έρευνας στο compiling for perfromance optimization. Από εκεί και πέρα για να μπορέσει να δώσει παραπάνω ώθηση διαθέτει ένα complex instruction set όπου ναι δεν υπάρχει χώρος για optimization αλλά κάτι τέτοιο δεν χρειάζεται γιατί η CISC εντολές είναι ήδη optimized για τις target applicatιons.

[DarthMoul]

Δεν ξέρω αν κινδυνεύουμε να βγούμε oftopic αλλά μου αρέσει η κουβέντα και την συνεχίζω.
Συγνώμη που δεν έδωσα σωστή αναφορά. Το βιβλίο εκδόθηκε το 2005 από την elsevier. Φρεσκαδούρα δηλαδή.
Και βέβαια σου τα δίνει όλα αυτά ο Pentium (περισότερο ή λιγότερο) άλλο που εσύ δεν το ξέρεις γιατί το programmers view που έχει αποφασίσει να κάνει expose η Intel είναι ποιο κοντά στον CISC. Και φυσικά δεν το έχει επιλέξει για να δίνει τροφή στα δικά σου σενάρια σχετικά με RISC/CISC. Με αυτό τον τρόπο έχει μια απλή arch (RISC) όπου μπορεί να εφαρμόσει όλα τα αποτελέσματα των τόσων ετών έρευνας στο compiling for perfromance optimization. Από εκεί και πέρα για να μπορέσει να δώσει παραπάνω ώθηση διαθέτει ένα complex instruction set όπου ναι δεν υπάρχει χώρος για optimization αλλά κάτι τέτοιο δεν χρειάζεται γιατί η CISC εντολές είναι ήδη optimized για τις target applicatιons.

Αν κατάλαβα καλά μου λες ότι η Intel τελικά μου τα δίνει όλα αυτά, αλλά το κάνει κρυφά και δεν μου το λέει στα manuals για να μου κάνει την ζωή εύκολη. Δεν ξέρω αλλά όσες φορές δοκίμασα να γράψω assembly με τους 8 registers και το register renaming που κάνουν οι x86 μου φάνηκε απείρως δυσκολότερη διαδικασία από ανάλογη σε risc. Ίσως να είναι και θέμα συνήθειας.

Οι έρευνες της Intel στο compiling for performance απέδωσαν τόσο καλά που τελικά αγόρασε το Gem compiler layer του alpha για να καταφέρει να βγάλει δικό της optimized compiler. Μαζί με τα σχέδια του ev8 για να υλοποιήσει το SMT και αυτό πετσοκομμένο. Όχι ότι ο icc είναι κακός. Κάθε άλλο. Πηγαίνει και τις δύο αρχιτεκτονικές (x86 και EPIC) στα όρια. Η ένσταση μου είναι στο ποιά είναι τα όρια των x86 και αν τελικά τα innovations που μας διαφημίζουν είναι δικά τους, ή εξαγορασμένα, ή κλεμμένα (με αποφάσεις δικαστηρίων) και αν τελικά οι επιδόσεις δικαιολογούν όλα αυτά τα χρήματα του ζητάει.

[small_boy22]

Ναι, τελικά-τελικά όλα καταλήγουν σε κάτι, είτε αυτό λέγεται reduced set μικροκώδικας είτε ηλεκτρομαγνητικοί παλμοί. Έχεις αναρωτηθεί πόσοι κύκλοι χρειάζονται να 'σπάσει' ένα complex instuction σε ένα reduced; Εκεί παίζουν οι RISC. Κάθε εφαρμογή έχει τις απαιτήσεις της.
Συνήθως στους μικροελεγκτές χρησιμοποιούνται (99% των περιπτώσεων) RISC αρχιτεκτονικές λόγω της ισχύος σε χαμηλές ταχύτητες ρολογιού.

---> Στα PC έχουν κυριαρχήσει οι CISC για καθαρά λόγους ευκολίας ανάπτυξης κώδικα. <---

Δυσκολευομαι να καταλαβω τι εννοεις με αυτην την φραση.
Μηπως θες να πεις οτι λογω του μεγαλου μεριδιου που εχουν στην αγορα ειναι περισσοτερος ο κωδικας που παραγεται ?

Αν βρεις μεσα σε αυτο τον κωδικα εστω το 50% optimized θα σου κανω αγαλμα..
Γιατι οταν μαθαινουν οι πιο πολλοι Visual Basic, Delphi και γενικα δουλεουν με components τι να μαθουν απο code optimization ? Αλλα σε αυτα σε ωθουν τα Windows..
Δηλαδη τι να κλασο*ν τα 8 general purpose registers στους x86 ?
Aν εγω θελω 20 μεταβλητες στον κωδικα μου ας ειναι καλα ο μεγας compiler !!
Δεν ειναι τυχαιο που ο gcc4 αλλα πρωτα o ICC εχουν νectorizer .. χτυπησαν τοιχο σε ρολοι και FPU μηπως ?!

Darthmoul απο την μερια που σχολιαζεις τα αποτελεσματα του Χeon τοτε σιγουρα μας μαθαινεις πραγματα αλλα οταν συγκρινεις τον Xeon με τον Αlpha η μονη ενταση που εχω ειναι κατα ποσο μπορεις εχεις αντικειμενικη συγκριση FPU αφου εστιαζω εκει και οχι σε συγκριση επεξεργαστων.

O Alpha εχει vector unit οπως οι SSE και το Αltivec ?
To software για τον Alpha εχει εγκαταλειφθει ?

[nivas]

Ναι, τελικά-τελικά όλα καταλήγουν σε κάτι, είτε αυτό λέγεται reduced set μικροκώδικας είτε ηλεκτρομαγνητικοί παλμοί. Έχεις αναρωτηθεί πόσοι κύκλοι χρειάζονται να 'σπάσει' ένα complex instuction σε ένα reduced; Εκεί παίζουν οι RISC. Κάθε εφαρμογή έχει τις απαιτήσεις της.
Συνήθως στους μικροελεγκτές χρησιμοποιούνται (99% των περιπτώσεων) RISC αρχιτεκτονικές λόγω της ισχύος σε χαμηλές ταχύτητες ρολογιού.

Στα PC έχουν κυριαρχήσει οι CISC για καθαρά λόγους ευκολίας ανάπτυξης κώδικα.

Ναι έχω αναρωτηθεί. Μέγιστο όσους κύκλους θα χρειαζόταν και ο RISC για να εκτελέσει την complex εντολή με το δικό του ISA και σίγουρα λιγότερο λόγο του ότι έχει optimized αυτήν την εντολή.

Οκ σύμφωνει. Και εγώ λέω ότι ένα RISC ISA είναι κάπως φτωχό για το general purpose processing environment.

Μόνο ευκολία ανάπτυξης κώδικα?? Δηλαδή στον PowerPC δεν μπορείς εύκολα να αναπτύξης κώδικα??????? Ευκολία επιτάχυνσης διαδικασίας η οποία εμφανίζεται συχνά στις εφαρμογές τις οποίες απευθύνεσε.

[DarthMoul]

Darthmoul απο την μερια που σχολιαζεις τα αποτελεσματα του Χeon τοτε σιγουρα μας μαθαινεις πραγματα αλλα οταν συγκρινεις τον Xeon με τον Αlpha η μονη ενταση που εχω ειναι κατα ποσο μπορεις εχεις αντικειμενικη συγκριση FPU αφου εστιαζω εκει και οχι σε συγκριση επεξεργαστων.

O Alpha εχει vector unit οπως οι SSE και το Αltivec ?
To software για τον Alpha εχει εγκαταλειφθει ?
Ο Alpha είχε κορυφαία FPU στην εποχή του. Κατά την γνώμη μου το να πατσίζει με την FPU του Xeon τόσα χρόνια μετά και με αυτές τις προϋποθέσεις (3GHz + SMT), δεν είναι επίτευγμα του Alpha αλλά αδυναμία του Xeon.

Ναι οι Alpha έχουν vector units. Από πλευράς software είναι σε maintenance mode από το 2001. Το ίδιο και στο hardware. Από το 1999 είχαν μόνο μια αύξηση συχνότητας από το 1 Ghz στο 1.15 Ghz. Η αρχιτεκτονική έχει ουσιαστικά πεθάνει και αντικαθίσταται από τον Itanium.

[nivas]

Αν κατάλαβα καλά μου λες ότι η Intel τελικά μου τα δίνει όλα αυτά, αλλά το κάνει κρυφά και δεν μου το λέει στα manuals για να μου κάνει την ζωή εύκολη. Δεν ξέρω αλλά όσες φορές δοκίμασα να γράψω assembly με τους 8 registers και το register renaming που κάνουν οι x86 μου φάνηκε απείρως δυσκολότερη διαδικασία από ανάλογη σε risc. Ίσως να είναι και θέμα συνήθειας.

Οι έρευνες της Intel στο compiling for performance απέδωσαν τόσο καλά που τελικά αγόρασε το Gem compiler layer του alpha για να καταφέρει να βγάλει δικό της optimized compiler. Μαζί με τα σχέδια του ev8 για να υλοποιήσει το SMT και αυτό πετσοκομμένο. Όχι ότι ο icc είναι κακός. Κάθε άλλο. Πηγαίνει και τις δύο αρχιτεκτονικές (x86 και EPIC) στα όρια. Η ένσταση μου είναι στο ποιά είναι τα όρια των x86 και αν τελικά τα innovations που μας διαφημίζουν είναι δικά τους, ή εξαγορασμένα, ή κλεμμένα (με αποφάσεις δικαστηρίων) και αν τελικά οι επιδόσεις δικαιολογούν όλα αυτά τα χρήματα του ζητάει.

Γιατί έγραψες assembly σε x86. Για να πουσάρεις την εφαρμογή??????
Είναι ήδη πουσαρισμένη. Εκτός αν γράφεις low level applications (ούτε oι drivers δεν ανήκουν ποια σε αυτήν την κατηγορία). Τώρα ότι δεν δίνει έδαφως για πειραματισμούς ώστε να μπορέσει να κερδίσεις το un-utilized performance τότε μάλλον ναι. Αλήθεια υπάρχει μετρικό για πόσο είναι αυτό.

Δεν καταλαβαίνω τι σχέση έχει το ότι η INTEL είναι πολύ κακό παιδί και αξίζει να το βάλουμε τιμωρία με την σύγκριση archs. Μπερδεύεις λίγο το την δράση με το αποτέλεσμα. Δεν ισχυρίστικα ότι η INTEL ανέπτυξε οτιδήποτε ή ότι έχει φοβερούς μηχανικούς. Ωραία πήρε όλο το knowledge έτοιμο. Και αυτό τι σημαίνει? Οτι το knowledge δεν υπάρχει??? :108:

[small_boy22]

Ο Alpha είχε κορυφαία FPU στην εποχή του. Κατά την γνώμη μου το να πατσίζει με την FPU του Xeon τόσα χρόνια μετά και με αυτές τις προϋποθέσεις (3GHz + SMT), δεν είναι επίτευγμα του Alpha αλλά αδυναμία του Xeon.

Ναι οι Alpha έχουν vector units. Από πλευράς software είναι σε maintenance mode από το 2001. Το ίδιο και στο hardware. Από το 1999 είχαν μόνο μια αύξηση συχνότητας από το 1 Ghz στο 1.15 Ghz. Η αρχιτεκτονική έχει ουσιαστικά πεθάνει και αντικαθίσταται από τον Itanium.

To τελευταιο που γραφεις ισχυει για το παρον ?
Εχεις γραψει σε αλλο ποστ οτι με την εξισωση socket για Xeon και Itanium ισως σπρωχνει η Ιntel τον Itanium στο γκρεμο..
Οποτε ποιος ο λογος να κανουν μεχρι αυτον τον καιρο port το software του Alpha στον Itanium αν τελικα αντικασταθει ο Itanium απο τον Xeon ?
Τι περιεργες κινησεις ειναι αυτες της Intel ?

[DarthMoul]

Γιατί έγραψες assembly σε x86. Για να πουσάρεις την εφαρμογή??????
Είναι ήδη πουσαρισμένη. Εκτός αν γράφεις low level applications (ούτε oι drivers δεν ανήκουν ποια σε αυτήν την κατηγορία). Τώρα ότι δεν δίνει έδαφως για πειραματισμούς ώστε να μπορέσει να κερδίσεις το un-utilized performance τότε μάλλον ναι. Αλήθεια υπάρχει μετρικό για πόσο είναι αυτό.

Δεν καταλαβαίνω τι σχέση έχει το ότι η INTEL είναι πολύ κακό παιδί και αξίζει να το βάλουμε τιμωρία με την σύγκριση archs. Μπερδεύεις λίγο το την δράση με το αποτέλεσμα. Δεν ισχυρίστικα ότι η INTEL ανέπτυξε οτιδήποτε ή ότι έχει φοβερούς μηχανικούς. Ωραία πήρε όλο το knowledge έτοιμο. Και αυτό τι σημαίνει? Οτι το knowledge δεν υπάρχει??? :108:
Συγκεκριμένα κομμάτια έγραψα για τον λόγο που είπες. Και όντως κέρδισα σε σχέση με τον compiler που είχα τότε.

Η ένσταση μου είναι σε αυτά που διαφημίζει. Εδώ μας είπε πρόσφατα πως αυτή εφηύρε πρώτη τον μικροεπεξεργαστή το 1971.

Το knowledge φυσικά και υπάρχει. Τεχνολογία της περασμένης δεκαετίας εξαγορασμένη και προβαλλόμενη ως πρωτοποριακή. Ως επί τω πλείστον προέρχεται από risc επεξεργαστές και η εφαρμογή τους στους x86 δίνει προϊόντα καχεκτικά και σε επιδόσεις και σε κλιμάκωση σε σχέση με τον ανταγωνισμό. Μόνο καχεκτικό τιμολόγιο δεν έχει.

[DarthMoul]

To τελευταιο που γραφεις ισχυει για το παρον ?
Εχεις γραψει σε αλλο ποστ οτι με την εξισωση socket για Xeon και Itanium ισως σπρωχνει η Ιntel τον Itanium στο γκρεμο..
Οποτε ποιος ο λογος να κανουν μεχρι αυτον τον καιρο port το software του Alpha στον Itanium αν τελικα αντικασταθει ο Itanium απο τον Xeon ?
Τι περιεργες κινησεις ειναι αυτες της Intel ?
To ξέρω ότι σου φαίνονται περίεργα όλα αυτά αλλά αν τα εξηγήσω εδώ θα βγούμε εντελώς off-topic. Καλύτερα να ανοίξει ένα άλλο Thread και να το κουβεντιάσουμε ξεχωριστά.

[small_boy22]

To ξέρω ότι σου φαίνονται περίεργα όλα αυτά αλλά αν τα εξηγήσω εδώ θα βγούμε εντελώς off-topic. Καλύτερα να ανοίξει ένα άλλο Thread και να το κουβεντιάσουμε ξεχωριστά.

Συμφωνω, οποτε εχεις χρονο ανοιξε ενα thread να μας παρουσιασεις τα τεκμηρια ωστε να τα διαβασουμε, να καταλαβουμε και να σχολιασουμε περεταιρω :)

Γιατι για να εισαι Ελληνας μεταξυ αλλων πρεπει να γνωριζεις και ελληνικη ιστορια.
Πιστευω οτι εν μερει κατι αντιστοιχο ισχυει και για το Computer Science γενικα :)

[hyperspaced]

@small_boy: Δε μπορείς να κατηγορήσεις καμμία γλώσσα προγραμματισμού μέσου/υψηλού (C,C++) και υψηλού επιπέδου (VB) υπέρ της assembly.
Ναι, φυσικά και το ξέρω ότι assembly σε RISC είναι πολύ αποδοτική. Όμως, βλέπεις το δέντρο και χάνεις το δάσος.

Το δάσος είναι ότι για να υπάρχει ανάπτυξη στους επεξεργαστές (και για να κάνουμε αυτή τη συζήτηση) πρέπει να ρέει χρήμα = να υπάρχουν πρακτικές ΚΑΙ ΦΙΛΙΚΕΣ εφαρμογές που να φτιάχνονται γρήγορα από ανθρώπους με μέτριες γνώσεις προγραμματισμού, ώστε να τις χρησιμοποιούν άνθρωποι με ΚΑΜΜΙΑ γνώση προγραμματισμού (οι οποίοι και πληρώνουν). Μόνο έτσι ρέει το χρήμα. Βλέπε Microsoft. Ο Bill το κατάλαβε και έβγαλε γκα-φρά.

Διαφορετικά, αν ο κόσμος αποτελούταν από ανθρώπους σαν εμάς (πίστεψέ με, λίγοι θα ήμασταν) θα είμασταν σε ένα unix terminal και θα κάναμε εκτέλεση super PI σε RISC στα 200ΜΗz και οι άλλοι θα μας κοιτούσαν περίεργα.

Ναι, καλώς βγήκε ο CISC, ναί καλώς βγήκε η C++, ναι καλώς βγήκε η VB, ναι καλώς βγήκαν τα components, και καλώς βγήκε το .NET.

@nivas: Στον CISC έχεις μεγαλύτερο 'API' για να παίξεις.


Ααααα... και * * * ΝΑΙ * * * ΕΙΜΑΣΤΕ ΕΚΤΟΣ TOPIC !!!!!


edit: Ααα, ναι, ο Itanium πήρε τον π0ύλ0. Και καλά έκανε, γιατί δε μπορεί να υπάρχει τόσο ακριβός επεξεργαστής και με τόσους registers.
Κύριοι, έχετε 8 registers για να παίξετε. Αν σας αρέσει. Απλά πράγματα, ευκολα στην κατασκευή και φθηνά. Αν θέλετε επιδόσεις, βάλτε πολλούς πυρήνες.

[small_boy22]

@small_boy: Δε μπορείς να κατηγορήσεις καμμία γλώσσα προγραμματισμού μέσου/υψηλού (C,C++) και υψηλού επιπέδου (VB) υπέρ της assembly.
Ναι, φυσικά και το ξέρω ότι assembly σε RISC είναι πολύ αποδοτική. Όμως, βλέπεις το δέντρο και χάνεις το δάσος.

Το δάσος είναι ότι για να υπάρχει ανάπτυξη στους επεξεργαστές (και για να κάνουμε αυτή τη συζήτηση) πρέπει να ρέει χρήμα = να υπάρχουν πρακτικές ΚΑΙ ΦΙΛΙΚΕΣ εφαρμογές που να φτιάχνονται γρήγορα από ανθρώπους με μέτριες γνώσεις προγραμματισμού, ώστε να τις χρησιμοποιούν άνθρωποι με ΚΑΜΜΙΑ γνώση προγραμματισμού (οι οποίοι και πληρώνουν). Μόνο έτσι ρέει το χρήμα. Βλέπε Microsoft. Ο Bill το κατάλαβε και έβγαλε γκα-φρά.

Διαφορετικά, αν ο κόσμος αποτελούταν από ανθρώπους σαν εμάς (πίστεψέ με, λίγοι θα ήμασταν) θα είμασταν σε ένα unix terminal και θα κάναμε εκτέλεση super PI σε RISC στα 200ΜΗz και οι άλλοι θα μας κοιτούσαν περίεργα.

Ναι, καλώς βγήκε ο CISC, ναί καλώς βγήκε η C++, ναι καλώς βγήκε η VB, ναι καλώς βγήκαν τα components, και καλώς βγήκε το .NET.

@nivas: Στον CISC έχεις μεγαλύτερο 'API' για να παίξεις.


Ααααα... και * * * ΝΑΙ * * * ΕΙΜΑΣΤΕ ΕΚΤΟΣ TOPIC !!!!!


Να ισιωσουμε λιγο την συζητηση και συνεχιζουμε μετα.

Δεν αναφερθηκα ποτε σε assembly !!!
κοιτα στην κατηγορια "ΠΡΟΓΡΑΜΜΑΤΙΣΜΟΣ"
Ο Darthmoul εχει γραψει μερικα tutorials για code οptimazation κτλ..
Μεσα σε αυτα εμπεριεχεται και με ποια σειρα να δηλωνεις τις μεταβλητες στο προγραμμα σε οποιαδηποτε γλωσσα..
Για τοσο βασικα πραγματα μιλαμε :o

Ανοιγουμε τοπικ για CISC vs. RISC σε ηπιο κλιμα και πιστευω να συνεχισουμε εκει.
Προτεινω το επομεπο ποστ που θα αφορα CISC vs. RISC να γινει σε νεο τοπικ και να το ανοιξει ο επομενος που θα κανει ποστ.

[DarthMoul]

Επειδή εγώ είχα ανοίξει αυτό το thread πριν από πολύ καιρό και για να το επαναφέρουμε στον ίσιο δρόμο:

Είχε γίνει μια συζήτηση παλιότερα και πολλοί έκαναν παράπονα ότι το Hyperthreading της Intel είναι απάτη. Ο λόγος ήταν ότι έτρεχαν single threaded προγράμματα και όπως ήταν λογικό δεν έβλεπαν και ιδιαιτερες βελτιώσεiς. Γι αυτό και έγραψα εγώ αυτό το απλό multithreaded πρόγραμμα έτσι ώστε να ελέγξουμε αν ο ισχυρισμός της Intel για performance boots 20%-30% ανάλογα με την εφαρμογή είναι πραγματικός. Και πράγματι οι δοκιμές με ένα και πολλά threads έδωσαν ανάλογο ποσοστό βελτίωσης.

Στην πορεία επειδή δημιουργήθηκε η εντύπωση ότι οι επεξεργαστές της Intel με HT είναι οι πρώτοι και οι καλύτεροι και δεν υπάρχει κανένας άλλος, σύγκρινα τον Xeon με ενα αντίστοιχο σύστημα alpha αρκετών ετών παλαιότερο για να φανεί στην πράξη τι τεχνολογία μας πουλάνε καί ότι μόνο για τεχνολογία αιχμής και καινοτομική δεν πρόκειται όπως κακώς διαφημίζεται.

Νομίζω πως το thread πρέπει να μείνει σε αυτά τα πλαίσια. Καλό θα ήταν όπως είπε και ο φίλος small_boy22 όποιος θέλει να συζητήσουμε για CISC, RISC, EPIC, x86, Itanium κλπ να ανοίξει αντίστοιχο ή αντίστοιχα threads, να κάνει την τοποθέτηση ή τις ερωτήσεις του και όποιος θέλει να απαντήσει εκεί.

[DVD_GR]

παντως στον τασκ μανατζερ ελεγε οταν ετρεχες ενα προγραμμα φουλ οτι ειχε usage 50% και καλα στα $ντελ και ηταν απατη γιατι τρεχοντας 2 instances του προγραμματος πηγαινε το usage 100% αλλα απο βελτιωση 2-3% max...

[DarthMoul]

παντως στον τασκ μανατζερ ελεγε οταν ετρεχες ενα προγραμμα φουλ οτι ειχε usage 50% και καλα στα $ντελ και ηταν απατη γιατι τρεχοντας 2 instances του προγραμματος πηγαινε το usage 100% αλλα απο βελτιωση 2-3% max...
Το Hyperthreading δεν θα αποδόσει στην περίπτωση που και τα δύο threads διεκδικούν τον ίδιο πόρο την ίδια στιγμή. Αυτό το είχαμε διαπιστώσει και παλιότερα όταν κάναμε δοκιμές με το pctbench. Αν η CPU σου έχει πχ ένα vector unit και έχεις δύο threads να το διεκδικούν την ίδια στιγμή δεν θα δεις και σπουδαία βελτίωση. Αν όμως το ένα thread δουλεύει με το vector unit και το άλλο κάνει προσθέσεις ακεραίων, ή μεταφέρει δεδομένα από και προς την μνήμη τότε θα δεις καλή βελτίωση. Σε αυτές τις περιπτώσεις παίζει μεγάλο ρόλο το thread synchronization, κάτι το οποίο δεν υπάρχει όταν τρέχεις δύο instances. Ακόμα και στα multithreaded προγράμματα το thread synchronization είναι καθαρά θέμα της ποιότητας του κώδικα που έχει γράψει ο προγραμματιστής.

Καλά μην περιμένεις ότι η Intel στις διαφημίσεις της θα στα πει αυτά. Στα technical references όμως τα γράφει.

[small_boy22]

Τo hyperthreading ειναι και για το Vector unit ? Γενικα ειναι και για τις 3 βασικες μοναδες εκτελεσης των x86 ? (ALU,FPU,Vector unit)

Να το σιγουρεψω αλλα απο οτι εχουμε πει γενικα ως τωρα:

Οι pentium4 εχουν 2 ALU χρονισμενες σε διπλασια συχνοτητα απο το ρολοι
1 FPU και 1 vector unit , σωστα ?

Οι Αthlon64/Opteron εχουν (?) ALU 1 FPU και 1 Vector Unit ?



Και συνεχιζω: Για την αξιοποιηση του hyperthreading θελουμε υποστηριξη απο το λειτουργικο και μια εφαρμογη που να μπορει να εκμεταλευεται τo hyperthreading. Οποτε συνοψιζοντας αφου τα XP κανουν το ιδιο που κανει και το Linux ως λειτουργικο μετα μας μενει να εχουμε multithreaded εφαρμογη.
Κατι τετοιο απο οτι υποπτευομαι μας οδηγει σε open source και ισως free λογισμικο..
Θυμαμαι χαρακτηριστικα μια δοκιμη με threads που ειχες κανει Darthmoul με Access σε Windows και MySQL σε Linux και τελικα η MySQL εκανε threads ενω η Access εκανε τα δικα της.Οποτε αν δεν εχει σοβαρη υποστηριξη για threads η βαση δεδομενων που δινει η ιδια η M$ τι να περιμενουν οι χρηστες των Windows απο τα χιλιαδες applicatios και utilities που κυκλοφορουν για τα Windows ? μαλλον απο λιγα εως τιποτα :p

[DarthMoul]

Τo hyperthreading ειναι και για το Vector unit ? Γενικα ειναι και για τις 3 βασικες μοναδες εκτελεσης των x86 ? (ALU,FPU,Vector unit)

Ναι.


Να το σιγουρεψω αλλα απο οτι εχουμε πει γενικα ως τωρα:

Οι pentium4 εχουν 2 ALU χρονισμενες σε διπλασια συχνοτητα απο το ρολοι
1 FPU και 1 vector unit , σωστα ?

Ναι. Από κάποιο χρονικό σημείο και μετά οι Xeon απέκτησαν και δεύτερη FPU. Δεν θυμάμαι λεπτομέριες. Με τα καινούργια chips και τους EE δεν έχω κοιτάξει τι γίνεται.


Οι Αthlon64/Opteron εχουν (?) ALU 1 FPU και 1 Vector Unit ?

Νομίζω ναι. Αλλά η FPU του k8 ειναι κατά πολύ γρήγορότερη από αυτή των P4. Στο vector unit υστερεί ελαφρώς. Εδώ δεν έχεις SMT όμως. Γι αυτό προσέχεις πολύ το data dependency για να αξιοποιήσεις πλήρως το out-of-order execution. Cisc-to-Risc decoders και οι υπόλοιπες υβριδικές τεχνολογίες για τις οποίες μιλάγαμε παραπάνω δεν βοηθάνε εδώ. Ακόμα και ο καλύτερος compiler λίγα μπορεί να κάνει. Όλη η δουλειά είναι στα χέρια του προγραμματιστή.


Και συνεχιζω: Για την αξιοποιηση του hyperthreading θελουμε υποστηριξη απο το λειτουργικο και μια εφαρμογη που να μπορει να εκμεταλευεται τo hyperthreading. Οποτε συνοψιζοντας αφου τα XP κανουν το ιδιο που κανει και το Linux ως λειτουργικο μετα μας μενει να εχουμε multithreaded εφαρμογη.
Κατι τετοιο απο οτι υποπτευομαι μας οδηγει σε open source και ισως free λογισμικο..
Θυμαμαι χαρακτηριστικα μια δοκιμη με threads που ειχες κανει Darthmoul με Access σε Windows και MySQL σε Linux και τελικα η MySQL εκανε threads ενω η Access εκανε τα δικα της.Οποτε αν δεν εχει σοβαρη υποστηριξη για threads η βαση δεδομενων που δινει η ιδια η M$ τι να περιμενουν οι χρηστες των Windows απο τα χιλιαδες applicatios και utilities που κυκλοφορουν για τα Windows ? μαλλον απο λιγα εως τιποτα :p
To SMT είναι hardware level multithreading. Και μόνο η ύπαρξη του βοηθάει. Το πόσο εξαρτάται και από την φύση και τον σχεδιασμό των εφαρμογών. Αν θέλεις multithreaded DBMS από την Microsoft θα πας σε SQL Server. Ίσως να έχουν κάνει multithreaded και την τελευταία Access αλλά δεν το έχω κοιτάξει.