At 2:52 PM +0100 1/17/04, Elizabeth Mattijsen wrote:
Don't know why you thgink it would be fetched 3 times, but as using
tied variables in Perl 5, a fetch is done _everytime_ the value of
the tied variable is needed.
You misunderstand. I'm talking about fetching the PMC for the
variable *out of
On Fri, Jan 16, 2004 at 09:27:57AM -0500, Dan Sugalski wrote:
With perl, for example, it's distinctly possible that this:
our $foo; # It's a global
$foo = 12;
if ($foo 10) {
print $foo;
}
will require fetching $foo's PMC out of the global namespace three
times, once for
At 09:27 -0500 1/16/04, Dan Sugalski wrote:
To some extent, yes. I just had a really nasty thought, and I think
the compiler writers need to get Official Rulings on behavior.
With perl, for example, it's distinctly possible that this:
our $foo; # It's a global
$foo = 12;
if ($foo 10) {
[EMAIL PROTECTED] (Dave Mitchell) writes:
The perl5 internals are a complete mess. It's like Jenga - to get the
perl5 tower taller and do something new you select a block somewhere in
the middle, with trepidation pull it out slowly, and then carefully
balance it somewhere new, hoping the whole
On Sat, Jan 17, 2004 at 04:58:25PM +, Simon Cozens wrote:
[EMAIL PROTECTED] (Dave Mitchell) writes:
The perl5 internals are a complete mess. It's like Jenga - to get the
perl5 tower taller and do something new you select a block somewhere in
the middle, with trepidation pull it out
Elizabeth Mattijsen [EMAIL PROTECTED] wrote:
If you're thinking about this, then maybe a better heuristic would be
to group globals into groups that are _only_ referenced within a
specific scope and fetch them on scope entry and store them on scope
exit. But then, anything like eval or the
On Thu, Jan 15, 2004 at 06:27:52PM -0500, Melvin Smith wrote:
At 06:13 PM 1/15/2004 -0500, Melvin Smith wrote:
At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
At 15:51 -0500 1/15/04, Melvin Smith wrote:
Comments questions welcome.
Why am I thinking of the register keyword in C?
At 9:30 AM +0100 1/16/04, Elizabeth Mattijsen wrote:
At 19:52 -0500 1/15/04, Melvin Smith wrote:
At 04:26 PM 1/15/2004 -0700, Luke Palmer wrote:
I can see some potential problems to solve with regards to some
languages where variables are dynamic and can be undefined,
such as Perl6, but the
[EMAIL PROTECTED] (Dan Sugalski) writes:
if ($foo 10) {
print $foo;
}
This is mainly because of the possibility of tied or
overridden namespaces, which would argue for a refetch on each use.
No, come on, Dan. It's far worse than that.
It'll be possible, from Perl-space to
Tim Bunce [EMAIL PROTECTED] wrote:
Aren't constant strings going to be saved in a way that lets the
address of the saved string be used to avoid string comparisons?
Constant strings get an entry in the constant_table. So for comparing 2
constant strings of the *same* code segment, strings
At 3:51 PM -0500 1/15/04, Melvin Smith wrote:
While sitting on IRC with Dan and Jonathan discussing how to
optimizer a certain construct with how we handle globals/package
variables, etc. I came to the conclusion that it would be valuable
to not have to fetch each and every global, lexical or
Simon Cozens [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
if ($foo 10) {
print $foo;
}
This is mainly because of the possibility of tied or
overridden namespaces, which would argue for a refetch on each use.
No, come on, Dan. It's far worse than that.
At 2:37 PM + 1/16/04, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
if ($foo 10) {
print $foo;
}
This is mainly because of the possibility of tied or
overridden namespaces, which would argue for a refetch on each use.
No, come on, Dan. It's far worse than that.
At 4:02 PM +0100 1/16/04, Leopold Toetsch wrote:
Honestly an overridden op could insert new rules in the code and
recompile everything. If we have to always check for such nasty things,
then we can forget all performance and optimizations.
That, at least, we don't have to worry about. None of the
While sitting on IRC with Dan and Jonathan discussing how to
optimizer a certain construct with how we handle globals/package
variables, etc. I came to the conclusion that it would be valuable
to not have to fetch each and every global, lexical or package
variable by name, individually, but
At 15:51 -0500 1/15/04, Melvin Smith wrote:
IMCC could analyze a module, decide if the optimization makes
sense, and place commonly used values (constants or
variables) in a pre-packaged register frame. (or more than 1)
This is done at compile / load time of course. If it were all
constants,
At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
At 15:51 -0500 1/15/04, Melvin Smith wrote:
IMCC could analyze a module, decide if the optimization makes
sense, and place commonly used values (constants or
variables) in a pre-packaged register frame. (or more than 1)
This is done at
At 18:13 -0500 1/15/04, Melvin Smith wrote:
At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
At 15:51 -0500 1/15/04, Melvin Smith wrote:
It might also be more useful to have it more granular than
16, maybe in 4s or 8s. By doing life analysis and some
weighting, IMCC might be able to turn
Melvin Smith writes:
At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
Why am I thinking of the register keyword in C?
I have no idea and I can't see the relationship. :)
With Parrot's architecture, we have overhead of storing and retrieving
globals, lexicals and package variables
At 06:13 PM 1/15/2004 -0500, Melvin Smith wrote:
At 10:02 PM 1/15/2004 +0100, Elizabeth Mattijsen wrote:
At 15:51 -0500 1/15/04, Melvin Smith wrote:
Comments questions welcome.
Why am I thinking of the register keyword in C?
I have no idea and I can't see the relationship. :)
I just realized my
At 04:26 PM 1/15/2004 -0700, Luke Palmer wrote:
Melvin Smith writes:
My email was concerned with storing/retrieving multiple variables
with a single lookup, not with hinting to the compiler.
Okay. Can you show an example of this optimization. I'd rather see it
in a HLL talking about PIR, as
21 matches
Mail list logo
