Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 33 reacties
Bron: C|Net

Sun heeft een nieuwe opensourceprogrammeertaal beschikbaar gesteld. De programmeertaal Fortress is bedoeld voor high-performance computing en is een moderne opvolger van de vijftig jaar oude programmeertaal Fortran.

Fortress maakt gebruik van een interpreter die Java vereist om te kunnen functioneren. De taal is voornamelijk bedoeld voor gebruik in onderzoeksprojecten door onderzoekers aan universiteiten en andere organisaties, aldus Fortress-projectleider Eric Allen. Fortress moet een moderne opvolger worden van de programmeertaal Fortran die in de jaren vijftig van de vorige eeuw door IBM is ontwikkeld voor gebruik op de eerste computers van het bedrijf. De, voor computerbegrippen, antieke programmeertaal wordt tegenwoordig echter nog veel gebruikt voor 'high-performance'-taken zoals het uitvoeren van berekeningen voor weersvoorspellingen en andere simulaties. De ontwikkeling van Fortress is dan ook gefinancierd door de Amerikaanse defensie-afdeling Darpa in het kader van een supercomputerproject.

IBM Mainframe
IBM 704 mainframe, een van de computers waarvoor Fortran werd ontwikkeld.

Fortress is geoptimaliseerd voor gebruik op computersystemen die zijn voorzien van multicoreprocessors. Volgens Sun is het met de huidige programmeertools nog wel mogelijk om dual- en quadcoreprocessors optimaal te gebruiken, maar programmeren voor processors met acht of zelfs zestien cores, zoals Suns eigen Niagara-processor, wordt al een stuk lastiger. Fortress zou vooral in dit laatste domein zijn kracht kunnen laten zien. Een programmeur moet binnen Fortress expliciet aangeven wanneer een stuk programmacode niet parallel moet worden uitgevoerd. Zo zal standaard bijvoorbeeld een lus in programmacode worden geoptimaliseerd zodat meerdere iteraties tegelijk worden uitgevoerd op verschillende processorcores. Daarnaast probeert de programmeertaal de dataopslag zodanig te optimaliseren dat gegevens die een core op korte termijn nodig heeft in de buurt van die core worden opgeslagen, bijvoorbeeld in het cachegeheugen van die core. De specificaties van Fortress zijn nu nog in ontwikkeling en ook de eerste versie van de interpreter, die nu beschikbaar is, is nog niet compleet. Sun heeft plannen om op termijn een compiler voor de taal uit te brengen, die ook uitgebreidere optimalisatiemogelijkheden zou bieden. Tegen die tijd zou Fortress ook breder inzetbaar moeten zijn dan alleen voor highperfomancecomputing.

Moderatie-faq Wijzig weergave

Reacties (33)

Mooi stukje marketing van Sun.
Dit heeft dus geen zier met Fortran te maken.

Alle code moet volledig opnieuw geschreven worden en de sourcecode lijkt ook niet op Fortran.

De enige reden dat er nog Fortran gebruikt wordt is juist dat bedrijven die vreselijk oude code niet opnieuw willen schrijven. Die zitten dus echt niet te wachten op het herschrijven van die code naar Fortress.

Sun wil gewoon meeliften op de naam Fortran.
Ooit was dat de enige taal die goed geschikt was voor moeilijke berekeningen. Maar 10 jaar geleden was het al volkomen achterhaald.

Wat er werkelijk aan de hand is, is volgens mij het volgende:
- Sun heeft processors met heel veel cores.
- Sun loopt tegen het probleem aan dat de huidige multithreading technieken wel geschikt zijn voor een beperkt aantal threads, en dus een beperkte aantal cores, maar niet geschikt zijn systemen met vele tientallen cores.
- Sun moet dus een nieuwe taal schrijven om hun eigen hardware goed te kunnen benutten.
- De potentiele klanten van die nieuwe taal, zijn de bedrijven die zeer grote en complexe berekeningen doen.
Dat zijn bedrijven die vroeger Fortran gebruikten, en vaak nog steeds Fortran gebruiken.

Hoe haal je die potentiele klanten over moet die nieuwe taal te gebruiken? Heel simpel: je doet alsof die nieuwe taal de opvolger van Fortran is.
Met een beetje geluk is de manager die het geld in handen heeft ook nog iemand die al zo oud is, dat ie nog uit de tijd komt dat Fortran geweldig was. (jaren zestig en zeventig)
Sun heeft processors met heel veel cores. Maar die delen één FPU (floating point unit) en zijn daarom volkomen ongeschikt voor wetenschappelijk rekenwerk.

Jammer dat die eenheden op de cell processor een single precision FPU hebben....
Interessant. Dat zou dus betekenen dat ze hun nieuwe taal niet kunnen gebruiken om hun eigen hardware te verkopen aan die klanten?
De Niagara CPU's (en systemen) zijn bedoeld om zware webapplicaties af te handelen waar floating point performance geen issue is.
Inderdaad, de Niagara-1 is vooral bedoeld om een hoge TPS te halen in transaction based systems. Een request afhandelen in een web server geldt dan ook als een transactie.

Een bak gebasseerd op de Niagara-1 moet dan ook vooral "requesten pompen", terwijl het zwaardere rekenwerk aan een andere bak wordt overgelaten die bijvoorbeeld de business logic draait (in zware enterprise systemen) of eventueel direct queries naar een DB stuurt (die dan weer rekenwerk vericht).

Overigens zal de Niagara-2 juist wel meer FP units bevatten. Daarnaast zijn er ook wel testen geweest met de Niagara-1 als DB server (waar is dus niet voor bedoeld is, maar als test dus), en die presteerde natuurlijk inderdaad niet super, maar ook weer niet zo ongelooflijk slecht.
Klopt. De Niagara CPU's (en systemen) zijn bedoeld om zware webapplicaties af te handelen waar floating point performance geen issue is. Bij de cores is dus bezuinigd op FP units. Dankzij deze bezuinigingen krijgt Sun het voor elkaar om zoveel cores op een chip te bakken (geloof me: bij Intel zijn ze echt niet achterlijk).
Dus jawel: ongeveer de laatste CPU die ik mijn "High Performance" systeem zou willen hebben is zo'n multi-core Sun CPU.

Hugo
Door gebruik te maken van een inerpreter verkwist je imho veel van de snelheid die je door multicore zou willen bereiken.
Door gebruik te maken van een inerpreter verkwist je imho veel van de snelheid die je door multicore zou willen bereiken
Nee hoor, in een extreem voorbeeld:

Stel dat de interpreter een vertraging van 2x veroorzaakt, maar dat je door het inzetten van 16 cores een 14 voudige speedup kunt bereiken.

Dan is je gemiddelde speed-up nog steeds een factor 7.
x / 2 * 16 = 14 / 2 = 7 Het enige wat mij dit zegt is dat x = 1,75 en dat dat een heel vreemd getal is om zo'n vergelijking mee te beginnen. Ik denk dat Grzzl bedoeld dat als de interpreter een factor 2 vertraagd de helft van je cores iets oneigenlijks aan het doen zijn.
Ik denk dat Grzzl bedoeld dat als de interpreter een factor 2 vertraagd de helft van je cores iets oneigenlijks aan het doen zijn.
Nee, zo simpel is het niet.

Een interpreter kun je zien als een soort super-managed omgeving. Die kan runtime heel veel beslissingen maken over hoe code verdeeld moet worden, en dus ook hoe de code het beste geparallelliseerd kan worden.

Nu zou je theoretisch deze beslissingen als programmeur ook zelf kunnen maken, maar je code wordt daardoor dikwijls te complex. Gevolg is dat veel, en dan bedoel ik echt VEEL programmeurs het er maar bij laten zitten en hun code sequentieel houden. Daarnaast weet je als programmeur ook niet altijd van te voren of jouw code op een single, dual, quad, of 16-way bak zal gaan draaien. Daar moet je dan weer extra code voor gaan schrijven die dat allemaal bijhoudt.

Last but not least kun de user ook nog eens andere programma's op z'n bak tegelijk draaien. Als code op een dual bak draait, en de gebruiker heeft 1 core al 75% belast, dan kan het veel effecienter zijn om je code NIET in 2-en op te splitsen, maar zolang als die ene core bezit is, juist expliciet sequentieel houdt.

Code om al die beslissingen te maken kost ook niet nix aan performance. Deze interpreter belooft dat allemaal al voor je op te lossen.

Ik snap dat het in leken oren heel raar klinkt dat een X percentage van je totale CPU aan overhead opgaat, maar dat is nu eenmaal een realiteit bij parallel programmeren, interpreter of niet. Als je bijvoorbeeld nu bekijkt wat een OO omgeving, dynamische talen, plug-ins etc, niet allemaal aan overhead kosten t.o.v. bare metal programmeren.

Als je totale speed-up (in performance of in development time) nog steeds groter is dan zonder deze systemen, dan is het potentieel de moeite waard.
Tenzij dat geaccelereerd is door de CPU of een co-processor is dat ook al rete traag vergeleken met een native binary
Je weet niet waar je het over hebt.

Managed talen zoals Java en C#, en eigenlijk alles wat ge-JIT wordt is helemal niet per definitie rete traag. Doormiddel van een JIT is het juist mogelijk om run-time optimalisaties te maken, deze zijn meestal van een type die je statisch helemaal niet kunt maken.

Als simpelste voorbeeld kun je een branch prediction nemen. Een statische compiler weet niet welke kant de brach opgaat. Een dynamische compiler echter kan run time informatie gebruiken, en de branch zo herschrijven dat de common case het snelle pad is, en de uncommon case het langzamere pad.

Code die je op een high performance VM draait, zoals de JVM, kan zeer sterk optimaliseren. Diverse algoritmen draaien er dan ook daarwerkelijk beter op.

Dat JITted code langzamer zou zijn is net zo'n fabeltje als dat handcrafted assembly per definitie sneller is dan compiled code (bv C of C++). Think again, moderne CPU architecturen worden tegelijk ontwikkeld met compilers. In zekere zin is de moderne compiler de frontend voor de CPU, en niet de ABI. Vroeger was dat juist andersom. De ABI was helemaal ingericht op de menselijke programmeur en begon langzaam op een high-level programmeer taal te lijken. Compilers waren A nog niet advanced genoeg, en B konden voor een dergelijke complexe interface slecht code genereren, Tegenwoordig met super-scalair architecturen en hun out of order execution is low level assembly programmeren helemaal niet meer per definitie sneller.

Terug naar de VM wereld; er zijn zelfs zogenaamde native re-compilers beschikbaar. Deze doen eigenlijk nix anders dan wat een VM doet: assembly pakken en run-time (re)compilen. Het enige verschil is dat een native re-compiler van native naar (dezelfde) native code compiled, en een VM zoals de JVM van de ene assembly naar de andere.

Het resultaat is in beide gevallen echter hetzelfde: winst door het uitbuiten van run-time kennis.
@flowerp
Interpreter, ala, je legt net uit waarom...
maar waarom dan in Godsnaam in Java???

Tenzij dat geaccelereerd is door de CPU of een co-processor is dat ook al rete traag vergeleken met een native binary.
@flowerp

Die run-time optimalisatie van de Java interpreter wordt al sinds het prille begin van Java beloofd, maar tot op heden is er geen enkele serieuze stap in die richting genomen en zijn er ook voor andere interpreted talen nog geen run-time optimizers die ook maar enigszins in de buurt komen van precompiled code. Uitbuiten van run-time kennis is een theoretisch voordeel dat zich in de praktijk absoluut nog niet wordt behaald.

Her-compilatie is een leuke speed-up maar op het moment dat je JVM bytecode gaat vertalen naar native bytecode heb je geen beschikking meer over de broncode. Dit gebrek zorgt ervoor dat je bepaalde high-level optimalisaties niet meer optimaal uit kan voeren; de bytecode bevat enkel hóé iets moet gebeuren, niet wát de bedoeling was.

Het is jarenlang beloofd dat Java de snelheid van precompiled code zou halen, en ikzelf heb er ook jaren in geloofd. Maar op een bepaald moment zal je toch toe moeten geven dat 't gewoon nog steeds trager is.

Dus; in theorie heb je gelijk dat Java even snel zou kunnen zijn. Echter, in de praktijk draait Java véél langzamer.
Dus; in theorie heb je gelijk dat Java even snel zou kunnen zijn. Echter, in de praktijk draait Java véél langzamer.
No offence, maar ik denk dat die praktijk alleen bestaat uit de beleving in jouw hoofd.

Geen enkele (wetenschappelijke) benchmark bewijst wat jij beweerd. Sterker nog, het zelfde algoritme performed in een Java implementatie zelfs in een aantal gevallen beter dan een compiled C++ versie, waarbij voor de C++ versie dan gewoon aggresieve optimalisatie flags zijn gebruikt.

Google er zelf maar eens op en je zult verbijsterd staan ;)
Java blijkt in benchmarks ondanks zijn JVM juist onverwacht snel in wetenschappelijk rekenwerk. Zo'n programma houdt zich typisch bezig met double precision floating point bewerkingen binnen een aantal geneste for-loops. De loops worden door de JIT compiler gecompileerd. En het berekenen van die FFT's in double precision (waar het programma de meeste tijd aan spendeert) gebeurt in een zwaar geoptimaliseerde "native" floating point library.
Waarschijnlijk word er gedacht dat de interpreter stap maar een kleine is in vergelijking met de executie van het programma. Het feit dat 't goed schaalt belangrijker dan de initiële kostten. De overhead zal wellicht te groot zijn als je het op 1 processor draait, maar zodra je er 16 processors tegenaan gooit is die overhead verwaarloosbaar zijn.
Door gebruik te maken van een interpreter kun je een nieuwe programmeertaal veel sneller de wereld in helpen. Het schrijven van een interpreter vergt veel minder werk dan het schrijven van een compiler. De executiesnelheid van een interpreter ligt wel enkele malen lager, maar deze aanpak kan wel de kracht van de taal demonstreren.
Veel talen hebben in eerste instantie alleen een interpreter ter beschikking (Java bijvoorbeeld, de JIT compiler is slechts van de laatste jaren)
8 jaar geleden vind jij "de laatste jaren"?
Java bestond toen nog maar amper!!
Het grootste voordeel van Fortran, en de enige reden dat het nog gebruikt wordt, is de performance. Dat de Java interpreter niet veel overhead zou hebben (zoals anderen beweren) betekent dat er IETS aan overhead zou zijn, waardoor de taal niet meer sneller zou zijn dan equivalent aan gecompileerde C/C++, Pascal of Cobol en het dus zijn bestaansreden verliest.
hmmm, dat zou wel eens boeiend kunnen zijn voor het bedrijf waar ik werk. Alleen moeten dan bijna alle apps omgebouwd worden. Jammer.
Als alle apps omgebouwd moeten worden, in hoeverre kan het dan interessant zijn? Ombouwen is $$$DUUR$$$ en (meestal) inefficiënt (omdat legacy meestal ook niet meer 100% aansluit op de behoeften).
Dat is dan ook precies de reden waarom dat vreselijk verouderde Fortran nog gebruikt word.

10 jaar geleden was Fortran al op sterven na dood. Alleen bedrijven zoals Shell etc, hadden nog ontzettend veel grote software die geheel in Fortran geschreven was. En opnieuw schrijven was gewoon niet de moeite waard.
(vandaar dat ik toen nog Fortran77 moest leren :()
In de wetenschap (zeker als er natuurkundigen bij zijn betrokken) wordt Fortran nog steeds veel gebruikt. Ik gebruik bijna dagelijks Fortran software en ik ben bepaald niet de enige.
Ook wel eens gevraagd waarom die taal nog gebruikt wordt?

Ik heb het ook voor mijn geofysica studie moeten leren, maar zoals ik al zei was het toen al achterhaald.

C is bv veel plezieriger, en levert net zo snelle code af. Maar er zaten daar een stel oude docenten die met Fortran opgegroeid waren, die er geen genoeg van konden krijgen. (en het ergste was nog wel dat we Fortran77 moesten leren ipv Fortran90)

Als je een nieuw stuk software gaat schrijven is er geen enkele goede reden om Fortran te gebruiken, en een heleboel redenen om het niet te gebruiken.
Als je al Fortran gebruikt, dan is dit een interessante ontwikkeling om in de gaten te houden. Doe je dat niet, dan heb je blijkbaar Fortress niet al te snel nodig.

Sommige groepen doen hun rekenwerk in C++, omdat Fortran zo zijn (ouderwetse) ristricties heeft, maar misschien dat Fortress hier een steentje kan bij dragen. Ik ben benieuwd in iig (8>
Er is geen rekening gehouden met backward compatability. Dus ik zie het als een nieuwe taal. Niet zoals C++ en C# een doorontwikkeling zijn op C.
C++ is ook niet op alle fronten backwards compatible en C# is het überhaupt niet.
Er is een sterkere relatie tussen C, C++ en C# dan tussen Fortran en Fortress. Dat is het punt waar het om gaat. Als je over backward compatablitiy gaat praten en dan C# als volledig niet backward compatible beoordeeld, dan krijg ik het idee dat je doelt op .NET eigenschappen waarbij gebruik gemaakt wordt van een Common Language Runtime. Er zijn wel degelijk backward compatible taalonderdelen in C#. Was het niet Bjarne Soustrup himself die in C# slechts 17 uitbreidingen onderkende die min of meer als bedrijfsspecifieke (M$) extensies gezien zouden kunnen worden ? Je reaktie lijkt slechts gericht op het afbranden van een eerdere reaktie waarbij je het punt waar het om gaat over het hoofd ziet.
ja wat had je dan verwacht als je een andere programmeer taal gaat gebruiken? :z
Denk dat er eerder sprake van zal zijn van nieuwe applicaties die in Fortress geprogrammeerd zullen worden. En inderdaad als je dan code wilt hergebruiken zal er wat omgeschreven moeten worden.

Als een huidige Fortran applicatie goed werkt (op 1 of enkele cores) is er weinig reden waarschijnlijk om hem om te bouwen voor 16 cores of zo.
Zo zal standaard bijvoorbeeld een lus in programmacode worden geoptimaliseerd zodat meerdere iteraties tegelijk worden uitgevoerd op verschillende processorcores.
Dat lijkt me een slecht voorbeeld. Bij iteraties is de volgende stap afhankelijk van de vorige. En dat kun je juist niet paralleliseren.
De berekening van een pixel voor een fractal kun je bijvoorbeeld niet paralleliseren. Je kunt wel meerdere pixels tegelijkertijd berekenen, zolang ze niet afhankelijk zijn van de uitkomst van zijn buren.
kan ik tetris mooi hierin programmeren :+
Heb groot respect voor u, Dames en Heren Programmeurs!!!


Mij lukt het nog niet om wat in GWbasic te schrijven...

En van alles wat hier werd besproken snap ik geen jota...

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True