Alex Martelli wrote: > OK, I've placed on http://www.aleax.it/Python/ the files that pybench > writes (with the -file option) for each machines, the names are > onmbp.txt and onwin2k.txt -- just 20k each (I'm not sure their format is > documented, but I guess that, worst case, one just needs to study > pybench's sources).
Nice, thank you. The files just contain pickled data, but you need pybench installed to unpickle the classes. I used the command pybench -s win2k.txt -c osx.txt to compare the data sets. Here are the results. Left two columns are Windows times, right column is change from OS X time. I resorted the tests by percentage change (win2k slowest->fastest) to provide a better picture of what's going on: PYBENCH 1.0 Benchmark: /home/ed/python-w2k.txt (rounds=10, warp=20) measured against: /home/ed/python-osx.txt (rounds=10, warp=20) Tests: per run per oper. diff ------------------------------------------------------------------------ (slower on win2k) StringMappings: 309.33 ms 2.46 us +112.53% ConcatUnicode: 157.47 ms 1.05 us +77.43% ConcatStrings: 103.57 ms 0.69 us +44.86% DictWithFloatKeys: 169.10 ms 0.28 us +21.52% UnicodeProperties: 86.00 ms 0.43 us +6.69% PythonFunctionCalls: 85.83 ms 0.52 us +1.22% UnicodeSlicing: 85.64 ms 0.49 us +0.16% (faster on win2k) IfThenElse: 70.38 ms 0.10 us -2.45% SmallLists: 76.98 ms 0.30 us -4.44% CompareUnicode: 85.22 ms 0.23 us -4.72% StringPredicates: 87.25 ms 0.31 us -6.13% NestedForLoops: 38.47 ms 0.11 us -8.07% CompareInternedStrings: 59.12 ms 0.12 us -8.12% SimpleListManipulation: 41.93 ms 0.16 us -8.55% CreateStringsWithConcat: 35.02 ms 0.18 us -9.16% TryRaiseExcept: 49.62 ms 3.31 us -9.53% StringSlicing: 63.61 ms 0.36 us -9.77% SmallTuples: 68.65 ms 0.29 us -12.77% CompareFloatsIntegers: 72.31 ms 0.16 us -13.72% Recursion: 45.88 ms 3.67 us -16.20% CompareFloats: 51.26 ms 0.11 us -17.05% CompareStrings: 76.14 ms 0.15 us -17.51% PythonMethodCalls: 60.74 ms 0.81 us -17.75% CreateUnicodeWithConcat: 90.22 ms 0.45 us -17.76% BuiltinFunctionCalls: 39.38 ms 0.31 us -17.79% SimpleFloatArithmetic: 57.72 ms 0.10 us -19.44% SecondImport: 29.59 ms 1.18 us -19.71% CreateInstances: 63.02 ms 1.50 us -21.08% SimpleIntFloatArithmetic: 55.92 ms 0.08 us -21.78% SimpleComplexArithmetic: 42.40 ms 0.19 us -22.84% BuiltinMethodLookup: 78.26 ms 0.15 us -24.54% UnicodePredicates: 56.17 ms 0.25 us -24.75% SpecialInstanceAttribute: 117.49 ms 0.20 us -24.97% DictWithStringKeys: 62.30 ms 0.10 us -26.18% TupleSlicing: 73.63 ms 0.70 us -26.34% NormalInstanceAttribute: 65.19 ms 0.11 us -26.50% UnicodeMappings: 65.20 ms 3.62 us -27.68% SecondPackageImport: 31.25 ms 1.25 us -28.74% SpecialClassAttribute: 65.94 ms 0.11 us -30.30% ListSlicing: 50.75 ms 14.50 us -31.37% SecondSubmoduleImport: 39.39 ms 1.58 us -31.98% SimpleDictManipulation: 37.88 ms 0.13 us -32.24% NormalClassAttribute: 66.37 ms 0.11 us -33.40% DictCreation: 36.66 ms 0.24 us -34.25% DictWithIntegerKeys: 54.73 ms 0.09 us -35.76% SimpleLongArithmetic: 27.03 ms 0.16 us -39.80% TryExcept: 62.54 ms 0.04 us -42.17% SimpleIntegerArithmetic: 42.88 ms 0.06 us -42.52% CompareIntegers: 42.81 ms 0.05 us -45.54% ForLoops: 25.72 ms 2.57 us -53.99% CompareLongs: 25.45 ms 0.06 us -63.04% ------------------------------------------------------------------------ Average round time: 3847.99 ms -12.61% None of these tests look to me like anything virtualization would affect. Beyond that, I'm not sure what to make of it. The fastest gains on win2k (>39%) seem to come from branching and arithmetic tests. Maybe the ms compiler has significantly better branch prediction (might explain why ForLoops and TryExcept have such large gains while NestedForLoops and TryRaiseExcept are more modest). I can't postulate why some tests show >20% gains, like the *Slicing and *InstanceAttributes ones. No idea why the first group of tests came out faster on OS X. I really don't have enough platform-specific knowledge to make sense of what's going on. Maybe someone with more experience can comment? There may just be too many factors at play to tease out causal relationships. > The compiler Apple distributes freely is still gcc -- the intel compiler > (rumored to have better optimization) costs hundreds of dollars, so > Apple couldn't possibly distribute it for free with XCode. I know ICC is commercial and thus not in XCode, but I thought maybe Apple was using ICC internally to compile some parts of OSX. I have no firm basis for that belief, it's probably just a rumor I picked up somewhere. > Consider me available if you need some other tests and don't have other > easy access to OSX and Windows running on the same HW. Thanks. -- http://mail.python.org/mailman/listinfo/python-list