mboost-dp1
unknown
hvis AMD har ret i et eller flere af anklagepunkterne, vil jeg mene det er en ret stor svinestreg fra intels side... men som vi kan se, sidder intel jo ret godt i det og er sikkert gode venner med regeringerne rundt omkring, så det bliver nok ikke i USA at intel får nogen hug, højst ved en EU domstol...
Det lyder ikke så fedt, hvis det er rigtigt. Intel vil sikkert forsvare sig med at de "ekstra" kodeveje blot er for at sikre kompabilitet med andre processorer, eller noget i den stil.
#1 Du har fuldstændig ret. Da jeg skrev nyheden, havde jeg flere kilder oppe at vende, men besluttede mig på at vælge BusinessWeek, da jeg kender den bedst.
Desværre var følgende ikke med hos BusinessWeek. (Kilden er Reuters, som jeg desværre ikke havde set før nu.)
Ret skræmmende at den amerikanske regering ikke tager misbrug af monopol særligt seriøst. Måske har Intel købt for mange senatorer? Hvem ved. Jeg er bare glad for at EU ikke er lige så korrupte.
Desværre var følgende ikke med hos BusinessWeek. (Kilden er Reuters, som jeg desværre ikke havde set før nu.)
Japan has also acted against Intel, but U.S. authorities have expressed little interest in becoming involved. Antitrust authorities in the United States have said that abuse of dominance or monopolization cases are their lowest priority, after cartels and mergers.
Ret skræmmende at den amerikanske regering ikke tager misbrug af monopol særligt seriøst. Måske har Intel købt for mange senatorer? Hvem ved. Jeg er bare glad for at EU ikke er lige så korrupte.
Må da nok sige at AMD har hevet nogle ret alvorlige anklager frem. Man må ikke gå ud fra at de gør dette, uden at have beviserne til at bakke sagen op. Er det tilfældet så vil jeg da nok mene at Intel er gået noget over stregen.
Det bliver spændende at se hvordan sagen udvikler sig, det skulle ikke undrer nogen hvis Intel kommer med et kontra-sagsanlæg.
Det bliver spændende at se hvordan sagen udvikler sig, det skulle ikke undrer nogen hvis Intel kommer med et kontra-sagsanlæg.
#6 barnligt ? hehe... nej det er sgu benhård forretning, de er jo en profit-maksimerende virksomhed - alle kneb gælder (også dem under bæltestedet (hvis de ikke bliver opdaget)). Det er jo ikke småpenge der er på spild.
Ikke dermed sagt at det ikke er noget af en svinestreg hvis det skulle holde vand...
Ikke dermed sagt at det ikke er noget af en svinestreg hvis det skulle holde vand...
"Ydermere påstår AMD også, efter at have undersøgt Intels compiler nærmere"
I hvilke situationer bruger man den? Måske bare mig der ikke ved nok, men har AMD ikke også en man kan bruge eller??
I hvilke situationer bruger man den? Måske bare mig der ikke ved nok, men har AMD ikke også en man kan bruge eller??
Som der står i diskutionen på slashdot:
Jamen hvad er det så AMD brokker sig over? Så må de jo selv lave en compiler der kan udnytte de functioner deres CPU har som en Intel ikke har. Det kunne jo være at Intel drager nytte af at vide hvad deres specs er og derfor kan optimere bedre til deres egen? Og hvis den så finder ud af at det ikk er en Intel, må de jo tage deres forholdsregler mod at koden også kan køre på en Via CPU f.eks.
Pretty much anyone who wants fast 32Bit code uses the Intel Compilers, even on AMD
yes, ICC generates faster code even on AMD-CPU's than GCC (for example) does. But that's not the point AMD is making. AMD claims that ICC detects whether the CPU is an AMD-CPU. If it is, it generates slower executables, even though there's no real technical reason to do so. It does so merely to put AMD at a disadvantage. Yes, the code might still be faster than GCC-generated code (you could say that it tells quite a bit about GCC as well....), but it's still crippled when compared to Intel-code.
Jamen hvad er det så AMD brokker sig over? Så må de jo selv lave en compiler der kan udnytte de functioner deres CPU har som en Intel ikke har. Det kunne jo være at Intel drager nytte af at vide hvad deres specs er og derfor kan optimere bedre til deres egen? Og hvis den så finder ud af at det ikk er en Intel, må de jo tage deres forholdsregler mod at koden også kan køre på en Via CPU f.eks.
#11
Tja, du er meget god til at spille djævlens advokat og det er et validt argument (måske rigtigt, hvem ved), men hvis man ser på de ideologiske forskelle på USA og Europa så har EU det med at være mere markedsregulerende, hvorimod USA's ideologi plejer mere at være "hands-off".
Tja, du er meget god til at spille djævlens advokat og det er et validt argument (måske rigtigt, hvem ved), men hvis man ser på de ideologiske forskelle på USA og Europa så har EU det med at være mere markedsregulerende, hvorimod USA's ideologi plejer mere at være "hands-off".
Der er en fejl i nyheden, hvor det fremsættes således at "fejlen" (kald det hvad man vil) kun er rettet mod AMD processorer.
Dette er ikke korrekt.
Assemblerkoden tjekker på processorens navn, og hvis der ikke ses "Genuineintel" så benyttes SSE ikke korrekt, hvilket resulterer i "store" performance tab :/
Og nu til min kommentar:
Jeg troede seriøst ikke at intel var så sleske - da de lavede tricket med at booste MHz'ne for at give folk en falsk tro om at intels processorer var hurtigere blev jeg harm og valgte ikke at købe intel i lang tid pga dette - nu har de givet mig en god grund til at hade dem længe endnu... tsk tsk.
Dette er ikke korrekt.
Assemblerkoden tjekker på processorens navn, og hvis der ikke ses "Genuineintel" så benyttes SSE ikke korrekt, hvilket resulterer i "store" performance tab :/
Og nu til min kommentar:
Jeg troede seriøst ikke at intel var så sleske - da de lavede tricket med at booste MHz'ne for at give folk en falsk tro om at intels processorer var hurtigere blev jeg harm og valgte ikke at købe intel i lang tid pga dette - nu har de givet mig en god grund til at hade dem længe endnu... tsk tsk.
Ikke helt uventet, eftersom der længe har været rygter og påstande om, at Intel enten tvinger store firmaer til at bruge deres processorer, eller giver tilbud der er under produktionsprisen, som AMD forståeligt nok ikke kan konkurrere med.
Desværre er der jo risikoen for, at det i sidste ende rammer os forbrugere, da enhver krone ud af Intels pung, skal dækkes et andet sted.
Min ros til raz0 for den velskrevne og velresearchede nyhed. Dejligt at se lange oversættelser, i stedet for engelsk c/p :)
Desværre er der jo risikoen for, at det i sidste ende rammer os forbrugere, da enhver krone ud af Intels pung, skal dækkes et andet sted.
Min ros til raz0 for den velskrevne og velresearchede nyhed. Dejligt at se lange oversættelser, i stedet for engelsk c/p :)
Desværre er der jo risikoen for, at det i sidste ende rammer os forbrugere, da enhver krone ud af Intels pung, skal dækkes et andet sted.
Hvorfor går det ud over forbrugeren de kan bare vælge en anden CPU at købe, mener stadig vi er et frit land og selv må vælge hvad vi køber..
#15
Hvorfor går det ud over forbrugeren de kan bare vælge en anden CPU at købe, mener stadig vi er et frit land og selv må vælge hvad vi køber..
Missing the point here. Nogle folk foretrækker Intel, og det ville da være surt for dem, hvis de skal til at betale mere for deres processorer, fordi Intel bryder monopollovgivningen, og derfor får en bøde? Om de kan skifte til en anden, er egentlig min pointe uvedkommende.
Jamen hvad er det så AMD brokker sig over? Så må de jo selv lave en compiler der kan udnytte de functioner deres CPU har som en Intel ikke har. Det kunne jo være at Intel drager nytte af at vide hvad deres specs er og derfor kan optimere bedre til deres egen? Og hvis den så finder ud af at det ikk er en Intel, må de jo tage deres forholdsregler mod at koden også kan køre på en Via CPU f.eks.
Hele essencen er jo netop, at de selvsamme optimeringer til intels cpu fungerer lige så godt på AMDs som på Intels processorere, derfor er det jo direkte til grin, at Intels compiler vælger alternative og performance nedsættende codepaths, hvis en hvilken som helst anden cpu end lige intel dukker op.
I noticed this problem back in January of 2004, with Intel C++ 8.0, and went through heck over nine months with Intel's customer support to get it fixed until I eventually had to abandon their compiler.
They responded with completely ridiculous answers, such as:
"Our 8.0 memcpy was indeed optimized for a Pentium(r)4 Processor,when we reworked this routine we used the simplest, most robust, and straightforward implementation for older processors so that we didn't need the extra code to check for alignment, length, overlap, and other conditions."
This forced Intel C++ to use the "Pentium 4" memcpy regardless of which processor in in the machine. It turns out that their special "Pentium 4" memcpy which I tested thoroughly in all kinds of situations, and it worked perfectly fine on an AMD Athlon and a Pentium III. I pointed this out to them.
I received the following response:
"The fast mempcy is over 2000 lines of hand coded assembly, with lots of special cases where different code paths are chosen based on relative alignment of the source and destination. ... If the performance of memcpy/memset only are improved for Pentium III will that satisfy you?"
fra slashdot kommentar
Ganske interessant og lummert :)
#13 - Den forgrening som alt andet end GenuineIntel ledes over i er generisk IA32 (nul SSE og andet smart). Såfremt at compiler switches selvfølgelig er sat til at producere den slags "Processor Dispatch" eksekverbare.
Iøvrigt:
Jeg synes at klagen over compileren lidt ligner noget piveri fra AMDs side. Ihvertfald det at at de klager over at programmer muligvis kan crashe i IA32 forgreningen: Det er da softwareproducentens opgave at gennemteste deres produkter. Anklagen lægger nærmest op til at en rigtig brugbar feature som Processor Dispatch slet ikke kan tillades i et Intel produkt.
Man kunne måske ønske sig at man selv ku' definere profiler baseret på feature flag. Og flere forgreninger end 2 forgreninger ved auto settings. Selv hvis man håndkoder, så kan man vist kun skelne mellem diverse Intel profiler. AFAIK ihvertfald.
Iøvrigt:
Jeg synes at klagen over compileren lidt ligner noget piveri fra AMDs side. Ihvertfald det at at de klager over at programmer muligvis kan crashe i IA32 forgreningen: Det er da softwareproducentens opgave at gennemteste deres produkter. Anklagen lægger nærmest op til at en rigtig brugbar feature som Processor Dispatch slet ikke kan tillades i et Intel produkt.
Man kunne måske ønske sig at man selv ku' definere profiler baseret på feature flag. Og flere forgreninger end 2 forgreninger ved auto settings. Selv hvis man håndkoder, så kan man vist kun skelne mellem diverse Intel profiler. AFAIK ihvertfald.
Det er jo lidt af en svinestreg, hvis nyheden skulle vise sig at holde stik. Fair nok kun at optimerer til sit eget produkt, men ligefrem at sløve eksekveringen med vilje hvis det er en konkurerende CPU er ganske rigtigt konkurranceforvridende.
Intel har haft fabrikker i EU siden 1989, primært i Irland hvor Fab24 og den kommende Fab24-2 kommer til at ligge.
...tror nu nærmere forskellen ligger i at AMD har fabrikker i EU.
Intel har haft fabrikker i EU siden 1989, primært i Irland hvor Fab24 og den kommende Fab24-2 kommer til at ligge.
#19 - jeg læste en artikel om en ikke-AMD tilsluttet person som havde en cluster med primært AMD'er, historien var den at han opgraderede sin compiler og pludselig begyndte at oplevel crashes på hele parken, undtagen nogle enkelte maskiner.. han undersøgte det og det viste sig at disse maskiner var intelmaskiner.
Han kiggede nærmere på det og han kunne se at assembler koden specifikt tjekekde på efter GenuineIntel, og BAGEFTER tjekkede på features - altså den ignorerede hvad processoren rent faktisk kunne og tjekkede kun på dette hvis det var en intel.
De får svært ved at forklare at det er "profilering"...
Men jeg tror nu sagen kommer til at køre på hvorvidt Intel gjorde dette med vilje eller ej - jeg tror ikke der er nogen tvivl om sagen, her er der hårde tørre fakta der ikke kan bestrides, men hvad man anklager intel for er at gøre dette bevidst for at vinde markedsandele - og det er så spørgsmålet om de gjorde.
Personligt tror jeg det er noget fis - den slags debugging og direkte profilering er noget man laver i et test-miljø. Hvis det var et decideret problem, og især når der er så stor forskel på forgreningerne, så burde de have dokumenteret det.
Han kiggede nærmere på det og han kunne se at assembler koden specifikt tjekekde på efter GenuineIntel, og BAGEFTER tjekkede på features - altså den ignorerede hvad processoren rent faktisk kunne og tjekkede kun på dette hvis det var en intel.
De får svært ved at forklare at det er "profilering"...
Men jeg tror nu sagen kommer til at køre på hvorvidt Intel gjorde dette med vilje eller ej - jeg tror ikke der er nogen tvivl om sagen, her er der hårde tørre fakta der ikke kan bestrides, men hvad man anklager intel for er at gøre dette bevidst for at vinde markedsandele - og det er så spørgsmålet om de gjorde.
Personligt tror jeg det er noget fis - den slags debugging og direkte profilering er noget man laver i et test-miljø. Hvis det var et decideret problem, og især når der er så stor forskel på forgreningerne, så burde de have dokumenteret det.
Anand har også om det i hans blog.
http://anandtech.com/weblog/default.aspx#228
http://anandtech.com/weblog/default.aspx#228
So AMD is suing Intel. First, I'd suggest reading through the 48-page complaint filed by AMD. Given that Vinney is in law school, I've seen a few of these things, but this one is surprisingly legible even for us non-legal types :)
I've known about this sort of stuff for quite some time, in fact, I'd say that out of the 48 pages AMD's legal team put together there's a lot missing. AMD told me that they aren't putting all cards on the table, but here are a couple of other things that I've seen personally:
I can't even begin to count the number of times where motherboard manufacturers have told me that they could not:
1) Send an AMD motherboard for review
2) Promote an AMD motherboard
3) Let us take pictures of an AMD motherboard
Out of fear of Intel retaliation. Remember the original Athlon days when no motherboard manufacturer would dare make a board for the K7? All of the frightened manufacturers were afraid of them losing their Intel chipset allocation if they supported the K7.
#22 - Mjah, mjoh.. Profilerne er jo desværre en blanding af understøttede features og tuningsparametre. Den mest effektive kode får man ved at have processor-specifikke profiler. Feature flag fortæller jo kun en del af historien.
gcc har også profiler som er specifikke for Intel og for AMD (e.g. -mtune=Prescott eller -mtune=athlon64). Heldigvis er der gjort en adskillelse af arkitektur/features og tunings profil.
Det er fair nok at brokke sig over at processor dispatch stubben i Intel compileren ikke er fleksibel nok. Måske er det bare formuleret underligt fordi det skal fremlægges for lægmand.
gcc har også profiler som er specifikke for Intel og for AMD (e.g. -mtune=Prescott eller -mtune=athlon64). Heldigvis er der gjort en adskillelse af arkitektur/features og tunings profil.
Det er fair nok at brokke sig over at processor dispatch stubben i Intel compileren ikke er fleksibel nok. Måske er det bare formuleret underligt fordi det skal fremlægges for lægmand.
#8
Intel compileren (ICC) er en ganske god compiler, den er velegnet ved compilering paa unix platformen, fordi de andre compilere til x86 generelt producerer middelmaadig kode.
Gcc er en god compiler, men den er relativt elendig til at optimere x86 kode naar man sammenligner med win32 platformens compilere (dermed ikke sagt at gcc er en daarlig compiler, jeg bruger selv ikke andet paa unix, men det har desvaerrre indtilvidere vaeret resultatet af at skulle understoette mange styresystemer og mange arkitekturer i samme kodebase, lad os haabe gcc 4+ kan aendre paa det.)
Intel compileren (ICC) er en ganske god compiler, den er velegnet ved compilering paa unix platformen, fordi de andre compilere til x86 generelt producerer middelmaadig kode.
Gcc er en god compiler, men den er relativt elendig til at optimere x86 kode naar man sammenligner med win32 platformens compilere (dermed ikke sagt at gcc er en daarlig compiler, jeg bruger selv ikke andet paa unix, men det har desvaerrre indtilvidere vaeret resultatet af at skulle understoette mange styresystemer og mange arkitekturer i samme kodebase, lad os haabe gcc 4+ kan aendre paa det.)
Der er en rigtig god post over hos Slashdotterne, som skærer problematikken ud i pap.
http://yro.slashdot.org/comments.pl?sid=155593&...
Anyway, så kan det blive en rigtig dyr omgang for Intel at tabe i EU, eftersom Europa Kommissionen har mulighed for at give bøder svarende til 10% af den årlige omsætning hos et given firma. Bare se på de bøder Microsoft har fået!
Look, the issue is this:Læs resten af posten her:
* There are AMD processors that support MMX, SSE, SSE2 (Intel Processor extensions)
* The Intel Compiler is a widely used one for a segment of developers.
* The compiler should create code which will use any and all of Intel's own optimizations( MMX, SSE, SSE2 )
* The compiler will do this for Intel Processors.
* The compiler will not use those very same extensions/optimizations when it detects an AMD cpu.
* Those extensions are implemented by AMD to INTEL's specifications(licensed from them).
* The compiler SHOULD make use of them.
* They are NOT AMD specific extensions/optimizations.
* The allegation is that INTEL made their compiler to work properly when compiling for INTEL chips, but not use ANY optimization extensions(intel or otherwise) when it detects an AMD chip.
The compiler doesn't need to be optimized for AMD's chips. But it does need to be optimized for extensions which Intel supports. The claim is that Intel's compiler DOES NOT support their own extensions when an AMD chip is detected. . .
By crippling the resulting code when the compiler detects an AMD CPU, Intel is essentially LYING about the performance of their processor and about the performance of the AMD processor through resulting benchmark software(s) and applications compiled with the Intel compiler. . .
It ISN'T about INTEL's compiler not optimizing itself for AMD specific instruction sets. It is about INTEL's compiler not optimizing itself for INTEL specific extensions on AMD CPUs, which AMD has license from INTEL and implemented in their processors. . .
The compiler should be checking for the existence of extensions and choosing to compile in functionality or not. Most games and graphics packages use dynamic libraries and alternate blocks of code for different extensions detected. If small, mid-sized, and large game companies can do this... why can't INTEL?
http://yro.slashdot.org/comments.pl?sid=155593&...
Anyway, så kan det blive en rigtig dyr omgang for Intel at tabe i EU, eftersom Europa Kommissionen har mulighed for at give bøder svarende til 10% af den årlige omsætning hos et given firma. Bare se på de bøder Microsoft har fået!
Det lader til at AMD nu er løbet ind i lidt modvind:
AMD accuses Dixons of colluding with Intel on chips
Lidt af en bet at nævne et firma i sit saganlæg, som så siger at man er forkert på den :S
Terracide...
AMD accuses Dixons of colluding with Intel on chips
Dixons is just one of many computer retailers that AMD states has been subject to financial "coercion" from Intel.
But yesterday Dixons hit back against AMD. In a written statement, the company said: "The specific reference to the Dixons Group in the AMD suit is factually incorrect and we are correcting misinformation in the filing. PC World never discusses one supplier's business with another."
It added: "This is a matter between AMD and Intel. In the interest of providing our customers with the best price, widest range and great service, we have long-standing, commercial relationships with both companies, and others, which are of course fully compliant with all relevant regulations and our own ethical sourcing policy."
Lidt af en bet at nævne et firma i sit saganlæg, som så siger at man er forkert på den :S
Terracide...
Troede sgu AMD og Intel var bedre venner.
Det sagt, så kan jeg faktisk ikke se problemet i at Intel laver en compiler som virker bedre på deres egne CPU'er. Intel har jo udviklet den for at udbrede deres egen CPU arkitektur, ikke for deres blå øjnes skyld. Og som #27 siger, så står det jo i dokumentationen.
Det sagt, så kan jeg faktisk ikke se problemet i at Intel laver en compiler som virker bedre på deres egne CPU'er. Intel har jo udviklet den for at udbrede deres egen CPU arkitektur, ikke for deres blå øjnes skyld. Og som #27 siger, så står det jo i dokumentationen.
Hvorfor overholder Intel ikke deres egne extentions? man kan da ikke "sælge" en funktion til et andet firma, og så lave en compiler der med vilje blokere de funktioner man har solgt, når den opdager en anden chip! Når AMD har licenceret de extentions, så burde compileren også bruge dem!
desuden er det vel et spørgsmål om tid, før nogle af de firmaér der er nævnt i amd´s sag, udtaler et eller andet posetivt omkring Intel.. man kunne let forstille sig at Intel ville forsøge at presse firmaér til at sige det ikke passer osv!
desuden er det vel et spørgsmål om tid, før nogle af de firmaér der er nævnt i amd´s sag, udtaler et eller andet posetivt omkring Intel.. man kunne let forstille sig at Intel ville forsøge at presse firmaér til at sige det ikke passer osv!
#31: Kan stadig ikke se problematikken. Bare fordi du har købt en æske legoklodser, betyder det ikke du får særbehandling, hvis du besøger legoland. Licenserne til MMX og SSE og compileren er 2 forskellige produkter.
EDIT: Vil lige tilføje at jeg ikke bare poster for at sige positive ting om Intel. Og så bruger jeg GCC :0)
EDIT: Vil lige tilføje at jeg ikke bare poster for at sige positive ting om Intel. Og så bruger jeg GCC :0)
Minder det ikke lidt om da Microsoft redirectede hvis den så en Opera browser (hvor den side man så kom til, var dårligere)?
Jeg håber AMD vinder, det kan godt være de piver lidt, men Intel har ikke været særlig søde mod dem, hvis de har gjort alt det AMD beskylder dem for... Hvis de taber, håber jeg ikke det går ud over forbrugerne :-/ (stiger Intels, stiger AMDs sikkert også lidt).
Jeg håber AMD vinder, det kan godt være de piver lidt, men Intel har ikke været særlig søde mod dem, hvis de har gjort alt det AMD beskylder dem for... Hvis de taber, håber jeg ikke det går ud over forbrugerne :-/ (stiger Intels, stiger AMDs sikkert også lidt).
Anyway, så kan det blive en rigtig dyr omgang for Intel at tabe i EU, eftersom Europa Kommissionen har mulighed for at give bøder svarende til 10% af den årlige omsætning hos et given firma. Bare se på de bøder Microsoft har fået!
AHA! Det er der fra vi får råd til landbrugsstøtten. Tak for dette bidrag Intel, for hvis beskyldningerne er rigtige så kan vi hæve bistandschecken til vores forkælede landmænd og endelig få fuldstændig kål på de afrikanske landmænd. Forbrugerne er jo for dumme til at handle politisk og til at kunne kende forskel på firmaer der hedder det samme.
Hmm
Nu kan det jo godt være jeg ikke er den skarpeste kniv i skuffen..
MEN: Er en kompiler ikke noget man bruger for at komme fra programmeringssprog til *.exe fil ?
Hvis dette er tilfældet hvorfor køber alle der udvikler programmer så ikke bare en P4 til at kompilere skidtet på, så aktiverer den vel de der ekstra features og lægger dem i *.exe filen og så må filen vel også virke godt med en AMD...
XxX
Nu kan det jo godt være jeg ikke er den skarpeste kniv i skuffen..
MEN: Er en kompiler ikke noget man bruger for at komme fra programmeringssprog til *.exe fil ?
Hvis dette er tilfældet hvorfor køber alle der udvikler programmer så ikke bare en P4 til at kompilere skidtet på, så aktiverer den vel de der ekstra features og lægger dem i *.exe filen og så må filen vel også virke godt med en AMD...
XxX
Hvilken indflydelse kommer det til at have for diverse benchmark programmer ? Hvor mange af dem er kompileret med ICC ? I teorien burde der vel komme et pænt performance boost til AMD (og andre "generic") ud af det ?
#38,
Det hjælper ikke rigtigt noget. Problemet er nemlig at den *.exe fil, som compileren laver, selv lige checker hvilken CPU det er, og derefter køre et andet program.
Man kan sige at der er 2 versioner af programmet inde i *.exe filen. En til Intel og en til andre CPU'er.
Det hjælper ikke rigtigt noget. Problemet er nemlig at den *.exe fil, som compileren laver, selv lige checker hvilken CPU det er, og derefter køre et andet program.
Man kan sige at der er 2 versioner af programmet inde i *.exe filen. En til Intel og en til andre CPU'er.
#38, #39:
det er ikke compileren der kigger på hvilken CPU maskinen har, det er det producerede program.
groft eksempel: vi compiler et program som får et tal ind, ganger dette med 5 og viser resultatet:
- - - - - - - -
A=input()
HVIS CPU=INTEL
B=A*5
ELLERS
B=A
B=B+A
B=B+A
B=B+A
B=B+A
SLUT HVIS
udskriv(B)
- - - - - - - -
Problemet i dette eksempel er, at compileren laver et program, som checker om det er en intel CPU, hvis ikke, laves gange-operationen som en masse plus-operationer, også selv om CPUen sagtens kan gange. programmet burde checke om CPUen kan gange, i stedet for at checke hvem der har produceret den, og på den måde har intel begået en svinestreg. hvis man compiler programmet i en mere neutral compiler som GCC, vil det se således ud:
- - - - - - - -
A=input()
HVIS eksisterer(*)
B=A*5
ELLERS
B=A
B=B+A
B=B+A
B=B+A
B=B+A
SLUT HVIS
udskriv(B)
- - - - - - - -
Nu er det ikke simple ting som gange og plus, der er problemet i denne sag, men princippet er det samme, da intel compilerens programmer ikke benytter sig af ting som MMX og SSE, hvis de kører på andet end intel.
det er ikke compileren der kigger på hvilken CPU maskinen har, det er det producerede program.
groft eksempel: vi compiler et program som får et tal ind, ganger dette med 5 og viser resultatet:
- - - - - - - -
A=input()
HVIS CPU=INTEL
B=A*5
ELLERS
B=A
B=B+A
B=B+A
B=B+A
B=B+A
SLUT HVIS
udskriv(B)
- - - - - - - -
Problemet i dette eksempel er, at compileren laver et program, som checker om det er en intel CPU, hvis ikke, laves gange-operationen som en masse plus-operationer, også selv om CPUen sagtens kan gange. programmet burde checke om CPUen kan gange, i stedet for at checke hvem der har produceret den, og på den måde har intel begået en svinestreg. hvis man compiler programmet i en mere neutral compiler som GCC, vil det se således ud:
- - - - - - - -
A=input()
HVIS eksisterer(*)
B=A*5
ELLERS
B=A
B=B+A
B=B+A
B=B+A
B=B+A
SLUT HVIS
udskriv(B)
- - - - - - - -
Nu er det ikke simple ting som gange og plus, der er problemet i denne sag, men princippet er det samme, da intel compilerens programmer ikke benytter sig af ting som MMX og SSE, hvis de kører på andet end intel.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund