diff --git a/app/views/layouts/application.html.haml b/app/views/layouts/application.html.haml index d497b2b..16b6357 100644 --- a/app/views/layouts/application.html.haml +++ b/app/views/layouts/application.html.haml @@ -16,9 +16,9 @@ %ul.nav %li= link_to "Home" , root_path %li= link_to "Architecture", "/rubyx/layers.html" - %li= link_to "Soml (obsolete)" , "/soml/typed.html" %li= link_to "Arm Resources" , "/arm/overview.html" %li= link_to "About" , "/project/motivation.html" + %li= link_to "Misc" , "/misc/index.html" %li= link_to "News" , blog_index_path =link_to "https://github.com/ruby-x" do =image_tag "x-small.png", style: "position: absolute; top: 15px; right: 15px; border: 0; width: 70px" diff --git a/app/views/pages/misc/_menu.html.haml b/app/views/pages/misc/_menu.html.haml new file mode 100644 index 0000000..45457fc --- /dev/null +++ b/app/views/pages/misc/_menu.html.haml @@ -0,0 +1,5 @@ +.row + %ul.nav + %li= link_to "Threads (rumble)" , "threads.html" + %li= link_to "Optimisation (ideas)" , "optimisations.html" + %li= link_to "SOML (old)", "soml.html" diff --git a/app/views/pages/soml/bench.numbers b/app/views/pages/misc/bench.numbers similarity index 100% rename from app/views/pages/soml/bench.numbers rename to app/views/pages/misc/bench.numbers diff --git a/app/views/pages/misc/index.html.haml b/app/views/pages/misc/index.html.haml new file mode 100644 index 0000000..2b56a89 --- /dev/null +++ b/app/views/pages/misc/index.html.haml @@ -0,0 +1,12 @@ += render "pages/misc/menu" + +%h1= title "Ideas, old and new" + +An idea is where everything starts. Like this project. But not every idea +makes it to reality, and some that do do not turn out as planned. + +This is a collection of both, the overripe and unripe. Maybe we can learn from the +first, and by continuously reexamining the second see if it is worth the +effort to bring them down to earth. + +%h2 Unrealized diff --git a/app/views/pages/misc/optimisations.html.haml b/app/views/pages/misc/optimisations.html.haml new file mode 100644 index 0000000..b21fff6 --- /dev/null +++ b/app/views/pages/misc/optimisations.html.haml @@ -0,0 +1,33 @@ += render "pages/misc/menu" + +%h1=title "Optimisation ideas" + +%p I won’t manage to implement all of these idea in the beginning, so i just jot them down. + +%h3 Inlining +%p + Ok, this may not need too much explanation. Just work. It may be interesting to experiment how much this saves, and how much + inlining is useful. I could imagine at some point it’s the register shuffling that determines the effort, not the + actual call. +%p Again the key is the update notifications when some of the inlined functions have changed. +%p + And it is important to code the functions so that they have a single exit point, otherwise it gets messy. Up to now this + was quite simple, but then blocks and exceptions are undone. + +%h3 Register negotiation +%p + This is a little less baked, but it comes from the same idea as inlining. As calling functions is a lot of register + shuffling, we could try to avoid some of that. +%p More precisely, usually calling conventions have registers in which arguments are passed. And to call an “unknown”, ie any function, some kind of convention is neccessary. +%p + But on “cached” functions, where the function is know, it is possible to do something else. And since we have the source + of the function around, we can do things previously impossible. +%p One such thing may be to recompile the function to accept arguments exactly where they are in the calling function. Well, now that it’s written down. it does sound a lot like inlining, except without the inlining:-) +%p + An expansion if this idea would be to have a Negotiator on every function call. Meaning that the calling function would not + do any shuffling, but instead call a Negotiator, and the Negotiator does the shuffling and calling of the function. + This only really makes sense if the register shuffling information is encoded in the Negotiator object (and does not have + to be passed). +%p + Negotiators could do some counting and do the recompiling when it seems worth it. The Negotiator would remove itself from + the chain and connect called and new receiver directly. How much is in this i couldn’t say though. diff --git a/app/views/pages/soml/syntax.html.haml b/app/views/pages/misc/soml.html.haml similarity index 87% rename from app/views/pages/soml/syntax.html.haml rename to app/views/pages/misc/soml.html.haml index 41ea81b..cf7d849 100644 --- a/app/views/pages/soml/syntax.html.haml +++ b/app/views/pages/misc/soml.html.haml @@ -1,7 +1,27 @@ -= render "pages/soml/menu" += render "pages/misc/menu" %h1= title "Soml Syntax" +Soml was a step on the way. While i was still thinking about VM's and c++ , +the year was 2015. +%br +I had thought that some kind of typed layer was needed, and that one could +implement the higher level in a language. A typed language, sort of like c++, +that would be used to implement the code of ruby. +%br +A little like PyPy has a core that only uses a small set of python, that can, +a la crystal, be fully type inferred. +%br +This idea turned out to be wrong, or difficult. Because the bridge between the +typed an untyped was unclear or i didn't get it to work. The current system +works by typing self, but not it's instances. A difficult mix to express in a +language. +%br +This led me to abandon soml and rewrite the functionality as vool and mom layers. +But Soml was working, the parser is still about and there are some interesting +=link_to "benchmarks" , "soml_benchmarks.html" +that came from it and really validated the calling convention. + %h2 Top level Class and methods %p The top level declarations in a file may only be class definitions %pre diff --git a/app/views/pages/soml/benchmarks.html.haml b/app/views/pages/misc/soml_benchmarks.html.haml similarity index 95% rename from app/views/pages/soml/benchmarks.html.haml rename to app/views/pages/misc/soml_benchmarks.html.haml index 7b7f0a4..22d8395 100644 --- a/app/views/pages/soml/benchmarks.html.haml +++ b/app/views/pages/misc/soml_benchmarks.html.haml @@ -1,7 +1,11 @@ -= render "pages/soml/menu" += render "pages/misc/menu" + +Disclaimer: read the intro of +=link_to "Soml" , "soml.html" +first. This is obsolete, and has only historic value. + %h1= title "Simple soml performance numbers" - %p These benchmarks were made to establish places for optimizations. This early on it is clear that performance is not outstanding, but still there were some surprises. diff --git a/app/views/pages/rubyx/threads.html.haml b/app/views/pages/misc/threads.html.haml similarity index 99% rename from app/views/pages/rubyx/threads.html.haml rename to app/views/pages/misc/threads.html.haml index 1f4e7cd..83f1ba1 100644 --- a/app/views/pages/rubyx/threads.html.haml +++ b/app/views/pages/misc/threads.html.haml @@ -1,4 +1,4 @@ -= render "pages/rubyx/menu" += render "pages/misc/menu" %h1= title "Threads are broken" diff --git a/app/views/pages/soml/typed.html.haml b/app/views/pages/misc/typed.html.haml similarity index 99% rename from app/views/pages/soml/typed.html.haml rename to app/views/pages/misc/typed.html.haml index 22274bd..08d53a0 100644 --- a/app/views/pages/soml/typed.html.haml +++ b/app/views/pages/misc/typed.html.haml @@ -1,4 +1,4 @@ -= render "pages/soml/menu" += render "pages/misc/menu" %h1= title "Typed intermediate representation" diff --git a/app/views/pages/rubyx/_menu.haml b/app/views/pages/rubyx/_menu.haml index a8ec0d1..acc4a63 100644 --- a/app/views/pages/rubyx/_menu.haml +++ b/app/views/pages/rubyx/_menu.haml @@ -4,5 +4,3 @@ %li= link_to "Parfait", "parfait.html" %li= link_to "Debugger", "debugger.html" %li= link_to "Memory" , "memory.html" - %li= link_to "Threads" , "threads.html" - %li= link_to "Optimisation ideas" , "optimisations.html" diff --git a/app/views/pages/rubyx/optimisations.html.haml b/app/views/pages/rubyx/optimisations.html.haml deleted file mode 100644 index 8e38bab..0000000 --- a/app/views/pages/rubyx/optimisations.html.haml +++ /dev/null @@ -1,75 +0,0 @@ -= render "pages/rubyx/menu" - -%h1=title "Optimisation ideas" - -%p I won’t manage to implement all of these idea in the beginning, so i just jot them down. -%h3#avoid-dynamic-lookup Avoid dynamic lookup -%p This off course is a broad topic, which may be seen under the topic of caching. Slightly wrongly though in my view, as avoiding them is really the aim. Especially for variables. -%h4#i---instance-variables I - Instance Variables -%p Ruby has dynamic instance variables, meaning you can add a new one at any time. This is as it should be. -%p - But this can easily lead to a dictionary/hash type of implementation. As variable “lookup” is probably - %em the - most - common thing an OO system does, that leads to bad performance (unneccessarily). -%p - So instead we keep variables layed out c++ style, continous, array style, at the address of the object. Then we have - to manage that in a dynamic manner. This (as i mentioned - = succeed ")" do - %a{:href => "memory.html"} here -%p - When a new variable is added, we create a - %em new - Type and change the Type of the object. We can do this as the Type will - determine the Class of the object, which stays the same. The memory page mentions how this works with constant sized objects. -%p So, Problem one fixed: instance variable access at O(1) -%h4#ii---method-lookup II - Method lookup -%p Off course that helps with Method access. All Methods are at the end variables on some (class) object. But as we can’t very well have the same (continuous) index for a given method name on all classes, it has to be looked up. Or does it? -%p - Well, yes it does, but maybe not more than once: We can conceivably store the result, except off course not in a dynamic - structure as that would defeat the purpose. -%p - In fact there could be several caching strategies, possibly for different use cases, possibly determined by actual run-time - measurements, but for now I just destribe a simeple one using Data-Blocks, Plocks. -%p - So at a call-site, we know the name of the function we want to call, and the object we want to call it on, and so have to - find the actual function object, and by that the actual call address. In abstract terms we want to create a switch with - 3 cases and a default. -%p - So the code is something like, if first cache hit, call first cache , .. times three and if not do the dynamic lookup. - The Plock can store those cache hits inside the code. So then we “just” need to get the cache loaded. -%p Initializing the cached values is by normal lazy initialization. Ie we check for nil and if so we do the dynamic lookup, and store the result. -%p - Remember, we cache Type against function address. Since Types never change, we’re done. We could (as hinted above) - do things with counters or robins, but that is for later. -%p - Alas: While Types are constant, darn the ruby, method implementations can actually change! And while it is tempting to - just create a new Type for that too, that would mean going through existing objects and changing the Type, nischt gut. - So we need change notifications, so when we cache, we must register a change listener and update the generated function, - or at least nullify it. -%h3#inlining Inlining -%p - Ok, this may not need too much explanation. Just work. It may be intersting to experiment how much this saves, and how much - inlining is useful. I could imagine at some point it’s the register shuffling that determines the effort, not the - actual call. -%p Again the key is the update notifications when some of the inlined functions have changed. -%p - And it is important to code the functions so that they have a single exit point, otherwise it gets messy. Up to now this - was quite simple, but then blocks and exceptions are undone. -%h3#register-negotiation Register negotiation -%p - This is a little less baked, but it comes from the same idea as inlining. As calling functions is a lot of register - shuffling, we could try to avoid some of that. -%p More precisely, usually calling conventions have registers in which arguments are passed. And to call an “unknown”, ie any function, some kind of convention is neccessary. -%p - But on “cached” functions, where the function is know, it is possible to do something else. And since we have the source - (ast) of the function around, we can do things previouly imposible. -%p One such thing may be to recompile the function to acccept arguments exactly where they are in the calling function. Well, now that it’s written down. it does sound a lot like inlining, except without the inlining:-) -%p - An expansion if this idea would be to have a Negotiator on every function call. Meaning that the calling function would not - do any shuffling, but instead call a Negotiator, and the Negotiator does the shuffling and calling of the function. - This only really makes sense if the register shuffling information is encoded in the Negotiator object (and does not have - to be passed). -%p - Negotiators could do some counting and do the recompiling when it seems worth it. The Negotiator would remove itself from - the chain and connect called and new receiver directly. How much is in this i couldn’t say though. diff --git a/app/views/pages/soml/_menu.html.haml b/app/views/pages/soml/_menu.html.haml deleted file mode 100644 index 967d42b..0000000 --- a/app/views/pages/soml/_menu.html.haml +++ /dev/null @@ -1,8 +0,0 @@ -.row - %ul.nav - %li - %a{:href => "typed.html"} Typed - %li - %a{:href => "benchmarks.html"} Performance - %li - %a{:href => "syntax.html"} Syntax (obsolete)