From: Óscar F. <of...@wa...> - 2008-03-21 20:30:14
|
Hi! I've just installed andLinux Beta 1 rc6 (02/12/2008) (minimal / XFCE version) on WinXP SP2. I'm really impressed with andLinux (which implies coLinux!). However, I'm dissappointed about its performance: running a test suite on the host machine, VMWare Workstation 6.0 (Guest: Debian Etch) and andLinux takes this time: Host machine: 49 seconds VMWare: 48 seconds andLinux: 108 seconds The test suite consists on interpreting more than 1000 little programs. For every program, the interpreter is executed. The terminal is fast (it shows all text on 0.2 seconds, while VMWare needs 2.5 seconds). I'm using the local volume (i.e. no Samba involved). There is no shortage of RAM, neither on andLinux (uses 192 MB and `top' shows several dozens free; the interpreter just needs about 4 MB for each run) nor on the host Machie (1GB total, 400 MB free). Is this performance normal? The result of the current state of coLinux? Or an andLinux specific problem? -- Oscar |
From: <Use...@zo...> - 2008-03-21 21:37:56
|
of...@wa...(?scar Fuentes) 21.03.08 21:27 >Hi! >I've just installed andLinux Beta 1 rc6 (02/12/2008) (minimal / XFCE >version) on WinXP SP2. >I'm really impressed with andLinux (which implies coLinux!). >However, I'm dissappointed about its performance: running a test suite >on the host machine, VMWare Workstation 6.0 (Guest: Debian Etch) and >andLinux takes this time: >Host machine: 49 seconds >VMWare: 48 seconds >andLinux: 108 seconds Take outmost care when benchmarking! Times in VMs are not relyable. How does the host "feel" when the bench is running? I assume a 100% load under VMware, host rendered unusable? while colinux is "coopperative"? >The test suite consists on interpreting more than 1000 little >programs. For every program, the interpreter is executed. >The terminal is fast (it shows all text on 0.2 seconds, while VMWare >needs 2.5 seconds). I'm using the local volume (i.e. no Samba >involved). >There is no shortage of RAM, neither on andLinux (uses 192 >MB and `top' shows several dozens free; the interpreter just needs >about 4 MB for each run) nor on the host Machie (1GB total, 400 MB >free). >Is this performance normal? AFAIK VMware is "optimzed" to win such bench marks. VMware looses on file and netaccess, aka: real world ;-( But comparing VMware with colinux is unfair, anyway. >The result of the current state of >coLinux? Or an andLinux specific problem? I found colinux pretty fast enough. Maybe you can post a link to your benchmark programm? Rainer |
From: Óscar F. <of...@wa...> - 2008-03-21 23:43:27
|
Use...@zo... (Rainer Zocholl) writes: > Take outmost care when benchmarking! > Times in VMs are not relyable. My stopwatch is very reliable, and it agrees with both VMWare and coLinux :-) > How does the host "feel" when the bench is running? > > I assume a 100% load under VMware, host rendered unusable? > while colinux is "coopperative"? The system feels snappy on both cases. As the test suite is CPU bound, there is a 100% load on both cases too, as it should. > AFAIK VMware is "optimzed" to win such bench marks. > VMware looses on file and netaccess, aka: real world ;-( This is not a benchmark. It is real-world work and I must execute it dozens of times per day. > But comparing VMware with colinux is unfair, anyway. Why? >>The result of the current state of >>coLinux? Or an andLinux specific problem? > > I found colinux pretty fast enough. > > Maybe you can post a link to your benchmark programm? If you insist, I'll locate a project that shows a similar behaviour, as my test suite uses a fairly common approach. -- Oscar |
From: <Use...@zo...> - 2008-03-22 15:22:16
|
of...@wa...(?scar Fuentes) 22.03.08 00:43 Once upon a time "?scar Fuentes " shaped the electrons to say... >Use...@zo... (Rainer Zocholl) >writes: >> Take outmost care when benchmarking! >> Times in VMs are not reliable. >My stopwatch is very reliable, and it agrees with both VMWare and >coLinux :-) Ok. You didn't mention independed mesurement. >> AFAIK VMware is "optimzed" to win such bench marks. >> VMware looses on file and netaccess, aka: real world ;-( >This is not a benchmark. It is real-world work and I must execute it >dozens of times per day. Ok, your need CPU time, right, not IO. >> But comparing VMware with colinux is unfair, anyway. >Why? VMware is much much older, developed by a payed team driven by comerical interrest (you know EMC,the owner of VMware.) Colinux is mainly based on vulantary (great) work of some nice guys like Henry et al. But you are right: If there is a factor of 2 to 3 in performance waste, it might be worth a view. But 4 me "stability" is more important: I can simply buy more GHz clocks with the next chip releases. >> Maybe you can post a link to your benchmark programm? >If you insist, I'll locate a project that shows a similar behaviour, >as my test suite uses a fairly common approach. I think that would be a good idea, so i'll "insist" ;-) |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-21 21:39:43
|
Óscar Fuentes wrote: > Hi! > > I've just installed andLinux Beta 1 rc6 (02/12/2008) (minimal / XFCE > version) on WinXP SP2. > > I'm really impressed with andLinux (which implies coLinux!). > > However, I'm dissappointed about its performance: running a test suite > on the host machine, VMWare Workstation 6.0 (Guest: Debian Etch) and > andLinux takes this time: > > Host machine: 49 seconds > VMWare: 48 seconds > andLinux: 108 seconds > > The test suite consists on interpreting more than 1000 little > programs. For every program, the interpreter is executed. > > The terminal is fast (it shows all text on 0.2 seconds, while VMWare > needs 2.5 seconds). I'm using the local volume (i.e. no Samba > involved). There is no shortage of RAM, neither on andLinux (uses 192 MB > and `top' shows several dozens free; the interpreter just needs about 4 > MB for each run) nor on the host Machie (1GB total, 400 MB free). > > Is this performance normal? The result of the current state of coLinux? > Or an andLinux specific problem? > Can I download this test somethere? What is the local volume? A image file somethere on disk, or a true partition? What version of coLinux is there included? (uname -a) coLinux 0.8.0 has some improvemnets on block device with parameter "setcobd=async". It's available from http://www.colinux.org/snapshots/ -- Henry N. |
From: Óscar F. <of...@wa...> - 2008-03-21 23:36:45
|
Henry Nestler <Henry.Ne@Arcor.de> writes: > Can I download this test somethere? No, sorry. But I expect the same from the gcc testsuite, for instance, as it is very similar. Compiling is slower too. It is a C++ project and is compiled with g++ 4.1.2 in VMWare (80 seconds) and 4.1.3 in coLinux (124 seconds). > What is the local volume? A image file somethere on disk, or a true > partition? It is a image file (I hope that andLinux didn't partitioned my HD while installing! :-) > What version of coLinux is there included? (uname -a) Linux andLinux 2.6.12-co-0.7.1 #1 Sat Jul 14 12:13:49 UTC 2007 i686 GNU/Linux > coLinux 0.8.0 has some improvemnets on block device with parameter > "setcobd=async". It's available from http://www.colinux.org/snapshots/ I'll try it after learning how to upgrade, but the test suite is CPU bound (if the OS does a minimally sensible disk caching). coLinux is really awesome. Congratulations! -- Oscar |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-22 16:04:36
|
Óscar Fuentes wrote: >> What is the local volume? A image file somethere on disk, or a true >> partition? > > It is a image file (I hope that andLinux didn't partitioned my HD while > installing! :-) Ok. You not using the cofs. That would badly in such tests. >> What version of coLinux is there included? (uname -a) > > Linux andLinux 2.6.12-co-0.7.1 #1 Sat Jul 14 12:13:49 UTC 2007 i686 GNU/Linux Is Ok. That kernel does not use REGPARM. Small improvements comes with coLinux kernel 2.6.22, there REGPARM default. And what kernel you have in VMware? >> coLinux 0.8.0 has some improvemnets on block device with parameter >> "setcobd=async". It's available from http://www.colinux.org/snapshots/ > > I'll try it after learning how to upgrade, but the test suite is CPU > bound (if the OS does a minimally sensible disk caching). "setcobd=async" would no help for the executing time of "./configure". This helps only in systems with reading/writing from multitask or Multi-thread applications. Typicaly configure is a linear task. There, async option does not help. -- Henry N. |
From: Óscar F. <of...@wa...> - 2008-03-22 00:01:34
|
Óscar Fuentes <of...@wa...> writes: > Henry Nestler <Henry.Ne@Arcor.de> writes: > >> Can I download this test somethere? > > No, sorry. But I expect the same from the gcc testsuite, for instance, > as it is very similar. Compiling is slower too. It is a C++ project and > is compiled with g++ 4.1.2 in VMWare (80 seconds) and 4.1.3 in coLinux > (124 seconds). This is a another good test case: Building GNU Make from http://ftp.gnu.org/pub/gnu/make/make-3.81.tar.gz coLinux VMWare configure: 42.2 seconds 18.7 seconds make : 15.1 seconds 8.5 seconds As mentioned on my previous message, VMWare is 6.0.0 with Debian etch as guest OS, gcc 4.1.2. coLinux is 0.7.1 with Ubuntu Gutsy, gcc 4.1.3. -- Oscar |
From: <Use...@zo...> - 2008-03-22 15:22:14
|
of...@wa...(?scar Fuentes) 22.03.08 01:01 Once upon a time "?scar Fuentes " shaped the electrons to say... >?scar Fuentes <of...@wa...> writes: >> But I expect the same from the gcc testsuite, for >> instance, as it is very similar. Compiling is slower too. It is a >> C++ project and is compiled with g++ 4.1.2 in VMWare (80 seconds) >> and 4.1.3 in coLinux (124 seconds). always exactly 50% "plus". >This is a another good test case: >Building GNU Make from >http://ftp.gnu.org/pub/gnu/make/make-3.81.tar.gz #mkdir bench #cd bench #wget http://ftp.gnu.org/pub/gnu/make/make-3.81.tar.gz #tar xzf make-3.81.tar.gz #cd make-3.81 #time ./configure <... <real 0m46.911s <user 0m10.410s <sys 0m28.630s #time make <real 0m15.610s (validated with manual stopwatch) <user 0m10.150s <sys 0m5.240s #time make <... <real 0m0.340s <user 0m0.220s sys 0m0.090s second try: real 0m43.181s user 0m10.270s sys 0m31.700s real 0m16.280s user 0m10.680s sys 0m5.570s CPU: cat /proc/cpuinfo vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.60GHz stepping : 8 cpu MHz : 1596.000 cache size : 2048 KB bogomips : 104.65 clflush size : 64 colinux:~/work/bench/make-3.81# free total used free shared buffers cached Mem: 125944 88200 37744 0 7172 52172 -/+ buffers/cache: 28856 97088 Swap: 524280 0 524280 #uname -a Linux colinux 2.6.22.18-co-0.8.0 #1 PREEMPT Fri Mar 14 05:23:51 UTC 2008 i686 GNU/Linux # cat /etc/issue Debian GNU/Linux 4.0 \n \l # gcc --version gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) ########################################## native CPU debian (dynamically throttled 2,1GHz Dual core AMD CPU): uname -a Linux vdr 2.6.23x2 #2 SMP PREEMPT Sat Oct 20 03:08:47 CEST 2007 i686 GNU/Linux vdr:~/work/bench/make-3.81# gcc --version gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) configure: real 0m19.401s user 0m10.430s sys 0m7.220s make: real 0m9.315s user 0m8.510s sys 0m0.680s vdr:~/work/bench/make-3.81# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) X2 Dual Core Processor BE-2350 stepping : 1 cpu MHz : 1000.000 cache size : 512 KB bogomips : 2010.75 ########################### Virtual Box: configure real 0m31.718s user 0m11.001s sys 0m17.721s make: real 0m11.393s user 0m8.489s sys 0m2.424s ubuntu 7.10 (With running)xwindows ~/bench/make-3.81# uname -a Linux zoc-desktop 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux ~/bench/make-3.81# free total used free shared buffers cached Mem: 527644 447596 80048 0 22424 305236 -/+ buffers/cache: 119936 407708 Swap: 409616 34664 374952 ~/bench/make-3.81# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.60GHz stepping : 8 cpu MHz : 1595.741 cache size : 2048 KB bogomips : 3229.85 clflush size : 64 # cat /etc/issue Ubuntu 7.10 \n \l > coLinux VMWare >configure: 42.2 seconds 18.7 seconds >make : 15.1 seconds 8.5 seconds >As mentioned on my previous message, VMWare is 6.0.0 with Debian etch >as guest OS, gcc 4.1.2. coLinux is 0.7.1 with Ubuntu Gutsy, gcc 4.1.3. So i got the same results: -Colinux is the slowest. -VirtualPC third -VMware second (not tested here as too much overhead and too deep manipulations of OS) -Native fastest (surprise, surprise ;-)) (I wonder why "bogomips" are only 100 on colinux, bogo...) |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-22 15:50:13
|
Rainer Zocholl wrote: > (I wonder why "bogomips" are only 100 on colinux, bogo...) That is the overhead between native and coLinux. In the loop where bogomips are calculated, coLinux does only switching between Windows and Linux. That cost many time. coLinux goes faster, if you mounts filesystem with "noatime". For every file access, coLinux ask the host about current precice time to write the file "last access time". If starts many of processes, it can the speed problem here. -- Henry N. |
From: Paolo M. <pao...@gm...> - 2008-03-22 09:09:52
|
On Sat, Mar 22, 2008 at 1:01 AM, Óscar Fuentes <of...@wa...> wrote: > Óscar Fuentes <of...@wa...> writes: > > > Henry Nestler <Henry.Ne@Arcor.de> writes: > > > >> Can I download this test somethere? > > > > No, sorry. But I expect the same from the gcc testsuite, for instance, > > as it is very similar. Compiling is slower too. It is a C++ project and > > is compiled with g++ 4.1.2 in VMWare (80 seconds) and 4.1.3 in coLinux > > (124 seconds). > > This is a another good test case: > > Building GNU Make from > > http://ftp.gnu.org/pub/gnu/make/make-3.81.tar.gz > > coLinux VMWare > configure: 42.2 seconds 18.7 seconds > make : 15.1 seconds 8.5 seconds > > As mentioned on my previous message, VMWare is 6.0.0 with Debian etch as > guest OS, gcc 4.1.2. coLinux is 0.7.1 with Ubuntu Gutsy, gcc 4.1.3. > > > > -- > Oscar > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > Hi, I used VMware workstation 5.5 with slackware for several months. Then I changed to colinux. I don't have time measurement. I only have the impression that colinux is a little faster compiling. But I don't have any number to demostrate it. The great advantage of colinux is to have cofs .... the vmware module to access to my host fs didn't work fine. Bye, Paolo |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-22 15:33:25
|
Paolo Minazzi wrote: > On Sat, Mar 22, 2008 at 1:01 AM, Óscar Fuentes <of...@wa...> wrote: >> Óscar Fuentes <of...@wa...> writes: >> >> > Henry Nestler <Henry.Ne@Arcor.de> writes: >> > >> >> Can I download this test somethere? >> > >> > No, sorry. But I expect the same from the gcc testsuite, for instance, >> > as it is very similar. Compiling is slower too. It is a C++ project and >> > is compiled with g++ 4.1.2 in VMWare (80 seconds) and 4.1.3 in coLinux >> > (124 seconds). >> >> This is a another good test case: >> >> Building GNU Make from >> >> http://ftp.gnu.org/pub/gnu/make/make-3.81.tar.gz >> >> coLinux VMWare >> configure: 42.2 seconds 18.7 seconds >> make : 15.1 seconds 8.5 seconds >> >> As mentioned on my previous message, VMWare is 6.0.0 with Debian etch as >> guest OS, gcc 4.1.2. coLinux is 0.7.1 with Ubuntu Gutsy, gcc 4.1.3. coLinux-0.7.3 native configure: 63s 28s make: 28s 15s There can see, that colinux is ~50% slower as native. I can only compair native with coLinux. Have no VMware under Windows. CoLinux runs with 256MB of native 480MB RAM, gcc 3.3.1, both runs on same installation (dualboot). You wrote: > Host machine: 49 seconds > VMWare: 48 seconds > andLinux: 108 seconds There VMware is faster as native systems? That let me thing it is not real. Or it is some kind of prefetching cache to have faster disk access? Perhaps VMware loads some of the disk into RAM? What is the host CPU type? -- Henry N. |
From: <Use...@zo...> - 2008-03-22 16:59:21
|
Henry.Ne@Arcor.de(Henry Nestler) 22.03.08 16:33 >You wrote: >> Host machine: 49 seconds >> VMWare: 48 seconds >> andLinux: 108 seconds >There VMware is faster as native systems? That let me thing it is not >real. I would assume a "quantization error". i ran the make twice and got different results with more than 1000ms. I assume thare are other tasks running too. >Or it is some kind of prefetching cache to have faster disk >access? Perhaps VMware loads some of the disk into RAM? Rainer |
From: Óscar F. <of...@wa...> - 2008-03-22 17:00:57
|
Henry Nestler <Henry.Ne@Arcor.de> writes: > You wrote: >> Host machine: 49 seconds >> VMWare: 48 seconds >> andLinux: 108 seconds > > There VMware is faster as native systems? That let me thing it is not > real. It is real. I checked it with a stopwatch. > Or it is some kind of prefetching cache to have faster disk > access? Perhaps VMware loads some of the disk into RAM? The test suite starts a process more than 1000 times, pipes the output into the controlling process, etc. My experience shows that GNU/Linux is more effective than Windows for this sort of tasks. > What is the host CPU type? Intel Pentium M @ 2 GHz (single core). -- Oscar |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-22 18:13:04
|
Óscar Fuentes wrote: > Henry Nestler writes: > >> You wrote: >>> Host machine: 49 seconds >>> VMWare: 48 seconds >>> andLinux: 108 seconds >> There VMware is faster as native systems? That let me thing it is not >> real. > > It is real. I checked it with a stopwatch. > >> Or it is some kind of prefetching cache to have faster disk >> access? Perhaps VMware loads some of the disk into RAM? > > The test suite starts a process more than 1000 times, pipes the output > into the controlling process, etc. My experience shows that GNU/Linux is > more effective than Windows for this sort of tasks. Suggest from you, here is a test script, that only eceute some processes, without disk io: #!/bin/bash loop=10000 while test $loop -gt 0 do x=`uname -r` loop=$(($loop - 1)) done Tested with Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz 22.9s native, kernel 2.6.17 89.7s coLinux 0.8.0, kernel 2.6.22.18 Can you run tis on WVware please? -- Henry N. |
From: Óscar F. <of...@wa...> - 2008-03-22 18:31:18
|
Henry Nestler <Henry.Ne@Arcor.de> writes: >> The test suite starts a process more than 1000 times, pipes the output >> into the controlling process, etc. My experience shows that GNU/Linux is >> more effective than Windows for this sort of tasks. > > Suggest from you, here is a test script, that only eceute some > processes, without disk io: > #!/bin/bash > > loop=10000 > while test $loop -gt 0 > do > x=`uname -r` > loop=$(($loop - 1)) > done > > Tested with Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz > 22.9s native, kernel 2.6.17 > 89.7s coLinux 0.8.0, kernel 2.6.22.18 > > Can you run tis on WVware please? 26.2 seconds Pentium M 2.00 GHz VMWare 6.0.0 Linux etch 2.6.18-5-686 #1 SMP I can't test it on coLinux, because I corrupted fstab while trying to mount with noatime: I made a typo (noattime) and now the file system mounts read-only. umount does not work, nor mount -o remount, etc. -- Oscar |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-22 18:51:13
|
Óscar Fuentes wrote: > Henry Nestler <Henry.Ne@Arcor.de> writes: > >>> The test suite starts a process more than 1000 times, pipes the output >>> into the controlling process, etc. My experience shows that GNU/Linux is >>> more effective than Windows for this sort of tasks. >> Suggest from you, here is a test script, that only eceute some >> processes, without disk io: >> #!/bin/bash >> >> loop=10000 >> while test $loop -gt 0 >> do >> x=`uname -r` >> loop=$(($loop - 1)) >> done >> >> Tested with Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz >> 22.9s native, kernel 2.6.17 >> 89.7s coLinux 0.8.0, kernel 2.6.22.18 >> >> Can you run tis on WVware please? > > 26.2 seconds > Pentium M 2.00 GHz > VMWare 6.0.0 > Linux etch 2.6.18-5-686 #1 SMP Ok. And is not faster as my native. An other PC: I have 17.1s on Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz. Runs only on one core and with 1.6GHz (2.6.22.5-31 SuSE 10.3 native) > I can't test it on coLinux, because I corrupted fstab while trying to > mount with noatime: I made a typo (noattime) and now the file system > mounts read-only. umount does not work, nor mount -o remount, etc. > By the while "noatime" does not improve speed. I have tested with and without. Differ coLinux version made no effect. All test on same machine, with SuSE 9.0, coLinux runs on partitions (dualboot). make-3.81.tar.gz unpack config make Native SuSE90 1.8s 28.3s 14.6s kernel 2.6.17 colinux0.7.3 1.7s 63.6s 28.2s (first, after reboot Windows) 1.0s 64.4s 28.6s 0.6s 61.1s 24.4s 0.9s 64.2s 28.6s 1.0s 64.0s 29.1s colinux0.7.2 0.9s 54.3s 28.6s colinux0.8.0 0.9s 64.9s 28.7s (noatime) 0.8s 65.7s 28.7s (atime) colinux080async 0.8s 65.4s 29.0s 0.9s 65.8s 29.4s 0.7s 62.2s 28.9s colinux0.6.4 0.8s 64.6s 27.7s 0.8s 61.2s 29.0s 0.8s 63.4s 28.8s coLinux speed is 50% slower as native. -- Henry N. |
From: <Use...@zo...> - 2008-03-22 19:24:12
|
of...@wa...(?scar Fuentes) 22.03.08 19:31 >I can't test it on coLinux, because I corrupted fstab while trying to >mount with noatime: I made a typo (noattime) and now the file system >mounts read-only. umount does not work, nor mount -o remount, etc. boot new image or knoppix #mount -o loop brokenimage /mnt #vi /mnt/etc/fstab #umount /mnt #halt boot broken image HTH |
From: Óscar F. <of...@wa...> - 2008-03-22 19:46:35
|
Use...@zo... (Rainer Zocholl) writes: >>I can't test it on coLinux, because I corrupted fstab while trying to >>mount with noatime: I made a typo (noattime) and now the file system >>mounts read-only. umount does not work, nor mount -o remount, etc. > > > boot new image or knoppix Thanks, Rainer, but Henry already explained how to fix this off-list. [snip] -- Oscar |
From: Óscar F. <of...@wa...> - 2008-03-22 19:19:55
|
Henry Nestler <Henry.Ne@Arcor.de> writes: > Óscar Fuentes wrote: >> Henry Nestler <Henry.Ne@Arcor.de> writes: >> >>>> The test suite starts a process more than 1000 times, pipes the output >>>> into the controlling process, etc. My experience shows that GNU/Linux is >>>> more effective than Windows for this sort of tasks. >>> Suggest from you, here is a test script, that only eceute some >>> processes, without disk io: >>> #!/bin/bash >>> >>> loop=10000 >>> while test $loop -gt 0 >>> do >>> x=`uname -r` >>> loop=$(($loop - 1)) >>> done >>> >>> Tested with Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz >>> 22.9s native, kernel 2.6.17 >>> 89.7s coLinux 0.8.0, kernel 2.6.22.18 >>> >>> Can you run tis on WVware please? >> >> 26.2 seconds >> Pentium M 2.00 GHz >> VMWare 6.0.0 >> Linux etch 2.6.18-5-686 #1 SMP > > Ok. And is not faster as my native. Please note that VMWare was slightly faster than the host *WindowsXP* system for the same operation (running a test suite that requires executing more than 1000 times the same process). If GNU/Linux is more efficient than WindowsXP for this task, as I suspect, it is expected that your native GNU/Linux is faster than my VMWare GNU/Linux guest, even if my processor is a bit faster. BTW, your shell script runs on 87.5 seconds on my coLinux install. > An other PC: I have 17.1s on Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz. Runs > only on one core and with 1.6GHz (2.6.22.5-31 SuSE 10.3 native) > >> I can't test it on coLinux, because I corrupted fstab while trying to >> mount with noatime: I made a typo (noattime) and now the file system >> mounts read-only. umount does not work, nor mount -o remount, etc. >> > > By the while "noatime" does not improve speed. Same here. -- Oscar |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-29 15:22:24
|
Hello, Óscar Fuentes wrote: > Henry Nestler <Henry.Ne@Arcor.de> writes: > >> Óscar Fuentes wrote: >>> Henry Nestler <Henry.Ne@Arcor.de> writes: >>> >>>>> The test suite starts a process more than 1000 times, pipes the output >>>>> into the controlling process, etc. My experience shows that GNU/Linux is >>>>> more effective than Windows for this sort of tasks. >>>> Suggest from you, here is a test script, that only eceute some >>>> processes, without disk io: >>>> #!/bin/bash >>>> >>>> loop=10000 >>>> while test $loop -gt 0 >>>> do >>>> x=`uname -r` >>>> loop=$(($loop - 1)) >>>> done >>>> >>>> Tested with Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz >>>> 22.9s native, kernel 2.6.17 >>>> 89.7s coLinux 0.8.0, kernel 2.6.22.18 scnapshot-20080329 http://www.colinux.org/snapshots/ is significant faster now: 30.1s coLinux 0.8.0-20080329, kernel 2.6.22.18 Round about 500.000 OS switches in this test script are optimised with a better handling of page allocation. The gust call to the host never, if the page is always allocated. The changes on guest side would also speed up some other programms. Typically all programms with high numbers of memory alloc/free runs faster. The other test http://ftp.gnu.org/pub/gnu/make/make-3.81.tar.gz is now: configure make native: 28s 15s coLinux-0.7.3: 63s (41%) 28s (53%) coLinux-20080329: 31s (90%) 19s (79%) -- Henry N. |