RE: finalization
You still need to malloc() your memory; however I realize that the allocator can be *really* fast here. But still, you give a lot of the gain back during the mark-and-sweep phase, especially if you also move/compact the memory. As you said, the allocator can be really fast. Most advanced gc will use thread local heap to allocate temp objects, so we don't even have to sync or membar. The mark-and-sweep is ok for small heap, 1MB. For large heap, we can use concurrent gc, multi-threaded gc, multi-heap. Normally large heap implies SMP, so we have some cpu power to steal to do expensive gc. The big gain only comes in when your program is small/quick enough to actually finish before the GC kicks in the first time (think CGI). In that case you just discard the whole heap instead of doing a proper garbage collection (unless of course someone thought they could still do something inside a finalizer during global destruction and you still need to finalize every other object on your heap :). As I said, the finalization should be discouraged. It is application's problem if it uses extensive finalization, just like an application uses bubble sort instead of qsort, there is not much we can do here. That is one of mistakes of Java. Java promises too much. To do so, Java carries significant overhead to fullfill its promise. For example, Java has 6+ different types of weak reference, including finalization reference. There are very few people in the world can understand the difference. What is the point to have them just for those smart but few people. Don't even dream of accessing Perl scalars simultaneously from multiple threads without some kind of locking. That is the problem of Perl. In Smalltalk, every primitive object is immutable -- Integer, Float, Fraction, Symbol. The String, Array, ByteArray have fixed size. So there is no need for any synchronization. If you want to mess up your Array using MT, just do it. In the end, you will get a messy array, but you can not hurt the system/runtime in anyway. You want a modifiable buffer? Get a StringBuilder object and lock it on every access. That is one of stupid design of Java. If I need sync, I can do it myself. Why StrinBuffer, Vector, Hashtable, XXXStream sync on every access? Stupid. If I want to have a multi-read data structure, I have to write my own. What is the point??? Hong
RE: Expunge implicit @_ passing
Brent Dax wrote: On the other hand, it could stop some of the really stupid uses for inheritance I've seen. The dumbest one was in high school Advanced Placement's C++ classes--the queue and stack classes inherited from the array class! Oh? How could final classes prevent such a travesty? Are you seriously suggesting that the Array class should be designed such that it cannot be inherited? -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: finalization
On Tue, 28 Aug 2001, Sam Tregar wrote: Well, there's the Perl 5 reference counting solution. In normal cases DESTROY is called as soon as it can be. Of course we're all anxious to get into the leaky GC boat with Java and C# because we've heard it's faster. I wonder how fast it is when it's halfway under water and out of file descriptors. GC has nothing to do with finalization. Many people want it to, and seem to conflate the two, but they're separate. Dead object detection and cleanup doesn't have to be tied to memory GC. It won't be in perl 6. The perl 6 engine will guarantee whatever cleanup/finalization order and timliness that Larry puts into the language definition. That's not a problem. FWIW, going from a manual memory management scheme to a GC scheme is generally a good-sized performance win. Talk to the GCC people if you don't believe that. Dan
notes from a stroustrup talk
This arrived as part of a mailing list that I suppose I opted into at some point: == More ++, Less C Standard template libraries, abstract classes and multiparadigm programming are keys to high-performance == Too much C++ code is just C. For example, people do class hierarchies in a very naive way. They think of a few implementation details that are common and they throw them into a base class. I have been preaching about this for nearly 15 years, and nobody listens. It's so much easier to make your own mistakes than to listen, lectured Bjarne Stroustrup, creator of the C++ language in his Tuesday, August 28, 2001 keynote at the Software Development East conference in Boston. Now head of ATT's Large-Scale Programming Research Department in Florham Park, New Jersey, Stroustrup continues his focus on efficient algorithms and high performance. The solution to the problem of overloaded base classes, said Stroustrup, is to write interfaces that are totally abstract. Writing code like this is a bit tedious because of the repetition, but if you have a concept, make it a class. This is one way to handle common state. Beginning his talk with a graph depicting the performance of linear algebra calculations programmed in C++ and Fortran, Stroustrup pointed out that, while beating Fortran at what it does best is difficult, it can be done. These are my semi-arm-waving comments on efficiency. Efficiency matters--not everywhere, but in embedded systems and performance numerics, which are areas that interest me, it does. What is slowing down C++ coders everywhere? First, too much reinvention of the wheel, he said. If you think you can build a matrix library, go ahead, but there are many already available. He also lambasted Smalltalk-style hierarchies and showed several code snippets explaining how to better manage resources. Say you acquire a resource and then you close it out at the end. What if you never get to the end? he asked rhetorically. OK, so you open a try block, catch the exception... But there is something fundamentally wrong with this solution. Your code has roughly doubled in size. You're better off creating a class with a destructor. Object-oriented programming, Stroustrup went on to say, is really just one of several paradigms C++ users have at their disposal. Multiparadigm programs that use OO, generic programming and data abstraction are powerful ways to achieve fast performance and power. If you were designing C++ today, would you do anything differently? an audience member asked. Undoubtedly, responded Stroustrup. Language design is a response to a set of problems you are facing at a point in time. I would want to support direct representation. I would not, however, build a high-level language and sacrifice efficiency. A lot of times, that question really is, 'Did you really mean to design something like Java but you couldn't?' and the answer is no. In terms of performance, C++ and Java don't mesh. I could make a similar statement about C#, but I won't. You also have to remember that I don't like proprietary languages. So how will C++ evolve over the next 10 years? Templated type definitions should be there, Stroustrup predicted. The main effort should be in standardizing some of the libraries. It's not going to be easy, but I see it as a language that maintains its emphasis on run-time efficiency. The area I'm most interested in is distributed computing. I don't see any real likelihood of changes in C++ for supporting Web development; that belongs in the area of libraries. Whether any such libraries can be standardized is a big question, though. I have my doubts. --Alexandra Weber Morales -- David Nicol 816.235.1187 A government of the p8a, by the p8a, and for the p8a.
Re: Expunge implicit @_ passing
Michael G Schwern wrote:
If you *really* wanted to write an optimized redirector, you'd
have the redirector eliminate itself.
sub foo {
my $method = $_[0]-{_foo} || $_[0]-can(_foo);
{
no warnings 'redefine';
*foo = $method;
}
goto $method;
}
:)
It's nice to see that someone looked at the import method in
Pollute::Persistent
At some point I came up with a list of Ways Life Would Improve
If Perl Had Tail-Recursion, or something like that. It largely
hinged on being able to access the calling context more aggressively
than returning a value back into it, was a side-effect of something
else, or required something else which had other beneficial effects.
Sorry about the vagueness
--
David Nicol 816.235.1187
A government of the p8a, by the p8a, and for the p8a.
Come and get me, Schwern
Michael G Schwern wrote: The idea that a class is either 'perfect' or 'complete' has to be the silliest, most arrogant thing I've ever heard! So, subsequent refinements have to use a has-a instead of an is-a relation in re: objects of the final class. Maybe the inclusion of this feature could lets certain nervous implementors get to sleep without worrying about getting blamed for things their objects did after they were out of their control. Java is, after all, all about giving guarantees of authenticity and whatnot. Bill J. Programmer publishes a class foo that is guaranteed to correctly blarg the frobniz, someone subclasses it and breaks the blarg function, that simply will not do! With a final it is no longer possible for the new class to identify itself as a foo. -- David Nicol 816.235.1187 A government of the p8a, by the p8a, and for the p8a.
Re: CLOS multiple dispatch
I sure miss multi-dispatch. http://dev.perl.org/rfc/256.html Damian
Re: CLOS multiple dispatch
Schwern explained:
# Following RFC 256
sub name (Foo $self) : multi {
return $self-{name};
}
sub name (Foo $self, STRING $name) : multi {
$self-{name} = $name;
return $self-{name};
}
which is quite a bit simpler.
...and more efficient (since the selection is done in the core dispatcher,
not in the subroutine itself).
However, there is much more to multiple dispatch than this (technically,
Schwern's example is just subroutine overloading).
For example, here is an event handler for a GUI:
sub handle (Window $w, Event $e) : multi {
log(Unknown event $($e-desc) called on window $($w-name));
}
sub handle (Window $w, CloseEvent $e) : multi {
$w-close;
}
sub handle (ImportantWindow $w, CloseEvent $e) : multi {
$w-close if yesno_dialog(Really close this window???);
}
sub handle (Window $w, MoveEvent $e) : multi {
$w-moveto($e-newpos);
}
sub handle (FixedWindow $w, MoveEvent $e) : multi {
beep();
}
Note that the handler that is selected depends on the *combination* of
the types of the two arguments. And that the dispatcher understands
the argument/parameter inheritance relationships and selects the most
specific handler for each combination. For example, a MoveEvent sent to
a FixedWindow causes a beep, but a MoveEvent sent to any other type of
window is dispatched to the more-generic handle(Window $w, MoveEvent $e)
subroutine, which causes it to move.
Damian
