In perl.perl6.internals, you wrote:
> --- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> * SLOW (same slow with register or odd aligned)
>> * 0x818118a :sub0x8164cac,%ebx
>> * 0x8181190 :jne0x818118a
> The slow one has the loop crossing over a 16 byte boundary. Try moving it
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 JIT
[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
:o
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 w
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 o
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" h
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
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 popu
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 te
Luke Palmer writes:
> I don't think so. Rather, that becomes:
>
> him.hit(I);
>
> And to clarify, you should probably format it like this:
>
> hit him: I;
>
> But computer languages aren't generally used to specify past tense
> anyway
>
why priperties are sort of ... becau
Luke Palmer wrote:
> I would imagine that would only work if $a was known at compile time:
I think we could do it at runtime too. You could conceivably use
runtime resolution to, for example, choose from between several
different caching behaviors to be passed to a complex routine:
sub get_c
Damian Conway wrote:
sub debug is immediate is exported (@message) {
return $debugging ?? { print $*STDERR: @message; } :: {;}
}
Won't @message need lazy evaluation? How will Perl know to
delay interpolation until the result of the "macro" is called
at run time?
- Ken
Ken Fox wrote:
Won't @message need lazy evaluation? How will Perl know to
delay interpolation until the result of the "macro" is called
at run time?
Good point. It would also need to be slurped.
So that's:
sub debug is immediate is exported (*@message is lazy) {
return $debuggi
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 U
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
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
consta
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
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. Asia
--- 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.
__
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
20 matches
Mail list logo
