[plug] [linmagau] Distro Day (Revisited) - comments

[Sham Chukoury]

Hey folks.

Quite interesting article, I must say. :)
About the screen/console issue affecting kernel builds: it's known that
framebuffer consoles tend to be slower than 'plain' consoles, so not
much of a surprise there. Maybe redirecting all output to /dev/null will
speed things even more? ;)

About the HT test... I don't think that was quite a fair assesment. I
don't run a HT machine myself, however "Hyper-threading seems to be
'hype' on Linux until applications are written to take advantage of
it(...)" doesn't seem right to me. A friend of mine recently got a P4
2.4c with HT (which he overclocked to ~3GHz, but that's another
story...) and managed to build a 2.4.22 kernel - with SMP support - for
it. He's running RH8 and said he was recently compiling a kernel while
simultaneously rendering a simple animated OpenGL scene (uni
assignment). He reported no slowdown on the OpenGL animation (running at
500x500) while the kernel compilation took just a minute or two longer.
Both logical CPUs were maxed out while these tasks were running.

[5 mins later...]

While I started writing this e-mail, my friend started tinkering with
xmms visualisations. :) I just asked him to check his CPU usage while
running the 'jess' visualisation (which takes up 100% cpu usage on my
machine). He reported: 99.4% usage on CPU00 and 37% usage on CPU01.
Apparently, jess was being handled by CPU00 while the actual rendering
on X windows was being handled by CPU01. Therefore, HT doesn't simply
benefit multi-threaded applications, but also seems to improve resource
usage while running single-threaded processes concurrently. Like I
said... "seems" to improve...

§:)

_______________________________________________
plug mailing list
plug at plug.linux.org.au
http://mail.plug.linux.org.au/cgi-bin/mailman/listinfo/plug