Announcement

Collapse
No announcement yet.

Gentoo vs. Ubuntu performance comparison

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Apopas
    replied
    Why the hell I saw that benchmarks after 2 months???

    Leave a comment:


  • kraftman
    replied
    Originally posted by yotambien View Post
    What bloat do you refer to that it would affect the numbers like that? It's not that Ubuntu runs random crappy applications for the sake of it--or that's what I hope.
    Things like some debugging enabled (I have fully upgraded rc version to stable and there are still debugging options turned on - cat /boot/config-2.6.31-14-generic |grep DEBUG |grep =), perfcounters and maybe some other, similar features which can affect performance. I'm not saying having such options enabled is bad.
    Last edited by kraftman; 31 October 2009, 03:40 PM.

    Leave a comment:


  • Ex-Cyber
    replied
    Doesn't mplayer enable some asm routines based on runtime CPU detection?

    Leave a comment:


  • yotambien
    replied
    Originally posted by RealNC View Post
    And did you tell a difference with mplayer between -march=your_cpu and -march=i486?

    And how did you try to measure the difference in the first place? Because virtually no one can count FPS just by looking
    Heh, absolutely noone. I had used mplayer's benchmark option. I looked at the first minutes of a couple of random videos I had lying around, and the differences were minimal and seemingly random. I don't remember the compiling options, but Kano is probably right and mplayer does the right thing so it was expected that I didn't see any real differences. Other issue may be that they were MPEG-4 (low? simple?), nothing very demanding. Off topic, later on I also benchmarked mplayer's h264 decoding speed compared to mplayer using CoreAVC, and the results were again similar, except that the CPU burden was in different places (single processor here).

    Leave a comment:


  • krazy
    replied
    Originally posted by chithanh View Post
    (...)the assumption that kernel version skewed the results is not consistent with the almost sweeping win of the 2.6.30 based system over 2.6.28.
    Why not? Two kernel releases apart = huge differences in performance. Just look at the PostgreSQL performance delta 2.6.31 to 2.6.32.

    Of course, I don't know if the different kernel causes performance differences or not, but it could - thus this comparison is useless.

    Leave a comment:


  • mits
    replied
    Originally posted by yotambien View Post
    I don't know if it would be nice, but it wouldn't be fair. Ubuntu is a distribution that is targeted at the general public, as is Debian or OpenSuse.
    I didn't mean that it should generally be aimed towards newer systems, just that if there's a big difference between the performance of the greatest common divisor and the new hardware, maybe packages for a new arch should be made too (*kiiiind* of like amd64)

    Leave a comment:


  • RealNC
    replied
    Maybe, but I know for sure that it won't run on a Pentium 4, because I actually tried and get "illegal instruction" errors.

    Leave a comment:


  • psycho_driver
    replied
    Originally posted by RealNC View Post
    Optimization flags are always used. In Ubuntu and every other distro too. They don't use --march though, since the apps needs to run on many types of CPU. Compiling with --march=core2, would result in the distro not being able to run on anything older than an Intel Core 2.
    Not necessarily. I just built my athlon ii 620 system, and took the raid 1 drives out of my gentoo --march=core2 built system, and it booted up and ran fine after I recompiled my kernel for the hardware that had changed. If compiled for an older architecture via --march, there's a good chance it'll run on another cpu type (within the same family) so long as the new cpu type supports every feature that the old cpu supported.

    EDIT: Oops, I originally read "older" as "other".

    Leave a comment:


  • Kano
    replied
    mplayer detects the cpu in the configure script and when you don't use --enable-runtime-cpudetection it will be optimized for the build system. I always recompile mplayer - with some extra patches which are not not mainline and luckyly even my slowest system does not need more than 3 min

    Leave a comment:


  • RealNC
    replied
    Originally posted by yotambien View Post
    But this is why I asked, because I had the feeling that you were refering to that 'bloat'. Are you sure that having more configure options will affect the performance of the program when you don't use the extra stuff? I remember comparing mplayer from Debian multimedia repo and a self-compiled one some time ago...I couldn't tell the difference, honestly.
    And did you tell a difference with mplayer between -march=your_cpu and -march=i486?

    And how did you try to measure the difference in the first place? Because virtually no one can count FPS just by looking
    Last edited by RealNC; 30 October 2009, 07:11 PM.

    Leave a comment:

Working...
X