1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
[[!tag faq/general]]
[[!meta title="Is the Hurd slow?"]]
The Hurd is currently slower than Linux, yes. But not very much, so it is
completely usable.
Take care when running the Hurd in fully-virtualized machines: virtualization
software use ugly heuristics to make Linux run faster, which will not work on
the Hurd (or BSD, etc.) so comparisons in virtualized environments do not really
hold. Also take care of not comparing Hurd (which is currently 32bit) with a
64bit Linux execution: 64bit has *much* more computational and optimization
possibilities than 32bit. At least, use -m32 to build a 32bit Linux version of a
test for comparison.
The main reason for slowness is *not* because of the overhead of RPCs. It's
mostly simply because less care has been done on implementing what makes Linux
fast: intelligent read-ahead, carefully-tuned page cache, etc. or even just
missing DMA support for your disk controller.
There is no ground reason this can not be achieved on GNU/Hurd, it has just not
been a priority until now (first make it work, then make it work fast). We are
currently working on multi-page pager and read-ahead, which should improve this
a lot.
|
