Forgot your password?
typodupeerror
Intel Hardware

PCMark Memory Benchmark Favors GenuineIntel 298

Posted by kdawson
from the not-what-you'd-call-neutral dept.
javy_tahu writes "A review by Ars Technica disclosed that PCMark 2005 Memory benchmark favors GenuineIntel CPUID. A VIA Nano CPU has had its CPUID changed from the original VIA to fake GenuineAMD and GenuineIntel. An improvement of, respectively, 10% and 47% of the score was seen. The reasons of this behavior of FutureMark product are not yet known."
This discussion has been archived. No new comments can be posted.

PCMark Memory Benchmark Favors GenuineIntel

Comments Filter:
  • Money (Score:5, Insightful)

    by TheRealMindChild (743925) on Friday August 01, 2008 @09:32AM (#24432213) Homepage Journal
    The reasons of this behavior of FutureMark product are not yet known

    Easy. Intel paid them to make it that way.
  • Money? (Score:4, Insightful)

    by IWantMoreSpamPlease (571972) on Friday August 01, 2008 @09:35AM (#24432265) Homepage Journal

    Seems obvious, but follow the money trail, does PCMark get backing from Intel?

  • by dlgeek (1065796) on Friday August 01, 2008 @09:36AM (#24432281)

    A VIA Nano CPU has had its CPUID changed from the original VIA to fake GenuineAMD and GenuineIntel. An improvement of, respectively, 10% and 47% of the score was seen.

    It sounds to me like this could possibly be explained by some kind of conditional optimization that the compiler puts in for various chips, to take advantage of differences in their designs that can improve performance.

    Then again, probably not.

  • by Plantain (1207762) on Friday August 01, 2008 @09:37AM (#24432305)

    This could all be explained if they compiled with something silly like ICC

    http://www.theinquirer.net/en/inquirer/news/2005/07/13/intel-compiler-nobbles-amd-chips-claim [theinquirer.net]

  • by davidwr (791652) on Friday August 01, 2008 @09:39AM (#24432345) Homepage Journal

    This definitely requires clarification from the creator of the benchmark.

    It is possible that the benchmark uses the CPUID to change how the benchmark works, for example, to work around known flaws in a given chip. If this is the case, then the problem is not "omyghoshitplaysfavorites" but rather lack of full disclosure that the benchmarks are not directly comparable across different chips. In the most benign scenario, this could be someone at the benchmark creator's shop forgetting to tell the documentation team. This is still a very serious issue, but it's not fraud.

  • by mikeabbott420 (744514) on Friday August 01, 2008 @09:40AM (#24432359) Journal
    Code that only used SSE3 or some such on the basis of the CPU ID might explain it but conspiracy is more fun to believe. Lies, Damn Lies and Benchmarks.
  • MMX/SMD Extensions (Score:5, Insightful)

    by Cassini2 (956052) on Friday August 01, 2008 @09:41AM (#24432377)

    Could it be that FutureMark uses the GenuineIntel and AMD flags to enable processor specific extensions? and then does a whole bunch of math with those extensions and never bothers to check the result?

    This would indicate some really terrible code on FutureMarks part, and VIA should be flagging those op-codes as illegal op-codes, but it might be possible that something like this could happen. It is even possible that the CPUID checks are duplicated in some library somewhere that actually gets the correct code sequence right, and the main FutureMark code disables the advanced functions of the library whenever the GenuineIntel and AMD flags are missing. Thus FutureMark may feature both code sequences that work and those that don't, and the resulting incompatibilities are what causes the issues.

  • by Ed Avis (5917) <ed@membled.com> on Friday August 01, 2008 @09:41AM (#24432379) Homepage

    Why would you even consider running a benchmark program you don't have source code for and cannot compile yourself? (If you are worried about random compiler differences messing up the results, you can check an MD5 sum of the final binary against the published one, but it is important that you can reproduce the binary from source and you can read the source to find out what it does.)

    If compilers like ICC cripple their code depending on CPUID, that will just lead all manufacturers to set CPUID to GenuineIntel, just as moronic websites (with help from Microsoft) ensured that all browsers call themselves 'Mozilla'.

  • Benchmark (Score:4, Insightful)

    by Rinisari (521266) on Friday August 01, 2008 @09:41AM (#24432389) Homepage Journal

    Well, PC Mark 2005 is no longer good for testing processors against processors of another maker, i.e. only good for intra-AMD, etc.

  • Re:Money (Score:4, Insightful)

    by Lord_Frederick (642312) on Friday August 01, 2008 @09:44AM (#24432435)

    Even if this is an unintentional error, they have certainly lost some credibility.

  • by Anonymous Coward on Friday August 01, 2008 @09:47AM (#24432471)

    quit talking about shit you don't understand.

    Two different compilers will almost always produce two different executables. They're just different, that's just how it is. So an md5 comparison will always fail.

  • by neokushan (932374) on Friday August 01, 2008 @09:47AM (#24432487)

    In all likelihood, this probably IS the case, but that still goes a long way to discredit Futuremark as it shows their benchmarks were certainly NOT fairly tested.

  • by MBCook (132727) <foobarsoft@foobarsoft.com> on Friday August 01, 2008 @09:51AM (#24432581) Homepage

    You can't. That's why it was discovered now. Intel and AMD don't let you change the CPUID results on their CPUs. Via DOES let you change it. (You could hack the benchmark to change the checks, but then your results are invalid because you changed the benchmark code)

    Either way, that's not an excuse. As Ars points out, if it is just checking for something like SSE2 the Nano has that. If you want to make an optimized code path it should be based on if a feature is reported as present or not, not who made the CPU.

    It's just really REALLY fishy.

  • by brunascle (994197) * on Friday August 01, 2008 @09:52AM (#24432585)

    Exactly, what happens when you run an AMD chip under both IDs? or an Intel?

    As TFA mentions, we cant test it. AMD and Intel lock the CPUIDs on their chips. VIA doesnt. I do think AMD should do some testing in-house though, as I'm sure they could change the CPUID themselves. Though I wouldnt be surprised if they'd already tried this long ago. I know I would have. And if there were major discrepancies, we probably would have heard about it by now.

  • by bill_mcgonigle (4333) * on Friday August 01, 2008 @10:05AM (#24432845) Homepage Journal

    It sounds to me like this could possibly be explained by some kind of conditional optimization that the compiler puts in for various chips, to take advantage of differences in their designs that can improve performance.

    People are trusting closed-source benchmarks? Well, golly gee, who'd'a thunk there'd be errors, oversights, or shenanigans?

    If this was used for anything more than entertainment value, any methodical person would have at least compared multiple closed-source benchmarks. If that proved to be inappropriately favoring a vendor, then, OK, start calling 'conspiracy', but this just sounds like an error in a tool that was never validated.

  • Re:Money (Score:5, Insightful)

    by ShieldW0lf (601553) on Friday August 01, 2008 @10:08AM (#24432893) Journal

    Moral of the story is, when you're dealing with code like this, where it has the capacity to influence who receives billions of dollars and who doesn't, well, you can't trust it if it's closed source and not subject to public scrutiny.

    Closed source test suites cannot be trusted, shouldn't even be considered by potential purchasers, and have been misleading the public for years and years. This is mute evidence to the fact.

  • by Anonymous Coward on Friday August 01, 2008 @10:10AM (#24432947)

    Yeah, except that ICC Intel optimizations frequently improve AMD scores as well (over generic optimizations). Not always as much as it helps Intel processors, but it does help some.

  • by clickclickdrone (964164) on Friday August 01, 2008 @10:11AM (#24432955)
    It's a 3+ year old benchmark being let loose on 2008 vintage CPU's and making mistakes on it's optimisations. I wouldn't expect anything else. It's going to have a 3 year old view on the kind of things these CPUs can do and will act accordingly.
  • by tucuxi (1146347) on Friday August 01, 2008 @10:20AM (#24433143)

    If I were an evil fraudster at PCMark, paid for Intel to deliver worse scores to rivals, I would make sure that these rivals had no easy way of uncovering the fraud. Testing for an ID looks much more like bad code paths than like "sneaky fraud".

    There is no shortage of alternative quirks that can be used to see whether a given processor belongs to one family or another. Should enough of these quirks be combined, it would be *very* hard to discover an evil-related cause.

    Of course, choosing the 'bad' path given an ID may just be blatant enough to provide plausible deniability for the developers that "messed up". However, being a firm proponent of Hanlon's Razor, I would rather call it a bug than a "sponsored feature".

    On the other hand, kudos to the guys at Ars who thought of changing the ID and, when the numbers did not add up, make further tests to nail down the argument. Instead of just forgetting about the problem and performing a "review as usual", which would have doubtlessly required less effort. Yay for inquisitive hacker - reviewers.

  • Re:Money (Score:2, Insightful)

    by DrWho42 (558107) on Friday August 01, 2008 @10:24AM (#24433263) Homepage
    If the authors of this benchmark test were competent they would have written the code for low-level tests like memory bandwidth in assembly language, so compiler choice would not impact them.
  • by MadKeithV (102058) on Friday August 01, 2008 @10:26AM (#24433289)
    But nothing changes in the CPU operation if you only change the reported CPUID. In the best case that means the 3DMark developers have spent a lot more optimizing for Intel specifically, applying a number of techniques that would have been just as valid for an AMD or VIA processor. They spent that effort without bothering to check the effect on the AMD and VIA specific paths, thus they did not get the same treatment as intel.
    And that's simply Intel favoritism.
  • by poot_rootbeer (188613) on Friday August 01, 2008 @10:32AM (#24433421)

    It sounds to me like this could possibly be explained by some kind of conditional optimization that the compiler puts in for various chips, to take advantage of differences in their designs that can improve performance.

    I suppose it's possible that a VIA chip running code optimized for what the benchmark believes is an Intel CPU might perform better than the same chip running the benchmark's unoptimized code path, but as I understand it the VIA Nano is pretty entry-level; any optimizations present in it should probably be available to most CPUs across the market.

    Perhaps the unoptimized code is exceptionally sub-optimal, which is itself a way to skew results to make the Genuine* results look better.

  • Re:Money (Score:5, Insightful)

    by Kamokazi (1080091) on Friday August 01, 2008 @10:40AM (#24433573)

    And this is partly why I generally ignore benchmark scores, and look at real-world performance. It's possible for the benchmark or the hardware being benchmarked to 'cheat' or at least behave very differently and produce bogus scores. If i'm looking for a new video card, I don't look at 3DMark scores, I look at framerates in games that I play (or that use the same engine). If I'm looking for a CPU, I'll look at RAR compression times or video encoding speeds. If I'm looking for a storage solution at work, I look at file copy speeds of similar file quantities and sizes, or I/O performance of a similar database.

  • Re:Money (Score:5, Insightful)

    by clickclickdrone (964164) on Friday August 01, 2008 @10:43AM (#24433633)

    This is just a classic example of amateur (poster) vs professional (Intel dev team).

    Writes an (anonymous) Intel representative.

  • Re:Money (Score:3, Insightful)

    by SirShmoopie (1333857) on Friday August 01, 2008 @10:52AM (#24433783)

    Ok then, point me to an open source benchmarking program that's as complete, and I'll use it.

    Might it just be that they got the software done as cheaply as possible, marked it as ready for release as soon as they could, and never bothered to fix what was obviously a glaring flaw?

    Anyway, as an open source developer myself I don't really buy this 'open source will always be better' deal. It can only be better if the project is fortunate enough to attract quality coders and designers. There are a lot more open source programs then there are highly skilled programmers willing and able to work on them.

  • Re:Money (Score:4, Insightful)

    by ShieldW0lf (601553) on Friday August 01, 2008 @10:53AM (#24433799) Journal
    It doesn't have to be complicated. I can see a business case for a few large game developers to collaborate on creating a modular open source test suite that would allow a user to load, run and score game-based benchmarks. The modules themselves wouldn't have to be open source for it to be effective in gauging the performance of this game on this hardware. Then, if Intel pays the publisher a fortune to make this game run faster on their hardware than the others, that wouldn't corrupt the integrity of the test, just the game.
  • by Tom9729 (1134127) <tom9729@@@gmail...com> on Friday August 01, 2008 @10:54AM (#24433811) Homepage

    That's a pretty good analogy.

    If Futuremark is indeed enabling CPU features based upon the CPUID, then this situation is a lot like the webpages that render incorrectly in Firefox unless the user agent is set to Internet Explorer.

  • by OmniGeek (72743) on Friday August 01, 2008 @10:57AM (#24433889)

    Does it really matter whether the cause was "incredibly sloppy coding" or "Intel bribed them?" Either way, their benchmark cannot be trusted, and trustworthiness is ESSENTIAL for a benchmark. If anyone pays serious attention to this (which, having read TFA, it seems to merit), then FutureMark is toast.

  • Re:Money (Score:5, Insightful)

    by Goaway (82658) on Friday August 01, 2008 @11:00AM (#24433947) Homepage

    What I don't get is why game developers don't release freeware benchmark versions of their engines.

    Because that would require a non-trivial amount of work for no substantive payoff?

  • by harrkev (623093) <kfmsd@harr[ ]onfamily.org ['els' in gap]> on Friday August 01, 2008 @11:20AM (#24434269) Homepage

    If you're *really* out to test performance (and need that performance) you *will* optimize on a clock count basis and to know that, you have to know the implementation specifics of *the* processor you're on.

    Because, as we all know, real applications do this. Winzip has different code paths for different processors, as well as Office, and Photoshop, right?

    In real life, you do things in the fastest GENERIC way possible. If SSE should make it faster, check for the existence of SSE, and then use it. If SSE not present, fall back to MMX. That is what REAL applications do in REAL life. What good does a theoretical bandwidth do if no software actually uses it?

  • by Anonymous Coward on Friday August 01, 2008 @11:30AM (#24434457)

    Because the faster the machine the more efficiently it does the task, allowing you to do even more concurrently and do more things in the future?

    There was a time when my amd k6 350mhz could do anything i ever wanted, and even do it with passive cooling if i underclocked it to 333mhz.

    Then I wanted to do more things.

  • Re:Money (Score:4, Insightful)

    by LarsG (31008) on Friday August 01, 2008 @11:48AM (#24434721) Journal

    And why would Intel's compiler emit code that is not x86-compliant? Code should look at cpuid feature bits, not "GenuineIntel".

  • Re:Money (Score:5, Insightful)

    by Anonymous Coward on Friday August 01, 2008 @11:51AM (#24434789)

    Here, sir, is the Internet, which you have won fair and square.

  • Re:Money (Score:2, Insightful)

    by xerxesVII (707232) on Friday August 01, 2008 @11:52AM (#24434803)
    Too bad that just mentioning Larry the goddamned cable guy should undo any funny you are trying to give recognition to.
  • Re:Money (Score:5, Insightful)

    by SanityInAnarchy (655584) <ninja@slaphack.com> on Friday August 01, 2008 @11:53AM (#24434813) Journal

    Ok then, point me to an open source benchmarking program that's as complete, and I'll use it.

    glxgears.

    Seriously, when they are changing the results based on the vendor name, it makes any result suspect -- which makes it pretty much useless as a benchmark. At least with glxgears, while it may not be a particularly accurate benchmark, it's at least guaranteed to be fair.

    Anyway, as an open source developer myself I don't really buy this 'open source will always be better' deal.

    That's not the point of this exercise.

    Open source will not always make a better game, or a better office suite, or even a better text editor.

    But there are some kinds of software which you need to trust, and which are difficult to verify without the source. Benchmarks are one example. SSH clients are another. For these, I would not even consider a proprietary version -- it's not about features or relative quality; open source is a necessity.

  • by omnipresentbob (858376) on Friday August 01, 2008 @12:20PM (#24435367) Homepage

    Which would explain why AMD only got a 10% boost and GenuineIntel a 47%?

  • by bigstrat2003 (1058574) * on Friday August 01, 2008 @12:30PM (#24435543)

    The same exact way you know if the test is fair if the source is open. The vast majority of us are trusting someone at some point along the line. News flash: 90% of the computer users in the world aren't programmers! They don't look at open source code to make sure they can trust it, they ask someone they consider to be a trusted source, who has earned that status by being reliable in the past. It doesn't matter if that trusted person is someone you know personally, some random dude on the internet, or a vendor.

    Contrary to the claims of OSS proponents, the code isn't really more trustworthy if it's open, because not all of us are programmers. If we were (hell, even if most of us were), that'd be true. As things are, though, closed source is only slightly less trustworthy than open source.

  • by deanoaz (843940) on Friday August 01, 2008 @12:53PM (#24436021)
    >>> Contrary to the claims of OSS proponents, the code isn't really more trustworthy if it's open, because not all of us are programmers. If we were (hell, even if most of us were), that'd be true. As things are, though, closed source is only slightly less trustworthy than open source.

    I disagree. At this point there is controversy. It will be explained by the vendor and people will have to either accept the explanation or not.
    If it were open source, the facts of how the code behaves could be determined by third parties and publicized. We wouldn't have to take anyone's word for it.
  • by Dr_Barnowl (709838) on Friday August 01, 2008 @01:11PM (#24436355)

    $randomInternetDude

    If the source is open, you have multiple samples of $randomInternetDude to choose from. And it's not really random either. More like $internetDudeWithUnhealthyInterestInGameEngineProgramming, who I would expect to know a thing or two.

    And you can always learn enough to verify it for yourself, if you have the source.

    Better than trusting $corporatePrMan, anyway.

  • by bigstrat2003 (1058574) * on Friday August 01, 2008 @01:18PM (#24436479)
    Random in the sense of not knowing the person and how much you can trust them. So, to rephrase myself, $unknownInternetDude. He probably knows a thing or two, but then, so do the people who wrote this software, so that isn't really a factor. And I absolutely am not willing to trust $unknownInternetDude without a good reason. For all I know, that person is also $trojanAuthorOfDoom. It's just as unwise to trust him as it is to trust $corporatePrMan.
  • by asmussen (2306) <asmussen.cox@net> on Friday August 01, 2008 @01:35PM (#24436783)

    The problem with this argument is that with open source software, you don't just have to trust a single random guy for your information. When the source is open, it is often the case that MANY people in the online community will examine the code, and through discussion there emerges a consensus which is far more reliable than the opinion of just one random guy. That isn't to say that the community as a whole is never wrong, but it's vastly more trustworthy and reliable than just some $randomInternetDude.

  • Re:Money (Score:5, Insightful)

    by Goaway (82658) on Friday August 01, 2008 @01:39PM (#24436873) Homepage

    "Everything I don't know how to do is easy!"

  • by KWTm (808824) on Friday August 01, 2008 @01:55PM (#24437141) Journal

    Ok, here is what _might_ have happened perfectly legitimately and with no bad intent: When the benchmark was originally written, someone took his time to carefully write optimized code for the Intel, AMD and Via processors at that time. When running on a Via processor, the benchmark executes the code that ran fastest on a Via processor in 2005. When running on an AMD processor, it executes the code that ran fastest on an AMD processor in 2005, and so on.

    I'll give you credit for coming with a scenario that replaces malice with a heaping dose of incompetence. If what you say is true, then that's not a benchmark at all. After all, you're not comparing the same things; for all you know, you're comparing the skill of the programmer at writing for the VIA processor with the skill of the programmer at writing for the AMD processor.

    You might as well write a benchmark to see how long it takes for various processors to divide 4195835.0 by 3145727.0 and come up with 1.333739068902037589 [wikipedia.org]! (Note: The correct answer is 1.333820449136241002.)

  • Re:Money (Score:2, Insightful)

    by Some_Llama (763766) on Friday August 01, 2008 @02:04PM (#24437287) Homepage Journal

    pcmark had credibility? These are the guys who make 3dmark right? the program that gives you a "score" that in no way reflects how your system will actually perform IRL?

    I don't know anyone who takes these as a serious benchmark.. just recently a friend and I ran 3dmark2008 (2007/) against both of our machines.. his won.. but when we ran actual game benchmarks (like the built in ones for crysis and quake4) mine beat his soundly. Go figure.. he had an Intel, i have an AMD.

  • Re:Money (Score:3, Insightful)

    by Splab (574204) on Friday August 01, 2008 @02:07PM (#24437329)

    Because the drivers will be optimized for these tests, rather than the game - they did it before, they will do it again (Nvidia and ATI sure wasn't above it).

  • by Haeleth (414428) on Friday August 01, 2008 @02:31PM (#24437737) Journal

    You're missing the point.

    With proprietary software, you only get one entity to assure you it's legit, and that's the vendor. If the vendor is a trojan author of doom, you're screwed.

    With open-source software, you get many people looking to see if there's anything sneaky going on. Since you have multiple samples, your result is more likely to be accurate. If one or more of them are trojan authors of doom, then it doesn't really matter, because the honest ones can spot and point out the malicious code.

  • by Anonymous Coward on Friday August 01, 2008 @02:38PM (#24437847)

    I trust neither, unless previously proven trustworthy. If either side's explanation is reasonable, then that's an indicator that they might be trustworthy, however, I won't believe either side's explanation without some sort of evidence to back it up.

    Yes, and the whole point of this argument that you are stubbornly failing to see is that with open source code, that evidence is easy to find and easy to produce.

    Closed source code:

    Random Internet guy: $PRODUCT is broken.
    Vendor: Oh no it isn't.
    10 Random Internet guy: Oh yes it is.
    Vendor: Oh no it isn't.
    GOTO 10

    Open source code:

    Random Internet guy: $PRODUCT is broken. Look at line 314 of hard_stuff.cpp -- it's checking the wrong variable!
    Vendor: Oops.

  • Re:Money (Score:3, Insightful)

    by Skuld-Chan (302449) on Friday August 01, 2008 @03:10PM (#24438557)

    I've never worked in game development, but I know at other software companies I worked for anything that went out the door (no matter how small - whether it was paid for or not) to the consuming public had to have gone through a full QA cycle which took weeks - especially for apps that were available in more than one language.

    The reason for this is simple - if its crap (even if its free) you lose goodwill with the customer. For paid for applications doubly so because you may lose money on sales.

  • by WNight (23683) on Friday August 01, 2008 @04:30PM (#24440253) Homepage

    Because software isn't religion. There's a right answer and a wrong answer. You prove things.

    Even if you can't look at a three-line code sample and follow the logic (which I doubt - if you tried) people could write a demonstration of the flaw in, for example, Ruby, which you could cut and paste into another browser window and run on someone else's computer [hobix.com] so you didn't need to worry about trojans.

    If this was legit the code would look like this

    CPUID = get_cpu_id
    [...]
    case CPUID
        when 'Intel' ; enable_SSE2
        when 'AMD' ; enable_SSE
        else ; enable_nothing
    end

    Seriously, that's how complex it should look.

    With some searching even a non-programmer could find that simply by searching for strings like SSE and the logic should be fairly clear.

  • by NitroWolf (72977) on Friday August 01, 2008 @05:13PM (#24440933)

    Wow. Just wow. "I don't agree with you, so you must be trolling," is really rude, even for the internet. Consider not posting any more if you can't handle people who disagree with you.

    It's not the fact that I disagree with you, it's the fact that you are wrong. It's not an opinion, it's a fact. Therefore, you are trolling or are mentally handicapped, because you are no longer ignorant, since you've been informed you are wrong by a number of different people.

    I noticed you completely skipped over the part about how science and statistics are gathered. I put that there for a reason. It's to enlighten you to the fact that there IS A REASON wide swaths of random people are polled, and not just one or two people. It's because IT IS MORE ACCURATE.

    Furthermore, if all it takes for something to be trustworthy is for a lot of people to endorse it, then I'd believe a hell of a lot of things, many of them conflicting. Christianity, atheism, evolution, creationism, old music is better, new music is better... the list could extend for a very long time. Trustworthiness is based on past results. Nothing more, nothing less. One company can be just as trustworthy as the entire Internet, and the entire Internet can be just as untrustworthy as one company.

    It doesn't take a lot of people, it takes a lot of people who are experts in the field AND have no vested interest in the outcome. Everything you cite has lots of people who either not and expert, have a vested interest in the outcome, or BOTH.

    Trustworthiness is not based solely on past results. Trustworthiness is a product of verification and honesty. In the context we are talking about, it's also based on interests. The company in question has a vested interest in certain results, therefore their "conclusions" for those results should be automatically suspect if they confirm their claims. People skew reported data all the time, sometimes on purpose, sometimes not... but it happens, and it happens a lot. The same thing happens with companies/corporations (though usually it's on purpose).

    you automatically have a less accurate assessment

    Bull. You may still have a very accurate assessment, that's why you get someone who you trust to check it over for you. It may happen that you trust the company making the product, it may happen that you trust your brother who works on the Linux kernel in his spare time. The important thing is that you get the information verified by a trustworthy source, not whether or not it comes from the vendor or someone independent.

    How? How do you get someone you trust to check it over for you? I, you, your LInux kernel buddy doesn't have access to the code. How does he check it for you?

    It's kinda funny, since you claim to want someone to check it for you that is expressly NOT the company involved. This is why I know you're trolling, now. You agree, you just want to get a rise out of people by being an idiot.

    Good luck with that.

  • by p3d0 (42270) on Friday August 01, 2008 @05:54PM (#24441535)

    It's not a call, it's an instruction. Are you talking about intercepting it with virtualization? Or are you talking about modifying the benchmark code?

  • by Endo13 (1000782) on Friday August 01, 2008 @06:56PM (#24442233)

    That's ALL you ever have, from ANYONE! Hell, if that's your reason for not trusting, I damn well hope you don't trust anyone at all. Anyone you know can only give you their own word that they will continue to be trustworthy in the future. That's what trust is!!

    No, you're wrong. That's not all you ever have. You completely missed the most important part: "All you have is their own word." See that? That means there is no else to vouch for them. That's what closed source is. When it's open source, you have a whole fucking lot more than just their own word. You also have the word of every other person who has the capability to read and understand the code. If one of them is lying, you can bet another of them will raise a big stink about it. And that's totally ignoring the fact that a closed-source software vendor always has incentive to present their software more favorably than they should. It's their own product, only they know the details, a they're always going to be favorably biased towards it. It should be an understood fact that a closed source vendor will always lie about their software as much as they can get away with. And they can get away with quite a bit. You can't get away with any lying at all with open source.

: is not an identifier

Working...