but as i understand it ...changing a single threaded app to multi-threaded
at its core is a huge undertaking aand i'm not sure its even on the drawing
board for v 12 ...but i could be wrong....maybe its coming in v10 :D :D :D
On Mon, Jun 11, 2018 at 9:02 PM, Tom Glod <t...@makeshyft.com> wrote:
> i see what you mean..... the single threaded aspect of LC is a
> drag....... i'm actually trying my hand at some kind of workaround for this
> limitation for the global conference in september ....i aim to do some
> multi-core processing using LC and measure performance gain over specific
> workloads ...like search....db query..... and i/o.
>
> On Mon, Jun 11, 2018 at 8:08 PM, Sannyasin Brahmanathaswami via
> use-livecode <use-livecode@lists.runrev.com> wrote:
>
>> I wasn't thinking about high language per se. but more from an engine
>> point of view, specifically use of "Goroutines"
>>
>> "But, most of the modern programming languages(like Java, Python etc.)
>> are from the ’90s single threaded environment. Most of those programming
>> languages supports multi-threading. But the real problem comes with
>> concurrent execution, threading-locking, race conditions and deadlocks.
>> Those things make it hard to create a multi-threading application on those
>> languages.
>> {snip]
>> On the other hand, Go was released in 2009 when multi-core processors
>> were already available. That’s why Go is built with keeping concurrency in
>> mind. Go has goroutines instead of threads. They consume almost 2KB memory
>> from the heap. So, you can spin millions of goroutines at any time.
>>
>> How Goroutines work? Reffrance: http://golangtutorials.blogspo
>> t.in/2011/06/goroutines.html
>>
>> Other benefits are :
>>
>> Goroutines have growable segmented stacks. That means they will use
>> more memory only when needed.
>> Goroutines have a faster startup time than threads.
>> Goroutines come with built-in primitives to communicate safely
>> between themselves (channels).
>> Goroutines allow you to avoid having to resort to mutex locking when
>> sharing data structures.
>> Also, goroutines and OS threads do not have 1:1 mapping. A single
>> goroutine can run on multiple threads. Goroutines are multiplexed into
>> small number of OS threads.
>> =========
>>
>> And from the reference a "Goroutine" may be not language specific and
>> maybe (I don't know much about the engine) I am dreaming about the rabbit
>> in the moon, but, for Mark's "idea machine" there is this:
>>
>> " Effectively for us goroutines hides many of the internal machine
>> complexities in achieving parallelism. This also means that the language
>> designers could implement changes to how goroutines scale on the machine
>> taking advantage of hardware and CPU improvements."
>>
>> Brahmanathaswami
>>
>>
>> On 6/10/18, 5:01 AM, "use-livecode on behalf of Tom Glod via
>> use-livecode" <use-livecode-boun...@lists.runrev.com on behalf of
>> use-livecode@lists.runrev.com> wrote:
>>
>> LC and Go have entirely different target markets....but since you can
>> easily make 1 application talk to another application using sockets
>> .....
>> or open process...... the LC and Go make a wonderful partnership if
>> you
>> need to build UI ...but also do High Performance Computing.
>>
>> The 2 can make a great couple indeed. But neither can replace the
>> other.
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
