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.
> blogspot.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
