Prime Cores V1.0 Freeware

Xstreme

Totocellux ha scritto:

mmmhhhh ........
eravamo partiti da questo problema che tu avevi rilevato:

quindi ti ho chiesto:

in sintesi, mi hai risposto:

riformulo la domanda, ed esponendola in diverso modo spero di essere più diretto.

Per risolvere quel problema inerente il tasto abort hai utilizzato un sistema di classi, e al momento non ha importanza in che linguaggio esse siano state scritte.

dopo che viene premuto il tasto abort, quanti cicli della propria elaborazione impiega mediamente la classe multithreading "calcoli" o chi per essa (la classe multithreading di controllo) per accorgersi dell'evento e quindi avere la contezza che il calcolo debba essere immediatamente interrotto?

su un calcolo con quad core

ho inserito il rilevamento dei millisecondi

alla pressione del tasto reset,

ho inserito un altro rilevamento sulla linea di codice

che toglie "corrente" alla classe "calcolo" :

premuto reset 183984037

intercettato in 183984038

1 millisecondo

Max Clock Speed (+/- 5% MHz) : 3347

1000 diviso 3347

0,29 cicli

Totocellux

bonis62 ha scritto:

su un calcolo con quad core
ho inserito il rilevamento dei millisecondi

alla pressione del tasto reset,

ho inserito un altro rilevamento sulla linea di codice

che toglie "corrente" alla classe "calcolo" :

premuto reset 183984037

intercettato in 183984038

1 millisecondo

Max Clock Speed (+/- 5% MHz) : 3347

1000 diviso 3347

0,29 cicli

ora correggimi se sbaglio, quel valore di 0.29 cicli viene, questa volta, sprecato anche quando l'elaborazione continua regolarmente, cioè allorchè la classe multithreading "calcoli" o quella di controllo non riesca ad intercettare alcun evento associato alla pressione del tasto abort: è corretto?

il problema creato dall'utilizzo di questi controlli di gestione dell'interruzione è sempre il medesimo: fa perdere +o- efficienza a seconda dell'implementazione e della strategia utilizzata, in quanto per forza di cose il controllo (con il proprio bagaglio di tempo di intervento dovuto all'interconnessione con i thread di calcolo e/o controllo) deve essere continuamente attivo (cioè poter intervenire) comunque a priori per poter intercettare un evento di valenza superiore ed esterno come quello dell'evento associato alla pressione del tasto abort in questione.

Se il valore (espresso in intervallo di tempo) di questa perdita viene applicata al programma di gestione che so io, della conta delle pecore al pascolo questa perdita è ampiamente accettabile, ma quando viene ad inficiare l'efficienza di un algoritmo molto spinto come il tuo, direi che è un vero peccato.

Ora, se riuscissimo a stabilire su quella macchina quanti numeri primi in media si possano riuscire a scoprire nell'arco di 0.29 cicli al secondo, e rapportando tale valore con quello del totale dei singoli numeri mediamente scopribili nell'arco dell'unità di tempo, ecco che saremmo riusciti a trovare il grado di inefficienza del controllo in questione rispetto a quello di efficeinza dell'algoritmo di estrazione

EDIT

spero di esser stato chiaro, e non macchinoso come spesso mi accade di credere.

Xstreme

Totocellux ha scritto:

ora correggimi se sbaglio, quel valore di 0.29 cicli viene, questa volta, sprecato anche quando l'elaborazione continua regolarmente, cioè allorchè la classe multithreading "calcoli" o quella di controllo non riesca ad intercettare alcun evento associato alla pressione del tasto abort: è corretto?
il problema creato dall'utilizzo di questi controlli di gestione dell'interruzione è sempre il medesimo: fa perdere +o- efficienza a seconda dell'implementazione e della strategia utilizzata, in quanto per forza di cose il controllo (con il proprio bagaglio di tempo di intervento dovuto all'interconnessione con i thread di calcolo e/o controllo) deve essere continuamente attivo (cioè poter intervenire) comunque a priori per poter intercettare un evento di valenza superiore ed esterno come quello dell'evento associato alla pressione del tasto abort in questione.

Se il valore (espresso in intervallo di tempo) di questa perdita viene applicata al programma di gestione che so io, della conta delle pecore al pascolo questa perdita è ampiamente accettabile, ma quando viene ad inficiare l'efficienza di un algoritmo molto spinto come il tuo, direi che è un vero peccato.

Ora, se riuscissimo a stabilire su quella macchina quanti numeri primi in media si possano riuscire a scoprire nell'arco di 0.29 cicli al secondo, e rapportando tale valore con quello del totale dei singoli numeri mediamente scopribili nell'arco dell'unità di tempo, ecco che saremmo riusciti a trovare il grado di inefficienza del controllo in questione rispetto a quello di efficeinza dell'algoritmo di estrazione

EDIT

spero di esser stato chiaro, e non macchinoso come spesso mi accade di credere.

Se ragioni alla vecchia maniera , il discorso non è macchinoso , anzi fila,

ma , prevedendoti , la mia lunga risposta precedente è la risposta a questa tua, in quanto il ceck dell'interfaccia è a sua volta in multithreading,

i cicli che vengono impiegati al controllo del tutto sono al di fuori degli altri task;

il thread che controlla i registri , ha un refresh di 700 volte al secondo.

quando Primecores si esegue su CPU a core singolo (ormai quasi introvabili)...

vengono sfruttati i 16 timer multitasking che "i Windows" hanno di serie per simulare un ipotetico multithread.

se sali le scale con tre gambe anziche due, le sali più velocemente o con meno fatica ?

Xstreme

apix_1024 ha scritto:

fantastico... pure un pò di cicli sulle ram!! incredibile!! :AAAAH::AAAAH::AAAAH: ed hai spiegato bene anche la parte della programmazione. insomma se l'ho capita io dopo 19 ore di attività cerebrale devo dire che è proprio spiegata benissimoO0O0O0

quando la logica diventa un eccezzione per spiegarla occorre un altra eccezzione (autore : io) :asd:

Totocellux

bonis62 ha scritto:

[........]

il ceck dell'interfaccia è a sua volta in multithreading,

i cicli che vengono impiegati al controllo del tutto sono al di fuori degli altri task;

e cosa dovrebbero consumare tali cicli ?!

a carico di chi vengono eseguiti ?!

bonis62 ha scritto:

[........]

il thread che controlla i registri , ha un refresh di 700 volte al secondo.

immagino tu stia parlando dei registri della cpu.

ma non ho ben compreso cosa c'entri col controllo di cui stavamo parlando

bonis62 ha scritto:

[........]

se sali le scale con tre gambe anziche due, le sali più velocemente o con meno fatica ?

questo esempio, adottato nel tipo di elaborazione che stai portando avanti con la scoperta dei numeri primi, e la velocità e l'efficienza con la quale la si effettua, imho, dovrebbe entrarci ben poco.

Puoi utilizzare tutti i thread che vuoi ma la funzionalità di Windows resterà pur sempre di tipo time-sharing :leggi: : viene soltanto creata l'illusione di più processi eseguiti contemporaneamente!

In realtà sono portati a termine di seguito, uno alla volta in frazioni di tempo rapidissime, quindi salvati, messi in coda, e poi rimessi in elaborazione e ..... via via così

Hai l'opportunità di avvalorare le tue tesi: sfornami l'eseguibile dell'ultima versione di PrimeCores senza qualsiasi riga di codice inerente ai controlli sul calcolo e sull'abort e potremo tirare le somme

Xstreme

Totocellux ha scritto:

e cosa dovrebbero consumare tali cicli ?!
a carico di chi vengono eseguiti ?!

immagino tu stia parlando dei registri della cpu.

ma non ho ben compreso cosa c'entri col controllo di cui stavamo parlando

questo esempio, adottato nel tipo di elaborazione che stai portando avanti con la scoperta dei numeri primi, e la velocità e l'efficienza con la quale la si effettua, imho, dovrebbe entrarci ben poco.

Puoi utilizzare tutti i thread che vuoi ma la funzionalità di Windows resterà pur sempre di tipo time-sharing : viene soltanto creata l'illusione di più processi eseguiti contemporaneamente!

In realtà sono portati a termine di seguito, uno alla volta in frazioni di tempo rapidissime, quindi salvati, messi in coda, e poi rimessi in elaborazione e ..... via via così

Hai l'opportunità di avvalorare le tue tesi: sfornami l'eseguibile dell'ultima versione di PrimeCores senza qualsiasi riga di codice inerente ai controlli sul calcolo e sull'abort e potremo tirare le somme

a carico di chi vengono eseguiti ?!

ad un task che gira su tutti i cores presenti,

mediamente il tempo per il controllo di un registro si prende due o tre istruzioni,

spalmiamo questo tempo per tutti i cores rilevati nella CPU e ...

a mio parere non dovrebbe incidere più dello 0.001 sui tempi del test,

siamo nell'ordine dei microsecondi se non erro...

immagino tu stia parlando dei registri della cpu.

no, sto parlando dei registri di PrimeCores,

quando un thread ha finito il calcolo porta il

suo registro a zero, la routine di controllo controlla

700 volte al secondo quel registro,

lo ho portato fino a 700, perche fino a 700

ho rilevato i medesimi tempi,

oltre i 700 cicli di controllo appare un rallentamento di meno di mezzo secondo.

tipo time-sharing..

visto che il concetto del time-sharing è il mutitasking....,

l'illusione diventa realtà se scoperchi la tua cpu e ci trovi più di 1 core

In realtà sono portati a termine di seguito, uno alla volta...

posso dissociarmi da queste vaganti rivelazioni ?

Totocellux

bonis62 ha scritto:

tipo time-sharing..

visto che il concetto del time-sharing è il mutitasking....,

l'illusione diventa realtà se scoperchi la tua cpu e ci trovi più di 1 core

In realtà sono portati a termine di seguito, uno alla volta...

posso dissociarmi da queste vaganti rivelazioni ?

vaganti rivelazioni?! :asd:

l'affermazione non merita commento :coolsmiley:

il contenuto si

In un ambiente Time-Sharing come Windows:

Each thread is scheduled for a quantum, which defines the maximum amount of CPU time for which the thread can run before the kernel looks for other threads at the same priority to run. The exact duration of a quantum varies depending on what version of Windows is installed, the type of processor on which Windows is running, and the performance settings that have been established by a system administrator.

[........]

After a thread is scheduled, it runs until one of the following occurs:

Its quantum expires.
It enters a wait state.
A higher-priority thread becomes ready to run.

tratto da:

Scheduling, Thread Context, and IRQL

principino1984

questo thread sta diventando interessantissimo... continuate così perchè penso che state spiegando in termini "semplici" veramente tante cose su windows!

Marco

Xstreme

Totocellux ha scritto:

vaganti rivelazioni?!
l'affermazione non merita commento

il contenuto si

In un ambiente Time-Sharing come Windows:

Each thread is scheduled for a quantum, which defines the maximum amount of CPU time for which the thread can run before the kernel looks for other threads at the same priority to run. The exact duration of a quantum varies depending on what version of Windows is installed, the type of processor on which Windows is running, and the performance settings that have been established by a system administrator.

[........]

After a thread is scheduled, it runs until one of the following occurs:

Its quantum expires.

It enters a wait state.

A higher-priority thread becomes ready to run.

tratto da:

Scheduling, Thread Context, and IRQL

interessante articolo dell'anno 2004....

ti consiglio una lettura di un intero capitolo sul multithreading

....ma dell'anno 2008 :

http://msdn.microsoft.com/en-us/library/hyz69czz.aspx

qua riprende a spiegare il multithreading ma siamo in realtime cioè fine 2009

Multithreading with C and Win32

Le085

bonis62 ha scritto:

interessante articolo dell'anno 2004....
ti consiglio una lettura di un intero capitolo sul multithreading

....ma dell'anno 2008 :

http://msdn.microsoft.com/en-us/library/hyz69czz.aspx

interessante questa storia del multithreading simulato su una singola cpu.

Capisco il discorso che grazie a questo accorgimento, visto che le time slice sono molto piccole i thread sembra che vengano eseguiti tutti contemporaneamente dando così l'illusione del multithreading cosa che con il time-sharing non avviene perchè c'è più latenza tra un thread e l'altro.

ora non ho seguito bene il succo del dibattito (o meglio non l'ho capito ) ma a mio (modestissimo) parere questo multithreading virtuale è un po' più inefficciente del time-sharing perchè va spesso a interrompere l'esecuzione dei thread (quindi salvare tutti i registri del thread interrotto e caricare tutte le istruzioni dell'altro thread dal punto dove era astato interrotto) cosa che a mio avviso crea abbastanza inefficienza per via appunto di queste interruzioni.

E' vero che queste nuove cpu hanno politiche di scheduling piuttosto sofisticate ma rimane il fatto che secondo me è un po' piu' inefficiente.

Xstreme

Le085 ha scritto:

interessante questa storia del multithreading simulato su una singola cpu.
Capisco il discorso che grazie a questo accorgimento, visto che le time slice sono molto piccole i thread sembra che vengano eseguiti tutti contemporaneamente dando così l'illusione del multithreading cosa che con il time-sharing non avviene perchè c'è più latenza tra un thread e l'altro.

ora non ho seguito bene il succo del dibattito (o meglio non l'ho capito ) ma a mio (modestissimo) parere questo multithreading virtuale è un po' più inefficciente del time-sharing perchè va spesso a interrompere l'esecuzione dei thread (quindi salvare tutti i registri del thread interrotto e caricare tutte le istruzioni dell'altro thread dal punto dove era astato interrotto) cosa che a mio avviso crea abbastanza inefficienza per via appunto di queste interruzioni.

E' vero che queste nuove cpu hanno politiche di scheduling piuttosto sofisticate ma rimane il fatto che secondo me è un po' piu' inefficiente.

si possono scrivere milioni di testi sull'argomento,

ma sono solo parole, il discorso cambia quando

stai davantti ad una consolle bianca come il latte

e ci cominci a scrivere il codice....

comunque, in linea di massima sono d'accordo...quando si parla di singola CPU con singolo Core.

Totocellux

bonis62 ha scritto:

interessante articolo dell'anno 2004....
ti consiglio una lettura di un intero capitolo sul multithreading

....ma dell'anno 2008 :

http://msdn.microsoft.com/en-us/library/hyz69czz.aspx

qua riprende a spiegare il multithreading ma siamo in realtime cioè fine 2009

Multithreading with C and Win32

Tengo a precisare che tra il 2004, epoca in cui era scritto l'articolo su MSDN che ho postato, e oggi dicembre 2009 non è cambiato nulla di sostanziale nell'approccio elaborativo tra l'allora s.o. Windows XP e l'attuale Windows 7: time-sharing era nel 2004 e time-sharing è quello attuale :leggi:

Time-sharing sta a significare che Windows divide l'unità elementare di tempo (il minuto secondo) in innumerevoli finestre temporali più piccole (il valore espresso in tempo di queste finestre non è assoluto, viene definito sostanzialmente time-slice, ed è determinato peculiarmente anche dalla velocità della cpu) in modo da farlo diventare a sua volta unità elementare di tempo di elaborazione (chiamato anche quantum).

Fatto questo, tramite opportuni criteri distribuisce singolarmente ogni quantum in modo da assegnarlo ad uno ed un solo ben preciso thread che ne abbia fatto richiesta

Da ciò ne deriva consequenzialmente che il s.o. al termine dell'esecuzione di un singolo thread avrà a questo attribuito complessivamente un determinato numero di finestre temporali, quindi un ben preciso tempo di elaborazione, detto anche Tempo di Cpu

La somma di tutti i time-slice attribuiti ad ogni thread da cui il processo/programma/applicazione (task) è costituito, andrà in pratica a determinare la totalità del tempo macchina messo a disposizione (concetto di time-sharing) da Windows.

Tale valore sarà in pratica quello che in Windows viene descritto all'interno del Task Manager ed indicato per ogni processo/programma/applicazione (task) alla voce Tempo di cpu.

Accade però che il susseguirsi delle finestre temporali di elaborazione contenute in ogni unità di tempo (minuto secondo) non avverrà mai ad uso esclusivo di un singolo task e nemmeno di un thread ben preciso, in quanto molti altri thread/task (di sistema e non) richiederanno contestualmente risorse temporali per le proprie specifiche elaborazioni.

Il meccanismo di successione per cui tutti i thread in esecuzione saranno soddisfatti per le loro richieste (scheduling), viene gestito da Windows tramite opportuni criteri e secondo un algoritmo round-robin, significando che sussisterà un incessante susseguirsi di finestre temporali concesse (in modalità round-robin e tramite criteri stabiliti da diversi fattori) a tutto l'insieme dei thread facenti parte di tutti i task in esecuzione.

Quando nessun thread/task chiede alcun tempo di elaborazione al s.o., questi attribuisce i time-slice al task system o idle: se ci farete caso questo task sarà sostanzialmente sempre quello con il maggiore valore di Tempo di Cpu.

Proprio a motivo di ciò Windows, ai fini di un approccio di elaborazione multi-threading di tipo pre-emptive, effettua una cosidetta condivisione del tempo, significando che l'unità elementare di tempo viene condivisa tra tutti i programmi in esecuzione che ne facessero richiesta.

A ogni singolo programma in esecuzione, a seconda della modalità in cui è stato sviluppato (in particolare a seconda del numero di thread dai quali è costituito) può essere assegnato anche più di una di queste unità di tempo di elaborazione, che però non necessariamente saranno rese consecutive dal meccanismo di round-robin di assegnazione.

E' proprio questo il motivo per cui Windows e gran parte dei ss.oo. attualmente utilizzati, si dicano time-sharing oriented.

Come si può evincere dagli articoli da te indicati del 2008 e 2009, quella strada intraprende solo una variazione sul tema, significando che il valore dell'unità di tempo di elaborazione (quantum) da dedicare al singolo thread potrebbe anche essere più piccolo, ma non introduce nient'altro di sostanzialmente significativo o alcun carattere di discontinuità rispetto alla base del concetto di time-sharing.

Ho letto tutto di quei due articoli ma non ho trovato scritto da nessuna parte che alcuna versione di Windows possa dare il comando di far partire contemporaneamente (intendasi nella medesima unità elementare di tempo di cpu, chiamiamola quantum o in qualsiasi altro modo) l'elaborazione di due differenti thread.

Può essere che mi sia perso qualcosa ( :asd: ), e potrebbe starci data la mia età, quindi ti pregherei di indicare dove un concetto del genere sia esattamente asserito.

bonis62 ha scritto:

si possono scrivere milioni di testi sull'argomento,
ma sono solo parole, il discorso cambia quando

stai davantti ad una consolle bianca come il latte

e ci cominci a scrivere il codice....

comunque, in linea di massima sono d'accordo...quando si parla di singola CPU con singolo Core.

intanto non capisco cosa ci sia di così complicato nel comprendere che solo per il fatto di aggiungere 1 solo o altri n differenti core o addirittura altre cpu, non può essere assolutamente stravolto nulla nel meccanismo di scheduling da parte di Windows.

Può accadere solo il fatto che i thread, eseguiti prima tutti su una singola unità elaborativa, vengano ora singolarmente suddivisi su n core, nulla di più.

Nei sistemi multi-core o nei multi-cpu il principio di scheduling di Windows rimane esattamente il medesimo e null'altro, oltre la spartizione sulle aumentate unità di elaborazione a disposizione, contribuisce a modificarlo rispetto alla soluzione single-core.

Se non sei d'accordo (e può starci di pensare in modo differente), sei pregato però di dirci esattamente come funziona l'assegnazione dei time-slice ai thread di PrimesCore cioè se in pratica, secondo te, seguano criteri diffrenti da quelli da me delineati.

Resto pur sempre in attesa della versione priva dei vari controlli per valutare l'impatto di questi sulla velocità di esecuzione

Xstreme

Totocellux ha scritto:

Tengo a precisare che tra il 2004, epoca in cui era scritto l'articolo su MSDN che ho postato, e oggi dicembre 2009 non è cambiato nulla di sostanziale nell'approccio elaborativo tra l'allora s.o. Windows XP e l'attuale Windows 7: time-sharing era nel 2004 e time-sharing è quello attuale

Time-sharing sta a significare che Windows divide l'unità elementare di tempo (il minuto secondo) in innumerevoli finestre temporali più piccole (il valore espresso in tempo di queste finestre non è assoluto, viene definito sostanzialmente time-slice, ed è determinato peculiarmente anche dalla velocità della cpu) in modo da farlo diventare a sua volta unità elementare di tempo di elaborazione (chiamato anche quantum).

Fatto questo, tramite opportuni criteri distribuisce singolarmente ogni quantum in modo da assegnarlo ad uno ed un solo ben preciso thread che ne abbia fatto richiesta

Da ciò ne deriva consequenzialmente che il s.o. al termine dell'esecuzione di un singolo thread avrà a questo attribuito complessivamente un determinato numero di finestre temporali, quindi un ben preciso tempo di elaborazione, detto anche Tempo di Cpu

La somma di tutti i time-slice attribuiti ad ogni thread da cui il processo/programma/applicazione (task) è costituito, andrà in pratica a determinare la totalità del tempo macchina messo a disposizione (concetto di time-sharing) da Windows.

Tale valore sarà in pratica quello che in Windows viene descritto all'interno del Task Manager ed indicato per ogni processo/programma/applicazione (task) alla voce Tempo di cpu.

Accade però che il susseguirsi delle finestre temporali di elaborazione contenute in ogni unità di tempo (minuto secondo) non avverrà mai ad uso esclusivo di un singolo task e nemmeno di un thread ben preciso, in quanto molti altri thread/task (di sistema e non) richiederanno contestualmente risorse temporali per le proprie specifiche elaborazioni.

Il meccanismo di successione per cui tutti i thread in esecuzione saranno soddisfatti per le loro richieste (scheduling), viene gestito da Windows tramite opportuni criteri e secondo un algoritmo round-robin, significando che sussisterà un incessante susseguirsi di finestre temporali concesse (in modalità round-robin e tramite criteri stabiliti da diversi fattori) a tutto l'insieme dei thread facenti parte di tutti i task in esecuzione.

Quando nessun thread/task chiede alcun tempo di elaborazione al s.o., questi attribuisce i time-slice al task system o idle: se ci farete caso questo task sarà sostanzialmente sempre quello con il maggiore valore di Tempo di Cpu.

Proprio a motivo di ciò Windows, ai fini di un approccio di elaborazione multi-threading di tipo pre-emptive, effettua una cosidetta condivisione del tempo, significando che l'unità elementare di tempo viene condivisa tra tutti i programmi in esecuzione che ne facessero richiesta.

A ogni singolo programma in esecuzione, a seconda della modalità in cui è stato sviluppato (in particolare a seconda del numero di thread dai quali è costituito) può essere assegnato anche più di una di queste unità di tempo di elaborazione, che però non necessariamente saranno rese consecutive dal meccanismo di round-robin di assegnazione.

E' proprio questo il motivo per cui Windows e gran parte dei ss.oo. attualmente utilizzati, si dicano time-sharing oriented.

Come si può evincere dagli articoli da te indicati del 2008 e 2009, quella strada intraprende solo una variazione sul tema, significando che il valore dell'unità di tempo di elaborazione (quantum) da dedicare al singolo thread potrebbe anche essere più piccolo, ma non introduce nient'altro di sostanzialmente significativo o alcun carattere di discontinuità rispetto alla base del concetto di time-sharing.

Ho letto tutto di quei due articoli ma non ho trovato scritto da nessuna parte che alcuna versione di Windows possa dare il comando di far partire contemporaneamente (intendasi nella medesima unità elementare di tempo di cpu, chiamiamola quantum o in qualsiasi altro modo) l'elaborazione di due differenti thread.

Può essere che mi sia perso qualcosa (), e potrebbe starci data la mia età, quindi ti pregherei di indicare dove un concetto del genere sia esattamente asserito.

intanto non capisco cosa ci sia di così complicato nel comprendere che solo per il fatto di aggiungere 1 solo o altri n differenti core o addirittura altre cpu, non può essere assolutamente stravolto nulla nel meccanismo di scheduling da parte di Windows.

Può accadere solo il fatto che i thread, eseguiti prima tutti su una singola unità elaborativa, vengano ora singolarmente suddivisi su n core, nulla di più.

Nei sistemi multi-core o nei multi-cpu il principio di scheduling di Windows rimane esattamente il medesimo e null'altro, oltre la spartizione sulle aumentate unità di elaborazione a disposizione, contribuisce a modificarlo rispetto alla soluzione single-core.

Se non sei d'accordo (e può starci di pensare in modo differente), sei pregato però di dirci esattamente come funziona l'assegnazione dei time-slice ai thread di PrimesCore cioè se in pratica, secondo te, seguano criteri diffrenti da quelli da me delineati.

Resto pur sempre in attesa della versione priva dei vari controlli per valutare l'impatto di questi sulla velocità di esecuzione

posso farti due domande ?

cosi per dirne una,

io ho cominciato a programmare da quando uscì il PET2001,

tu da quanto programmi ?

la seconda potrebbe essere :

questi hanno scritto un completo sistema oprativo

multithread che gira su floppy da 1,44, funziona,

lo hai provato ?... MenuetOS

Totocellux

bonis62 ha scritto:

posso farti due domande ?
cosi per dirne una,

io ho cominciato a programmare da quando uscì il PET2001,

tu da quanto programmi ?

[..........]

ma cosa può entrarci questo nel nostro disquisire sul time-sharing?

Vorrei che lasciassi perdere il superfluo, sarebbe più utile a tutti che rispondessi con argomentazioni maggiormente esplicative.

Siccome la faccenda si è allungata parecchio e chi legge rischia di non comprendere le motivazioni di ciò di cui discutiamo, vorrei ricordare che ha avuto inizio quando ho espresso il dubbio che i controlli aggiuntivi che hai previsto sul tasto abort del tuo ottimo PrimeCores, avessero potuto leggermente penalizzare l'efficienza dell'algoritmo di estrazione.

Riguardo al linguaggio di programmazione utilizzato (a patto che sforni applicazioni multi-threading), voglio ricordarti che appare ininfluente dal punto di vista del meccanismo di scheduling utilizzato dal s.o.

bonis62 ha scritto:

[...........]

la seconda potrebbe essere :

questi hanno scritto un completo sistema oprativo

multithread che gira su floppy da 1,44, funziona,

lo hai provato ?... MenuetOS

non lo conosco

ma noi stiamo parlando di programmi win32 o al massimo win64, quindi cosa c'entra anche questa domanda?

Xstreme

Totocellux ha scritto:

ma cosa può entrarci questo nel nostro disquisire sul time-sharing?
Vorrei che lasciassi perdere il superfluo, sarebbe più utile a tutti che rispondessi con argomentazioni maggiormente esplicative.

Siccome la faccenda si è allungata parecchio e chi legge rischia di non comprendere le motivazioni di ciò di cui discutiamo, vorrei ricordare che ha avuto inizio quando ho espresso il dubbio che i controlli aggiuntivi che hai previsto sul tasto abort del tuo ottimo PrimeCores, avessero potuto leggermente penalizzare l'efficienza dell'algoritmo di estrazione.

Riguardo al linguaggio di programmazione utilizzato (a patto che sforni applicazioni multi-threading), voglio ricordarti che appare ininfluente dal punto di vista del meccanismo di scheduling utilizzato dal s.o.

non lo conosco

ma noi stiamo parlando di programmi win32 o al massimo win64, quindi cosa c'entra anche questa domanda?

----------------------------------------------------------------

ma cosa può entrarci questo....

perche volevo sapere se hai esperienza sul campo oltre che

una ammirevole teoria .

quindi cosa c'entra anche questa domanda?.....

si, è un OT, ero curioso di sapere come ti sembrava.

Totocellux

bonis62 ha scritto:

----------------------------------------------------------------
ma cosa può entrarci questo....

perche volevo sapere se hai esperienza sul campo oltre che

una ammirevole teoria .

se può esserti utile ho iniziato a programmare alla fine degli anni '80 in DOS con Clipper, e quindi per Windows appena uscì il corrispettivo Visual Objects, in pratica un altro figlio del C orientato al database management.

Poi ho dovuto per forza di cose iniziare con il Basic, Visual Basic, quindi mi sono dedicato completamente all'ASP alla fine degli anni '90 quando ho cominciato a dovermi interessare prevalentemente di DB Management via web in ambienti Microsoft IIS ......

vorrei capire una cosa, e quindi una domanda vorrei fartela io?

Se non avessi mai programmato, per caso le argomentazioni che ho portato sarebbero state meno rilevanti o importanti?

Xstreme

Totocellux ha scritto:

se può esserti utile ho iniziato a programmare alla fine degli anni '80 in DOS con Clipper, e quindi per Windows appena uscì il corrispettivo Visual Objects, in pratica un altro figlio del C orientato al database management.
Poi ho dovuto per forza di cose iniziare con il Basic, Visual Basic, quindi mi sono dedicato completamente all'ASP alla fine degli anni '90 quando ho cominciato a dovermi interessare prevalentemente di DB Management via web in ambienti Microsoft IIS ......

vorrei capire una cosa, e quindi una domanda vorrei fartela io?

Se non avessi mai programmato, per caso le argomentazioni che ho portato sarebbero state meno rilevanti o importanti?

se sai programmare allora ti faccio vedere questa cosa, perchè sei in grado di intuirne la lavorazione :

http://www.xstreme.it/b_for_t.zip

tanto per iniziare a vedere la demo ,

appena lanciata, trascina con il mouse

la scritta del tuo nick fino

all'angolo inferiore destro con

media/lenta velocità e poi lascia il

tasto del mouse, poi attendi, ogni quattro

secondi vi è una variazione dell'algoritmo

di controllo del multithread, ovviamente

visto che sei un programmatore vedendo

la demo credo che intuirai +o- come è fatta

e come sono gestiti singolarmente i punti.

Ovviamente ti puoi divertire con il mouse

a disegnare sullo screen altre forme e vedere

cose interessanti , se poi tieni aperto la

cronologia di utilizzo della cpu puoi vedere il codice

lavore sui cores...

(penso che se analizzi il codice vedrai una pezza

in assembler abbastanza lunga, ma non ha nulla

a vedere con la grafica, è uno spartano mini O.S.

che ho scritto per bypassare alcune gestioni

del win32 a modo mio)

con i numeri primi non potevo farti vedere come io

gestisco il multithreading, a livello grafico mi sembra

un pò più visibile.

Fermo restando che la tua teoria è esattissima.

ah.... per uscire premi il tasto ESC.

ps

carino ASP

macchinoso (secondo me) , ma ti da belle soddisfazioni.

Totocellux

bonis62 ha scritto:

tanto per iniziare a vedere la demo ,

appena lanciata, trascina con il mouse

la scritta del tuo nick fino

all'angolo inferiore destro con

media/lenta velocità e poi lascia il

tasto del mouse, poi attendi, ogni quattro

secondi vi è una variazione dell'algoritmo

di controllo del multithread, ovviamente

visto che sei un programmatore vedendo

la demo credo che intuirai +o- come è fatta

e come sono gestiti singolarmente i punti.

Ovviamente ti puoi divertire con il mouse

a disegnare sullo screen altre forme e vedere

cose interessanti , se poi tieni aperto la

cronologia di utilizzo della cpu puoi vedere il codice

lavore sui cores...

(penso che se analizzi il codice vedrai una pezza

in assembler abbastanza lunga, ma non ha nulla

a vedere con la grafica, è uno spartano mini O.S.

che ho scritto per bypassare alcune gestioni

del win32 a modo mio)

con i numeri primi non potevo farti vedere come io

gestisco il multithreading, a livello grafico mi sembra

un pò più visibile.

Fermo restando che la tua teoria è esattissima.

ah.... per uscire premi il tasto ESC.

[.........]

devo dirti che non mi sono mai dovuto impegnare nello sviluppo di applicazioni grafiche, quindi posso solo intuire le particolarità e le difficoltà del lavoro che hai fatto.

Beh, le esplosioni (tipo giochi di artificio) sembrano gestite molto bene, omogenee e l'espansione dei punti ha un buon effetto

intuisco come il lavoro dietro alla creazione e la gestione dei punti sia molto complesso e dispendioso per lo sviluppatore e per la cpu (e non solo dalla % di livello di occupazione).

per ora ho potuto vedere che impegna 20 oggetti GDI e che effettua poche letture e nessuna scrittura.

bonis62 ha scritto:

[.........]

ps

carino ASP

macchinoso (secondo me) , ma ti da belle soddisfazioni.

ASP non solo è macchinoso, ma ha diverse limitazioni (come Visual Basic del resto), per questo ho provato a passare ad ASP.Net

Xstreme

Totocellux ha scritto:

devo dirti che non mi sono mai dovuto impegnare nello sviluppo di applicazioni grafiche, quindi posso solo intuire le particolarità e le difficoltà del lavoro che hai fatto.
Beh, le esplosioni (tipo giochi di artificio) sembrano gestite molto bene, omogenee e l'espansione dei punti ha un buon effetto

intuisco come il lavoro dietro alla creazione e la gestione dei punti sia molto complesso e dispendioso per lo sviluppatore e per la cpu (e non solo dalla % di livello di occupazione).

per ora ho potuto vedere che impegna 20 oggetti GDI e che effettua poche letture e nessuna scrittura.

ASP non solo è macchinoso, ma ha diverse limitazioni (come Visual Basic del resto), per questo ho provato a passare ad ASP.Net

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;

namespace MvcApplication1.Controllers
{
[HandleError]
public class HomeController : Controller
{
public ActionResult Index()
{
return View();
}

public string SayHello()
{
return "Hello!";
}

}
}

nella mia ignoranza in tale linguaggio chiedo :

asp.net si potrebbe integrare in ambiente C++ o C# ?

la pezza ASM serve per gestire multithreading sui wrapper GDI

Xstreme

http://www.xstreme.it/BforTfor8.exe

la stessa applicazione,

ma ottimizzata per un

multithreading su 8 cores.

nota:

il visibile ritardo iniziale è dovuto al conteggio delle particelle,

operazione che serve per inserire le particelle dalla classe

standard che gestisce il multithread di Windows,

nella classe che gestisce il multithread a modo mio,

ovviamente come ben visibile questa routine non è

ottimizzata perchè mi interessava appunto far

notare la differenza.)