Understanding Object Structures
Hi All, On Jan 16, 2015, at 7:36 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Marcel,
On Jan 16, 2015, at 5:54 AM, Marcel Taeumel <marcel.taeumel@student.hpi.uni-potsdam.de> wrote:
Ah, okay. I was curious about the performance of iterating over an array vs. the linked list:
a := Array new: 1000. l := LinkedList new.
1000 timesRepeat: [l add: (StackLink with: nil)].
[a do: [:ea | 1 + 2]] bench. "'94,600 per second.'"
[l do: [:ea | 1 + 2]] bench. "'159,000 per second.'"
I expected the opposite! :-O Why is that so?
Look at the implementations of do:.
In the Array case we iterate over the indices using SmallIntegers (fast arithmetic with no allocation) and dereference each element using the Object>>at: primitive, which (apart from type and bounds checking) is simple indexed memory access. So one read per element.
In the LinkedList case each list element is fetched from the previous element and each value fetched from the element, so two reads per element.
This is interesting. (Marcel, Chris, forgive me; I'm presuming; please don't take this personally). Marcel above appears to lack an intuition about the structure of Array vs LinkedList. And in developing a hash algorithm for a 32-bit subset of Floats a few weeks ago Chris appeared to lack an I tuition about Floats being boxed, assuming they were value types, not containers. As a VM implementer I carry around a clear picture (literally, I am a visual thinker) of objects in my head. Those pictures are key to my approach to design and optimization. I presume that for someone approaching the system given only a textual description of object structures, through class comments and method source it is difficult to develop a good picture or mental model. For me, I read the blue book first, which is replete with pictures. I know that historically visual inspector frameworks such as Jun have been able to auto-generate pictorial representations of specific object graphs. I wonder how useful it would be to provide support for designers to include pictorial representations in class comments. Again I presume that the text model would have to support inclusion of simple bitmaps (to avoid having to include a full drawing framework in the system) and that the designer would construct a sample graph, generate a diagram using a visual inspector framework using eg Jun, render it to a bitmap and include it in the class comment. A more elaborate system could of course include the sample graph and render it dynamically, that would allow exploration. Either approach would make an interesting project, yes?
Best, Marcel
-- View this message in context: http://forum.world.st/The-Trunk-Collections-mt-593-mcz-tp4799750p4799893.htm... Sent from the Squeak - Dev mailing list archive at Nabble.com.
2015-01-16 16:55 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi All,
On Jan 16, 2015, at 7:36 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Marcel,
On Jan 16, 2015, at 5:54 AM, Marcel Taeumel < marcel.taeumel@student.hpi.uni-potsdam.de> wrote:
Ah, okay. I was curious about the performance of iterating over an array vs. the linked list:
a := Array new: 1000. l := LinkedList new.
1000 timesRepeat: [l add: (StackLink with: nil)].
[a do: [:ea | 1 + 2]] bench. "'94,600 per second.'"
[l do: [:ea | 1 + 2]] bench. "'159,000 per second.'"
I expected the opposite! :-O Why is that so?
Look at the implementations of do:.
In the Array case we iterate over the indices using SmallIntegers (fast arithmetic with no allocation) and dereference each element using the Object>>at: primitive, which (apart from type and bounds checking) is simple indexed memory access. So one read per element.
In the LinkedList case each list element is fetched from the previous element and each value fetched from the element, so two reads per element.
This is interesting. (Marcel, Chris, forgive me; I'm presuming; please don't take this personally). Marcel above appears to lack an intuition about the structure of Array vs LinkedList. And in developing a hash algorithm for a 32-bit subset of Floats a few weeks ago Chris appeared to lack an I tuition about Floats being boxed, assuming they were value types, not containers.
As a VM implementer I carry around a clear picture (literally, I am a visual thinker) of objects in my head. Those pictures are key to my approach to design and optimization.
I presume that for someone approaching the system given only a textual description of object structures, through class comments and method source it is difficult to develop a good picture or mental model. For me, I read the blue book first, which is replete with pictures.
I know that historically visual inspector frameworks such as Jun have been able to auto-generate pictorial representations of specific object graphs. I wonder how useful it would be to provide support for designers to include pictorial representations in class comments.
Again I presume that the text model would have to support inclusion of simple bitmaps (to avoid having to include a full drawing framework in the system) and that the designer would construct a sample graph, generate a diagram using a visual inspector framework using eg Jun, render it to a bitmap and include it in the class comment.
A more elaborate system could of course include the sample graph and render it dynamically, that would allow exploration.
Either approach would make an interesting project, yes?
I would prefer something conceptually simpler and worthwhile: the ability to embed a morph as a character in the text (would do the two approaches easily). And a bit of marshalling/text representation to make a completely textual representation possible. I used to have that for hypermedia (i.e. a drawing editor with text frame objects, and text frames able to display GUI components... in ParcPlace Smalltalk) Now I dream a bit of having something like TiddlyWiki in Pharo ;) Thierry
Hi Thierry, On Jan 16, 2015, at 8:10 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-01-16 16:55 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi All,
On Jan 16, 2015, at 7:36 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Marcel,
On Jan 16, 2015, at 5:54 AM, Marcel Taeumel <marcel.taeumel@student.hpi.uni-potsdam.de> wrote:
Ah, okay. I was curious about the performance of iterating over an array vs. the linked list:
a := Array new: 1000. l := LinkedList new.
1000 timesRepeat: [l add: (StackLink with: nil)].
[a do: [:ea | 1 + 2]] bench. "'94,600 per second.'"
[l do: [:ea | 1 + 2]] bench. "'159,000 per second.'"
I expected the opposite! :-O Why is that so?
Look at the implementations of do:.
In the Array case we iterate over the indices using SmallIntegers (fast arithmetic with no allocation) and dereference each element using the Object>>at: primitive, which (apart from type and bounds checking) is simple indexed memory access. So one read per element.
In the LinkedList case each list element is fetched from the previous element and each value fetched from the element, so two reads per element.
This is interesting. (Marcel, Chris, forgive me; I'm presuming; please don't take this personally). Marcel above appears to lack an intuition about the structure of Array vs LinkedList. And in developing a hash algorithm for a 32-bit subset of Floats a few weeks ago Chris appeared to lack an I tuition about Floats being boxed, assuming they were value types, not containers.
As a VM implementer I carry around a clear picture (literally, I am a visual thinker) of objects in my head. Those pictures are key to my approach to design and optimization.
I presume that for someone approaching the system given only a textual description of object structures, through class comments and method source it is difficult to develop a good picture or mental model. For me, I read the blue book first, which is replete with pictures.
I know that historically visual inspector frameworks such as Jun have been able to auto-generate pictorial representations of specific object graphs. I wonder how useful it would be to provide support for designers to include pictorial representations in class comments.
Again I presume that the text model would have to support inclusion of simple bitmaps (to avoid having to include a full drawing framework in the system) and that the designer would construct a sample graph, generate a diagram using a visual inspector framework using eg Jun, render it to a bitmap and include it in the class comment.
A more elaborate system could of course include the sample graph and render it dynamically, that would allow exploration.
Either approach would make an interesting project, yes?
I would prefer something conceptually simpler and worthwhile: the ability to embed a morph as a character in the text (would do the two approaches easily). And a bit of marshalling/text representation to make a completely textual representation possible.
Yes that's a *much* better idea and one we could realize v quickly.
I used to have that for hypermedia (i.e. a drawing editor with text frame objects, and text frames able to display GUI components... in ParcPlace Smalltalk)
Now I dream a bit of having something like TiddlyWiki in Pharo ;)
Thierry
I presume that for someone approaching the system given only a textual description of object structures, through class comments and method source it is difficult to develop a good picture or mental model. For me, I read the blue book first, which is replete with pictures.
I like to envision the physical model in my mind. I look at the class definitions to identify the object links (for pointer objects) and then the methods which modifies those vars. Once I have that picture of the physical model in my head, I then in my mind think about that shape model with each node "suited up" with its behaviors. Knowing their underlying links to other objects even helps me evaluate the consistency and nuance of the API).
I know that historically visual inspector frameworks such as Jun have been able to auto-generate pictorial representations of specific object graphs. I wonder how useful it would be to provide support for designers to include pictorial representations in class comments.
For years, I have been /totally/ interested in Alexandre's project, not just to represent in-memory models but large Magma models, visually. Roassal might struggle to perform with millions of nodes, I don't know, but I know Craig used Walrus to render a large model. Unfortunately I just haven't had the time to dig into these projects..
Again I presume that the text model would have to support inclusion of simple bitmaps (to avoid having to include a full drawing framework in the system) and that the designer would construct a sample graph, generate a diagram using a visual inspector framework using eg Jun, render it to a bitmap and include it in the class comment.
Squeak's Text model actually supports the inclusion of any Morph embedded as a single character. Maui uses that for its "documents" it actually works very well. Seeing animated, fully-functioning Morphs as characters in a document is kind'a cool.
A more elaborate system could of course include the sample graph and render it dynamically, that would allow exploration.
Either approach would make an interesting project, yes?
Best, Marcel
-- View this message in context: http://forum.world.st/The-Trunk-Collections-mt-593-mcz-tp4799750p4799893.htm... Sent from the Squeak - Dev mailing list archive at Nabble.com.
participants (3)
-
Chris Muller -
Eliot Miranda -
Thierry Goubier