[haiku-commits] Re: r34888 - haiku/trunk/src/system/kernel/vm
- From: Stephan Assmus <superstippi@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 06 Jan 2010 15:09:55 +0100
Hi,
On 2010-01-06 at 13:21:43 [+0100], Ingo Weinhold <ingo_weinhold@xxxxxx>
wrote:
> On 2010-01-06 at 02:20:39 [+0100], Rene Gollent <anevilyak@xxxxxxxxx>
> wrote:
> > On Tue, Jan 5, 2010 at 7:10 PM, Rene Gollent <anevilyak@xxxxxxxxx>
> > wrote:
> > > 17 minutes for a gcc4-only image build on FreeBSD 8.0.
> > >
> > > 39 minutes on Haiku r34913 (KDEBUG_LEVEL = 0 and tracing disabled).
>
> Still quite a distance to bridge.
>
> > On a possibly related note, I do notice that "jam clean" for a fully
> > built tree is 3-4 times slower on Haiku than on FreeBSD, though I'd
> > imagine some of that is due to deletes being slow on BFS as it needs to
> > also update the indices?
>
> Definitely. I'd guess even with indices disabled BFS might not be a
> champion when it comes to small files. Without having write support for
> both BFS and any other seriously competing FS on any platform, that's
> hard to verify, though.
I am currently collecting some benchmarks, and on my particular hardware,
my findings are more positive. My machine has one of the first Core 2 Duo
chips, with 1.83 GHz and not a whole lot of cache. All platforms I tested
were compiling the source code on the very same partition. Both ZETA and
Haiku were tested with a BFS partition that contained no index. On openSUSE
11.2, I tested the same partition as ReiserFS 3.6, but unfortunately, Ext4
is so disappointingly resource heavy, that the build is impossible even on
a 3.6 Gig partition with the build tools source tree removed (runs out of
space)! PC-BSD wants a 10 Gig primary partition, so I have no data on that
either. My numbers so far are this:
Compiling revision 28969 with GCC-pipe enabled using GCC 2.95.3, no
UserBuildConfig, haiku-image target, BFS without index:
ZETA 1.2:
real 86m54.680s
user 22m8.017s
sys 80m48.841s
Haiku r34888, KDEBUG=0:
real 14m3.377s
user 20m41.319s
sys 4m51.959s
This means that Haiku r34888 is 6.19 times faster than ZETA at this system
level benchmark!
Unfortunately, I couldn't compile that revision of the source on Linux
anymore, so I can only compare Haiku and Linux with ZETA out of the picture:
Compiling revision 34845 with GCC-pipe enabled using GCC 2.95.3, no
UserBuildConfig, haiku-image target, BFS without index and ReiserFS 3.6:
Haiku r34888, KDEBUG=0:
real 18m55.198s
user 27m35.263s
sys 6m41.622s
Haiku r34888, KDEBUG=0, different partition, regular BFS with index, slower
location on the drive, heavily used, almost full and thus heavily
fragmented:
real 24m0.412s
user 27m36.399s
sys 12m12.895s
openSUSE 11.2, same partition as BFS noindex with ReiseFS 3.6:
real 13m32.431s
user 17m10.099s
sys 2m49.717s
This means that Haiku, in the comparable benchmark of using noindex, is
only 1.4 times slower than Linux on my hardware and freaking 6.2 times
faster than ZETA. I find that pretty amazing.
In all tests, the respective systems were freshly booted, the object
directory had been deleted in the previous session. Again, all systems used
GCC 2.95.3 with a -j2 build. Haiku had ActivityMonitor embedded in the
desktop and ProcessController in the Deskbar, Linux had an activity monitor
widget in the Plasma desktop. ZETA had nothing of the like. No other
programs were running and the machine was left alone for the time. On
Linux, I had another run with 13m53.408s, but decided to take the better
result. (Same on ZETA 1.2, where a previous run took 88 minutes instead of
86.)
Bottom line: Good freaking job, Ingo!!
Best regards,
-Stephan
Other related posts:
