From: nicolas cellier Have to revert to a <pragma> thing...
I'm not convinced. Pragmas are at best a kludge.
I liked the early gcc response to #pragma. The spec stated that a compiler could do whatever it wanted when it saw a #pragma, so gcc tried to run a variety of games and threw a segmentation fault if it failed to find any of them.
- Peter
I think that nicolas is talking about method pragmas as in VW and now in squeak 3.9.
Retrospectively I think that pragmas are really an excellent addition to VW with is bloated with the lot of less desirable features (class import level...)
Stef
On 23 févr. 06, at 22:17, Peter Crowther wrote:
From: nicolas cellier Have to revert to a <pragma> thing...
I'm not convinced. Pragmas are at best a kludge.
I liked the early gcc response to #pragma. The spec stated that a compiler could do whatever it wanted when it saw a #pragma, so gcc tried to run a variety of games and threw a segmentation fault if it failed to find any of them.
- Peter
I'm not convinced. Pragmas are at best a kludge.
I liked the early gcc response to #pragma. The spec stated that a compiler could do whatever it wanted when it saw a #pragma, so gcc tried to run a variety of games and threw a segmentation fault if it failed to find any of them.
The pragmas in 3.9 are not there to tweak the code generator. After parsing they are put into the compiled method, so that the system can query tagged methods. It has absolutely nothing to do with the #pragma, except that is shared its name.
The Smalltalk pragmas are a key element to write extensible software. Right now a lot of extension problems can only be solved trough the use of strange naming conventions, such as that test-methods in SUnit have to start with #test, or that meta-descriptions in Magritte have to start with #description, etc. Moreover there is no clean way to tell the system that a specific method is used as an event-handler, or that a method explicitly fails an SLint rule, or that it returns a string of a specific mime-type, etc. Pragmas are a slick solution to a permanent problem that cannot be easily solved otherwise.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
Lukas Renggli wrote:
The pragmas in 3.9 are not there to tweak the code generator. After parsing they are put into the compiled method, so that the system can query tagged methods. It has absolutely nothing to do with the #pragma, except that is shared its name.
Which is precisely the reason why I originally called them "annotations" instead of pragmas.
Cheers, - Andreas
I liked the early gcc response to #pragma. The spec stated that a compiler could do whatever it wanted when it saw a #pragma, so gcc tried to run a variety of games and threw a segmentation fault if it failed to find any of them.
- Peter
Yes, early, but then they added their own __attribute__...
Which is precisely the reason why I originally called them "annotations" instead of pragmas.
Cheers,
- Andreas
As everybody, I dislike pragmas for they are compiler dependent, not part of the language definition itself, and lead to portability problems (already upset by structure alignment in {} and its damn pragmas).
Inside squeak, portability is not a problem, you can change the compiler, and you can make this change a prereq when loading into another image.
Problems will raise when you want to move outside Squeak. But in this case, Squeakers will also get problems with the {a. b. c.} extension, Dolphiners with the ##() extension etc...
So, at inter-dialect level, pragmas, annotations or whatever syntax extension will lead to portability problem, because they are not standard. The difference between #annotations and #pragmas might not be so thick from a pragmatic point of view...
------------------------------------------------------------------------ The facts: Without byte code optimization, Smalltalk would not be efficient at all. Byte code optimization makes Smalltalk not as extensible as it should be. This problem exists in other Smalltalks.
The solutions: - Nobody likes the pragma. OK. - Lukas does not like blocks evaluated once and only once. OK. - Bryce and Peter suggested unoptimizing only #and/#or:, and that is the simpler solution by now. In a 3.8 image just :
MessageNode>>transformAnd: encoder ^false MessageNode>>transformOr: encoder ^false
Maybe the not optimized and: won't break performance noticeably... worth trying...
A work around to get both optimized and notoptimized code on a class basis is this one (mostly 3 classes and 4 messages): - declare compilerClass ^NotOptimizedAndOrCompiler as class method where you intend to use your fuzzy logic and: extension... - NotOptimizedAndOrCompiler will arrange to use NotOptimizedAndOrParser - NotOptimizedAndOrParser will use NotOptimizedAndOrMessageNode - NotOptimizedAndOrMessageNode will only redefine above transformAnd: transformOr: methods - maybe have to change a few more refs of MessageNode... (turning isMemberOf: into isKindOf: and other things like that)
The clean solution is to dynamically inline message sends so the simple unoptimised version of and: is as fast as the optimised version. A system with dynamicly inlined messages would be much faster for other things as well.
Bryce
Waouh. At the VM level ? That one is far above my skills... Isn't it the kind of optimization in VW VM ? My understanding of efficiency problem when not open-bytecoding #and: is the creation of BlockContext. Inlining send you gain creation of a MethodContext but not of a BlockContext. But if you also gain speed elsewhere, that's surely better...
Nicolas
Hi All,
I am not new to Smalltalk but I am very, very new to Squeak and know nothing about the compiler and its optimizations, so this suggestion may be way off base, but here goes, couldn't the optimized code for and: and or: be enhanced to test to see if the receiver is a boolean and if not pass the message on the receiver in the non optimized way? Hopefully this extra test would not reduced the optimization much.
Lou ----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
Louis LaBrunda wrote:
Hi All,
I am not new to Smalltalk but I am very, very new to Squeak and know nothing about the compiler and its optimizations, so this suggestion may be way off base, but here goes, couldn't the optimized code for and: and or: be enhanced to test to see if the receiver is a boolean and if not pass the message on the receiver in the non optimized way? Hopefully this extra test would not reduced the optimization much.
That does not work because in the optimized case, the block object which is the argument to the message does not really get created at all. Instead, there are bytecodes which conditionally jump around the code in the block. It would be possible (with some trickery) to extract those bytecodes from the offending method and create a normal block with the same functionality, but given the observation that most cases where and: or or: are sent to a non-Boolean in error, it's probably not worth the effort. Removing the optimization from the compiler if the argument is not a block is quite easy, though. Currently, the boolean messages accept either a block or a variable as their argument, but not arbitrary expressions, which seems rather illogical to me. You can change the method in MessageNode which does this to read: checkBlock: node as: nodeName from: encoder
^(node isKindOf: BlockNode) ifTrue: [(node numberOfArguments > 0) ifTrue: [encoder notify: '<- ', nodeName , ' of ' , (MacroSelectors at: special) , ' must be a 0-argument block'] ifFalse: [true]] ifFalse: [false]
Then the optimization only happens if the argument is a 0-argument block.
Cheers, Hans-Martin
nicolas cellier writes:
The clean solution is to dynamically inline message sends so the simple unoptimised version of and: is as fast as the optimised version. A system with dynamicly inlined messages would be much faster for other things as well.
Bryce
Waouh. At the VM level ? That one is far above my skills... Isn't it the kind of optimization in VW VM ? My understanding of efficiency problem when not open-bytecoding #and: is the creation of BlockContext. Inlining send you gain creation of a MethodContext but not of a BlockContext. But if you also gain speed elsewhere, that's surely better...
Yes, sure at the VM level, though I believe that it's better to write such a compiler in Smalltalk rather than in Slang, C, or C++. I wasn't suggesting you do that kind of optimisation. Mearly suggesting that it's better done elsewhere.
Such optimisations are not in the VW VM though it does optimise contexts by using a context cache stack. I've been planning to use full method inlining to allow Exupery (a native code compiler for Squeak) to compete with VW for send performance.
Once you've inlined the and: method you'll end up with something like:
(firstBoolean ifTrue: [[secondBoolean] value] ifFalse: [false] ifOther: [firstBoolean and: [secondBoolean]])
At which point converting "[secondBoolean] value" to "secondBoolean is a very simple optimisation.
The ifTrue:ifFalse:ifOther is the same type test that needs to be used for any inlined methods. Making sure that the inlining creates intermediate that's easy to optimise will be critical, but that's a detail problem rather than a fundamental problem.
If you can make it to either Brussels or StS, you could hear a talk about what Exupery does now and what it's designed to eventually do.
Bryce
On 24.02.2006, at 22:42, Bryce Kampjes wrote:
Yes, sure at the VM level, though I believe that it's better to write such a compiler in Smalltalk rather than in Slang, C, or C++. I wasn't suggesting you do that kind of optimisation. Mearly suggesting that it's better done elsewhere.
Such optimisations are not in the VW VM though it does optimise contexts by using a context cache stack. I've been planning to use full method inlining to allow Exupery (a native code compiler for Squeak) to compete with VW for send performance.
There is a nice talk by Eliot Miranda about a system (where the dynamic optimization is done bytecode-to-bytecode in Smalltalk, leveraging the existing JIT as the backend for code generation):
Bytecode-to-bytecode adaptive optimization for Smalltalk http://video.google.com/videoplay?docid=-8988857822906068209
Marcus
andreas may be VW people got first the wrong name, but using a consistent one is better I think.
Stef
On 23 févr. 06, at 22:58, Andreas Raab wrote:
Lukas Renggli wrote:
The pragmas in 3.9 are not there to tweak the code generator. After parsing they are put into the compiled method, so that the system can query tagged methods. It has absolutely nothing to do with the #pragma, except that is shared its name.
Which is precisely the reason why I originally called them "annotations" instead of pragmas.
Cheers,
- Andreas
<meta> Not that I personally care that much about this particular name but you are touching a sore point here. That point is that in too many situations I have seen people copying really screwed up stuff from VW[*] and other systems just because they can't change it there and don't want to work around the differences. What happens then is that you are actively making Squeak worse by repeating a bad decision (even worse: you are repeating it although you have the benefit of hindsight) where instead you should be fixing the mistake and help make Squeak a better system.
And yes, I understand that this is inconvenient if you care about compatibility but slavishly repeating everything VW does will only get you a VW clone, not a better system. </meta>
[*] My pet peeve these days: Proliferation of standard protocols for the "sake" of compatibility with X, Y, or Z. Just look at the evolution of the Collection protocols over the last 4-5 Squeak versions to see what I mean. I mean, if people need compatibility, why not make a compatibility *package*? Like, in this, a subclass of the real thing that's named Pragma and can be used if you need "compatible" pragmas.
Cheers, - Andreas
stéphane ducasse wrote:
andreas may be VW people got first the wrong name, but using a consistent one is better I think.
Stef
On 23 févr. 06, at 22:58, Andreas Raab wrote:
Lukas Renggli wrote:
The pragmas in 3.9 are not there to tweak the code generator. After parsing they are put into the compiled method, so that the system can query tagged methods. It has absolutely nothing to do with the #pragma, except that is shared its name.
Which is precisely the reason why I originally called them "annotations" instead of pragmas.
Cheers,
- Andreas
<pragmatic and not ranting> I guess that we are not slavishly reproducing VW. And lukas and marcus did a really good to get annotation or pragmas in Squeak. Just helping Squeak and VW to communicate more. Because when you will be happily be able to use their crypto package then we would all have win something. And easing the port of good abstractions (Pier, Seaside) between the dialect is important for everybody. <\pragmatic and not ranting>
<meta> Not that I personally care that much about this particular name but you are touching a sore point here. That point is that in too many situations I have seen people copying really screwed up stuff from VW[*] and other systems just because they can't change it there and don't want to work around the differences. What happens then is that you are actively making Squeak worse by repeating a bad decision (even worse: you are repeating it although you have the benefit of hindsight) where instead you should be fixing the mistake and help make Squeak a better system.
And yes, I understand that this is inconvenient if you care about compatibility but slavishly repeating everything VW does will only get you a VW clone, not a better system.
</meta>
[*] My pet peeve these days: Proliferation of standard protocols for the "sake" of compatibility with X, Y, or Z. Just look at the evolution of the Collection protocols over the last 4-5 Squeak versions to see what I mean. I mean, if people need compatibility, why not make a compatibility *package*? Like, in this, a subclass of the real thing that's named Pragma and can be used if you need "compatible" pragmas.
Cheers,
- Andreas
stéphane ducasse wrote:
andreas may be VW people got first the wrong name, but using a consistent one is better I think. Stef On 23 févr. 06, at 22:58, Andreas Raab wrote:
Lukas Renggli wrote:
The pragmas in 3.9 are not there to tweak the code generator. After parsing they are put into the compiled method, so that the system can query tagged methods. It has absolutely nothing to do with the #pragma, except that is shared its name.
Which is precisely the reason why I originally called them "annotations" instead of pragmas.
Cheers,
- Andreas
Andreas, did you have a look at the implementation? It is not an 1:1, it just supports the same protocol.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
Yup, I sure did. Mostly because I was concerned about the IP aspects. But keep in mind that my rant was a meta rant and (in this case) pointed at using the name Pragma where one only has to look at http://www.google.com/search?q=define:+pragma to see that pragma describes not what these annotations are being used for and that therefore the "consistency" argument is really a "compatibility" argument, e.g., VW uses that bad name so we have to use the same bad name. And there is really no point in that unless you want to write a VW clone.
Cheers, - Andreas
Lukas Renggli wrote:
Andreas, did you have a look at the implementation? It is not an 1:1, it just supports the same protocol.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
Yup, I sure did. Mostly because I was concerned about the IP aspects. But keep in mind that my rant was a meta rant and (in this case) pointed at using the name Pragma where one only has to look at http://www.google.com/search?q=define:+pragma to see that pragma describes not what these annotations are being used for and that therefore the "consistency" argument is really a "compatibility" argument, e.g., VW uses that bad name so we have to use the same bad name. And there is really no point in that unless you want to write a VW clone.
Ok.
No I don't want a VW clone (e.g., we are doing fine without namespaces), but I want my Seaside, Magritte, Pier, etc. to be easily portable to VW.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
Lukas Renggli wrote:
No I don't want a VW clone (e.g., we are doing fine without namespaces), but I want my Seaside, Magritte, Pier, etc. to be easily portable to VW.
Yes, and that's exactly what I said in my meta rant: "people copying really screwed up stuff ... just because they can't change it there and don't want to work around the differences". In other words, you confirm my meta rant ;-)
Cheers, - Andreas
Yes, and that's exactly what I said in my meta rant: "people copying really screwed up stuff ... just because they can't change it there and don't want to work around the differences". In other words, you confirm my meta rant ;-)
If the name is the only thing you worry about, we can easily rename it to something else and then put an empty subclass called Pragma into a compatibility package. As long as the name is the only trouble causer I see no troubles ;-)
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
Lukas Renggli wrote:
Yes, and that's exactly what I said in my meta rant: "people copying really screwed up stuff ... just because they can't change it there and don't want to work around the differences". In other words, you confirm my meta rant ;-)
If the name is the only thing you worry about, we can easily rename it to something else and then put an empty subclass called Pragma into a compatibility package. As long as the name is the only trouble causer I see no troubles ;-)
And I wrote: "Not that I personally care that much about this particular name ..." and I meant it. After all this was a *meta* rant (that's what these tags are good for).
Cheers, - Andreas
On Feb 24, 2006, at 9:10 AM, stéphane ducasse wrote:
andreas may be VW people got first the wrong name, but using a consistent one is better I think.
Being consistent with the thinking and naming conventions of some Java folks, who might want to drop in, wouldn't hurt either. Especially as they might have a bigger problem to change their "bindings" than the VW-folks... ;-)
And to me "annotations" seems to be a much more telling word than "pragma" (though "attribute" from C# seems to be the more polymorph...)
See also http://en.wikipedia.org/wiki/Annotation "Differences in computer languages have given rise to a variety of words for programmer-added metadata, including annotation (Java), attribute (C#), pragma (C), and metadata (HTML)."
Cheers,
Markus
Stef
On 23 févr. 06, at 22:58, Andreas Raab wrote:
Lukas Renggli wrote:
The pragmas in 3.9 are not there to tweak the code generator. After parsing they are put into the compiled method, so that the system can query tagged methods. It has absolutely nothing to do with the #pragma, except that is shared its name.
Which is precisely the reason why I originally called them "annotations" instead of pragmas.
Cheers,
- Andreas
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bryce Kampjes -
Hans-Martin Mosner -
Louis LaBrunda -
Lukas Renggli -
Marcus Denker -
Markus Gaelli -
nicolas cellier -
Peter Crowther -
stéphane ducasse