2020.7.28..31: adds/cs/the first automation was written language:
here is what humans have over other animals:
. our language uses symbols that can entirely describe
our understanding of the world;
and our understanding of the world is so vast
that we can survive without adapting our genome
by engineering environmental adaptations.
. also,
language in its written form is
more important than speech (the verbal form);
because it represents a form of automation of our memory;
giving us not only communication
but a virtually infinite memory size.
. the first reliable computations involved
writing the steps of an algorithm
so that we could automate the part of our mind
that remembered each step and their ordering.
Showing posts with label concurrency. Show all posts
Showing posts with label concurrency. Show all posts
2020-07-31
2016-09-17
Milk for openMP
9.15: news.adda/lang/co/Milk for openMP:
917: summary:
. Milk language optimizes openMP,
to avoid having to rewrite code.
. if you are starting from scratch,
better to avoid openMP.
917: summary:
. Milk language optimizes openMP,
to avoid having to rewrite code.
. if you are starting from scratch,
better to avoid openMP.
Labels:
adda,
concurrency,
lang
2014-12-17
concurrency ideas inspired by obj'c
4.13: adda/oop/co/concurrency ideas inspired by obj'c:
. obj'c has a callback pattern
where a service provider is customizable
by expecting the clients to provide certain functions
that the service provider will call at special times .
. obj'c's callbacks will have a param indicating
which object is the service provider doing the callback
-- apple calls that the msg sender --
but that is generalizable as the caller:
each call is part of a call stack,
and we don't need to include the caller in the parameter
because the system can provide that as stack(-1),
eg, the adda language could reserve the term:
self`caller
( however, notice in pure oop, callers are
always obj's, not subprograms .
when a service provider is calling you back,
you don't want to know which of its subprogram's called you back;
you want a way to refer back to the service provider .
. the key to sorting this out is noticing
when there is cross-module communications .
. are all objects to be treated as separate processes?
)
. is there a distinction between caller and msg sender?
are objects async'ly called ? generally not,
since the call's parameters could be
references to caller's internals;
so, the caller is going to want to
wait for the call to finish .
. even if the callee is not writing to a shared object
the caller has to avoid writing until callee is done,
or it has to be a dynamically updateable type
(2 threads must agree to release as often as possible).
. if not waiting for callee to return,
there must be a lock on the refs target,
when callee is done handling the msg
the system has to notice if any params are pointers
and unlock the targets when the call is done;
ie,
the caller usually knows when a call is done,
because it wouldn't be runnable
unless all its callees had returned;
so, during an async call, the caller is still running
until it bumps into a locked resource,
and when the async callee returns,
the system must provide a notification,
and upon notification the caller can unlock the resources
that it had let that callee borrow,
or the system's notification could consist of
auto'ly unlocking what was shared with the callee .
. unlocking means decrementing an [in use by a callee].counter,
since with async calling concurrently,
there could be multiple readers locking out writers .
... may want to review
what's already been written about this;
but generally,
it would be nice to have a way for the caller
to know when an async callee is done
the async syntax could be
has-returned.flag`= async y`= f(x) .
. obj'c has a callback pattern
where a service provider is customizable
by expecting the clients to provide certain functions
that the service provider will call at special times .
. obj'c's callbacks will have a param indicating
which object is the service provider doing the callback
-- apple calls that the msg sender --
but that is generalizable as the caller:
each call is part of a call stack,
and we don't need to include the caller in the parameter
because the system can provide that as stack(-1),
eg, the adda language could reserve the term:
self`caller
( however, notice in pure oop, callers are
always obj's, not subprograms .
when a service provider is calling you back,
you don't want to know which of its subprogram's called you back;
you want a way to refer back to the service provider .
. the key to sorting this out is noticing
when there is cross-module communications .
. are all objects to be treated as separate processes?
)
. is there a distinction between caller and msg sender?
are objects async'ly called ? generally not,
since the call's parameters could be
references to caller's internals;
so, the caller is going to want to
wait for the call to finish .
. even if the callee is not writing to a shared object
the caller has to avoid writing until callee is done,
or it has to be a dynamically updateable type
(2 threads must agree to release as often as possible).
. if not waiting for callee to return,
there must be a lock on the refs target,
when callee is done handling the msg
the system has to notice if any params are pointers
and unlock the targets when the call is done;
ie,
the caller usually knows when a call is done,
because it wouldn't be runnable
unless all its callees had returned;
so, during an async call, the caller is still running
until it bumps into a locked resource,
and when the async callee returns,
the system must provide a notification,
and upon notification the caller can unlock the resources
that it had let that callee borrow,
or the system's notification could consist of
auto'ly unlocking what was shared with the callee .
. unlocking means decrementing an [in use by a callee].counter,
since with async calling concurrently,
there could be multiple readers locking out writers .
... may want to review
what's already been written about this;
but generally,
it would be nice to have a way for the caller
to know when an async callee is done
the async syntax could be
has-returned.flag`= async y`= f(x) .
Labels:
adda,
concurrency,
obj'c,
oop
2014-11-30
google`AppEngine file system intro
2.20: news.adda/co/google`AppEngine file system intro:
G'AppEngine`concepts:
. projects store objects in buckets
which are like folders but non-nestable;
and have names that are unique across
not just the project but all of g'storage .
. immutability applies only to objects
not filenames, [symbolic vs hard links].
Object names can contain
any combination less than 1024 bytes,
of Unicode characters (UTF-8 encoded)
including "/"
so that you can use old pathnames
while google sees the entire path as one filename,
as the only hierarchy is
(g'storage, some-bucket, some-pathname).
For most operations you can use either of
the following URLs to access an object:
storage.googleapis.com/≺bucket>/≺object>
≺bucket>.storage.googleapis.com/≺object>
www.googleapis.com/storage/v1beta2/b/≺bucket>/o/≺object>?alt=media (JSON API)
G'AppEngine`concepts:
. projects store objects in buckets
which are like folders but non-nestable;
and have names that are unique across
not just the project but all of g'storage .
. immutability applies only to objects
not filenames, [symbolic vs hard links].
Object names can contain
any combination less than 1024 bytes,
of Unicode characters (UTF-8 encoded)
including "/"
so that you can use old pathnames
while google sees the entire path as one filename,
as the only hierarchy is
(g'storage, some-bucket, some-pathname).
For most operations you can use either of
the following URLs to access an object:
storage.googleapis.com/≺bucket>/≺object>
≺bucket>.storage.googleapis.com/≺object>
www.googleapis.com/storage/v1beta2/b/≺bucket>/o/≺object>?alt=media (JSON API)
Labels:
adda,
cloud computing,
concurrency,
filesystem
the value of constants
2.20: news.adda/co/the value of constants:
11.30: summary:
. in classical programming constants are encouraged
because it simplifies the programming space:
you are no longer concerned with
accidently modifying a constant object
because the compiler or the hardware
will automatically detect that mistake for you .
. constants have even more usefulness
in the context of cloud computing .
11.30: summary:
. in classical programming constants are encouraged
because it simplifies the programming space:
you are no longer concerned with
accidently modifying a constant object
because the compiler or the hardware
will automatically detect that mistake for you .
. constants have even more usefulness
in the context of cloud computing .
Labels:
adda,
concurrency,
constant,
distributed,
pointers
2013-12-27
in-mode param use cases
12.8: adda/oop/in-mode param use cases:
8.731: 9.812:
. in-mode parameters that are offering values
(vs pointers) don't need an is-constant bit,
since they are copies that the callee can operate on;
in-mode pointers could use an is-constant bit
for describing whether the target can be modified?
the compiler can enforce constancy
by ensuring that the in-mode pointer's components
are passed only to other in-mode param's .
8.748:
. the primary reason for
in-mode param's being pointers
is when the callee expects the value to be
a large data structure,
and is agreeing to treat the pointer's target
as read-only rather than a writable copy .
. but another reason for an in-mode pointer
is that the pointer's target
is under the control of a different process
that will be changing the value in real time .
. so the formal in-mode pointer
needs to declare whether it honors read-only;
if it doesn't and an actual parameter is read-only
there could be a copy-on-write mechanism
where if the callee's code branched to
a place where it wanted to modify the target,
then the pointer was replaced to point to
a local copy of the target .
9.817: conclusion:
. an actual param has several cases:
# is a value (not a pointer):
. the value is copied,
and the callee's local version is modifiable .
# is a ptr real-time modified:
. the callee is getting a newsfeed
so there is no local version to modify
and it is considered read-only by callee .
# is a ptr not real-time modified:
. if the callee decides to modify the local version
one is created on demand (copy ptr target on modify).
8.731: 9.812:
. in-mode parameters that are offering values
(vs pointers) don't need an is-constant bit,
since they are copies that the callee can operate on;
in-mode pointers could use an is-constant bit
for describing whether the target can be modified?
the compiler can enforce constancy
by ensuring that the in-mode pointer's components
are passed only to other in-mode param's .
8.748:
. the primary reason for
in-mode param's being pointers
is when the callee expects the value to be
a large data structure,
and is agreeing to treat the pointer's target
as read-only rather than a writable copy .
. but another reason for an in-mode pointer
is that the pointer's target
is under the control of a different process
that will be changing the value in real time .
. so the formal in-mode pointer
needs to declare whether it honors read-only;
if it doesn't and an actual parameter is read-only
there could be a copy-on-write mechanism
where if the callee's code branched to
a place where it wanted to modify the target,
then the pointer was replaced to point to
a local copy of the target .
9.817: conclusion:
. an actual param has several cases:
# is a value (not a pointer):
. the value is copied,
and the callee's local version is modifiable .
# is a ptr real-time modified:
. the callee is getting a newsfeed
so there is no local version to modify
and it is considered read-only by callee .
# is a ptr not real-time modified:
. if the callee decides to modify the local version
one is created on demand (copy ptr target on modify).
Labels:
adda,
concurrency,
oop
2013-12-25
Parython is a #ParaSail version based on #python
11.22: news.adda/co/Parython is a ParaSail version based on python:
. a recent ParaSail article mentions Parython, (sources)
more on that earlier? yes but just a mention:
. parasail is featured at recent oopsla:
# bringing value semantics to parallel oop,
# parallel tutorial with
decomposition and work-stealing .
. a recent ParaSail article mentions Parython, (sources)
more on that earlier? yes but just a mention:
Achieving parallelism and safety at the same timenews.adda/co/ParaSail at oopsla:
by eliminating rather than adding features
has worked out better than we originally expected.
One of the lessons of the process has been that
just a small number of key ideas are sufficient to
achieve safe and easy parallelism.
Probably the biggest is the elimination of pointers,
with the substitution of expandable objects.
The other big one is the elimination of
direct access to global variables,
instead requiring that a variable be
passed as a (var or in out) parameter
if a function is going to update it.
Other important ones include
the elimination of parameter aliasing,
and the replacement of exception handling
with a combination of more
pre-condition checking at compile time
and a more task-friendly
event handling mechanism at run time.
So the question now is whether
some of these same key ideas
can be applied to existing languages,
to produce something with much the same look and feel
of the original, while moving toward a much more
parallel-, multicore-, human-friendly semantics.
. parasail is featured at recent oopsla:
# bringing value semantics to parallel oop,
# parallel tutorial with
decomposition and work-stealing .
2013-11-30
stackless mem'mgt
9.3: adda/mem'mgt/stackless:
[11.20: what stackless python does:
. a tasklet is like a separate program:
it has its own stack,
but for multi-threading it also
shares some state with some other program .
. pickling is the saving of a running program
into a file until needed,
when the file is unpickled to become
the same running program it was before .
pickling stackless python's tasklets:
This allows you to take a tasklet mid-execution,
serialise it to a chunk of data
and then unserialise that data at a later point,
creating a new tasklet from it
that resumes where the last left off.]
. stackless python allows simulation of the stack,
so it can freeze your program's long operation,
and restart it when you have the computer back .
. even though we cannot freeze the C`stack,
we can impl' our own stack .
. see also notes on a system for ensuring
user interaction was not interrupted by
a long operation from an uncooperative subprogram
(in our system for ensuring this,
the compiler is rewriting each subprogram
by sprinkling it with calls to the gui;
so that no subprogram causes the gui to be
starved for cpu time).
[11.20: what stackless python does:
. a tasklet is like a separate program:
it has its own stack,
but for multi-threading it also
shares some state with some other program .
. pickling is the saving of a running program
into a file until needed,
when the file is unpickled to become
the same running program it was before .
pickling stackless python's tasklets:
This allows you to take a tasklet mid-execution,
serialise it to a chunk of data
and then unserialise that data at a later point,
creating a new tasklet from it
that resumes where the last left off.]
. stackless python allows simulation of the stack,
so it can freeze your program's long operation,
and restart it when you have the computer back .
. even though we cannot freeze the C`stack,
we can impl' our own stack .
. see also notes on a system for ensuring
user interaction was not interrupted by
a long operation from an uncooperative subprogram
(in our system for ensuring this,
the compiler is rewriting each subprogram
by sprinkling it with calls to the gui;
so that no subprogram causes the gui to be
starved for cpu time).
Labels:
adda,
concurrency,
mem'mgt,
stackless
2013-08-31
semi-type-specific subheaps
14: adda/oop/type-specific heaps:
[29: intro:
. in a type-specific heap,
each object reference has 2 parts:
# an ID of the type it belongs to,
# a serial number unique to that type . 31:
. this promotes encapsulation,
because the reference isn't a pointer,
the only one who knows the object's address
is the type mgt that owns the object .
]
. given the idea of type-specific heaps,
how does that mix with adda's oop?
--that's the efficient form of oop;
the inefficient way of doing oop
uses garbage collection
and that is a choice independent of
which heap an object is owned by,
whether local or global .
. using pointers is not what causes
pointer semantics and garbage:
that's caused when assignments are overwriting
the pointer instead of the pointer's target:
to avoid garbage collection,
assignments need to overwrite the objects themselves
not the pointers to the objects .
. instead of a global type-specific heap
local vars would be placed into
the subprogram's local heap
that can have within it type-specific subheaps .




[29: intro:
. in a type-specific heap,
each object reference has 2 parts:
# an ID of the type it belongs to,
# a serial number unique to that type . 31:
. this promotes encapsulation,
because the reference isn't a pointer,
the only one who knows the object's address
is the type mgt that owns the object .
]
. given the idea of type-specific heaps,
how does that mix with adda's oop?
--that's the efficient form of oop;
the inefficient way of doing oop
uses garbage collection
and that is a choice independent of
which heap an object is owned by,
whether local or global .
. using pointers is not what causes
pointer semantics and garbage:
that's caused when assignments are overwriting
the pointer instead of the pointer's target:
to avoid garbage collection,
assignments need to overwrite the objects themselves
not the pointers to the objects .
. instead of a global type-specific heap
local vars would be placed into
the subprogram's local heap
that can have within it type-specific subheaps .
Labels:
adda,
concurrency,
efficiency,
encapsulation,
mem'mgt,
oop,
pointers
2013-03-09
platforms and requirements to target
1.23: addx/targets are {python, c, obj'c, parasail}:
. if parasail is not on all the needed platforms
the base lang should be obj'c not c;
because, obj'c has better programming-in-the-large features;
well, does it support concurrency?
. if parasail is not on all the needed platforms
the base lang should be obj'c not c;
because, obj'c has better programming-in-the-large features;
well, does it support concurrency?
Labels:
addx,
concurrency,
dev.c,
dev.obj'c,
dev.parasail,
dev.python,
security
concurrency4all Parallella
1.4: news.adds/Parallella/
concurrency4all got funding:
Parallella project will make parallel computing
accessible to everyone.
first seen here:
www.geekosystem.com/99-dollar-computer-
3.9: sign up here: parallella.org .
concurrency4all got funding:
Parallella project will make parallel computing
accessible to everyone.
first seen here:
www.geekosystem.com/99-dollar-computer-
3.9: sign up here: parallella.org .
Labels:
adds,
concurrency,
HPC,
Parallella
2013-01-31
virtual C
1.11: adda/dstr/safe pointers/virtual C:
. adda's pointers can feature arithmetic exactly like c;
yet it can still remain safe because
the addresses are not absolute;
the pointers are actually actually just offsets .
. adda's pointers can feature arithmetic exactly like c;
yet it can still remain safe because
the addresses are not absolute;
the pointers are actually actually just offsets .
Labels:
adda,
C,
concurrency,
dstr,
Parasail,
safe pointers
2012-11-17
concurrency both expressed and automated
8.23: adda/co/finding inherent concurrency automatically:
. how can we analyze a program in order to find
what parts of it can be done concurrently?
. at each step there are implicit inputs and outputs
for step#1, do I know its outputs?
for step#2 do I know its inputs?
(also, when step#1 makes calls,
do any of those calls modify any space that might be
needed by anything step#2 calls? ).
. if step#2's inputs don't intersect step#1's outputs,
then you can do both at the same time .
. to know these things, calls have to be
functional so that program space is obvious .
. when calls have multiple parameters,
the order of their evaluation is random;
which should be tantamount to saying
that parameters in the same tuple
can be run concurrently (co-runnable) .
. this also applies to all tuples that are at
the same level of an expression tree:
eg, in h( f(a,b), g(c,d) ), a,b,c,d are co.runnable .
. a low-level way to compare
subprogramming with coprogramming,
is that while any call could be seen as
a new {process, cpu} activation,
in subprogramming, after making a call,
it agrees to stop working until that call is done .
. often we can find that a group of operations
are all handled by the same type mgt, [11.17:
-- in fact, that is the definition of "(operation):
a subprogram that is outputting
the same type that it's inputting -- ]
so even though they are nested
you can send the whle thing in one call,
and, in that case,
the type mgt will know what's co.runnable .
8.23: todo.adda/co/review parasail's design:
. the parasail lang was able to parallelize implicitly a lot .
(see also comments of this page).
adda/co/explicit concurrency control:
. the abstraction to use for explicit concurrency control
is having a particular cpu called like a function:
cpu#n(subprogram, inputs, outputs)
-- the inputs are a copy of everthing sent to it .
-- outputs are addresses to put results in .
. how is go.lang outputting?
when go.lang says go f(x)
they expect f to either call an outputter
or have x be an outputting channel .
. instead of saying cpu#n(...)
just say co f(x, out), or y`= co f(x) .
8.24: adda/co/syntax:
. there are 2 forms of the function co
according to whether co is synchronous or asynch:
# co(f,g,h) -- co with multiple arguments --
expects spawn and wait .
# co f -- co with just one argument --
just launches f asynchronously .
8.31: co.self/dream/adda/co:
. the dream was something about
"(ways of doing backup for concurrency or ...)
"( ... and now that we can do that,
we can do this ...) [dream recall is too fuzzy].
. how can we analyze a program in order to find
what parts of it can be done concurrently?
. at each step there are implicit inputs and outputs
for step#1, do I know its outputs?
for step#2 do I know its inputs?
(also, when step#1 makes calls,
do any of those calls modify any space that might be
needed by anything step#2 calls? ).
. if step#2's inputs don't intersect step#1's outputs,
then you can do both at the same time .
. to know these things, calls have to be
functional so that program space is obvious .
. when calls have multiple parameters,
the order of their evaluation is random;
which should be tantamount to saying
that parameters in the same tuple
can be run concurrently (co-runnable) .
. this also applies to all tuples that are at
the same level of an expression tree:
eg, in h( f(a,b), g(c,d) ), a,b,c,d are co.runnable .
. a low-level way to compare
subprogramming with coprogramming,
is that while any call could be seen as
a new {process, cpu} activation,
in subprogramming, after making a call,
it agrees to stop working until that call is done .
. often we can find that a group of operations
are all handled by the same type mgt, [11.17:
-- in fact, that is the definition of "(operation):
a subprogram that is outputting
the same type that it's inputting -- ]
so even though they are nested
you can send the whle thing in one call,
and, in that case,
the type mgt will know what's co.runnable .
8.23: todo.adda/co/review parasail's design:
. the parasail lang was able to parallelize implicitly a lot .
(see also comments of this page).
adda/co/explicit concurrency control:
. the abstraction to use for explicit concurrency control
is having a particular cpu called like a function:
cpu#n(subprogram, inputs, outputs)
-- the inputs are a copy of everthing sent to it .
-- outputs are addresses to put results in .
. how is go.lang outputting?
when go.lang says go f(x)
they expect f to either call an outputter
or have x be an outputting channel .
. instead of saying cpu#n(...)
just say co f(x, out), or y`= co f(x) .
8.24: adda/co/syntax:
. there are 2 forms of the function co
according to whether co is synchronous or asynch:
# co(f,g,h) -- co with multiple arguments --
expects spawn and wait .
# co f -- co with just one argument --
just launches f asynchronously .
8.31: co.self/dream/adda/co:
. the dream was something about
"(ways of doing backup for concurrency or ...)
"( ... and now that we can do that,
we can do this ...) [dream recall is too fuzzy].
Labels:
adda,
asynchronous,
concurrency,
Parasail,
syntax
go vs python from the trenches 2012
8.22: news.adda/go vs python from the trenches 2012:
Graham King:
Graham King:
Would I be happy working with Go as mySteven (March 6, 2012 at 23:22)
main language? Yes, I would.
It’s a joy to work with,
and I got productive very fast.
Am I using it instead of Python
for all my new projects?
No, There are two reasons for that.
Firstly, it’s a very young language,
so library availability is limited
(for example, I need curses).
Second, well, Python is just so amazing.
[but] I see the benefit of static typing.
If I was still doing Java, or (heaven forbid) C++,
I would invest heavily in Go.
It was designed to replace them, and it does that well.
Go’s sweet spot is building servers.
(it makes concurrency safer and easier)
Other claimed benefits of Go over Python
are that it’s faster, and it’s “better at scale”.
For some things I’ve done
Python has been faster .
[and] The biggest difference [in speed]
is probably [just] in how well I write the code.
[also] nothing I do is CPU bound.
The “better at scale” argument doesn’t really apply
to building web apps with Django.
We scale by adding servers,
and [Django supports programming-in-the-large
with small self-contained ‘apps’ ]
You can get pretty close to a REPLwrite CPython extensions with Go:
[an interactive Read-Eval-Print Loop]
with goplay, [a web-based go compiler]
-- instead of interpreting, it compiles
[ go was designed for very fast compiling .]
Go is possible to daemonize.
You could use a sync.WaitGroup
to make main wait for any number of goroutines to exit .
But more directly, you can do the same thing by
adding this to the top of your program:
defer runtime.Goexit()
. goPy with gccgo .
Once the libraries and command-line tool are installed,
the "gopy" command-line tool
is generating the necessary C interface code;
and, then using gccgo will compile the code
into an extension module.
Labels:
adda,
concurrency,
GO,
python
walk and chew gum #Python
8.22: news.adda/python/co/walk and chew gum:
summary:
Google discourages Python for new projects?
[they encourage go.lang;
Python is said to need more resources?
I'm sure the problem is backwards compatibility .
. in the paper where they talked about Unladen Swallow
they mentioned wanting to remove the GIL
(the global interpreter lock for thread safety)
and this really surprised me coming from google staff,
because Python's project lead (another google staff)
has argued convincingly
that due to the language itself, [11.17:
ie, by being designed for interfacing C
(Jython and IronPython have no GIL)]
removing the GIL from CPython was impractical .
[11.17: at PyCon 2012, he adds:
which doesn't do much for encapsulation,
and therefore doesn't do much for thread safety
except to single-thread the interpreter .
. if you want something much like python
that also has good concurrency,
then google has given it to us in go.lang;
but, perhaps what he meant to say
is that it's like Intel's CISC architecture:
that was fundamentally slower than RISC;
but they virtualized it:
the machine instructions are converted
to RISC microcode .
. that's what big money could do for Python:
automatically find the inherent concurrency
and translate it to a threaded virtual machine .[11.17:
... but still interface flawlessly with
all C code on all platforms?
I'm no longer confident about that .]
[11.17: web:
. to overcome GIL limitation,
the parallel python SMP module;
runs python code in parallel
on both multicores and multiprocessors .
Doug Hellmann 2007 reviews it:
for the latest on Pythonic concurrency .]
8.22: news:
summary:
Google discourages Python for new projects?
[they encourage go.lang;
Python is said to need more resources?
I'm sure the problem is backwards compatibility .
. in the paper where they talked about Unladen Swallow
they mentioned wanting to remove the GIL
(the global interpreter lock for thread safety)
and this really surprised me coming from google staff,
because Python's project lead (another google staff)
has argued convincingly
that due to the language itself, [11.17:
ie, by being designed for interfacing C
(Jython and IronPython have no GIL)]
removing the GIL from CPython was impractical .
[11.17: at PyCon 2012, he adds:
Threading is for parallel IO.. Python has that old-style OOP,
Multiprocessing is for parallel computation.
The GIL does not hinder any of that.
... just because process creation in Windows
used to be slow as a dog, ...]
which doesn't do much for encapsulation,
and therefore doesn't do much for thread safety
except to single-thread the interpreter .
. if you want something much like python
that also has good concurrency,
then google has given it to us in go.lang;
but, perhaps what he meant to say
is that it's like Intel's CISC architecture:
that was fundamentally slower than RISC;
but they virtualized it:
the machine instructions are converted
to RISC microcode .
. that's what big money could do for Python:
automatically find the inherent concurrency
and translate it to a threaded virtual machine .[11.17:
... but still interface flawlessly with
all C code on all platforms?
I'm no longer confident about that .]
[11.17: web:
. to overcome GIL limitation,
the parallel python SMP module;
runs python code in parallel
on both multicores and multiprocessors .
Doug Hellmann 2007 reviews it:
. you need install your code only once:. see wiki.python.org/moin/Concurrency/
the code and data are both auto'distributed
from the central server to the worker nodes .
Jobs are started asynchronously,
and run in parallel on an available node.
The callable object that is
returned when the job is submitted
blocks until the response is ready,
so response sets can be computed
asynchronously, then merged synchronously.
Load distribution is transparent,
making it excellent for clustered environments.
Whereas Parallel Python is designed around
a “push” style distribution model,
the Processing package is set up to
create producer/consumer-style systems
where worker processes pull jobs from a queue .
Since the Processing package is almost a
drop-in replacement for the
standard library’s threading module,
many of your existing multi-threaded applications
can be converted to use processes
simply by changing a few import statements .
for the latest on Pythonic concurrency .]
8.22: news:
Labels:
adda,
concurrency,
dev.python,
GO,
GPGPU,
multithreading,
pypy
2012-11-15
task.type's syntax and semantics
adda/co:
8.16: syntax:
. when an object is given a message,
it is the object's type mgt that applies a method;
and, these type mgr's are tasks (co.programs);
but how do we get the obj's themselves
to be tasks? (ie, running code on a separate thread).
8.16: syntax:
. when an object is given a message,
it is the object's type mgt that applies a method;
and, these type mgr's are tasks (co.programs);
but how do we get the obj's themselves
to be tasks? (ie, running code on a separate thread).
Labels:
adda,
asynchronous,
concurrency,
multitasking,
Promise,
syntax,
type
2012-10-06
safe pointer details consider concurrency
8.4: adda/dstr/safe pointers/
space-efficiently pointing to both static type info and obj:
. we need to point at the symbol table index
not the obj itself, because,
only the symbol table index has the type tag
in the case when the type is static .
. as for space-efficiently doing this
at first I was worried about the
huge length of full paths
(process#, act'rec#, symbol table index);
but, [8.3:
just like urls have versions,
{fullpath(absolute), filename(relative addressing)},
pointers too should be available as
both long and short versions:
the full path is
(process#, act'rec#, symbol table index)
but if you are in the same act'rec,
you'd use a shorter version of the pointer:]
. if you are in the same activation record,
then the pointer is a mere 16bits:
(we assume here that a pointer needs a 3bit type tag,
and that the max# of symbols is 2^13 .
[8.21: 3bits?
. locally we need no tag at all,
because we just assume everthing is local;
otherwise, if it's a general pointer,
it will have the general type.tag arrangement
which usually means a static supertype,
and a dynamic on-board subtype,
which in the case of pointer needs 2 bits
for these 4 cases:
( internet address,
, local to system
, local to process
, local to act'rec ) .]
8.26: processID irrelevant:
. do we need to track the processID?
. any obj' we'd want to point at
is located within some act'rec;
so, isn't the act'recID enough?
8.28: 8.26:
. the act'rec obj' could have a subtype.tag
so that the same act'rec supertype
could represent all sorts of objects
like subprograms, coprograms, type mgt obj's, etc .
10.6:
. the main place to for finding out
how the current act'rec is related to a process
is by asking the task mgt who is
using this act'rec ID as a node index
into a tree of processes and their act'recs .
8.28: processID irrelevant despite pointers:
. when using pointers, the process ID matters;
because, we can give a pointer for assignments?
but that's not the problem of our pointer:
it has only to locate a target,
and it's up to exec to do the right thing .
. any time an assignment takes place
the target must be either a global obj,
(these are essentially act'recs because
they're made thread-safe by msg-taking functions)
or the owner had to have ordered the assignment
(that means either the owner is suspended for a subroutine
or the target is locked for a promised assign by an async).
8.26: processID fundamental?:
. we'd like to keep pointer sizes small,
so if we could know that an act'rec would
stay local to a particular process,
then we could possibly divide the number of act'recs
by the number of processes .
. we could say that each process has its own heap;
and, just as each act'rec has few symbol nodes,
a process has few act'recs,
so this is another form of subheap
the process subheap vs an actrec subheap .
8.28:
. unfortunately, given the use of recursion,
the number of act'recs per process can still be
arbitrarily large, so this would do nothing for
the size of an act'rec ID .
. the situation where process is fundamental
would be in systems with unprotected vars;
because, then process is a unit of thread safety:
anything can access any var within the process,
and then the process has only one thread .
. what we could have instead,
is a system where encapsulation and locks
are the basis of thread-safe computing:
. anything accessing a var must instead
ask that var's type mgt to do the accessing,
and then the type mgt has only one thread .
. a var lock gives sole ownership of a var
to another thread .
. in that sort of system,
a process is nothing more than an act'rec
that is run concurrently vs sequentially .
space-efficiently pointing to both static type info and obj:
. we need to point at the symbol table index
not the obj itself, because,
only the symbol table index has the type tag
in the case when the type is static .
. as for space-efficiently doing this
at first I was worried about the
huge length of full paths
(process#, act'rec#, symbol table index);
but, [8.3:
just like urls have versions,
{fullpath(absolute), filename(relative addressing)},
pointers too should be available as
both long and short versions:
the full path is
(process#, act'rec#, symbol table index)
but if you are in the same act'rec,
you'd use a shorter version of the pointer:]
. if you are in the same activation record,
then the pointer is a mere 16bits:
(we assume here that a pointer needs a 3bit type tag,
and that the max# of symbols is 2^13 .
[8.21: 3bits?
. locally we need no tag at all,
because we just assume everthing is local;
otherwise, if it's a general pointer,
it will have the general type.tag arrangement
which usually means a static supertype,
and a dynamic on-board subtype,
which in the case of pointer needs 2 bits
for these 4 cases:
( internet address,
, local to system
, local to process
, local to act'rec ) .]
8.26: processID irrelevant:
. do we need to track the processID?
. any obj' we'd want to point at
is located within some act'rec;
so, isn't the act'recID enough?
8.28: 8.26:
. the act'rec obj' could have a subtype.tag
so that the same act'rec supertype
could represent all sorts of objects
like subprograms, coprograms, type mgt obj's, etc .
10.6:
. the main place to for finding out
how the current act'rec is related to a process
is by asking the task mgt who is
using this act'rec ID as a node index
into a tree of processes and their act'recs .
8.28: processID irrelevant despite pointers:
. when using pointers, the process ID matters;
because, we can give a pointer for assignments?
but that's not the problem of our pointer:
it has only to locate a target,
and it's up to exec to do the right thing .
. any time an assignment takes place
the target must be either a global obj,
(these are essentially act'recs because
they're made thread-safe by msg-taking functions)
or the owner had to have ordered the assignment
(that means either the owner is suspended for a subroutine
or the target is locked for a promised assign by an async).
8.26: processID fundamental?:
. we'd like to keep pointer sizes small,
so if we could know that an act'rec would
stay local to a particular process,
then we could possibly divide the number of act'recs
by the number of processes .
. we could say that each process has its own heap;
and, just as each act'rec has few symbol nodes,
a process has few act'recs,
so this is another form of subheap
the process subheap vs an actrec subheap .
8.28:
. unfortunately, given the use of recursion,
the number of act'recs per process can still be
arbitrarily large, so this would do nothing for
the size of an act'rec ID .
. the situation where process is fundamental
would be in systems with unprotected vars;
because, then process is a unit of thread safety:
anything can access any var within the process,
and then the process has only one thread .
. what we could have instead,
is a system where encapsulation and locks
are the basis of thread-safe computing:
. anything accessing a var must instead
ask that var's type mgt to do the accessing,
and then the type mgt has only one thread .
. a var lock gives sole ownership of a var
to another thread .
. in that sort of system,
a process is nothing more than an act'rec
that is run concurrently vs sequentially .
Labels:
adda,
concurrency,
dstr,
safe pointers
2012-08-31
parasail is big win for reliable concurrency
12.7.2: news.adda/co/ParaSail
(Parallel Spec and Impl Lang) is by Ada's Tucker Taft:
first siting of parasail:
11/09/11 Language Lessons: Where New
Parallel Developments Fit Into Your Toolkit
(Parallel Spec and Impl Lang) is by Ada's Tucker Taft:
first siting of parasail:
11/09/11 Language Lessons: Where New
Parallel Developments Fit Into Your Toolkit
By John Moore for Intelligence In Software
The rise of multicore processors and programmable GPUs
has sparked a wave of developments in
parallel programming languages.
Developers seeking to exploit multicore and manycore systems
-- potentially thousands of processors --
now have more options at their disposal.
Parallel languages making moves of late
include the SEJITS of University of California, Berkeley;
The Khronos Group’s OpenCL;
the recently open-sourced Cilk Plus;
and the newly created ParaSail language.
Developers may encounter these languages directly,
though the wider community will most likely find them
embedded within higher-level languages.
. ParaSail incorporates formal methods such as
preconditions and post-conditions,
which are enforced by the compiler.
In another nod to secure, safety-critical systems,
Labels:
ada,
adda,
concurrency,
CUDA,
GPGPU,
HPCS,
mem'mgt,
microkernel,
multithreading,
Parasail,
preemptive,
safe pointers,
security,
supercomputing,
UHPC
2012-08-18
one call for trees of operations
7.22: addm/one call for trees of operations:
. the key to efficiency will be
providing support for integrated use of
both oop and concrete types;
ie, if the tree needs to be done fast
or in a tight space,
then the compiler uses native types;
but if it needs to handle polymorphism,
then it uses the type-tags,
and sends it to an oop type .
biop* oop:
*: (binary operations)
. the problem with the popular oop model
is that it is not helping much for biop's;
so, we should consider the binary parameter
to be one obj;
and, we again have oop working .
[8.13:
. this has always been implicit in my design;
biop oop works by featuring
2 type tags per arg: (supertype, subtype);
eg, (number, integer);
and then we don't have to worry about
where to send a (float, integer)
because they both have
the same supertype: number .
. this note was just pointing out
that I was realizing the syntax x`f -- vs f(x) --
was ok; whereas, previously
I had howled that oop was absurd because
it turned (x * y) into x`*(y)
as shorthand for asking x's type mgt
to apply the *-operation to (x,y);
what oop needs to be doing is (x,y)`*
as a shorthand for calling the type mgt that is
the nearest supertype shared by both x and y,
and asking it to apply the *-operation to (x,y).
8.15: and of coure,
oop langs like c++ need to get their own lang
and stop trying to fit within C,
so then we can go back to (x*y)
as a way to write (x,y)`* .]
. the key to efficiency will be
providing support for integrated use of
both oop and concrete types;
ie, if the tree needs to be done fast
or in a tight space,
then the compiler uses native types;
but if it needs to handle polymorphism,
then it uses the type-tags,
and sends it to an oop type .
biop* oop:
*: (binary operations)
. the problem with the popular oop model
is that it is not helping much for biop's;
so, we should consider the binary parameter
to be one obj;
and, we again have oop working .
[8.13:
. this has always been implicit in my design;
biop oop works by featuring
2 type tags per arg: (supertype, subtype);
eg, (number, integer);
and then we don't have to worry about
where to send a (float, integer)
because they both have
the same supertype: number .
. this note was just pointing out
that I was realizing the syntax x`f -- vs f(x) --
was ok; whereas, previously
I had howled that oop was absurd because
it turned (x * y) into x`*(y)
as shorthand for asking x's type mgt
to apply the *-operation to (x,y);
what oop needs to be doing is (x,y)`*
as a shorthand for calling the type mgt that is
the nearest supertype shared by both x and y,
and asking it to apply the *-operation to (x,y).
8.15: and of coure,
oop langs like c++ need to get their own lang
and stop trying to fit within C,
so then we can go back to (x*y)
as a way to write (x,y)`* .]
Labels:
addm,
asynchronous,
concurrency,
ipc,
Promise
signals
7.27: adda/cstr/signals:
7.30: intro:
. pyqt signals are a system of inter-object communication;
any object can emit a signal
to convey that some event has occurred;
and, any other object may connect a signal handler
to be launched whenever a particular object
raises a particular signal .
. signals can return any sort of record,
and the corresponding signal handlers
are expected to declare their parameter's type
to be the same type as the signal's returned record .
. pyqt sees signals as launching slots
and then the act of connecting a signal handler
is filling such a slot with a subprogram .
. there can be multiple connections to a slot,
so the slot is often filled with multiple handlers .
7.30: intro:
. pyqt signals are a system of inter-object communication;
any object can emit a signal
to convey that some event has occurred;
and, any other object may connect a signal handler
to be launched whenever a particular object
raises a particular signal .
. signals can return any sort of record,
and the corresponding signal handlers
are expected to declare their parameter's type
to be the same type as the signal's returned record .
. pyqt sees signals as launching slots
and then the act of connecting a signal handler
is filling such a slot with a subprogram .
. there can be multiple connections to a slot,
so the slot is often filled with multiple handlers .
Labels:
adda,
concurrency,
cstr,
ipc,
notifications,
oop,
signals
Subscribe to:
Posts (Atom)