Java vs C++... Sono stanco...

[cdimauro]

Originariamente inviato da cionci

Un Gabage Collector fatto con gli smart pointer si scrive in 10 minuti con la STL

Ma nessuno lo fa a quanto pare.

[cdimauro]

Originariamente inviato da cionci

E Windows Server come fa ? Se non sbaglio NT e 2000 facevano come hai detto te.

Anche Tiger fa così.

E infatti lo ribadisco: la PAE viene usata male così.

[cdimauro]

Originariamente inviato da k0nt3

a me sembra tantissimo per un SO

Non sarebbe per il solo s.o., ma per tutto.

[cdimauro]

Originariamente inviato da cionci

Non solo della tag cache. Mi sembra di aver letto che c'è un'ulteriore livello nella tabella delle pagine e questo mette in crisi il TLB.

Francamente non ricordo proprio dell'aggiunta di un ulteriore livello per la decodifica dell'indirizzo virtuale.

[k0nt3]

Originariamente inviato da cdimauro

Ma nessuno lo fa a quanto pare.

cerca bene su internet

[^TiGeRShArK^]

Originariamente inviato da cdimauro

Ricordo di aver letto tempo fa che mediamente le prestazioni di un'applicazione managed .NET 2.0 sono del 90% circa rispetto alla stessa, ma compilata in x86 per win32.

da vari test che avevo visto qualche tempo fa risultava che C# era in effetti su quei livelli, mentre java arrivava quasi sempre intorno al 95% delle prestazioni con codice non managed, quindi java ad oggi risulta essere addirittura + veloce del C# contrariamente a quanto molti ancora pensano (c'è ancora ki dice ke è un ordine di grandezza + lento del C++ ).
Avevo visto i risultati del linpack e di non mi ricordo quale altro bench.. forse lo sciencemark..

[cdimauro]

Originariamente inviato da ^TiGeRShArK^

da quello che ricordo io quello era il problema minore..
quando dovevi accedere continuamente a pagine situate in blocchi diversi avevi prestazioni decisamente catastrofiche.
Quello era uno dei principali vantaggi dell'uso di x86-64 con programmi che usavano enormi quantità di memoria.

Esattamente: la penalizzazione c'è, ma usando la memoria alta come "area di transito".

[cdimauro]

Originariamente inviato da ^TiGeRShArK^

da quel che so almeno in ambiente mobile ci si sta già muovendo in questa direzione mediante dei chip atti proprio ad accelerare la VM java in hardware...
Ora però mi sfugge il nome del chipppettino in questione

Sono gli ultimi modelli della famiglia ARM:

http://www.arm.com/products/CPUs/ARM7EJSCore.html
http://www.arm.com/products/CPUs/ARM926EJ-S.html
http://www.arm.com/products/CPUs/ARM1026EJS.html
http://www.arm.com/products/CPUs/ARM1136JF-S.html
http://www.arm.com/products/CPUs/ARM1176.html

In particolare: http://www.arm.com/products/esd/jazelle_home.html

[cdimauro]

Originariamente inviato da k0nt3

cerca bene su internet

Non avresti qualche link "on-the-fly", cortesemente?

[^TiGeRShArK^]

Originariamente inviato da cdimauro

Sono gli ultimi modelli della famiglia ARM:

http://www.arm.com/products/CPUs/ARM7EJSCore.html
http://www.arm.com/products/CPUs/ARM926EJ-S.html
http://www.arm.com/products/CPUs/ARM1026EJS.html
http://www.arm.com/products/CPUs/ARM1136JF-S.html
http://www.arm.com/products/CPUs/ARM1176.html

In particolare: http://www.arm.com/products/esd/jazelle_home.html

yep jazelle
mi sa ke è lui
in effetti mi ricordavo un nome un pò... "gaio"

[k0nt3]

@cdimauro
http://www.google.it/search?q=c%2B%2...UTF-8&oe=UTF-8

[cionci]

Originariamente inviato da k0nt3

@cdimauro
http://www.google.it/search?q=c%2B%2...UTF-8&oe=UTF-8

Credo che intendesse "ma nessuno ne fa uso"

[cdimauro]

Originariamente inviato da ^TiGeRShArK^

da vari test che avevo visto qualche tempo fa risultava che C# era in effetti su quei livelli, mentre java arrivava quasi sempre intorno al 95% delle prestazioni con codice non managed, quindi java ad oggi risulta essere addirittura + veloce del C# contrariamente a quanto molti ancora pensano

In effetti pensavo anch'io che le prestazioni di .NET 2.0 fossero migliori rispetto a Java.

(c'è ancora ki dice ke è un ordine di grandezza + lento del C++ ).

Sarà rimasto fermo alla JVM totalmente interpretata:

Avevo visto i risultati del linpack e di non mi ricordo quale altro bench.. forse lo sciencemark..

Il LinPack non lo prenderei come riferimento, perché è basato su UN solo algoritmo (risoluzione di sistemi di equazioni differenziali a matrici sparse, se non ricordomale).

ScienceMark dovrebbe essere costituito da una suite più diversificata, ma sempre orientata ad applicazioni scientifiche.

Sarebbe interessate lo SPEC, che la cui suite è costituta da centinaia di applicazioni delle più disparate tipologie.

[cdimauro]

Originariamente inviato da cionci

Credo che intendesse "ma nessuno ne fa uso"

Esattamente. Altrimenti i segmentation fault sarebbero stati debellati da un pezzo (per lo meno col C++).

[tomminno]

Originariamente inviato da 71104

perché?

Mai dato un'occhita all'occupazione di memoria di un programma C#?

in 3 anni lo scrivi un sistema operativo, dipende da quali sono gli obiettivi e quanta manodopera c'è a disposizione. più che altro io dubito che riusciranno veramente a realizzare un intero sistema operativo (kernel compreso) in .NET, Microsoft vorrà anche investire su questa nuova tecnologia ma non così tanto... considera che comunque il tutto dovrebbe continuare a supportare in backward compatibility gli attuali drivers e l'attuale subsystem Win32, altrimenti è un semplice suicidio. raramente però nelle piattaforme managed è facile gestire ciò di cui gli attuali device drivers per Windows hanno bisogno: tutte le struct che essi utilizzano, tra documentate, opache e non documentate, hanno un layout ben preciso che penso in C# sarebbe decisamente meno gestibile che in C. forse è per questo che il C# ha la keyword unsafe

Si pensa che per i dipendenti M$ siano tutte documentate.
Comunque ci hanno messo 6 anni a sviluppare Vista che non è certo un OS scritto da 0, probabilmente ci vorranno almeno 15 anni prima di avere un OS desktop interamente managed.

convertire il mondo alle piattaforme managed secondo te è un comodo loro? certo, lo sarà di sicuro quando il mondo sarà stato convertito ad una piattaforma managed loro, ma vorrei sapere cosa importa a te: la tua vita non può che cambiare in meglio senza i puntatori, e allora stacci senza tante storie, no? ti fanno un grande favore, si vede che meritano un ringraziamento.

Che dire a me non piace assolutamente il C#

tipo? uno formato universale per i puntatori a metodi?
comunque non vedo cosa c'entri: hai fatto un'affermazione ("tirano acqua al loro mulino") già di per se' discutibile e pretendi di anche rifilarcela molto alla lontana.

Tiri ancora in ballo la storia dei puntatori a metodo quanto non sapevi nemmeno dell'esistenza di auto_ptr?

Che ne dici di una sciocchezzuola come il refactoring, niente a che vedere con il linguaggio in sè ma con l'editor, tant'è che ti fanno scaricare un plugin di terze parti.
O il class designer introdotto solo in Orcas.
O i bug che per essere corretti sei obbligato a comprarti Orcas visto che non sono stati corretti nell'SP1.
O l'intellisense che funziona 100 volte peggio di quello del C#. E non diamo la colpa alla difficoltà della sintassi perchè è proprio il funzionamento ad essere differente.
In M$ stanno spingeno verso il mondo .NET il resto sta già andando a morire.

[tomminno]

Originariamente inviato da cdimauro

Questo potrebbe succedere se ogni major version rompesse pesantemente la compatibilità col passato, ma non mi risulta.

A livello di sintassi no ma i controlli grafici col C# 2.0 si legano ai datasource con tutto quello che ne consegue, nell'1.1 si usavano i dataset. E siccome C# significa usare l'editor in tutte le sue funzionalità...
Per risolvere i casini creati dall'editor hanno introdotto le partial class, mah.

Hai mai provato a passare da ASP 1.1 a ASP 2.0? Sempre codice C# è ma è assolutamente impossibile farne il porting.

Riuso del codice: se hai scritto delle classi in C# 1.1 che segue il paradigma dei dataset chiaramente farai inmodo che queste manipolino e restituiscano dataset, ma come la mettiamo se volessi riusare quel codice per un programma C# 2.0? La procedura di creazione di un dataset è volutamente macchinosa nel VS2005 proprio per invogliare il passaggio ai datasource, questo comporta che non riutilizzerò mai il codice che ho scritto un anno fa.

Non vedo il nesso. Managed <> enorme quantità di memoria richiesta.

Quindi non ti è mai capitato di notare l'abnorme uso di memoria del C#?
Del resto è del tutto normale, visto tutto quello che si porta dietro.

Con Vista Windows è stato oggetto di una profonda riscrittura (e .NET è stato utilizzato estensivamente), che però non è ancora stata completata: lo sarà, appunto, con la prossima versione.

Non so quale sia la parte dell'OS oggetto della scrittura in .NET so solo che sul mio nuovo portatile con 2GB di ram, senza antivirus mi ritrovo con il 46% di memoria occupata con FF e un paio di finestre aperte.
Se usassi Matlab o Photoshop cosa dovrei fare comprare l'espansione di memoria?

Mi sembra normale: il futuro è managed, e ha poco senso continuare a investire su prodotti che diventeranno presto obsoleti (C# ha già rosicchiato una buona fetta del mercato, e considerato che è un linguaggio molto giovane ha tutte le carte in regole per imporsi).

Per il resto, chi non tira acqua al proprio mulino?

Ma come la mettiamo con il supporto a lungo termine? A lavoro seguo dei progetti nati nel 1998 in VB che già da parecchio tempo sentono il peso degli anni per la mancanza del multithreading e ora per l'impossibilità di girare su Vista. Un analogo programma scritto in C++ non avrebbe di questi problemi.
Sicuro che un programma C# di oggi tra 10 anni non avrà gli stessi problemi?
Non tutti i software sono fatti per durare un paio d'anni.

[mjordan]

Comunque per come la vedo io:

1) Dire che C e C++ sono linguaggi obsoleti e morti è una gran cagata. Nuove API nascono ogni giorno per questi linguaggi e nuove estensioni a tali linguaggi vengono presentate con cadenza regolare. Il GPGPU è appannaggio esclusivo del C cosi come molte altre tecnologie. Diciamo che C sta diventando sempre piu' specifico, non per questo è un linguaggio morto. Stesso dicasi per C++. A sostegno di ciò, sarei curioso di sapere quanti dicono che C è un linguaggio morto e sono fermi al C89 (o peggio ancora al K&R), mentre i rispettivi comitati di standardizzazione stanno per rilasciare nuove spec (e meno male che sono morti).
2) C# da quando Java è stato aperto è diventato molto meno interessante rispetto a prima (e comunque è sempre stato un linguaggio dall'evoluzione molto piu' chiusa di Java in ogni caso).
3) I linguaggi di programmazione e che sono riusciti a sopravvivere nel tempo sono sempre stati quelli che non hanno mai intralciato le palle ad altri linguaggi che dominavano in determinati settori e inoltre sono stati portati con successo su molte piattaforme. C# intralcia le palle a troppi linguaggi e come portabilità su sistemi diversi da Microsoft è ancora un giocattolino accademico (e visto il trend lo rimarrà).

[Ufo13]

Ho una domanda sugli ambienti managed...

Da quello che mi risulta, nei games, la console va sfruttata al 100%... Non parlo tanto di velocità quanto di uso della memoria, per questo spendiamo un sacco di tempo ad elaborare l'allocazione di memoria con lo scopo di ridurre al minimo la frammentazione e svariate altre cose...

Mi chiedo ora.. In ambienti managed cosa succede? .NET per esempio usa la memoria (e altre risorse) come vuole?

Inoltre come sapete i processori hanno istruzioni SSE2/SSE3/ALTIVEC che richiedono strutture dati allineate ed altro. In ambiente managed cosa succede? Puoi sfruttare questi instruction set? Fa tutto .NET / Java?

[Ufo13]

Il GPGPU è appannaggio esclusivo del C cosi come molte altre tecnologie.

Uhm? Noi GPGPU lo scriviamo in HLSL/CG...

Sono d'accordissimo sul fatto che C++ non è proprio morto per niente... Boost porta avanti un sacco di cose interessanti, inoltre pare che sia prevista una nuova revisione...

[mjordan]

Originariamente inviato da Ufo13

Uhm? Noi GPGPU lo scriviamo in HLSL/CG...

Bhè, Cg non significa forse "C for graphics"? Non è forse pesantemente basato su C come sintassi? Comunque io mi riferivo a Cuda, che è molto piu' ad alto livello di HLSL/Cg/GLSL, oltre ad essere piu' adatto al GPGPU (quelli citati sopra sono pur sempre linguaggi pensati per lo shading).
Il futuro del GPGPU è questo e non sarà di certo l'unico esempio. Si possono fare altri milioni di esempi in cui C e C++ sono gli unici e rimarranno tali, per molto ma molto tempo.

Sono d'accordissimo sul fatto che C++ non è proprio morto per niente... Boost porta avanti un sacco di cose interessanti, inoltre pare che sia prevista una nuova revisione...

http://www.artima.com/cppsource/cpp0x.html