If a cog donates one or more of its hub slot to another cog (which is essentially what all the table-based schemes do) then there are objects that will operate differently - if at all - when loaded into the donating cog.
Yes, they are the objects that the user writes to operate this way. That is why they co-operate!
You only change the slots with objects that you know work (write/modify yourself).
Remember the saying "you can lead a horse to water but you can't make it drink"
Mooching, on the other hand, is guaranteed to only use slots that are unused. But in fact even mooching could still lead to some timing differences in overall program behavior - but it seems unlikely it would have anywhere near the impact of the table-based schemes.
Yes, they are the objects that the user writes to operate this way. That is why they co-operate!
You only change the slots with objects that you know work (write/modify yourself).
This is exactly why I claim these solutions are "complex" and break the Propeller's "plug and play" paradigm. You need to know a lot more than you do now to use these table-based schemes.
Hobbyists speak now or forever hold your peace if you actually read anything ;-)
As the one hobbyist who read the SimpleIDE User Guide (just chosen as an example, of course , I'm sure not what you meant), I should speak up now, right?
In the same way that Sharing is seen to be impacting, somehow.... how is it not the same with Mooching?
Mooching has the potential to have from 1 slot, to 15.
Somewhere in there, to be in any way effective, it has to have multiples of slots to be useful beyond a Standard Object.
So, in a Case whereing you have 15 Cores already running and using their slots, adding this Mooching object is useless, or potentially worse than a Standard Object programmed to a finely tuned 1 slot access rate.
Somewhere in that 500 Op space, you not only have to program the actual object, but also probably add in additional code for what to do when there is +1 slot available, +2, +3, etc.
For 'sloppy' Objects, I understand that Mooching will be useful for additional hub access, however overall, you are going to be required to read the docs, etc if you want to get any actual benefit from it.
Just as with the prototypical Standard Sharing, your User is going to cry, and his project is going to explode in a fiery mess when he doesn't get the performance from this Mooch Object that it claims to give.
Unless of course, you now want to say that your User is going to RTFM this time, and do all sorts of mental gymnastics keeping track of what objects are running, and how many of them are Mooching as well, etc, etc, etc.
Very much similar could be laid at the foot of Conjoined-Cores, which some here always fall back on when arguing hub sharing.
Conjoined-Cores breaks symmetry, determinism, and is just as likely to cause the same User complaints and failures.
No one discusses that. If they were, then I'm sure the response would be that 'Obviously the User is smart enough to know that he needs 2 Cogs'.
But in hub sharing, the User is deemed an incompetent fool ?
At this point, I could care which way Chip decides to go, although the obvious choice would be hub sharing = yes.
In discussion forthwith, lets just use the same smart/dumb User in all of our examples, to accurately compare apples - apples.
Conjoined-Cores breaks symmetry, determinism, and is just as likely to cause the same User complaints and failures.
I would argue the nature of the complaints might be different, even though the result may be the same. The paired cogs can fail at initialization, through the same mechanism we have now when there are no spare cogs.
But yes you do well to highlight the logical inconsistencies. I think this whole thinking exercise is valuable regardless of whether anything is adopted at any point.
Comments
Oh, I hand pick my singers, and they NEVER stutter - Why ? Because I have full control.
You only change the slots with objects that you know work (write/modify yourself).
Remember the saying "you can lead a horse to water but you can't make it drink" Agreed for once.
This is exactly why I claim these solutions are "complex" and break the Propeller's "plug and play" paradigm. You need to know a lot more than you do now to use these table-based schemes.
As the one hobbyist who read the SimpleIDE User Guide (just chosen as an example, of course
I do have a question though.
In the same way that Sharing is seen to be impacting, somehow.... how is it not the same with Mooching?
Mooching has the potential to have from 1 slot, to 15.
Somewhere in there, to be in any way effective, it has to have multiples of slots to be useful beyond a Standard Object.
So, in a Case whereing you have 15 Cores already running and using their slots, adding this Mooching object is useless, or potentially worse than a Standard Object programmed to a finely tuned 1 slot access rate.
Somewhere in that 500 Op space, you not only have to program the actual object, but also probably add in additional code for what to do when there is +1 slot available, +2, +3, etc.
For 'sloppy' Objects, I understand that Mooching will be useful for additional hub access, however overall, you are going to be required to read the docs, etc if you want to get any actual benefit from it.
Just as with the prototypical Standard Sharing, your User is going to cry, and his project is going to explode in a fiery mess when he doesn't get the performance from this Mooch Object that it claims to give.
Unless of course, you now want to say that your User is going to RTFM this time, and do all sorts of mental gymnastics keeping track of what objects are running, and how many of them are Mooching as well, etc, etc, etc.
Very much similar could be laid at the foot of Conjoined-Cores, which some here always fall back on when arguing hub sharing.
Conjoined-Cores breaks symmetry, determinism, and is just as likely to cause the same User complaints and failures.
No one discusses that. If they were, then I'm sure the response would be that 'Obviously the User is smart enough to know that he needs 2 Cogs'.
But in hub sharing, the User is deemed an incompetent fool ?
At this point, I could care which way Chip decides to go, although the obvious choice would be hub sharing = yes.
In discussion forthwith, lets just use the same smart/dumb User in all of our examples, to accurately compare apples - apples.
I would argue the nature of the complaints might be different, even though the result may be the same. The paired cogs can fail at initialization, through the same mechanism we have now when there are no spare cogs.
But yes you do well to highlight the logical inconsistencies. I think this whole thinking exercise is valuable regardless of whether anything is adopted at any point.