Re: 'make megatest' results for latest BillY WGET on AMD64/Linux --> highlighting FSCM
"Ger Hobbelt" <[email protected]>
| Newsgroups | gmane.mail.spam.crm114 |
|---|---|
| Message-ID | <[email protected]> |
Okay, let's concentrate on FSCM. To highlight FSCM, here's the diff -u
megatest snippet for vanilla CRM114 (always on AMD64/Linux):
**** Fast Substring Compression Match Classifier
type Q
-CLASSIFY fails; success probability: 0.1820 pR: -6.5278
-Best match to file #1 (q_test.css) prob: 0.8180 pR: 6.5278
+CLASSIFY fails; success probability: 0.1793 pR: -6.6061
+Best match to file #1 (q_test.css) prob: 0.8207 pR: 6.6061
Total features in input file: 69
-#0 (i_test.css): features: 207541, compression: 114.56, prob:
1.82e-01, pR: -6.53
-#1 (q_test.css): features: 223418, compression: 515.00, prob:
8.18e-01, pR: 6.53
+#0 (i_test.css): features: 230365, compression: 112.73, prob:
1.79e-01, pR: -6.61
+#1 (q_test.css): features: 246242, compression: 516.00, prob:
8.21e-01, pR: 6.61
type I
-CLASSIFY succeeds; success probability: 0.8097 pR: 6.2878
-Best match to file #0 (i_test.css) prob: 0.8097 pR: 6.2878
+CLASSIFY succeeds; success probability: 0.7951 pR: 5.8889
+Best match to file #0 (i_test.css) prob: 0.7951 pR: 5.8889
Total features in input file: 51
-#0 (i_test.css): features: 207541, compression: 324.22, prob:
8.10e-01, pR: 6.29
-#1 (q_test.css): features: 223418, compression: 76.22, prob:
1.90e-01, pR: -6.29
+#0 (i_test.css): features: 230365, compression: 296.86, prob:
7.95e-01, pR: 5.89
+#1 (q_test.css): features: 246242, compression: 76.50, prob:
2.05e-01, pR: -5.89
Notice the higher features counts for 64-bit boxes. Significant
increase, same code, ZERO code edits, just the WGET, compiled on
AMD64. Makes me go 'hmmmm'...
Anyway, I didn't notice this until AFTER I migrated, so let's go on:
We take the new GerH version of the latest FSCM code, completely
INTifadah'd an' all, and what do we get on our AMD64 box? diff -u
snippet:
**** Fast Substring Compression Match Classifier
+
+**** Fast Substring Compression Match Classifier
type Q
-CLASSIFY fails; success probability: 0.1820 pR: -6.5278
-Best match to file #1 (q_test.css) prob: 0.8180 pR: 6.5278
+CLASSIFY fails; success probability: 0.1793 pR: -6.6061
+Best match to file #1 (q_test.css) prob: 0.8207 pR: 6.6061
Total features in input file: 69
-#0 (i_test.css): features: 207541, compression: 114.56, prob:
1.82e-01, pR: -6.53
-#1 (q_test.css): features: 223418, compression: 515.00, prob:
8.18e-01, pR: 6.53
+#0 (i_test.css): features: 207541, compression: 112.73, prob:
1.79e-01, pR: -6.61
+#1 (q_test.css): features: 223418, compression: 516.00, prob:
8.21e-01, pR: 6.61
type I
-CLASSIFY succeeds; success probability: 0.8097 pR: 6.2878
-Best match to file #0 (i_test.css) prob: 0.8097 pR: 6.2878
+CLASSIFY succeeds; success probability: 0.7946 pR: 5.8742
+Best match to file #0 (i_test.css) prob: 0.7946 pR: 5.8742
Total features in input file: 51
-#0 (i_test.css): features: 207541, compression: 324.22, prob:
8.10e-01, pR: 6.29
-#1 (q_test.css): features: 223418, compression: 76.22, prob:
1.90e-01, pR: -6.29
+#0 (i_test.css): features: 207541, compression: 295.86, prob:
7.95e-01, pR: 5.87
+#1 (q_test.css): features: 223418, compression: 76.50, prob:
2.05e-01, pR: -5.87
Much better. That extra *** header line up there is because I ran the
test using megatest_ng.sh which coughs up each header TWICE so 'diff'
(not -u) will report each header: easier for me to see which
classifier is regurgitating a small, medium or large hairball, that's
all.
I'll ignore the slight difference in compression for now (well, I
don't think it's slight, but that's anal retentive me piping in):
looks good enough to proceed to the next stage, is what I intended to
do today after all: give Bill an example of an completely
'int/uint32_t' converted source code block which compiles with few or
no warnings.
So for our mutual reference, here's the GerH BACKPORTED result for
'make' in a vanilla setup. Okay, and now in understandable (American)
English...
1) I took the WGET copy of the sources.
2) Commented out the LDFLAGS line in Makefile to allow the stuff to
build (without this change, it doesn't on my system).
3) Run make megatest to create a local logfile. Look at the diffs,
mumble and continue.
4) Copy that local result to another file so we can compare against it lateron.
5) Copied the GerH crm_fast_substring_compression.c source file
OVERWRITING the local WGET copy.
6) Ran several cycles of (make/compile, vi/edit
crm_fast_substring_compression.c to taste, rinse & repeat) until I was
satisfied and a new CRM114 binary was born.
7) Run megatest.sh with the new bugger.
8) Look at the diffs with WGET's 'knowngood' reference logfile and the
(copied) logfile from stage (3+4).
Output for the last compile cycle so you can see what the new FSCM
int/uint32_t enabled FSCM code has to yak + for reference: compiler
version used to get this:
ger@Debbie:~/prj/1original/crm114/src/fscm1/crm114.sourceforge.net/src> make
cc -g -O3 -Wall -DPOSIX -DVERSION='"20080618-BlameBadGlasses"' -c
crm_fast_substring_compression.c -o crm_fast_substring_compression.o
crm_fast_substring_compression.c: In function 'crm_nextword2':
crm_fast_substring_compression.c:53: warning: passing argument 1 of
'crm_nextword' discards qualifiers from pointer target type
crm_fast_substring_compression.c: In function 'crm_mmap_file2':
crm_fast_substring_compression.c:66: warning: passing argument 1 of
'crm_mmap_file' discards qualifiers from pointer target type
crm_fast_substring_compression.c: In function 'crm_vector_tokenize_selector2':
crm_fast_substring_compression.c:91: warning: passing argument 2 of
'crm_vector_tokenize_selector' discards qualifiers from pointer target
type
crm_fast_substring_compression.c: In function 'crm_get_pgm_arg2':
crm_fast_substring_compression.c:103: warning: passing argument 3 of
'crm_get_pgm_arg' discards qualifiers from pointer target type
crm_fast_substring_compression.c:101: warning: unused variable 'ret'
#
# Now building the TRE regex version of CRM114. If you don't have
# TRE already, you will need to fetch it from the website and
# then ./configure --enable-static to get the static TRE libs,
# then build TRE, add /usr/local/lib to /etc/ld.so.conf, then
# to set the library up. Then you can build CRM114 itself.
#
cc crm_main.o crm_compiler.o crm_errorhandlers.o crm_math_exec.o
crm_var_hash_table.o crm_expandvar.o crm_stmt_parser.o
crm_vector_tokenize.o crm_expr_alter.o crm_expr_match.o
crm_css_maintenance.o crm_markovian.o crm_osb_bayes.o
crm_osb_hyperspace.o crm_correlate.o crm_osb_winnow.o
crm_winnow_maintenance.o crm_osbf_bayes.o crm_osbf_maintenance.o
crm_bit_entropy.o crm_neural_net.o crm_expr_clump.o crm_expr_window.o
crm_expr_isolate.o crm_expr_file_io.o crm_expr_syscall.o
crm_expr_classify.o crm_expr_translate.o crm_exec_engine.o
crm_debugger.o crm_str_funcs.o crm_preprocessor.o crm_expr_sks.o
crm_stats.o crm_expr_svm.o crm_fast_substring_compression.o \
crmregex_tre.o \
-lm -ltre -o crm114
#
# Done. Type "make help" to see what else you can make.
#
#
# Done.
#
# *** Type "make help" to see what else you can make.
#
ger@Debbie:~/prj/1original/crm114/src/fscm1/crm114.sourceforge.net/src>
gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (SUSE Linux)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Notice that all warnings are between line numbers 30 and 115 which is
the space in the source file where I dumped all the quick-hack stuff
to make the GerH code cooperate again with Bill's vanilla, which leads
me to conclude off hand:
Bill, you don't have to worry too much about myriads of warnings when
you migrate your code to 'int' all over and '[u]int32_t' at judicious
selected places; I did not count the number of typecasts in there, but
that number certainly has not reached my tolarance level for them or I
would have approached it in a different way.
Once one has converted ALL of CRM114 to the new 'int'+'[u]int32_t'
regime, some of the gory smut in the hack section can be discarded.
Most code in the 'hack section' from lines 30..115 are related to
fixes, overhauls and rewrites in the GerH code repository, compared to
the vanilla version of it all.
The added goodness of the conversion is that 64- and 32-bit results
are much more close to each other than before. With some extra huffing
and puffing you may get even closer to the ideal of 'identical'
(though the effort curve is exponential if you really crave
'identical' for all classifiers).
All in all, nothing deserving a panic. (It's just that one needs to
learn how to do this sort of thing and once it's grown into a (new)
habit, it's as I say it is: easy.)
Next on this channel: a writeup about FSCM int/int32_t migration
explaining what I did and why. Time for some commercials now. Don't
touch that dial, folks.
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php