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 , , 27 reacties
Bron: Intel, submitter: Femme

Intel heeft gisteren versie 7.0 van zijn compilers uitgebracht. De nieuwe release van deze toonaangevende source-machinecode converters omvat een C / C++ en Fortran compiler, die met name beter zijn geworden in het genereren van efficiënte (en dus snelle) executables. De meeste aandacht gaat echter uit naar de verbeterde optimalisaties voor multithreading, een logisch vervolg op de introductie van HyperThreading-hardware. Software gebouwd met behulp van de nieuwste compilers kan volgens Intel tot veertig procent beter presteren op de nieuwste processors, zoals de Itanium 2 en de HTT-enabled Pentium 4 (ten opzichte van executables gemaakt door een andere compiler).

De compilers kunnen naadloos worden geïntegreerd in respectievelijk Microsoft Visual Studio en Compaq Visual Fortran, maar er is ook een volledig GNU-compatible versie voor Linux beschikbaar voor beide programmeertalen. De overstap kan snel gemaakt zijn. Het CERN meldt dat het 890.000 regels sourcecode na één middag poorten voor Intel versie 7.0 al kon compileren, terwijl een normale compilerwissel ongeveer een week in beslag zou nemen. De C++ compiler kost 399 dollar voor Windows of Linux, de Fortran-versie is echter duurder: 499 dollar voor Windows en 699 dollar voor Linux:

Intel C++ Compiler boxshot Because of Intel's expertise in processor architecture, its compilers have been highly optimized for the Intel Itanium 2, Intel Pentium 4 and the Intel Xeon processors, resulting in a better compiled application for faster operations. Types of applications that will achieve enhanced performance when built using Intel compilers include commercial, transaction-oriented computing, computationally intensive financial, engineering and scientific applications, digital media, gaming and special effects.
Moderatie-faq Wijzig weergave

Reacties (27)

Opzich allemaal leuk en aardig, maar geen optimalisatie voor AMD processoren(logisch, duh). Maar als programmeur weet ik vaak niet op welke processors mijn software gaat draaien. En dus heb ik liever een algemenere compiler, die gebruik kan maken van een aantal slimmigheden op de Intel en op de AMD.

Maar ik hoop dat andere compiler fabrikanten dit oppikken en dit in hun compilers erin plakken, naast de support voor andere processors...
Grappig dat je dat zegt, want in het verleden is wel degelijk gebleken dat AMD processors kunnen profiteren van optimalisaties voor (en door) Intel. Natuurlijk heeft een Athlon weinig aan een optimalisatie voor HyperThreading, maar het al dan niet gebruiken van multithreading is de keuze van de programmeur.
De multi-threading optimalisaties zijn gunstig voor alle gebruikers van een computer met meerdere fysieke of logische processors. Dual Athlon of toekomstige dual Opteron gebruikers profiteren er dus ook van. Mijn twee Athlon processors zullen de optimalisaties in ieder geval erg kunnen waarderen :) .
Bij mijn vorige baan deden wij onze numerieke berekeningen op SGI's en intels. Ik weet dat deze compilers (toen nog beta) voor het intel platform erg veel voordelen konden behalen voor 'ons' type berekening.

Aangezien wij geen AMD's in onze groep maakte het gebrek aan optimalisatie voor AMD niet uit..... Ik kan je echter wel melden dat een benchmark op een AMD ook gunstig uitpakte. Mbv compiler opties kon je ook de mate van optimalisatie en target platform aangeven, plus de compatibiliteitsmate..

Voor een ander type berekeningen maakte de optimalisaties bijna geen klap uit, sterker nog soms klopten de resultaten niet meer. Aangezien dit niet mijn berekeningen niet waren, kan ik niet veel zeggen waar dit aanlag (compiler hij was toen nog beta, algorithme, overdaad aan compiler flags :+).
Als je weet dat 90% ofzo van de bevolking Intel CPU's gebruikt dan is het geen slechte keus om deze ook als uitgangspunt te gebruiken voor optimalisaties natuurlijk.

AMD optimalisaties spelen dan een ondergeschikte rol.
Wat betreft servers: ja. De doeleinden die Intel noemt zijn voornamelijk items waar eigenlijk alleen maar Intel procs worden gebruikt. Maar ze noemen ook gaming en multi media, en daar is het gebruik van AMD wat groter. Gamers willen zoveel mogelijk power voor zo min mogelijk geld...
intel zou behoorlijk dom bezig zijn moest het als doelstelling hebben om amd-procs beter te laten presteren tov van de intel-procs.

relatief goedkope compilers aanbieden die goede optimalisaties hebben voor intel-cpu's hoort ook bij de taken als cpu-fabrikant.
Multithreading lijkt mij voor een dual AMD systeem toch ook wel voordelig, uiteraard ook voor de HT intel CPU, maar dus niet enkel.
multithreading is zelfs voor single CPU systemen nuttig.

Maar ik neem aan dat Intel hier speciale multithreading optimalisaties voor hyperthreading bedoeld ipv voor multithreading in het algemeen.
Ik zie hier eigenlijk alleen grote voordelen voor software die echt heel snel moet zijn, maar waar je wel eisen kan stellen.. (Doom3 zal bijv. niet op zo'n compiler gecompiled worden, want op AMD moet het ook snel kunnen draaien). Dus dit zal het meeste nut zijn voor apps op clusters (rendering/database/etc)
Maar dan zal je ook wel een groot verschil merken, neem ik aan.

edit:
inderdaad, slechter dan normaal zal het in ieder geval niet draaien op AMD.. }:O
maar er zullen ook vast geen amd-specifieke optimalisaties worden gebruikt (en met ASM kan je dus ook nog een hoop)
Ik zie hier eigenlijk alleen grote voordelen voor software die echt heel snel moet zijn, maar waar je wel eisen kan stellen.. (Doom3 zal bijv. niet op zo'n compiler gecompiled worden, want op AMD moet het ook snel kunnen draaien)
Wie zegt dat programma's die met een Intel compiler gecompiled zijn niet snel draaien op non-Intel CPU's?

Het enige wat Intel extra doet is optimalisaties in de compiler stoppen die het programma zoveel mogelijk gebruik laat maken van feature's die Intel in zijn CPU's stopt, daardoor kan zo'n programma idd een erg grote winst boeken op Intel CPU's, maar dat wil dus niet zeggen dat het programma op bijvoorbeeld AMD bagger draait.

Immers is de Athlon volledig IA-32 compatible en kan dus gewoon het programma draaien zonder verlies. En als AMD toevallig feature's zoals SSE(2) gebruikt, profiteerd AMD er ook van.

De nieuwe release is vooral mooi voor de Itanium systemen, aangezien die erg afhankelijk zijn van de compiler in tegenstelling tot IA-32 CPU's. Die doen zelf aan branch-prediction terwijl de Itanium dat karwei aan de compiler overlaat. Daardoor is de de gebruikte compiler erg belangrijk.
Een compiler bepaalt ook de volgorde van de assembly instructies, cache-gedrag, memory access, sprong gedrag, gebruikte instructies, etc. En dat kan voor een Intel of een AMD totaal verschillend zijn.
En niet hellemaal toevallig hebben al die moderne CPU van dezelfde optimalizaties profijt. Ze hebben namelijk allebei langere pijplijnen dan vorige genaties processors. Manieren om die pijplijn gevuld te houden is voordelig voor beide processoren. Misschien profiteert de intel P4 hier meer van dan de AMD XP, maar de amd zal er (9 van de 10 keer) niet op achteruitgaan.

RISC of VLIW processors hebben het veel moeilijker met code die voor een andere generaties CPU's is geoptimaliseerd, maar de x86 CISC processor heeft niet zoveel afhanklijkheden naar de architectuur.

An als een programma een paar % sneller wordt enkel en alleen dorr het door een andere compiler te halen dan zullen niet veel softwareboeren hier moeite mee hebben.
Ik denk dat er wel degelijk een kans bestaat dat Carmack deze compiler kiest voor Doom III. Hij is namelijk iemand van de oude stempel, die nog assembler kan programmeren. Van die kennis maakt hij gebruik om de meest kritieke delen van de engine voor zowel Intel als AMD optimaal te laten draaien. Een compiler zal normaalgesproken niet de assemblercode die met de hand is geschreven omgooien (tenzij je daar expliciet om vraagt misschien), dus maakt het voor dat deel weinig uit.

Wat wèl interessant is, is dat Carmack in de Doom III engine voor het eerst gebruik maakt van multithreading, precies het sterke punt van deze compiler. Dat dat toevallig ook het sterke punt is van de nieuwste generatie Intel-processors en niet van AMD, heeft daar weinig mee te maken. Wie een 3D-engine maakt laat geen 'gratis' extra performance liggen voor het ene platform omdat het andere daar niet op vooruit gaat.

Minpunt is wel dat een x86-64 versie van Doom niet met de Intel-compiler kan worden gebouwd ;). Aangezien daarvoor sowieso een aparte .exe gemaakt moet worden kan hij echter alsnog de Microsoft-compiler gebruiken.
Aangezien de quake engine al van SMP gebruik kon maken lijkt het me uitermate onwaarschijnlijk dat die engine niet multithreaded zou zijn geweest.
De Quake3 Engine is niet Multithreaded.
Wat wel geschikt is voor SMP en Multithreading is de rest. Een dedicated server met Dual processor is dus bijvoorbeeld wel stukken sneller(en kan dus meerdere spelers van plezier voorzien op 1 server).
Het had leuk geweest als Intel de compiler gratis had weggegeven om hun CPU-features te promoten :?. Misschien dat AMD het wel doet.
AMD heeft geen eigen compiler, maar biedt wel een paar compilers van derden aan (voor een vergelijkbare prijs).
Kijk dan maar op http://www.intel.com/software/products/global/eval.htm waar je kan vinden dat er ook 2 manieren zijn om er gratis aan te komen: een 30-dagen demo, en een "Non-Commercial Unsupported Version", die je zo te zien wel onbeperkt voor eigen gebruik kan gebruiken:
The non-commercial license includes access to the Intel® self-help support repository, the Compiler User Forums, and issue submission to Intel® Premier Support. You will not receive the timely response to support issues through Intel Premier Support that commercial customers receive. In addition, the non-commercial license means the compiler cannot be used to produce products for resale or commercial use.
Maar dat is dan alleen voor de Linux versie. Ik kan de Non-Commercial Unsupported versie voor windows niet vinden...

[edit]
Overbodig :? Dus het is niet relevant dat de nieuwe versie van de Intel C/C++ compiler niet gratis is te downloaden voor windows en wel voor Linux?(buiten de trial version om)????
Een beetje fatsoenlijke programmeur die een goede performance wenst die bouwt toch een executable die verschillend draait op een Intel en AMD. Gewoon even scannen wat voor type CPU en daar dan diverse geoptimaliseerde routines voor gebruiken.

Je kunt immers afzonderlijke delen compileren en dan later aan elkaar linken. En per deel dus je optimalisaties instellen mbv compiler directives.
Gewoon even scannen wat voor type CPU

Dat is dus dodelijk. Dan performt je programma misschien niet meer als er een cpu langs komt die je niet kent. Zoals de AMD XP die plotseling SSE2 ondersteunde en al die benchmark programma's die dacht, AMD --> dat doet geen SSE2 , dag performance.

Een beetje programmeur gebruikt algoritmen die sneller zijn op elk platform. En als je dan toch die specifieke optimalisaties nodig hebt dan zal je libraries van een ander (Microrsoft windows directx ofzo) gebruiken die dat al doen.
Zoals de AMD XP die plotseling SSE2 ondersteunde en al die benchmark programma's die dacht, AMD --> dat doet geen SSE2 , dag performance.
Dat is alleen zo als je CPU detectie slecht is, want voor SSE2 test je gewoon een feature flag (en of het OS het ondersteunt) en kijk je niet naar de vendor string.
Het leuke is dat Microsoft hetzelfde deed met de Cyrix detectie in Windows. Alleen ging het toen om het specifiek uitzetten van features (zie websites waar je de patches van kan downloaden voor als je juist die features wilt inschakelen).

Zo dom is het niet, het hoeft maar 1 malig tijdens installatie - ik zou zelfs voor automatische compilatie gaan tijdens install als dat vele procenten zou schelen ten opzichte van 1 general compile van de game-makers....
De meeste fatsoenlijke programmeurs (bestaan ze nog?) kunnen beter eens de algoritmes overdenken. Dat zet meer zoden aan de dijk dan dit soort optimalisaties.

En als het echt om de laatste kloktik gaat, dan moeten de critische stukken beter met de hand gecodeerd worden.

(Neemt niet weg dat dit een leuk extra is, zo'n nieuwe compiler).
Deze compiler is voor iedereen goed geschikt. Zelfs AMD gebruikt bijna altijd de Intel compiler voor haar benchmarks. Zie o.a. hier.

Ik ben zelf benieuwd of we met deze compiler nu ook onder Linux alles kan compilen. Zou graag Gentoo met de Intel compiler compilen :9~
Hierover loopt al een draadje op het gentoo forum. Het blijkt dat de Intel compiler tegenover de GCC compiler in integer berekeningen langzamer is dan GCC maar in floating point sneller. Ook programma's waar vetor gebeuren handig is heeft intel voordeel.
Bijna alle programma's heeft integer berekeningen, dus de GCC compiler is (met uitzondering van specifieke applicatie's) een snelheidsvoordeel.

Ik ben niet zo bekend met die onderwerp die je moet misschien maar eens hier kijken.

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