1 |
What were you benchmarking since you never even mentioned that, the |
2 |
compilation of the software or the resulting executable's performance. |
3 |
The first one seems pretty useless to me, while the latter does make |
4 |
sense. |
5 |
|
6 |
On Mon, 2002-04-08 at 04:46, Spider wrote: |
7 |
> I know well that this is was completely unscientific and unreproductible |
8 |
> behaviour, with only one run and so on. |
9 |
> |
10 |
> PDC20265: chipset revision 2 |
11 |
> PDC20265: not 100% native mode: will probe irqs later |
12 |
> PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. |
13 |
> ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:DMA, hdf:pio |
14 |
> ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio |
15 |
> |
16 |
> hde: Maxtor 5T030H3, ATA DISK drive |
17 |
> its an Athlon t-bird 1GHz |
18 |
> MemTotal: 288548 kB |
19 |
> (PC-100 SDRAM) |
20 |
> |
21 |
> Filesystem on the drive used for compilations are ReiserFS. |
22 |
> |
23 |
> Using r5 hash to sort names |
24 |
> ReiserFS version 3.6.25 |
25 |
> |
26 |
> also, the fact that I dont use the same compiler flags for both |
27 |
> compilers are a dead giveaway. |
28 |
> |
29 |
> Better code, I can't speak for. More tests, I can, I've had to patch up |
30 |
> some c++ code in order to fit the stricter tests, something I consider |
31 |
> good. |
32 |
> |
33 |
> |
34 |
> cpu idle time doesn't matter much when diskaccess is ventured, should I |
35 |
> ever intend to do a good benchmark I'd use tmpfs for the whole process, |
36 |
> and make sure I dont run out of RAM while doing it. This is a user |
37 |
> comparsion, the feeling of how long things take to compile c++. |
38 |
> |
39 |
> And yes, the machine was in "normal use" at the time. Xchat, sylpheed |
40 |
> and some aterm's. bad behaviour for a benchmarker. But standard for me |
41 |
> whenever I compile things, and thats how I wanted the comparsion done. |
42 |
> |
43 |
> kernel is for once the default gentoo one, something I seldom use |
44 |
> normally. (I prefer -jam series) |
45 |
> |
46 |
> //Spider |
47 |
> |
48 |
> |
49 |
> |
50 |
> > |
51 |
> > So, regarding your benchmarks Spider. There is something wrong, |
52 |
> > definately. And I think our gentoo kernel heads around here should |
53 |
> > take a close look at it. Sure, GCC 3.X *is* slower on compilation |
54 |
> > time, however, your tests show a very disturbing fact: Under some |
55 |
> > circumstances, your CPU seems to spend unreasonable amount of time not |
56 |
> > doing anything. This could be an indication of a bigger issue, |
57 |
> > possibly a configuration or a hardware issue. There might be an issue |
58 |
> > going on with the cache or the filesystem or even the loader. How much |
59 |
> > memory the PC you used has and what kind of drive and filesystem did |
60 |
> > you use? (I hope that all this is not a side effect of one of the |
61 |
> > Gentoo kernel patches...) |
62 |
> > |
63 |
> |
64 |
> |
65 |
> -- |
66 |
> begin happy99.exe |
67 |
> This is a .signature virus! Please copy me into your .signature! |
68 |
> See Microsoft KB Article Q265230 for more information. |
69 |
> end |
70 |
-- |
71 |
Geert Bevin Uwyn |
72 |
"Use what you need" Lambermontlaan 148 |
73 |
http://www.uwyn.com 1030 Brussels |
74 |
gbevin@××××.com Tel & Fax +32 2 245 41 06 |