IRC.

1 files changed, 31 insertions, 0 deletions

diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn
index ec14fa52..8147e5eb 100644
--- a/open_issues/performance.mdwn
+++ b/open_issues/performance.mdwn
@@ -81,3 +81,34 @@ call|/glibc/fork]]'s case.
       gnumach and the hurd) just wake every thread waiting for an event when
       the event occurs (there are a few exceptions, but not many)
     <antrik> ouch
+
+
+# IRC, freenode, #hurd, 2012-09-13
+
+{{$news/2011-q2#phoronix-3}}.
+
+    <braunr> the phoronix benchmarks don't actually test the operating system
+      ..
+    <hroi_> braunr: well, at least it tests its ability to run programs for
+      those particular tasks
+    <braunr> exactly, it tests how programs that don't make much use of the
+      operating system run
+    <braunr> well yes, we can run programs :)
+    <pinotree> those are just cpu-taking tasks
+    <hroi_> ok
+    <pinotree> if you do a benchmark with also i/o, you can see how it is
+      (quite) slower on hurd
+    <hroi_> perhaps they should have run 10 of those programs in parallel, that
+      would test the kernel multitasking I suppose
+    <braunr> not even I/O, simply system calls
+    <braunr> no, multitasking is ok on the hurd
+    <braunr> and it's very similar to what is done on other systems, which
+      hasn't changed much for a long time
+    <braunr> (except for multiprocessor)
+    <braunr> true OS benchmarks measure system calls
+    <hroi_> ok, so Im sensing the view that the actual OS kernel architecture
+      dont really make that much difference, good software does
+    <braunr> not at all
+    <braunr> i'm only saying that the phoronix benchmark results are useless
+    <braunr> because they didn't measure the right thing
+    <hroi_> ok