Well, 27% is the overall advantage when running the co-expression
activations within the context of the language interpreter. If you believe
my other number where Unicon's interpreter is 43% faster, then the actual
advantage of the stackless coswitch is probably at least twice the 27% or
even more. Since Objecticon had 43% deficit to overcome. It is a good
advantage, but not as much superior as one would think. And of course, for
a lot of co-expressions that do actually something other than counting
where the the co-expression spend more time processing, the co-switch
performance quickly becomes negligible. This is not to say stackless
coexpressions are not good, but as you mentioned, we have a lot of other
features that depend on the current semantics of coexpression. Unless we
have a path to make all of those features work with stackless
co-expressions I don't think what stackless co-expressions worth giving up
those features.
Cheers,
Jafar
On Sat, Apr 30, 2016 at 5:37 PM, Jeffery, Clint (jeffe...@uidaho.edu) <
jeffe...@uidaho.edu> wrote:
> Thanks Jafar for these very interesting comparisons. Robert would know
> better than I, but it may well be that when he first told me of his plans
> to do stackless co-expressions, I said something stupid like: my monitoring
> facilities are built using the current co-expression switch and Unicon will
> never adopt a different co-expression switch unless the monitoring
> facilities are supported. So he went off and invented Object Icon. Then
> again, I may be misremembering and inventing that anecdote. [image: 😊]
> In any case, if he has 27% faster co-expressions that is a great technical
> accomplishment, worthy of Robert's other great creations. UDB and other
> monitors remain the world's biggest customer of co-expressions, so I
> wish monitors ran on his 27% faster co-expressions. And I am not sure I'd
> give up any normal execution speed for faster co-expressions, since most
> programs do not use co-expressions. But I recognize that these numbers are
> not authoritative.
>
>
> Cheers,
>
> Clint
> ------------------------------
> *From:* Jafar Al-Gharaibeh <to.ja...@gmail.com>
> *Sent:* Saturday, April 30, 2016 11:12:28 AM
> *To:* Bruce & Breeanna Rennie
> *Cc:* Unicon
> *Subject:* Re: [Unicon-group] Soft thread changes
>
> My previous email decided to "fly" before I was done :) .... here is the
> results:
>
> Objecticon: 9.7 seconds
> Unicon: 12.3 seconds.
>
>
> The context switch is 27% faster in Objecticon, I actually expected a lot
> bigger difference.
> To get a feel of the interpreter loop performance in both languages I ran
> this program:
>
> procedure main()
>
> every 1 to 200000000
>
> end
> Objecticon: 17.0 seconds
> Unicon: 11.9 seconds.
>
> Unicon is 43% faster. These were quick tests, so number should not be
> taken literally, I just wanted to get a quick reference point.
>
> Cheers,
> Jafar
>
>
>
>
>
>
>
>
> On Sat, Apr 30, 2016 at 12:58 PM, Jafar Al-Gharaibeh <to.ja...@gmail.com>
> wrote:
>
>> Here are some information about Objecticon co-expressions including
>> difference in semantics compared with Icon/Unicon:
>> http://objecticon.sourceforge.net/Coexpressions.html
>>
>> And here is another link with a brief discussion about the implementation
>> of co-expressions:
>> http://objecticon.sourceforge.net/ImplementationNotes.html
>>
>>
>> I'm not familiar with ObjectIcon implementation to say much about it, but
>> from the discussion in the above link, co-expressions seems to be a lot
>> cheaper in term of memory requirement (no stack), and in context switch
>> performance (no recursive call to the interpreter). Co-expression stack in
>> Unicon is configurable so you can reduce the memory requirement if the
>> application uses a lot of "little" co-expressions, but still a stack is
>> needed.
>>
>> On the performance front of context switch, while a recursive call to the
>> interpreter is needed, it only takes place once at the first activation so
>> it is not really a problem in this case. There is however some state that
>> needs to be saved/restored, both c state and interpreter state. With
>> native coswitch in Unicon that we have in all common platforms now
>> (recently added Mac OS and ARM Linux) the cosiwtch is "fast". I decided to
>> test how "slow" Unicon's context switch compared to the
>> stackless/non-recursive implementation of co-expressions in Object Icon. I
>> built both on my Raspberry Pi (No graphics in both, and concurrency turned
>> off in the case of Unicon). Here is the program that I tested:
>>
>> procedure main()
>>
>> c := create 1 to 20000000
>>
>> while @c
>>
>> end
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Apr 29, 2016 at 8:01 PM, Bruce & Breeanna Rennie <
>> bren...@dcsi.net.au> wrote:
>>
>>> Good morning Jay and Steve,
>>>
>>> It is a personal project to understand the difference between Unicon and
>>> ObjectIcon. My reasons are related to the co-expression implementation
>>> differences and the fact that ObjectIcon is a no recursive interpreter
>>> (unlike Unicon). My original reason for looking at both is that I am
>>> looking at a reimplementation of the icon runtime as a indirect threaded
>>> form. I have been puzzling about this for many years but, it has only
>>> been in recent times that I have the extra time to look at these things.
>>>
>>> My investigations should, at this point, have no bearing on what Jafar
>>> is doing. As far as I can tell, I am the only one looking at the
>>> implementation differences. As I am NOT a c programmer, I am also having
>>> to look at the implementation as a novice. I have always found c as
>>> being a hodge podge in terms of a language. But that is really neither
>>> here nor there.
>>>
>>> At this point, I can't give any real comment on either implementation
>>> with respect to threads, co-expressions and efficiency.
>>>
>>> regards
>>>
>>> Bruce Rennie
>>>
>>> On 30/04/16 02:37, Jay Hammond wrote:
>>> > Robert Parlett developed Objecticon.
>>> >
>>> > https://rosettacode.org/wiki/Category:ObjectIcon
>>> >
>>> > and
>>> >
>>> > http://objecticon.sourceforge.net/
>>> >
>>> > say a bit about it.
>>> >
>>> > From a long time ago maybe 8 years, I seem to remember there being
>>> > discussion in this group about a different co-expression implementation
>>> > in Objecticon being more efficient at threads, co-expressions than the
>>> > then Unicon one.
>>> >
>>> > There was of course also a downside to that approach. There always are
>>> > compromises.
>>> >
>>> > If it's not too much of a distraction, would Bruce and or Jafar care
>>> > to comment on where
>>> > Unicon (and Objecticon) are now wrt threads, co-expressions,
>>> efficiency?
>>> >
>>> > jay
>>> >
>>> > On 29/04/2016 17:04, Steve Graham wrote:
>>> >> ObjectIcon?
>>> >>
>>> >>
>>> ------------------------------------------------------------------------
>>> >> *From:* Bruce & Breeanna Rennie <bren...@dcsi.net.au>
>>> >> *To:* Jafar Al-Gharaibeh <to.ja...@gmail.com>
>>> >> *Cc:* Unicon group <unicon-group@lists.sourceforge.net>
>>> >> *Sent:* Thursday, April 28, 2016 8:35 PM
>>> >> *Subject:* Re: [Unicon-group] Soft thread changes
>>> >>
>>> >> Good afternoon Jafar,
>>> >>
>>> >> As I am able I'll have a look and see if I can add anything of worth
>>> for
>>> >> the implementation. The idea sounds good. At the moment I am still
>>> >> trying to wrap my head around the differences between Unicon and
>>> >> ObjectIcon implementation details.
>>> >>
>>> >> regards
>>> >>
>>> >> Bruce Rennie
>>> >>
>>> >> On 29/04/16 12:21, Jafar Al-Gharaibeh wrote:
>>> >> > Good Morning Bruce,
>>> >> >
>>> >> > Soft-threads ( software threads or maybe vs hard-threads) are a
>>> hybrid
>>> >> > between native co-expressions and threads made possible by my recent
>>> >> > changes to allow native coswitch() to coexist with concurrent
>>> threads.
>>> >> > They are similar to native co-expressions in that they are
>>> completely
>>> >> > a Unicon thing (no OS context, i.e can't be scheduled by the OS),
>>> but
>>> >> > they are similar to threads in that they are concurrent. Since a
>>> soft
>>> >> > thread doesn't have a pthread (OS context) it needs to be scheduled
>>> >> > "manually". Unlike co-expressions which get scheduled via an
>>> explicit
>>> >> > activation, soft threads are managed implicitly by the language's
>>> >> > runtime. That means we need a scheduler that takes care of this new
>>> >> > task with all of the problems that comes with it. :)
>>> >> >
>>> >> > The goal is allow us to create a lot of "cheap" concurrent threads
>>> >> > even without creating pthreads, or get by with a few pthreads
>>> through
>>> >> > thread pooling, etc. The idea is to decouple Unicon's threads from
>>> the
>>> >> > the OS threads.
>>> >> >
>>> >> > What I have committed so far under "SoftThread" ifdefs is very very
>>> >> > basic experimental implementation that I did in under two hours. I
>>> >> > got some basic scheduling to work and was able to run a small demo.
>>> We
>>> >> > have a long a long way to go. If anyone is interested in this or
>>> >> > helping with implementation I'd be very happy to share more details
>>> >> > with them.
>>> >> >
>>> >> > Cheers,
>>> >> > Jafar
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Thu, Apr 28, 2016 at 8:25 PM, Bruce & Breeanna Rennie
>>> >> > <bren...@dcsi.net.au <mailto:bren...@dcsi.net.au>
>>> >> <mailto:bren...@dcsi.net.au <mailto:bren...@dcsi.net.au>>> wrote:
>>> >> >
>>> >> > Good morning Jafar,
>>> >> >
>>> >> > Can you clue us into what the soft-thread changes are for,
>>> please?
>>> >> >
>>> >> > regards
>>> >> >
>>> >> > Bruce Rennie
>>> >> >
>>> >>
>>> >> Unicon-group mailing list
>>> >> Unicon-group@lists.sourceforge.net
>>> >> <mailto:Unicon-group@lists.sourceforge.net>
>>> >> https://lists.sourceforge.net/lists/listinfo/unicon-group
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Find and fix application performance issues faster with Applications
>>> Manager
>>> > Applications Manager provides deep performance insights into multiple
>>> tiers of
>>> > your business applications. It resolves application problems quickly
>>> and
>>> > reduces your MTTR. Get your free trial!
>>> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>>> >
>>> >
>>> > _______________________________________________
>>> > Unicon-group mailing list
>>> > Unicon-group@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/unicon-group
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Find and fix application performance issues faster with Applications
>>> Manager
>>> Applications Manager provides deep performance insights into multiple
>>> tiers of
>>> your business applications. It resolves application problems quickly and
>>> reduces your MTTR. Get your free trial!
>>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>>> _______________________________________________
>>> Unicon-group mailing list
>>> Unicon-group@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/unicon-group
>>>
>>
>>
>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group
