* Speed regression from 3.2 to 3.3
@ 2003-01-21 7:41 Matt Austern
2003-01-21 7:57 ` Pop Sébastian
0 siblings, 1 reply; 11+ messages in thread
From: Matt Austern @ 2003-01-21 7:41 UTC (permalink / raw)
To: gcc
[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]
I wanted to get some more information on the scope of the regression;
we've got a lot of fragmentary information flying around. I'm trying to
measure one specific case, which I hope is representative, of the
regression in C++ compilation speed from 3.2 to 3.3. For "3.2" I chose
gcc_3_2_1_release. For "3.3" I chose the top of gcc-3_3_branch as
of this morning. I did my measurements on a 1.5GHz P4 system, running
Linux 2.4.x. I made sure to run each measurement 5 times to verify that
I had reproducible results.
My measurement: compiling a single file from one of the QT example
programs. You can reproduce my results by unpacking qt-x11-free-3.1.1,
going into examples/xml/tagreader-with-features, and compiling the file
structureparser.cpp. I compiled it with all the same flags as it's
given in
the ordinary QT makefile, except that I compiled it at -O0.
OK, so the broad outline of what I've found out so far:
1. The regression is huge, a change from 3.3s real time to 4.9s.
That's 48%. The regression is almost entirely in user time,
as opposed to system time.
2. The back end is irrelevant, since I used -O0. As far as this
regression goes, none of the fancy optimization algorithms matter.
Using -ftime-report: the only phases that consistently account for
more than 1% of the time are garbage collection, preprocessing,
lexical analysis, and parsing. Parsing dominates, with roughly
50% of total time.
3. All of the regression is accounted for by regressions in the gc
and parser phases. Average gc time went up from 0.6s to 1.4s,
and average parser time went up from 2.3s to 2.9s.
I find the gc regression to be particularly interesting. First, note
that
this can't be accounted for by the bug that Geoff fixed. Even if it
applied to this test case, which it doesn't, Geoff fixed it in the 3.3
release branch a week ago. So what can the gc regression mean?
Logically, I can only think of two possibilities: either the gc
algorithm
suddenly got worse, or else the gc is now working on twice as much
memory as it used to. Both possibilities are a bit hard to believe, but
the second strikes me as far more plausible than the first.
Advice on tracking this down more precisely?
--Matt
P.S. For those who want to see my raw data, I'm including it as
an attachment.
[-- Attachment #2: regression_timing.bz2 --]
[-- Type: application/octet-stream, Size: 1884 bytes --]
[-- Attachment #3: Type: text/plain, Size: 11 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Speed regression from 3.2 to 3.3
2003-01-21 7:41 Speed regression from 3.2 to 3.3 Matt Austern
@ 2003-01-21 7:57 ` Pop Sébastian
2003-01-21 16:08 ` Jan Hubicka
0 siblings, 1 reply; 11+ messages in thread
From: Pop Sébastian @ 2003-01-21 7:57 UTC (permalink / raw)
To: Matt Austern; +Cc: gcc
On Mon, Jan 20, 2003 at 03:44:40PM -0800, Matt Austern wrote:
>
> I find the gc regression to be particularly interesting. First, note
> that
> this can't be accounted for by the bug that Geoff fixed. Even if it
> applied to this test case, which it doesn't, Geoff fixed it in the 3.3
> release branch a week ago. So what can the gc regression mean?
> Logically, I can only think of two possibilities: either the gc
> algorithm
> suddenly got worse, or else the gc is now working on twice as much
> memory as it used to. Both possibilities are a bit hard to believe, but
> the second strikes me as far more plausible than the first.
>
You could try to reverse gc changes to its 3.2 version and look wether
time spent in gc decreases or not...
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Speed regression from 3.2 to 3.3
2003-01-21 7:57 ` Pop Sébastian
@ 2003-01-21 16:08 ` Jan Hubicka
2003-01-22 10:58 ` Matt Austern
0 siblings, 1 reply; 11+ messages in thread
From: Jan Hubicka @ 2003-01-21 16:08 UTC (permalink / raw)
To: Pop Sébastian; +Cc: Matt Austern, gcc
> On Mon, Jan 20, 2003 at 03:44:40PM -0800, Matt Austern wrote:
> >
> > I find the gc regression to be particularly interesting. First, note
> > that
> > this can't be accounted for by the bug that Geoff fixed. Even if it
> > applied to this test case, which it doesn't, Geoff fixed it in the 3.3
> > release branch a week ago. So what can the gc regression mean?
> > Logically, I can only think of two possibilities: either the gc
> > algorithm
> > suddenly got worse, or else the gc is now working on twice as much
> > memory as it used to. Both possibilities are a bit hard to believe, but
> > the second strikes me as far more plausible than the first.
> >
>
> You could try to reverse gc changes to its 3.2 version and look wether
> time spent in gc decreases or not...
This is quite dificult to do as large parts of PCH branch has been
merged to 3.3. Can you just take a look at 3.2 time and mem reports and
looks what has changed to have something to start with?
Honza
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Speed regression from 3.2 to 3.3
2003-01-21 16:08 ` Jan Hubicka
@ 2003-01-22 10:58 ` Matt Austern
2003-01-22 19:23 ` Andrea 'fwyzard' Bocci
0 siblings, 1 reply; 11+ messages in thread
From: Matt Austern @ 2003-01-22 10:58 UTC (permalink / raw)
To: Jan Hubicka; +Cc: Pop Sébastian, gcc
[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]
On Monday, January 20, 2003, at 11:57 PM, Jan Hubicka wrote:
>> You could try to reverse gc changes to its 3.2 version and look wether
>> time spent in gc decreases or not...
>
> This is quite dificult to do as large parts of PCH branch has been
> merged to 3.3. Can you just take a look at 3.2 time and mem reports
> and
> looks what has changed to have something to start with?
What I see from the time report is pretty much what I said before: the
parser and the gc have gone up dramatically, nothing else matters.
I'm attaching a graph, for those who are interested.
I'm especially interested in the gc numbers, since it's hard to imagine
any good reason for why they went up.
Mem report shows... Well, one thing it shows is that the per-node
statistics (how many nodes of each type got allocated) have
disappeared in 3.3 and 3.4. Was that intentional?
I didn't see anything particularly interesting in the mem_report
information that I do have. I'm attaching the output it; perhaps
someone else will see more than I did. But at this point I still don't
know whether the gc time shot up because the gc is suddenly dealing
with lots more memory, or whether there's just a simple bug in the
collector.
--Matt
[-- Attachment #2: timings.pdf --]
[-- Type: application/pdf, Size: 22751 bytes --]
[-- Attachment #3: Type: text/plain, Size: 2 bytes --]
[-- Attachment #4: memreport.txt --]
[-- Type: text/plain, Size: 12410 bytes --]
bash-2.05$ ~/root32/bin/g++ -c -fmem-report -pipe -Wall -W -O0 -DQT_NO_DEBUG -DQT_SHARED -I/home/austern/qt-x11-free-3.1.1/mkspecs/linux-g++ -I. -I/usr/include/freetype2 -I../../../include -I/usr/X11R6/include -I/usr/X11R6/include -I.moc/release-shared/ structureparser.cpp
Tree Number Bytes % Total
error_mark 3 48 0.000
identifier_node 11931 745k 6.667
tree_list 36477 712k 6.369
tree_vec 10610 493k 4.415
block 5758 359k 3.217
void_type 4 448 0.004
integer_type 270 29k 0.264
real_type 7 784 0.007
complex_type 4 448 0.004
vector_type 15 1680 0.015
enumeral_type 128 14k 0.125
boolean_type 2 224 0.002
pointer_type 2719 297k 2.659
reference_type 1145 125k 1.120
method_type 4836 528k 4.729
array_type 218 23k 0.213
record_type 1501 164k 1.468
union_type 17 1904 0.017
function_type 1637 179k 1.601
lang_type 2 224 0.002
integer_cst 4635 144k 1.295
real_cst 37 2368 0.021
string_cst 119 3808 0.033
function_decl 10617 1161k 10.382
label_decl 182 19k 0.178
const_decl 1549 169k 1.515
type_decl 5330 582k 5.212
var_decl 2466 269k 2.411
parm_decl 18744 2050k 18.329
result_decl 3226 352k 3.155
field_decl 1305 142k 1.276
namespace_decl 4 448 0.004
component_ref 3791 118k 1.059
bit_field_ref 18 576 0.005
indirect_ref 3941 76k 0.688
array_ref 204 6528 0.057
constructor 170 5440 0.047
compound_expr 271 8672 0.076
modify_expr 693 21k 0.194
init_expr 1283 40k 0.358
target_expr 224 7168 0.063
cond_expr 188 6016 0.053
call_expr 3482 108k 0.973
method_call_expr 1358 42k 0.379
plus_expr 1162 36k 0.325
minus_expr 352 11k 0.098
mult_expr 145 4640 0.041
trunc_div_expr 71 2272 0.020
trunc_mod_expr 17 544 0.005
rdiv_expr 11 352 0.003
fix_trunc_expr 24 480 0.004
float_expr 21 420 0.004
negate_expr 39 780 0.007
min_expr 2 64 0.001
max_expr 2 64 0.001
abs_expr 8 160 0.001
lshift_expr 35 1120 0.010
rshift_expr 34 1088 0.009
bit_ior_expr 96 3072 0.027
bit_xor_expr 3 96 0.001
bit_and_expr 228 7296 0.064
bit_not_expr 13 260 0.002
truth_andif_expr 254 8128 0.071
truth_orif_expr 99 3168 0.028
truth_not_expr 194 3880 0.034
lt_expr 201 6432 0.056
le_expr 64 2048 0.018
gt_expr 138 4416 0.039
ge_expr 37 1184 0.010
eq_expr 520 16k 0.145
ne_expr 506 15k 0.141
convert_expr 481 9620 0.084
nop_expr 7202 140k 1.258
non_lvalue_expr 105 2100 0.018
save_expr 52 1664 0.015
addr_expr 4405 86k 0.769
predecrement_expr 84 2688 0.023
preincrement_expr 390 12k 0.109
postdecrement_expr 19 608 0.005
postincrement_expr 42 1344 0.012
expr_with_file_location 7 224 0.002
exc_ptr_expr 1 16 0.000
sizeof_expr 162 3240 0.028
arrow_expr 946 18k 0.165
expr_stmt 4026 78k 0.703
compound_stmt 8364 163k 1.460
decl_stmt 1436 28k 0.251
if_stmt 1091 34k 0.305
for_stmt 109 3488 0.030
while_stmt 210 6720 0.059
do_stmt 9 288 0.003
return_stmt 2365 46k 0.413
break_stmt 58 928 0.008
switch_stmt 5 160 0.001
label_stmt 81 1620 0.014
asm_stmt 2 128 0.001
scope_stmt 4166 81k 0.727
case_label 43 1376 0.012
stmt_expr 122 2440 0.021
cleanup_stmt 13 416 0.004
ptrmem_cst 3 60 0.001
nw_expr 30 960 0.008
dl_expr 22 704 0.006
scope_ref 681 21k 0.190
member_ref 8 256 0.002
aggr_init_expr 1 32 0.000
throw_expr 63 1260 0.011
template_decl 2584 282k 2.527
template_parm_index 2068 64k 0.578
template_type_parm 2478 271k 2.423
typename_type 655 71k 0.640
typeof_type 22 2464 0.022
using_decl 279 30k 0.273
template_id_expr 54 1728 0.015
binding 10781 210k 1.883
overload 5034 78k 0.703
lookup_expr 9775 190k 1.707
modop_expr 1069 33k 0.299
cast_expr 487 9740 0.085
reinterpret_cast_expr 29 580 0.005
const_cast_expr 9 180 0.002
static_cast_expr 98 1960 0.017
dotstar_expr 8 256 0.002
subobject 188 3760 0.033
ctor_stmt 686 10k 0.096
ctor_initializer 192 6144 0.054
try_block 64 2048 0.018
eh_spec_block 211 6752 0.059
handler 64 2048 0.018
Total 219036 10M
RTX Number Bytes % Total
const_int 130 1040 7.922
const_double 21 672 5.119
const_vector 19 152 1.158
pc 1 8 0.061
reg 10 160 1.219
mem 402 6432 48.995
symbol_ref 580 4640 35.344
cc0 1 8 0.061
eq 1 16 0.122
Total 1165 12k
Size Allocated Used Overhead
8 68k 49k 1564
16 260k 133k 3900
32 1520k 958k 16k
64 2376k 2342k 20k
128 4096 640 32
256 84k 17k 588
512 20k 16k 140
1024 8192 5120 56
2048 4096 4096 28
4096 8192 8192 56
112 7008k 6791k 54k
20 2652k 1922k 33k
Total 13M 11M 131k
String pool
entries 11931
identifiers 11931 (100.00%)
slots 16384
bytes 161k (13k overhead)
table size 64k
coll/search 0.3342
ins/search 0.0801
avg. entry 13.84 bytes (+/- 11.32)
longest entry 261
??? tree nodes created
(No per-node statistics)
obstack permanent_obstack: 100 bytes, 1 chunks
Type hash: size 32749, 5543 elements, 0.935632 collisions
no search statistics
bash-2.05$ ~/root33/bin/g++ -c -fmem-report -pipe -Wall -W -O0 -DQT_NO_DEBUG -DQT_SHARED -I/home/austern/qt-x11-free-3.1.1/mkspecs/linux-g++ -I. -I/usr/include/freetype2 -I../../../include -I/usr/X11R6/include -I/usr/X11R6/include -I.moc/release-shared/ structureparser.cpp
Tree Number Bytes % Total
Total 0 0
RTX Number Bytes % Total
Total 0 0
Size Allocated Used Overhead
8 60k 50k 1380
16 124k 115k 1860
32 1372k 979k 14k
64 1420k 1026k 12k
128 4096 768 32
256 104k 17k 728
512 96k 41k 672
1024 24k 6144 168
2048 8192 4096 56
4096 12k 12k 84
8192 8192 8192 28
16384 16k 16k 28
65536 64k 64k 28
112 7536k 7236k 58k
20 2740k 2086k 34k
12 44k 6300 748
44 940k 887k 8460
Total 14M 12M 134k
String pool
entries 12305
identifiers 12305 (100.00%)
slots 32768
bytes 165k (13k overhead)
table size 128k
coll/search 0.3481
ins/search 0.0813
avg. entry 13.74 bytes (+/- 11.47)
longest entry 282
??? tree nodes created
(No per-node statistics)
Type hash: size 32749, 5592 elements, 0.909418 collisions
no search statistics
bash-2.05$ ~/root34/bin/g++ -c -fmem-report -pipe -Wall -W -O0 -DQT_NO_DEBUG -DQT_SHARED -I/home/austern/qt-x11-free-3.1.1/mkspecs/linux-g++ -I. -I/usr/include/freetype2 -I../../../include -I/usr/X11R6/include -I/usr/X11R6/include -I.moc/release-shared/ structureparser.cpp
Size Allocated Used Overhead
8 64k 50k 1472
16 132k 118k 1980
32 1656k 999k 17k
64 1444k 1004k 12k
128 8192 768 64
256 172k 17k 1204
512 128k 46k 896
1024 24k 6144 168
2048 12k 8192 84
4096 8192 8192 56
8192 24k 24k 84
16384 16k 16k 28
65536 64k 64k 28
131072 128k 128k 28
112 7868k 7173k 61k
20 3816k 1961k 48k
12 80k 7872 1360
44 1088k 911k 9792
Total 16M 12M 157k
String pool
entries 12316
identifiers 12316 (100.00%)
slots 32768
bytes 165k (13k overhead)
table size 128k
coll/search 0.3609
ins/search 0.0811
avg. entry 13.74 bytes (+/- 11.46)
longest entry 282
??? tree nodes created
(No per-node statistics)
Type hash: size 32749, 5604 elements, 0.894068 collisions
no search statistics
bash-2.05$
[-- Attachment #5: Type: text/plain, Size: 1 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Speed regression from 3.2 to 3.3
2003-01-22 10:58 ` Matt Austern
@ 2003-01-22 19:23 ` Andrea 'fwyzard' Bocci
2003-01-22 19:30 ` Matt Austern
0 siblings, 1 reply; 11+ messages in thread
From: Andrea 'fwyzard' Bocci @ 2003-01-22 19:23 UTC (permalink / raw)
To: Matt Austern; +Cc: Jan Hubicka, Pop Sébastian, gcc
At 15.30 21/01/2003 -0800, Matt Austern wrote:
>What I see from the time report is pretty much what I said before: the
>parser and the gc have gone up dramatically, nothing else matters.
>I'm attaching a graph, for those who are interested.
From your graph, it looks like GC times went back to a good shape in 3.4.
Suggestions ?
fwyzard
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Speed regression from 3.2 to 3.3
2003-01-22 19:23 ` Andrea 'fwyzard' Bocci
@ 2003-01-22 19:30 ` Matt Austern
2003-01-22 20:45 ` Joe Buck
0 siblings, 1 reply; 11+ messages in thread
From: Matt Austern @ 2003-01-22 19:30 UTC (permalink / raw)
To: Andrea 'fwyzard' Bocci; +Cc: Jan Hubicka, Pop Sébastian, gcc
On Wednesday, January 22, 2003, at 09:42 AM, Andrea 'fwyzard' Bocci
wrote:
> At 15.30 21/01/2003 -0800, Matt Austern wrote:
>> What I see from the time report is pretty much what I said before: the
>> parser and the gc have gone up dramatically, nothing else matters.
>> I'm attaching a graph, for those who are interested.
>
> From your graph, it looks like GC times went back to a good shape in
> 3.4.
> Suggestions ?
That's sure what it looks like. I'm sure that's an important clue, but
I don't
know what it means either.
--Matt
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Speed regression from 3.2 to 3.3
2003-01-22 19:30 ` Matt Austern
@ 2003-01-22 20:45 ` Joe Buck
2003-01-22 20:48 ` Matt Austern
0 siblings, 1 reply; 11+ messages in thread
From: Joe Buck @ 2003-01-22 20:45 UTC (permalink / raw)
To: Matt Austern
Cc: Andrea 'fwyzard' Bocci, Jan Hubicka, Pop Sébastian, gcc
On Wed, Jan 22, 2003 at 10:03:41AM -0800, Matt Austern wrote:
> On Wednesday, January 22, 2003, at 09:42 AM, Andrea 'fwyzard' Bocci
> wrote:
>
> > At 15.30 21/01/2003 -0800, Matt Austern wrote:
> >> What I see from the time report is pretty much what I said before: the
> >> parser and the gc have gone up dramatically, nothing else matters.
> >> I'm attaching a graph, for those who are interested.
> >
> > From your graph, it looks like GC times went back to a good shape in
> > 3.4.
> > Suggestions ?
>
> That's sure what it looks like. I'm sure that's an important clue, but
> I don't
> know what it means either.
Just a guess:
It's probably because of Mark's new C++ parser. If it's faster, that's
great news.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Speed regression from 3.2 to 3.3
2003-01-22 20:45 ` Joe Buck
@ 2003-01-22 20:48 ` Matt Austern
2003-01-22 23:13 ` Mark Mitchell
0 siblings, 1 reply; 11+ messages in thread
From: Matt Austern @ 2003-01-22 20:48 UTC (permalink / raw)
To: Joe Buck
Cc: Andrea 'fwyzard' Bocci, Jan Hubicka, Pop Sébastian, gcc
On Wednesday, January 22, 2003, at 11:22 AM, Joe Buck wrote:
> On Wed, Jan 22, 2003 at 10:03:41AM -0800, Matt Austern wrote:
>> On Wednesday, January 22, 2003, at 09:42 AM, Andrea 'fwyzard' Bocci
>> wrote:
>>
>>> At 15.30 21/01/2003 -0800, Matt Austern wrote:
>>>> What I see from the time report is pretty much what I said before:
>>>> the
>>>> parser and the gc have gone up dramatically, nothing else matters.
>>>> I'm attaching a graph, for those who are interested.
>>>
>>> From your graph, it looks like GC times went back to a good shape in
>>> 3.4.
>>> Suggestions ?
>>
>> That's sure what it looks like. I'm sure that's an important clue,
>> but
>> I don't
>> know what it means either.
>
> Just a guess:
> It's probably because of Mark's new C++ parser. If it's faster, that's
> great news.
I don't think that can account for it, since the big change from 3.2 to
3.3, as shown by -ftime-report, was in the gc phase. Time spent in
gc shot up from 3.2 to 3.2, and went down again in 3.4. So if Mark's
new parser has an effect, it would be that it's much more efficient in
memory usage. Is that plausible? (Honest question, not rhetorical.
I haven't looked at his code yet; quite possible the answer is yes.)
Parsing time dominates, in 3.2 through 3.4. As far as parsing time
goes, the main thing I'm seeing with -ftime-report about the new
parser is that there's no longer a separate lexical analysis phase,
so the time spent there goes to zero, but mostly it just means that
the time has been reshuffled: the sum of the lexical analysis and
parse phases is almost identical in 3.3 and 3.4.
Possibly there's just some straightforward gc bug in 3.3 that didn't
happen to get into 3.4. I can hope, anyway.
--Matt
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Speed regression from 3.2 to 3.3
2003-01-22 20:48 ` Matt Austern
@ 2003-01-22 23:13 ` Mark Mitchell
0 siblings, 0 replies; 11+ messages in thread
From: Mark Mitchell @ 2003-01-22 23:13 UTC (permalink / raw)
To: Matt Austern, Joe Buck
Cc: Andrea 'fwyzard' Bocci, Jan Hubicka, Pop Sébastian, gcc
--On Wednesday, January 22, 2003 11:29:39 AM -0800 Matt Austern
<austern@apple.com> wrote:
> gc shot up from 3.2 to 3.2, and went down again in 3.4. So if Mark's
> new parser has an effect, it would be that it's much more efficient in
> memory usage. Is that plausible? (Honest question, not rhetorical.
> I haven't looked at his code yet; quite possible the answer is yes.)
There are some ways in which it's more efficient, and some ways in
which it's not, but, on balance, I wouldn't think that's where the
big changes are coming from. I did make some improvements along the
way to avoid allocating so much memory, and (for example) removing
implicit typename has that effect.
There are some other algorithmic improvements we plan to make to the
C++ front end over the next month or so that will also speed it up,
at least in some cases.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Speed regression from 3.2 to 3.3
2003-01-22 20:48 Richard Guenther
@ 2003-01-22 20:52 ` Matt Austern
0 siblings, 0 replies; 11+ messages in thread
From: Matt Austern @ 2003-01-22 20:52 UTC (permalink / raw)
To: Richard Guenther; +Cc: Joe Buck, gcc
On Wednesday, January 22, 2003, at 11:26 AM, Richard Guenther wrote:
> It could be due to the fix Geoff has done to 3.4 to prevent some
> variable
> in ggc-page.c from overflowing causing collecting every alloc that had
> been backported only a few days ago. Did you check recent enough 3.3?
Yes. I checked with Geoff to make sure that I had a recent enough
3.3 to get his fix. He also thinks it's unlikely that the test case I
was
using would trigger the bug he fixed.
--Matt
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Speed regression from 3.2 to 3.3
@ 2003-01-22 20:48 Richard Guenther
2003-01-22 20:52 ` Matt Austern
0 siblings, 1 reply; 11+ messages in thread
From: Richard Guenther @ 2003-01-22 20:48 UTC (permalink / raw)
To: Joe Buck; +Cc: Matt Austern, gcc
It could be due to the fix Geoff has done to 3.4 to prevent some variable
in ggc-page.c from overflowing causing collecting every alloc that had
been backported only a few days ago. Did you check recent enough 3.3?
Just a thought,
Richard.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-01-22 21:07 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-21 7:41 Speed regression from 3.2 to 3.3 Matt Austern
2003-01-21 7:57 ` Pop Sébastian
2003-01-21 16:08 ` Jan Hubicka
2003-01-22 10:58 ` Matt Austern
2003-01-22 19:23 ` Andrea 'fwyzard' Bocci
2003-01-22 19:30 ` Matt Austern
2003-01-22 20:45 ` Joe Buck
2003-01-22 20:48 ` Matt Austern
2003-01-22 23:13 ` Mark Mitchell
2003-01-22 20:48 Richard Guenther
2003-01-22 20:52 ` Matt Austern
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).