Hoofdcategorieën
Device Settings

Intel helpt Linux-code te verbeteren

Door Gabi Gaasenbeek, donderdag 16 januari 2003 21:01
Bron: C|Net, views: 683

Intel heeft dinsdag nieuwe software aangekondigd waarmee ontwikkelaars van programma's voor Linux hun producten beter kunnen afstemmen op de Xeon en Pentium 4 processoren. Volgende week zal het bedrijf de Linux versie van het pakket genaamd VTune presenteren op de dan te houden LinuxWorld conferentie. Het programma is er al in een versie die op Windows systemen draait, de Linux programmatuur wordt dan op afstand in de gaten gehouden. VTune zal de aandacht richten op delen van de code die veel resources, zoals bijvoorbeeld geheugen, gebruiken. De Linux versie van VTune zal in februari verkrijgbaar zijn en zal werken met verschillende versies van Red Hat. Een testversie met ondersteuning voor SuSE en UnitedLinux staat voor het komende kwartaal op de planning:

Intel Xeon MP (klein)The Linux version of VTune, available in February, lags its Windows cousin in some ways. The Windows version has a graphical interface, works with more versions of Linux, and can monitor software running on Itanium processors. The Linux version will support Itanium computers later this year, McLaughlin said.

Intel's VTune software works with several versions of Red Hat's Linux. Intel is planning a test version later this quarter that will work with Linux from SuSE and its UnitedLinux business partners.
Volgende 22:45 Intel begint eerste tests voor 0,065 micron procédé
Vorige 20:39 The Inquirer over details Hammer-chipset nVidia
Advertentie

Reacties

«  1  2  »

Oei leuke stap voorwaarts voor intel. Hiermee halen ze zeker weten een stuk extra marktaandeel binnen. Ben benieuwd wat het antwoord van AMD zal zijn.

Wat bedoel je precies met marktaandeel? Denk je nou echt dat meer servers nu Linux gaan draaien omdat Intel een tooltje heeft uitgebracht waarmee ontwikkelaars applicaties kunnen optimaliseren voor de Intel procs? Ik denk het niet. Het is alleen wel fijn dat dit soort tooltjes ook voor Linux uitgebracht worden, dat is alleen maar positief. Maar verwacht van een profiler (want dat is VTune toch?) niet meer dan een paar procentjes winst qua snelheid enzo :)

Wat bedoel je precies met marktaandeel? Denk je nou echt dat meer servers nu Linux gaan draaien
Omg, hij heeft het over Intel ! Volgens mij is Intel een grote processor fabrikant, en niet een Gnu/Linux distributeur. Ik heb zo'n donkerbruin vermoeden dat het marktaandeel dus refereerde aan de hoeveelheid processors die de Intel-fabs verlaten. Maar een Intel Gnu/Linux distro kan natuurlijk nog komen :) Hell, ieder beetje ondernemend bedrijf brengt tegenwoordig een distro uit, of werkt er aan mee :P

>Ben benieuwd wat het antwoord van AMD zal zijn.
AMD en UnitedLinux zullen gaan samenwerken bij het porten van Linux software naar de x86-64 instructieset. Op die manier hoopt AMD de vraag naar zijn 64-bits Athlon 64 en Opteron processors te stimuleren. AMD werkt op dit gebied al tweeënhalf jaar samen met SuSE Linux:
http://www.tweakers.net/nieuws/25116

AMD heeft al lang een antwoord, in de vorm van het geschikt maken van linux voor de I64 instructies van de Hammer... Ik denk eerder dat dit een antwoord van intel daarop is.

Ux fanaten vinden het vast allemaal best :)

't Is idd een stap voorwaarts, een stap voorwaarts voor Linux. Meer en meer wordt linux nu serieus genomen, in dit geval dus door een grote hardware producent.

Intel heeft altijd al achter linux gestaan, dit bewijst dit alleen nog maar is. Of ze er zelf veel baat bij hebben betwijfel ik echter wel...

~Progster

Ik dacht dat alleen Intel en Microsoft twee handen op 1 buik waren :). Hopelijk komt HT ondersteuning voor de Linux kernel snel en nog voor dat de volgende stable uitkomt (kernel 2.6.x).

Het is natuurlijk ook een reden voor AMD om niet achter te lopen op intel. Er is al een x86-64 project voor de linux kernel. Hopelijk snel meer.

Ze maken alleen maar een compiler en een profiler voor linux hoor, meer niet.
En die moet je nog kopen ook :)
Wel goed dat die software er is trouwens, ik vind ICC 7.0 erg goed, is vast beter dan gcc.

wat weer een heerlijk onderbouwde posting:
ik vind A goed, hij zal wel beter zijn dan B.

en verder niets

zal wel een troll worden maar ik vind dat er vaak postings geplaatst worden zonder enige argumentatie/onderbouwing, het is hier toch geen babbelbox

Ik druk een vermoeden uit...
ICC is een stuk beter dan VS.NET, en VS.NET is niet de minste compiler.
Ik weet bijna zeker dat ICC beter is dan gcc.
Sterker nog, ICC MOET beter zijn dan gcc, hoe gaat Intel het anders verkopen?
Ik had trouwens elders al iets gemeld over de prestaties van ICC, dus dubbelposten leek me wat overbodig.
Ik heb nou eenmaal geen zin om altijd alles te onderbouwen en te verantwoorden. Sommige dingen zijn nogal evident, andere dingen kunnen toegelicht worden als iemand daarom vraagt, maar ik heb geen zin om bij voorbaat ellenlange posts te gaan maken waarin ik alles helemaal voorkauw, daar heb ik ook niet altijd tijd voor.

Jij bent de troller hier trouwens.
Zeker een pro-linux/opensource gast die er niet tegen kan dat gcc misschien niet de beste compiler ter wereld is? Jammer voor je, maar val mij daar niet mee lastig.

Intel heeft complete fabs puur op linux lopen.


waarom is Gentoo zo'n goede linux distrubitie (oa)? Omdat het alles compileerd voor jouw computer! je snelheids winst is zeer groot, en dat is zeker de moeite waard (imho). En als je de source heb, kan je alsnog het voor een andere PC compileren, is het niet?
Ow, en AMD en INTEL zullen echt niet zo veel gaan verschillen kwa instructies, snijden ze alleen maar hunzelf mee in de vingers. Iemand verzint iets? De ander brengt er wel weer support voor uit.

Ik ben zelf ook een fanatiek Gentoo gebruiker maar dat moet ik toch even ontkrachten ;)

Gentoo geeft een minieme snelheidswinst. Het gaat echt om fracties van seconden. Dat maakt het natuurlijk niet minder leuk :)

Prelinking heeft wel een redelijk grote impact, maar het feit blijft dat g++ code zeer traag is (jammer) in vergelijking met andere compilers.

Persoonlijk dat dit pakket dat 700 dollar kost enkel interessant is voor mensen met renderfarms die op Intel gebaseerd zijn. De thuisgebruiker heeft er niets aan.

Verder moet ik opmerken dat de Intel compiler voor GNU/Linux helemaal niet slecht is ! (Ik gebruik hem echter niet wegens non-free).

waar is dan de intel support voor 3dnow! ? ;( dat verhaal van je klopt dus niet!! in de toekomst voorzie ik alleen maar meer gerotzooi met specifieke instructies, natuurlijk allemaal beschermd met patenten en merk-registraties..

Ehm... de software wordt toch tegenwoordig op basis van de OS geschreven die het op zijn beurt via de kernel vertaalt naar de processor of zie ik dat nu verkeerd ?
Is toch ook de reden dat goed geprogrammeerde Windows software ook op de Alpha NT-versie werkt :?

Maar ik snap het wel... De huidige processoren performen het beste via de optimalisatie, zie ook de FlaskMPG testen bij Tomshardware tussen de P3 en de P4 zo'n 2 jaar terug. Daar bleek een P4 ge-optimaliseerde FlaskMPG ineens veel sneller te werken dan een standaard i386 versie.

Nu steeds meer bedrijven zich gaan afvragen als de steeds meer populaire Linux beter is dan de dure licentieconstructies die MS kent is het een markt om goed erin te springen.
Intel wilt door die optimalisatie natuurlijk aantonen dat hun procs/servers de snelsten zijn in die combinatie.

AMD zal vast en zeker snel volgen om op "cijfertjes" niet achter te lopen....

Nou .. ik kan je verzekeren dat er maar ZEER weinig OS-sen met enig marktaandeel zijn die op die manier werken hoor.. Alles wordt nog steeds keurig naar machinecode gecompileerd. Een OS heeft vaak wel heel wat standaard functies in bibliotheken die een applicatie behoorlijk inkorten (qua binary code, en alleen als je een dynamische link maakt) maar alles wordt uiteindelijk allemaal mooi nulletjes en eentjes direct bedoeld om als machinecode door een proc te worden ... eh.. verwerkt.
Alleen enigszinds bekend is .NET wat probeert met een tussentaal op verschillende hardwareplatformen te draaien. En je hebt natuurlijk de interpretertalen als JAVA, maar ik ken nog geen OS die geheel uit JAVA en een smalle binary kernel om alles te interpreteren is opgebouwd. Zal ook behoorlijk traag worden :+ ... Ik denk dat Transmeta's Crusoe ook wel aardig in de buurt komt, maar dat is meer een hardware oplossing. (die "Interpreteert" x86 code, of andere machinetaal, voor zijn eigen VLW processor)

Alpha NT heeft een x86-emulator subsystem.
Als je je sourcecode netjes hebt geschreven (geen vieze 32-bit-only pointer-grappen), dan kun je het zo recompilen voor native Alpha, en is het veel sneller.
AMD zal vast en zeker snel volgen om op "cijfertjes" niet achter te lopen....
Ik denk niet dat AMD op korte termijn een compiler-divisie op kan zetten, die kan gaan concurreren met Intel. Daar hebben ze de resources niet voor.
Ze kunnen maar beter zorgen dat hun CPUs niet te veel verschillen van de Intels, zodat ze Intel-code efficient kunnen verwerken... Het grote verschil tussen de Hammer en de P4 kan nog wel eens de achilleshiel van AMD worden op deze manier.
Alleen enigszinds bekend is .NET wat probeert met een tussentaal op verschillende hardwareplatformen te draaien. En je hebt natuurlijk de interpretertalen als JAVA
.NET en Java werken op precies dezelfde manier.
Java wordt niet geinterpreteerd, het wordt at runtime door een JIT-compiler gecompiled. Een Java 'binary' bevat Java-bytecode, die heel sterk lijkt op de MSIL-bytecode van .NET :)

Ik gebruik ICC 7.0 voor Windows op mijn Athlon, en haal er aanzienlijke winst mee (zeker 10-20%) tov. Visual Studio.NET.
Ik zou er niet raar van opkijken als ICC 7.0 voor linux ook beter is dan gcc (vooral met MMX/SSE code) voor Athlon.
Verder kan de compiler meerdere geoptimaliseerde codepaden in een enkele binary stoppen als je dat wilt, zodat de code op alle CPUs (goed) loopt.

hoe verkoop je meer chips

je zorgt dat de software-makers het makkelijk hebben

net als bij de xbox

In hoeverre gaat dat, dat op elkaar afstemmen?
Of is het alleen een marketing truc, om er gewoon een mooi labeltje bij te plakken?

[edit: typo]

wow luux!

wel apart eigenlijk...

Prima stap van Intel. Zo zie je maar dat in een matige markt er opeens allemaal nieuwe ideeën opgang vinden. Als Intel's chips het ook goed doen met Linux dan is het in landen die van open source houden ook beter zaken doen.



Win9x zal niet geoptimaliseerd zijn voor een P4 of Athlon, want die bestonden toen nog niet eens :)

Als je in de C library van VS.NET gluurt, zul je een hoop optimalisaties vinden, waaronder SSE2.

DirectX heeft ook optimalisaties voor MMX, SSE en SSE2.
Bij DLLs werkt het zo dat de eerste functiecall naar een processor-detectie-routine gaat. Daar wordt bepaald welke code er gedraaid moet gaan worden. Daarna worden alle functiepointer-tabellen geinitialiseerd met de meest optimale versie van de functies, en hop, het is geoptimaliseerd voor je CPU.
(je hebt je kernel het liefst compleet in je werkgeheugen op wat modules na mischien voor randapparatuur, en je krijgt op bovenstaande manier een inefficiente, logge, geheugen vretende kernel met lekker veel onnodige long jumps etc. etc. etc. Oh wacht dat IS windows ... sorry moest er even uit )
Heel simpel, zet iedere versie van de code op een eigen memory page (read-only). Dan worden de ongebruikte pagina's gewoon nooit ingeladen.
Als ze al ingeladen worden, kunnen ze zo weggegooid worden als ze niet meer gebruikt worden. Omdat ze read-only zijn, hoeven ze niet naar de swapfile geschreven te worden, omdat ze toch niet veranderd kunnen worden. Bij een eventuele swap-in kunnen ze dus uit de originele binary geladen worden.
Windows werkt al jaren zo, dit is de kracht van DLLs. Efficient gebruik van code.

Het programma is er al in een versie die op Windows systemen draait, de Linux programmatuur wordt dan op afstand in de gaten gehouden
Dit lijkt wel op een spyware programma. Als dit al een tijdje in windows zit dan weten ze alles van je systeem. (als je af en toe op on-line bent)...... :(

Kunnen ze niet gewoon mee helpen met de GNU compiler omdaar de code nog beter te optimizen voor Intell ?
Lijkt me namelijk veel beter om het direct op compile time te doen dan op runtime.

Er zijn dingen die alleen tijdens runtime zichtbaar zijn. Stel dat jouw programma dynamisch duizenden objecten aanmaakt, dan hoeft de compiler dat nog niet te weten tijdens het compileren. Maar als tijdens runtime blijkt dat het toch wel een ontzettende belasting voor dit-of-dat onderdeel is, DAN kun je er wat aan doen.

Niet dat jouw idee slecht is... Maar het is iets heel anders, en het ene zou het andere niet uitsluiten.

Nu ik erover nadenk, herinner ik me wel dat een vriend van me zei dat hij een speciale C++-compiler van Intel gebruikte, die speciaal optimizede voor zijn processor. Weet alleen niet meer welke processor dat was (P4 of Itanium).
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 22:45 Intel begint eerste tests voor 0,065 micron procédé
Vorige 20:39 The Inquirer over details Hammer-chipset nVidia
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011