Re: benchmarking - it's now all(-1,0,1,5,6)% faster
In perl.perl6.internals, you wrote:
--- Leopold Toetsch [EMAIL PROTECTED] wrote:
* SLOW (same slow with register or odd aligned)
* 0x818118a jit_func+194:sub0x8164cac,%ebx
* 0x8181190 jit_func+200:jne0x818118a jit_func+194
The slow one has the loop crossing over a 16 byte boundary. Try moving it
over a bit.
Yep, actually it looks like a 8 byte boundary:
Following program:
#!/usr/bin/perl -w
use strict;
for (my $i = 0; $i 100; $i++) {
printf %3d\t, $i;
open(P, m.pasm);
for (0..$i) {
print(P 'ENOP');
noop
ENOP
}
print(P 'EOF');
setI3, 1
setI4, 1
setI5, I4
time N1
REDO: subI4, I4, I3
if I4, REDO
time N5
subN2, N5, N1
setN1, I5
mulN1, 2
divN1, N2
setN2, 100.0
divN1, N2
print N1
print M op/s\n
end
EOF
close(P);
system(perl assemble.pl m.pasm | parrot -j -);
}
And here is the output:
0 790.826400 M op/s
1 523.305494 M op/s
2 788.544190 M op/s
3 783.447189 M op/s
4 783.975462 M op/s
5 788.208178 M op/s
6 782.466484 M op/s
7 788.059343 M op/s
8 788.836349 M op/s
9 522.986581 M op/s
10 788.895326 M op/s
11 784.021624 M op/s
12 789.773978 M op/s
13 788.065635 M op/s
14 783.558056 M op/s
15 789.010709 M op/s
16 782.463565 M op/s
17 523.049517 M op/s
18 781.350657 M op/s
19 784.184698 M op/s
20 789.683646 M op/s
21 781.362666 M op/s
22 783.994146 M op/s
23 789.100887 M op/s
24 783.990848 M op/s
25 370.620840 M op/s
26 786.862561 M op/s
27 784.092342 M op/s
28 789.106826 M op/s
29 784.027852 M op/s
30 780.688935 M op/s
31 787.913154 M op/s
32 783.576354 M op/s
33 526.877272 M op/s
34 780.493905 M op/s
35 790.339116 M op/s
36 789.166586 M op/s
37 782.154592 M op/s
38 786.902789 M op/s
39 783.834446 M op/s
40 784.003305 M op/s
41 522.135984 M op/s
42 780.618829 M op/s
43 790.167145 M op/s
44 783.284786 M op/s
45 790.363689 M op/s
46 781.002931 M op/s
47 783.720572 M op/s
48 789.774350 M op/s
49 523.933363 M op/s
50 786.970706 M op/s
51 780.966576 M op/s
52 789.234894 M op/s
53 784.317040 M op/s
54 780.993842 M op/s
55 789.914164 M op/s
56 783.705196 M op/s
57 291.958023 M op/s
58 783.653215 M op/s
59 788.739927 M op/s
60 784.599837 M op/s
61 783.917218 M op/s
62 790.051795 M op/s
63 782.589121 M op/s
64 784.846120 M op/s
65 523.988181 M op/s
66 788.746231 M op/s
67 781.811980 M op/s
68 786.188159 M op/s
69 790.023521 M op/s
70 783.149502 M op/s
71 786.531300 M op/s
72 781.711076 M op/s
73 527.106372 M op/s
74 783.735948 M op/s
75 788.491194 M op/s
76 782.442035 M op/s
77 780.387170 M op/s
78 789.259770 M op/s
79 779.781801 M op/s
80 788.186701 M op/s
81 523.328673 M op/s
82 790.407627 M op/s
83 782.751235 M op/s
84 788.410417 M op/s
85 782.625627 M op/s
86 782.056516 M op/s
87 787.631292 M op/s
88 782.218409 M op/s
89 425.664145 M op/s
90 778.734333 M op/s
91 787.851363 M op/s
92 784.661485 M op/s
93 788.292247 M op/s
94 783.754621 M op/s
95 789.181805 M op/s
96 788.326694 M op/s
97 523.357568 M op/s
98 782.105369 M op/s
99 781.796679 M op/s
This of course has the assumption, that the program did run at the
same address, which is - from my experience with gdb - usually true.
So moving the critical part of a program by just one byte can cause a
huge slowdown.
(This is an Athlon 800, i386/linux)
leo
Re: benchmarking - it's now all(-1,0,1,5,6)% faster
Andreas J. Koenig wrote: On Sat, 11 Jan 2003 22:26:39 +0100, Leopold Toetsch [EMAIL PROTECTED] said: Nicholas Clark wrote: So I'm confused. It looks like some bits of perl are incredibly sensitive to cache alignment, or something similar. This reminds me on my remarks on JITed mops.pasm which variied ~50% And it reminds me on my postings to p5p about glibc being very buggy up to 2.3 (posted during last October). I came to the conclusion that perl cannot be benchmarked at all with glibc before v2.3. There might be additional problems with glibc, but the deviations in JIT code timings are only caused by moving the loop by on byte (crossing a 8 byte boundary). leo
Re: benchmarking - it's now all(-1,0,1,5,6)% faster
[EMAIL PROTECTED] wrote: Nicholas Clark [EMAIL PROTECTED] wrote: :So I'm confused. It looks like some bits of perl are incredibly sensitive to :cache alignment, or something similar. And as a consequence, perlbench is :reliably reporting wildly varying timings because of this, and because it :only tries a few, very specific things. Does this mean that it's still useful? I think I remember seeing a profiler that emulates the x86 instruction set, and so can give theoretically exact timings. Does this ring a bell for anyone? I don't know if the emulation extended to details such as RAM and cache sizes ... Do you mean Valgrind ? You can get it from http://developer.kde.org/~sewardj/ Peter Hugo
Re: Objects, finally (try 1)
On 01/11/03 Nicholas Clark wrote: This allows us to declare 8bit characters and strings of those and all the stuff we're used to with C like unions ... (C# has 16bit chars, and strings are UTF8 encoded , IIRC) ... That doesn't sound right. But if it is right, then it sounds very wrong. (Translation: Are you sure about your terms, because what you describe sounds wonky. Hence if they are using UTF8 but with 16 bit chars, that feels like a silly design decision to me. Perl 5 performance is not enjoying a variable length encoding, but using an 8 bit encoding in 8 bit chars at least makes it small in memory.) The CLR runtimes use 16 bit chars and UTF16-encoded strings (at least as far as it's visible to the 'user' programs). lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
Re: Objects, finally (try 1)
If memory serves me right, Paolo Molaro wrote: The CLR runtimes use 16 bit chars and UTF16-encoded strings (at least as far as it's visible to the 'user' programs). 1023.2.3 #Strings heap 11 The stream of bytes pointed to by a #Strings header is the physical representation of the logical string heap. 13 but parts that are reachable from a table shall contain a valid null terminated UTF8 string. When the #String So I think the runtime does a UTF16 conversion , I suppose ...So you're right ... all C# programs get UTF16 strings to work with... but that's not the way they're in meta-data... (JVM also has UTF8 strings and 16 bit chars, it's not really a big issue :) But coming back to parrot ... I don't think parrot uses UTF8 (from what I could gather it seems to be all ASCII ?) ... Or is UTF8 hiding in somewhere ?... Gopal -- The difference between insanity and genius is measured by success
Re: Objects, finally (try 1)
On 01/12/03 Gopal V wrote: If memory serves me right, Paolo Molaro wrote: The CLR runtimes use 16 bit chars and UTF16-encoded strings (at least as far as it's visible to the 'user' programs). 1023.2.3 #Strings heap 11 The stream of bytes pointed to by a #Strings header is the physical representation of the logical string heap. 13 but parts that are reachable from a table shall contain a valid null terminated UTF8 string. When the #String The #Strings heap doesn't contain strings for programs that run in the CLR (unlike the #US -user sring- heap that contains the strings in UTF-16) encoding. What matters, though, is the encoding of the String class at runtime and that is defined to be UTF-16, it has absolutely no importance what encoding it has on disk (even though that encoding is still UTF-16). lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
optimising, and per file flags
IIRC Leo added an option to Configure.pl to turn on optimising. Prior to this, on IRC Dan said to me that we need to avoid the hack that perl5 found itself in, when it had to retro-fit the ability to change the compiler flags per file. Currently I don't think we have this ability. I was wondering if we could do it by specifying the optimiser flags in the form of /.../=xxx !...!=xxx yyy where the first two give a regular expression for the object file(s) we wish flags xxx to apply to. The alternative of !! for m!! should be allowed so that paths can be specified in the object files as needed, without shell escaping. All paths should be in Unix forward slash format, to reduce potential confusion. If there are no flags, then yyy applies to all other files. I think this works, except that I'm not sure how to have whitespace in xxx but let us have multiple regexps. I *think* we need to do this by having optimiser options be an array - specify the array on the command like by having multiple --optimise= flags, and interactively just keep accepting more flags, terminating at the first global flags yyy line. [We could even provide --optimize= as a synonym for the the Americans :-)] The reason I bring this up - I've just found this while browsing the gcc info pages: `-fgcse' Perform a global common subexpression elimination pass. This pass also performs global constant and copy propagation. _Note:_ When compiling a program using computed gotos, a GCC extension, you may get better runtime performance if you disable the global common subexpression elmination pass by adding `-fno-gcse' to the command line. Has anyone [er, I'm thinking of Leo :-)] tried benchmarking computed goto without this flag? And with the various align functions, such as -falign-jumps ? Nicholas Clark
RE: Objects, finally (try 1)
Gopal V:
# But coming back to parrot ... I don't think parrot uses UTF8
# (from what I could gather it seems to be all ASCII ?) ... Or
# is UTF8 hiding in
# somewhere ?...
Parrot will have a default string type that's build-specific, so that
e.g. Asian nations can have whatever the most popular encoding is in
their country. The default default string type will be utf8, but it's
currently ASCII because Unicode Is Hard.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
Re: benchmarking - it's now all(-1,0,1,5,6)% faster
On Sat, Jan 11, 2003 at 07:05:22PM +, Nicholas Clark wrote: I was getting about 5% speedups on penfold against vanilla development perl. Penfold is an x86 box (actually a Citrix chip, which may be important) running Debian unstable, with gcc 3.2.1 and 256M of RAM. I tried the same tests on mirth, a ppc box, again Debian unstable, gcc 3.2.1, but 128M of RAM. This time I saw 1% slowdowns. FWIW, in the past I've noticed that x86 and PPC do react differently to optimizations. I've had cases where things ran at the same speed on PPC yet showed large differences on x86. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Re: Objects, finally (try 1)
At 7:27 PM +0530 1/12/03, Gopal V wrote: But coming back to parrot ... I don't think parrot uses UTF8 (from what I could gather it seems to be all ASCII ?) ... Or is UTF8 hiding in somewhere ?... Unicode is hiding in the ICU directory, which we need to get integrated. We'll probably be mostly UTF16, only because that's what ICU uses and there's no good reason to reinvent the wheel again. All three encodings and their endian variants will be supported, as will a variety of other encodings and character sets. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: optimising, and per file flags
At 3:45 PM + 1/12/03, Nicholas Clark wrote: Prior to this, on IRC Dan said to me that we need to avoid the hack that perl5 found itself in, when it had to retro-fit the ability to change the compiler flags per file. Right, I want to do it right to begin with, as we'll undoubtedly have to do it anyway. This is all compiler and platform dependent. Pulling out GCC as an example, -O3 is too much for one or two of perl 5's source modules, but only on certain platforms and certain GCC versions. I have no doubt that we'll trip some C compiler bugs somewhere as well, so we might as well plan for it now. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [CVS ci] constant PMCs
At 11:58 AM +0100 1/11/03, Leopold Toetsch wrote: As already mentioned in the DOD threads, this patch adds a new constant_pmc_pool and one additional interface function: PMC *constant_pmc_new_noinit(Interp*, INTVAL base_type) We should get the freeze/thaw stuff done, then, since creating constant PMCs from bytecode will involve unthawing from the bytecode file. On the todo list. (Which actually exists, and I'll post soon) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
The draft todo/worklist
Okay, this has been sitting around for a while, and it's time to dump it. This is reasonably high-level, and a bit terse, so I'm throwing it out for discussion/addition/fleshing out. Comments, please. (As if I have to ask... :) *) freeze/thaw for PMCs *) object, draft 2 *) Objects, implemented *) Fixed disassembler *) ICU building *) Unicode encoding *) One other non-latin encoding charset *) IMCC built into parrot *) Dynamic bytecode creation spec implementation *) Vtable splitup *) Exceptions *) No warnings on compilation *) long long and long double builds, even without perl 5 support *) Perl 6 built as part of core build and test *) Dynamic bytecode loading *) z-code interpreter *) JIT test with tinderbox tests *) Foreign bytecode loading *) Parrot IO fully defined and implemented *) Working make install *) Answer Leo's outstanding questions *) Finish perl 6 regex implementation *) Working perl 5 parser -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Objects, finally (try 1)
At 10:07 AM -0800 1/12/03, Brent Dax wrote: Gopal V: # But coming back to parrot ... I don't think parrot uses UTF8 # (from what I could gather it seems to be all ASCII ?) ... Or # is UTF8 hiding in # somewhere ?... Parrot will have a default string type that's build-specific, so that e.g. Asian nations can have whatever the most popular encoding is in their country. The default default string type will be utf8, but it's currently ASCII because Unicode Is Hard. Well... default may well be latin-1 or plain ASCII, because Unicode Is Unneccesary. :) Well, most of the time at least. Unicode, of course, will be available, but if the data coming in is ASCII or Latin-1, re-encoding's a bit of a waste of time. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: The draft todo/worklist
--- Dan Sugalski [EMAIL PROTECTED] wrote: *) ICU building *) Unicode encoding Do we really need unicode in parrot? Seems to me like it dosen't really accomplish much but making string operations much slower. People would still be able to use it even if strings aren't encoded with it. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
RE: The draft todo/worklist
Mr. Nobody:
# --- Dan Sugalski [EMAIL PROTECTED] wrote:
# *) ICU building
# *) Unicode encoding
#
# Do we really need unicode in parrot? Seems to me like it
# dosen't really accomplish much but making string operations
# much slower. People would still be able to use it even if
# strings aren't encoded with it.
I suspect you have English blinders over your eyes.
We need to support non-ASCII encodings to support people in other
countries. We need to support Unicode so that data can be converted
between all these encodings without a combinatorial explosion of
converters.
If we don't implement Unicode ourselves, every language that uses
Unicode (including Perl, with the :uN regex modifiers) will have to
implement it--separately, slowly and probably incompletely. This is
going to lead to bugs, incompatibility, holes in functionality and other
generally Bad Things.
Would you rather that Parrot implement Unicode once and make sure it's
right, or that a dozen languages all implement their own incompatible,
broken Unicode systems?
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
