Import to git

author: Peter Drahoš <drahosp@gmail.com> 2010-10-01 03:22:32 +0200
committer: Peter Drahoš <drahosp@gmail.com> 2010-10-01 03:22:32 +0200
commit: 3fe8732f32e3675c62a46fcb70fb95ef936376a5 (patch)
tree: 98e1c640667bbb3f64fff664faf6f7d59ef0fe91 /comparison.html
download: lanes-3fe8732f32e3675c62a46fcb70fb95ef936376a5.tar.gz
lanes-3fe8732f32e3675c62a46fcb70fb95ef936376a5.tar.bz2
lanes-3fe8732f32e3675c62a46fcb70fb95ef936376a5.zip
1 files changed, 297 insertions, 0 deletions
diff --git a/comparison.html b/comparison.html
new file mode 100644
index 0000000..84ef9ca
--- /dev/null
+++ b/comparison.html
@@ -0,0 +1,297 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<!--
+    Comparison of Lua Lanes with other approaches
+-->
+<html>
+<head>
+  <meta name="description" content="Lua Lanes - Comparison" />
+  <meta name="keywords" content="Lua, Library, Multithreading, Threads, Rocks" />
+  <title>Lua Lanes - Comparison</title>
+</head>
+<body>
+<!-- comparisons +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
+<hr/>
+<h2 id="comparisons">Comparisons to other threading kits</h2>
+<p>
+A short comparison of Lanes with other existing Lua multithreading kits.
+</p>
+<table><tr><td width=40>
+    <td bgcolor="#ffffe0">
+<pre>
+=============
+  Lua Lanes
+=============
+With the introduction of Lindas (Jun-2008), Lua Lanes simplifies its API while
+simultaneously adding more power and speed.
+Pros:
+    - regular Lua 5.1 module
+    - completely separate Lua states, one per OS thread
+    - message passing, or shared data using Lindas
+    - no application level locking, ever
+    - scales well, up to 1000's of threads
+    - priorities (-2..+2) for launched threads
+    - threads are cancellable (with complete cleanup)
+    - timeouts on all pending operations
+    - thread contents are given as regular Lua functions; syntax checked early on,
+      syntax highlighting works
+    - standard libraries opened to subthreads can be granually selected
+    - fast stack-to-stack copies, via hidden "keeper states". No serialization needed.
+    - protects calls to 'require', allowing wide compatibility with existing
+      modules (and all, with minor changes)
+Cons:
+    - requires OS threads
+    - not utilizing network parallelism (all threads on one CPU)
+Sample:
+<<
+  require "lanes"
+  
+  local function calculate(a,b,c)
+    if not a then 
+      error "sample error; propagated to main lane when reading results"
+    end
+    return a+b+c
+  end
+  local h1= lanes.new(calculate)(1,2,3)
+  local h2= lanes.new(calculate)(10,20,30)
+  local h3= lanes.new(calculate)(100,200,300)
+  print( h1[1], h2[1], h3[1] )     -- pends for the results, or propagates error
+<<
+==================
+  Lua coroutines    (by Lua authors)
+==================
+<A HREF="http://www.lua.org/manual/5.1/manual.html#2.11">http://www.lua.org/manual/5.1/manual.html#2.11</A>
+<A HREF="http://lua-users.org/wiki/CoroutinesTutorial">http://lua-users.org/wiki/CoroutinesTutorial</A>
+Lua coroutines is an integral part of Lua 5 itself. It is listed here, since
+it should be the _first_ multitasking mechanism to consider. It can also be
+used together with Lanes, or the other mechanisms listed below.
+Coroutines are very usable in provider/consumer situations, allowing you to
+queue Lua functions on an as-needed dataflow basis with each other.
+ 
+Pros:
+    - works with plain Lua (no extensions)
+    - works on any platform
+    - lightweight (no OS level threading or locking involved)
+Cons:
+    - co-operative, meaning your code will need to decide, who gets to run
+    - does not utilize multiple CPUs/cores
+Sample:
+    ..TBD: sample code doing the "child" "parent" output here (see below)..
+=============
+  LuaThread     (by Diego Nehab)
+=============
+<A HREF="http://www.cs.princeton.edu/~diego/professional/luathread/">http://www.cs.princeton.edu/~diego/professional/luathread/</A>
+LuaThread provides thread creation, mutexes, condition variables, and inter-
+thread queues to the Lua scripts. It takes a C-kind of approach, where Lua
+globals are shared by the threads running, and need therefore to be guarded
+against multithreading conflicts. 
+Whether this is exactly what you want, or whether a more loosely implemented
+multithreading (s.a. Lanes) would be better, is up to you. One can argue that
+a loose implementation is easier for the developer, since no application level
+lockings need to be considered.
+Pros:
+    - no marshalling overhead, since threads share the same Lua state
+Cons:
+    - requires a modified Lua core
+    - application level locking required
+Sample:
+&lt;&lt;
+  local function flood(output, word)
+    while 1 do 
+        output:lock()
+        io.write(word, ", ")
+        output:unlock()
+    end
+  end
+  local output = thread.newmutex()
+  thread.newthread(flood, {output, "child"})
+  flood(output, "parent")
+&lt;&lt;
+=============
+  Lua Rings     (by Roberto Ierusalimschy &amp; Tom&aacute;s Guisasola)
+=============
+<A HREF="http://www.keplerproject.org/rings/">http://www.keplerproject.org/rings/</A>
+".. library which provides a way to create new Lua states from within Lua. 
+It also offers a simple way to communicate between the creator (master) and 
+the created (slave) states."
+".. master can execute code in any of its slaves but each slave only has
+access to its master (or its own slaves)."
+Rings offers separate Lua states, but no multithreading. This makes it simple,
+but it won't use more than one CPU core. Other differences include:
+    - opens all Lua standard libraries for subthreads
+      (Lanes opens the needed ones)
+    - marshalls numbers, strings, booleans, userdata
+      (Lanes marshalls also non-cyclic tables)
+    - "remotedostring" allows executing code in the master state
+      (Lanes does _not_ allow subthreads to trouble/modify master automatically,
+      to allow effective sandboxing. The same can be achieved by sending code 
+      between the threads, but master needs to explicitly allow this = receive
+      a function and execute it)
+    - offers "Stable, a very simple API to manage a shared table at the master
+      state"
+      (Lanes 2008 offers keeper tables)
+Pros:
+    - "offers Stable, a very simple API to manage a shared table at the master 
+    state"
+Cons:
+    - thread contents defined as strings, not Lua source as such; does not
+      give syntax check at file parsing, does not allow syntax highlight
+Sample:
+&lt;&lt;
+  require"rings"
+  S = rings.new ()
+  data = { 12, 13, 14, }
+  print (S:dostring ([[
+  aux = {}
+  for i, v in ipairs (arg) do
+        table.insert (aux, 1, v)
+  end
+  return unpack (aux)]], unpack (data))) -- true, 14, 13, 12
+  S:close ()
+&lt;&lt;
+==========================
+  Helper Threads Toolkit    (by Javier Guerra G.)
+==========================
+<A HREF="http://luaforge.net/projects/helper-threads/">http://luaforge.net/projects/helper-threads/</A>
+"Provides a consistent framework to write non-blocking C libraries, with a Lua
+interface for starting tasks and managing the Futures, Queues and Threads."
+This seems like a companion of the "occasional threading" model (see below);
+Lua side is kept clear of multithreading, while C side can be "spawn" off to
+do things on the background.
+Pros:
+    - provides an "update" mechanism, allowing the (C) thread and controlling
+      Lua to interact during execution of the thread
+    - ...
+Cons:
+    - thread is "only for C code and it can't touch or access the Lua state",
+      in other words there is no Lua-side multithreading concept (by design)
+========================
+  Occasional threading      (by Russ Cox)
+========================
+<A HREF="http://lua-users.org/lists/lua-l/2006-11/msg00368.html">http://lua-users.org/lists/lua-l/2006-11/msg00368.html</A>
+".. able to have certain C calls run in parallel with the [Lua] VM, but
+otherwise keep the VM single-threaded."
+That pretty much says it all.
+Pros:
+    - simple, yet providing for the "occasional" need to run really multithreaded
+    - can be made into a loadable module (says the message)
+Cons:
+    - only for occasional usage, the programming paradigm is still essentially
+      singlethreaded (by definition)
+    - not a real project, just a message on the Lua list (but a good one!)
+    
+=================
+  ConcurrentLua 
+=================
+<A TARGET="_blank" HREF="http://concurrentlua.luaforge.net/index.html"
+>http://concurrentlua.luaforge.net/index.html</A>
+ConcurrentLua is based on the Lua model for concurrency, namely coroutines, and
+extends this model by providing message-passing primitives. 
+".. implementation of the share-nothing asynchronous message-passing model"
+".. process can check its mailbox for new messages at any time, and if there 
+are any, they can be read in the order of arrival."
+".. processes in the system are implemented with Lua coroutines"
+".. still based on the cooperative multithreading model that Lua uses"
+Recent, released on 21 June 2008.
+Pros:
+    - From ground up designed for distributed computing (multiple computers,
+    not only CPU cores)
+    - Does not require a pre-emptive operating system
+Cons:
+    - Serialization must degrade raw performance in one-computer scenarios
+      (vs. stack-to-stack copying ala Lanes)
+    - Depends on LuaSocket and Copas modules.
+    - Each thread has a single mailbox tied to it (vs. separating threads and
+      connection resources)
+</pre>
+</td></tr></table>
+<!-- footnotes +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
+<hr/>
+<p>For feedback, questions and suggestions:
+<UL>
+    <li><A HREF="http://luaforge.net/projects/lanes">Lanes @ LuaForge</A></li>
+    <li><A HREF="mailto:akauppi@gmail.com">the author</A></li>
+</UL>
+</p>
+<!--
+<font size="-1">
+<p>
+1) ...
+</p>
+</font>
+-->
+</body>
+</html>
author	Peter Drahoš <drahosp@gmail.com>	2010-10-01 03:22:32 +0200
committer	Peter Drahoš <drahosp@gmail.com>	2010-10-01 03:22:32 +0200
commit	3fe8732f32e3675c62a46fcb70fb95ef936376a5 (patch)
tree	98e1c640667bbb3f64fff664faf6f7d59ef0fe91 /comparison.html
download	lanes-3fe8732f32e3675c62a46fcb70fb95ef936376a5.tar.gz lanes-3fe8732f32e3675c62a46fcb70fb95ef936376a5.tar.bz2 lanes-3fe8732f32e3675c62a46fcb70fb95ef936376a5.zip

diff --git a/comparison.html b/comparison.html new file mode 100644 index 0000000..84ef9ca --- /dev/null +++ b/comparison.html
@@ -0,0 +1,297 @@
	1	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
	2	<!--
	3	Comparison of Lua Lanes with other approaches
	4	-->
	5
	6	<html>
	7	<head>
	8	<meta name="description" content="Lua Lanes - Comparison" />
	9	<meta name="keywords" content="Lua, Library, Multithreading, Threads, Rocks" />
	10
	11	<title>Lua Lanes - Comparison</title>
	12	</head>
	13
	14	<body>
	15
	16	<!-- comparisons +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
	17	<hr/>
	18	<h2 id="comparisons">Comparisons to other threading kits</h2>
	19
	20	<p>
	21	A short comparison of Lanes with other existing Lua multithreading kits.
	22	</p>
	23
	24	<table><tr><td width=40>
	25	<td bgcolor="#ffffe0">
	26	<pre>
	27	=============
	28	Lua Lanes
	29	=============
	30
	31	With the introduction of Lindas (Jun-2008), Lua Lanes simplifies its API while
	32	simultaneously adding more power and speed.
	33
	34	Pros:
	35	- regular Lua 5.1 module
	36	- completely separate Lua states, one per OS thread
	37	- message passing, or shared data using Lindas
	38	- no application level locking, ever
	39	- scales well, up to 1000's of threads
	40	- priorities (-2..+2) for launched threads
	41	- threads are cancellable (with complete cleanup)
	42	- timeouts on all pending operations
	43	- thread contents are given as regular Lua functions; syntax checked early on,
	44	syntax highlighting works
	45	- standard libraries opened to subthreads can be granually selected
	46	- fast stack-to-stack copies, via hidden "keeper states". No serialization needed.
	47	- protects calls to 'require', allowing wide compatibility with existing
	48	modules (and all, with minor changes)
	49
	50	Cons:
	51	- requires OS threads
	52	- not utilizing network parallelism (all threads on one CPU)
	53
	54	Sample:
	55	<<
	56	require "lanes"
	57
	58	local function calculate(a,b,c)
	59	if not a then
	60	error "sample error; propagated to main lane when reading results"
	61	end
	62	return a+b+c
	63	end
	64
	65	local h1= lanes.new(calculate)(1,2,3)
	66	local h2= lanes.new(calculate)(10,20,30)
	67	local h3= lanes.new(calculate)(100,200,300)
	68
	69	print( h1[1], h2[1], h3[1] ) -- pends for the results, or propagates error
	70	<<
	71
	72
	73	==================
	74	Lua coroutines (by Lua authors)
	75	==================
	76
	77	<A HREF="http://www.lua.org/manual/5.1/manual.html#2.11">http://www.lua.org/manual/5.1/manual.html#2.11</A>
	78	<A HREF="http://lua-users.org/wiki/CoroutinesTutorial">http://lua-users.org/wiki/CoroutinesTutorial</A>
	79
	80	Lua coroutines is an integral part of Lua 5 itself. It is listed here, since
	81	it should be the _first_ multitasking mechanism to consider. It can also be
	82	used together with Lanes, or the other mechanisms listed below.
	83
	84	Coroutines are very usable in provider/consumer situations, allowing you to
	85	queue Lua functions on an as-needed dataflow basis with each other.
	86
	87	Pros:
	88	- works with plain Lua (no extensions)
	89	- works on any platform
	90	- lightweight (no OS level threading or locking involved)
	91
	92	Cons:
	93	- co-operative, meaning your code will need to decide, who gets to run
	94	- does not utilize multiple CPUs/cores
	95
	96	Sample:
	97
	98	..TBD: sample code doing the "child" "parent" output here (see below)..
	99
	100
	101	=============
	102	LuaThread (by Diego Nehab)
	103	=============
	104
	105	<A HREF="http://www.cs.princeton.edu/~diego/professional/luathread/">http://www.cs.princeton.edu/~diego/professional/luathread/</A>
	106
	107	LuaThread provides thread creation, mutexes, condition variables, and inter-
	108	thread queues to the Lua scripts. It takes a C-kind of approach, where Lua
	109	globals are shared by the threads running, and need therefore to be guarded
	110	against multithreading conflicts.
	111
	112	Whether this is exactly what you want, or whether a more loosely implemented
	113	multithreading (s.a. Lanes) would be better, is up to you. One can argue that
	114	a loose implementation is easier for the developer, since no application level
	115	lockings need to be considered.
	116
	117	Pros:
	118	- no marshalling overhead, since threads share the same Lua state
	119
	120	Cons:
	121	- requires a modified Lua core
	122	- application level locking required
	123
	124	Sample:
	125	<<
	126	local function flood(output, word)
	127	while 1 do
	128	output:lock()
	129	io.write(word, ", ")
	130	output:unlock()
	131	end
	132	end
	133
	134	local output = thread.newmutex()
	135	thread.newthread(flood, {output, "child"})
	136	flood(output, "parent")
	137	<<
	138
	139
	140	=============
	141	Lua Rings (by Roberto Ierusalimschy & Tomás Guisasola)
	142	=============
	143
	144	<A HREF="http://www.keplerproject.org/rings/">http://www.keplerproject.org/rings/</A>
	145
	146	".. library which provides a way to create new Lua states from within Lua.
	147	It also offers a simple way to communicate between the creator (master) and
	148	the created (slave) states."
	149
	150	".. master can execute code in any of its slaves but each slave only has
	151	access to its master (or its own slaves)."
	152
	153	Rings offers separate Lua states, but no multithreading. This makes it simple,
	154	but it won't use more than one CPU core. Other differences include:
	155
	156	- opens all Lua standard libraries for subthreads
	157	(Lanes opens the needed ones)
	158
	159	- marshalls numbers, strings, booleans, userdata
	160	(Lanes marshalls also non-cyclic tables)
	161
	162	- "remotedostring" allows executing code in the master state
	163	(Lanes does _not_ allow subthreads to trouble/modify master automatically,
	164	to allow effective sandboxing. The same can be achieved by sending code
	165	between the threads, but master needs to explicitly allow this = receive
	166	a function and execute it)
	167
	168	- offers "Stable, a very simple API to manage a shared table at the master
	169	state"
	170	(Lanes 2008 offers keeper tables)
	171
	172	Pros:
	173	- "offers Stable, a very simple API to manage a shared table at the master
	174	state"
	175
	176	Cons:
	177	- thread contents defined as strings, not Lua source as such; does not
	178	give syntax check at file parsing, does not allow syntax highlight
	179
	180	Sample:
	181	<<
	182	require"rings"
	183	S = rings.new ()
	184
	185	data = { 12, 13, 14, }
	186	print (S:dostring ([[
	187	aux = {}
	188	for i, v in ipairs (arg) do
	189	table.insert (aux, 1, v)
	190	end
	191	return unpack (aux)]], unpack (data))) -- true, 14, 13, 12
	192
	193	S:close ()
	194	<<
	195
	196
	197	==========================
	198	Helper Threads Toolkit (by Javier Guerra G.)
	199	==========================
	200
	201	<A HREF="http://luaforge.net/projects/helper-threads/">http://luaforge.net/projects/helper-threads/</A>
	202
	203	"Provides a consistent framework to write non-blocking C libraries, with a Lua
	204	interface for starting tasks and managing the Futures, Queues and Threads."
	205
	206	This seems like a companion of the "occasional threading" model (see below);
	207	Lua side is kept clear of multithreading, while C side can be "spawn" off to
	208	do things on the background.
	209
	210	Pros:
	211	- provides an "update" mechanism, allowing the (C) thread and controlling
	212	Lua to interact during execution of the thread
	213	- ...
	214
	215	Cons:
	216	- thread is "only for C code and it can't touch or access the Lua state",
	217	in other words there is no Lua-side multithreading concept (by design)
	218
	219
	220	========================
	221	Occasional threading (by Russ Cox)
	222	========================
	223
	224	<A HREF="http://lua-users.org/lists/lua-l/2006-11/msg00368.html">http://lua-users.org/lists/lua-l/2006-11/msg00368.html</A>
	225
	226	".. able to have certain C calls run in parallel with the [Lua] VM, but
	227	otherwise keep the VM single-threaded."
	228
	229	That pretty much says it all.
	230
	231	Pros:
	232	- simple, yet providing for the "occasional" need to run really multithreaded
	233	- can be made into a loadable module (says the message)
	234
	235	Cons:
	236	- only for occasional usage, the programming paradigm is still essentially
	237	singlethreaded (by definition)
	238	- not a real project, just a message on the Lua list (but a good one!)
	239
	240
	241	=================
	242	ConcurrentLua
	243	=================
	244
	245	<A TARGET="_blank" HREF="http://concurrentlua.luaforge.net/index.html"
	246	>http://concurrentlua.luaforge.net/index.html</A>
	247
	248	ConcurrentLua is based on the Lua model for concurrency, namely coroutines, and
	249	extends this model by providing message-passing primitives.
	250
	251	".. implementation of the share-nothing asynchronous message-passing model"
	252
	253	".. process can check its mailbox for new messages at any time, and if there
	254	are any, they can be read in the order of arrival."
	255
	256	".. processes in the system are implemented with Lua coroutines"
	257
	258	".. still based on the cooperative multithreading model that Lua uses"
	259
	260	Recent, released on 21 June 2008.
	261
	262	Pros:
	263	- From ground up designed for distributed computing (multiple computers,
	264	not only CPU cores)
	265	- Does not require a pre-emptive operating system
	266
	267	Cons:
	268	- Serialization must degrade raw performance in one-computer scenarios
	269	(vs. stack-to-stack copying ala Lanes)
	270	- Depends on LuaSocket and Copas modules.
	271	- Each thread has a single mailbox tied to it (vs. separating threads and
	272	connection resources)
	273
	274	</pre>
	275	</td></tr></table>
	276
	277
	278	<!-- footnotes +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
	279	<hr/>
	280
	281	<p>For feedback, questions and suggestions:
	282	<UL>
	283	<li><A HREF="http://luaforge.net/projects/lanes">Lanes @ LuaForge</A></li>
	284	<li><A HREF="mailto:akauppi@gmail.com">the author</A></li>
	285	</UL>
	286	</p>
	287
	288	<!--
	289	<font size="-1">
	290	<p>
	291	1) ...
	292	</p>
	293	</font>
	294	-->
	295
	296	</body>
	297	</html>