| Author |
Message |
Jan Vorbrüggen
Guest
|
 Posted:
Thu Sep 15, 2005 4:13 pm Post subject:
Re: Not enough parallelism in programming |
|
|
| Quote: | So people say "that's a programmer error - you aren't supposed to try
to execute in parallel two pieces of code that might overlap and
hence not be parallelizable."
1) that's true, you are not supposed to
2) it would be nice if there were an automatic way
of detecting such violations of parallelizability
- whether compile time or run time.
|
See occam2's usage and alias checker.
| Quote: | But say that the Object1 and Object2 classes have been instrumented
to do something like record into a logfile. Or maybe update some counter.
|
That's not allowed.
| Quote: | John Jakson may object that this happens only because of aliasing
through pointers. Yes, that's true. And since pointers are such
an important part of modern programming, it's pointless to create
a system that doesn't work with linked datastructures.
|
- Items such as F95's et seq. ALLOCATABLE variables obviate the need
for many instances of "traditional" pointers.
- It is really only linked lists and similar data structures that need
pointers. In such cases, you need synchronized access to the shared
data structure in some way or other. The important point is that this
is implemented in an (instance of an) object that is outside of your
parallel construct (running in parallel, possibly, but only one instance
being active at any one time), thus making sure that any synch proper-
ties are being properly implemented.
- Thus, all the compiler needs to check is that the formal arguments to
the objects being run in parallel do not overlap, and you are GO for
PAR.
Jan |
|
| Back to top |
|
 |
Andy Freeman
Guest
|
| Posted:
Thu Sep 15, 2005 4:15 pm Post subject:
Re: Not enough parallelism in programming |
|
|
Jan Vorbrüggen wrote:
| Quote: | Suppose that I have a data structure with two non-overlapping pieces A
and B where any update to one piece requires an update to the other.
If one updater updates A then B while another updates B then A you'll get
into trouble. In fact, if they both read and write A then read and
write B you'll get into trouble.
Nope. Both A and B will be OUT or INOUT parameters to both instances, and
the usage checker will complain that they aren't disjoint.
|
Who said anything about parameters?
In the "fails with just A" case, parameters can't help. x.R(A);
x.W(A);
y.R(A); y.W(A) can be executed that way or y.R(A); y.W(A); x.R(A);
x.W(A)
but not x.R(A), y.R(A); x.W(A); y.W(A). (In this case, the problem
comes
up if the system can decide to run two readers concurrently.) |
|
| Back to top |
|
|
Jan Vorbrüggen
Guest
|
| Posted:
Thu Sep 15, 2005 4:15 pm Post subject:
Re: Not enough parallelism in programming |
|
|
| Quote: | In the "fails with just A" case, parameters can't help. x.R(A);
x.W(A); y.R(A); y.W(A) can be executed that way or y.R(A); y.W(A); x.R(A);
x.W(A) but not x.R(A), y.R(A); x.W(A); y.W(A). (In this case, the problem
comes up if the system can decide to run two readers concurrently.)
|
If one of the parallel processes in an occam2 PAR writes to a variable,
no other process is allowed to reference it. Multiple readers are allowed.
Multiple instantions of the same procedure count seperately, of course.
Restrictive? Yes, but the only way to guarantee that things work properly.
Jan |
|
| Back to top |
|
|
JJ
Guest
|
| Posted:
Thu Sep 15, 2005 4:15 pm Post subject:
Re: Not enough parallelism in programming |
|
|
Andy Glew wrote:
| Quote: | Elaborating on my previous posts: I want somebody to define a parallel
or concurrent language where the meaning of not only the simple
statements such as are defined:
|
I will come back to this later after the cpa2005 conference.
Of the 25 or so odd papers I and another paper from U of CA propose a
Verilog + C hybrid, I want to see where these researchers are going
before I say anything. Most folks here won't know what Verilog or RTL
is all about or will take the time the time to look but VHDL might be
better known. Same is somewhat true for occam but a few here do know
that but occam is treated as a dead language dragged up by tired old
ranters like me and Rupert.
Now combine the set of people that can talk of Verilog and occam, you
are down to 2 I know of and others who never come here. Switch to VHDL
I drop out and others might drop in.
The real question is what is an object.
Many years ago I had the pleasure and time to write a full custom VLSI
layout editor for the Mac, I wanted this to do VLSI layout ofcourse, I
couldn't afford the Calma type stuff. I learned all about Event driven
programming, and later C++ OO came along. I am so glad I did this on
the Mac before OO came otherwise I suspect the whole thing might have
been a monster.
This full blown VLSI editer (used on a no of real fabbed chips) took up
a whopping 37KBytes. Today if I fire up an MFC or other framework and
auto build a template GUI program with zero content, I start at 400K
for bloody nothing.
One can see why SW is in a mess when nothing is 10x bigger than a
finnished product. Even interpreted on Windows under Basilisk, it rocks
way more than the original 68K it was written for.
Later I learnt Verilog, I was a bit sad to see the schematic appoach to
VLSI go away, but the synthesis justifies it, otherwise I might still
be hacking manual shift driven EDA SW.
Recently for this Transputer project that is supposed to run a hybrid
Verilog C occam subset I was thinking about how a GUI OS like say BeOS
would be written for it. Well any respectable SW engineer would say C++
right away and indeed BeOS API is a nice looking C++ kit while MFC is a
stinkin...
I actually think now that if GUIs use real world hardware models of
widgets like buttons (1,0), sliders (1.0--0.0), and a myriad of other
widget types, I can see the natural way to do that would be with
Verilog for all the event driven stuff and C for the lower level stuff.
module menuBar(in mouseUpDOwn, in mouseXY, out startPaneDownTrack..)
always @(mouseUpDOwn) {
// start
}
I am still getting my arms around this one, clearly C and occam can fit
in here too. Some will suggest occam !? PAR ALT framework copuld build
a GUI too, but GUIs are all about
..
I can see a set of modules instanced in a hierarchy as any chip would
be, but the signals connecting them up are as live as one can get, they
are real event driven wires carrying 1,0,z,x values or possibly objects
too. Verilog doesn't have the object idea just raw wire types.
The natural way to draw the GUI app would be with something that looks
remarkably like a VLSI editor too, attaching (instancing widgets) to
parent cells (panes) and so on. What needs to be added to the VLSI
editer are more object types besides boxes, polygons, such as pixmaps
and live signals.
I am reminded of Electric tools that had live VLSI editing, ie the
signals could be active while working with it.
The funny thing is that due to synthesis all research in VLSI graphics
except P/R is dead, no more schematics. While the SW crowd keeps
reiventing schematics with a sense of liveness.
Now put a bunch of people with vastly different backgrounds like that
in a company and crazy things pop out like occam and a Transputer.
talk later on specific points you make.
johnjakson at usa dot ..
transputer2 at yahoo |
|
| Back to top |
|
|
Jan Vorbrüggen
Guest
|
| Posted:
Thu Sep 15, 2005 4:15 pm Post subject:
Re: Not enough parallelism in programming |
|
|
| Quote: | Suppose that I have a data structure with two non-overlapping pieces A
and B where any update to one piece requires an update to the other.
If one updater updates A then B while another updates B then A you'll get
into trouble. In fact, if they both read and write A then read and
write B you'll get into trouble.
|
Nope. Both A and B will be OUT or INOUT parameters to both instances, and
the usage checker will complain that they aren't disjoint.
This really is nothing but a mechanized checker for Fortran 66 et seq.
actual arguments being according to the standard (with the little niggle
that until F90, the programmer had no way to express the intent of a
dummy argument).
Jan |
|
| Back to top |
|
|
Andy Freeman
Guest
|
| Posted:
Thu Sep 15, 2005 4:15 pm Post subject:
Re: Not enough parallelism in programming |
|
|
Jan Vorbrüggen wrote:
| Quote: | - Thus, all the compiler needs to check is that the formal arguments to
the objects being run in parallel do not overlap, and you are GO for
PAR.
|
Nope.
Suppose that I have a data structure with two non-overlapping pieces A
and B where any update to one piece requires an update to the other.
If
one updater updates A then B while another updates B then A you'll get
into trouble. In fact, if they both read and write A then read and
write
B you'll get into trouble.
Hmm. Separate reads and writes on one piece of data can let you get
into
trouble with the above rule. |
|
| Back to top |
|
|
Joe Seigh
Guest
|
| Posted:
Thu Sep 15, 2005 9:25 pm Post subject:
Re: Not enough parallelism in programming |
|
|
JJ wrote:
| Quote: |
I actually think now that if GUIs use real world hardware models of
widgets like buttons (1,0), sliders (1.0--0.0), and a myriad of other
widget types, I can see the natural way to do that would be with
Verilog for all the event driven stuff and C for the lower level stuff.
|
Real world hardware doesn't do things like resize itself on the fly.
Now think of situations such as a panel resizing itself while mouse
events are being generated concurrently with instantlly obsolete
mouse coordinate values. Not a problem as long as the hardware
is so fast you have virtually no latency and thus no need for
event/message queueing. Otherwise you have an interesting problem.
--
Joe Seigh
When you get lemons, you make lemonade.
When you get hardware, you make software. |
|
| Back to top |
|
|
JJ
Guest
|
| Posted:
Thu Sep 15, 2005 11:38 pm Post subject:
Re: Not enough parallelism in programming |
|
|
Joe Seigh wrote:
| Quote: | JJ wrote:
I actually think now that if GUIs use real world hardware models of
widgets like buttons (1,0), sliders (1.0--0.0), and a myriad of other
widget types, I can see the natural way to do that would be with
Verilog for all the event driven stuff and C for the lower level stuff.
Real world hardware doesn't do things like resize itself on the fly.
Now think of situations such as a panel resizing itself while mouse
events are being generated concurrently with instantlly obsolete
mouse coordinate values. Not a problem as long as the hardware
is so fast you have virtually no latency and thus no need for
event/message queueing. Otherwise you have an interesting problem.
--
|
Yes that is where it gets interesting, who says hardware doesn't change
shape?.
Um Verilog and other HDLs use an event wheel that is very similar in
principle to the GUI event manager, only several orders larger in scope
and designed usually to handle static lists of nano processes, a
special form of coroutining. Not even very differnet from an occam
scheduler.
What does hardware speed have to do with it, an 8MHz 68K Mac was
perfectly able to handle normal GUI events, it juat had no grunt power
to fill in the gaps with any real compute workload and worse had no
memory protection or process model.
It makes no difference if the events are described with a Pascal/C, or
C++ framework with simulated event wheel or Verilog with mostly hidden
simulated event wheel. The latter does allow that an entire hierarchy
of GUI widgets that describe a program look and feel can be described
by drawing out in a schematic form the old fashioned way (or edited as
language the new old new fashioned way) with real wires connecting
signals. We see this getting reinvented all the time. When I see the
GUI constructor kits, and then have to go in an fill methods and so on,
its just noise. Schematics with built in simulation already have this
live signal cabling.
Now Verilog lacks data abstractions but it does have its own
Pascally/ADAish looking Functions and Tasks used by the verification
folks.
Par HDLs really needs protected objects the same way seq languages do,
ie objID:array[index] where array can only be accessed by specifying
default or particular objIDs. When you have that supported in hardware
along with pervasive concurrency, HW & SW languages will become alot
more similar.
johnjakson at usa .. |
|
| Back to top |
|
|
JJ
Guest
|
| Posted:
Fri Sep 16, 2005 12:15 am Post subject:
Re: Not enough parallelism in programming |
|
|
David C. DiNucci wrote:
| Quote: | Andy Glew wrote:
Elaborating on my previous posts: I want somebody to define a parallel
or concurrent language where the meaning of not only the simple
statements such as are defined:
|
snipping
| Quote: | A bigger problem for parallel software engineering lies in hiding
behavior/timing. For example, I can ask two programmers to implement a
module that takes value on two ports, A and B, and produces a result on
port C that is their sum and one on D which is their difference (A-B).
Even if both programmers implement the module to this spec, with no
funny side effects or access to global info, one might work in my app
and one might not solely due to the order in which they read their
inputs from ports A and B and/or produce their results. Adding this
sort of info to the spec (e.g. in temporal logic) can get very complex
|
If you ask a hardware EE in Verilog (or VHDL) the precise answer is
assign
c = a+b, d = a-b;
Do not read this as C , exprn but as 2 continuous processes that will
follow any change at all on any bits of a,b even if 1,0,?,x bit value
changes. Not only that, but a,b,c,d can be any width upto 16M bits in
most implementations.
Further a delay can be included that also follows patterns such as 1->0
outputs take a delay and a different one for other transitions.
Also assume the EE has some knowledge of the timing of a,b and hence
c,d, they may be coming from unknown timing which is considered very
bad. Usually they are registered or were recently and follow some
combinatorial logic with delays.
Trying to model this in occam and I suspect in most any SW par language
is just doomed to reinvent only partially what timing accurate HDLS
already have.
Now when I do this in C, to be cheap & fast, the code looks exactly the
same but presumes that a,b are atatic and also only binary, so c,d get
reavualated whenever a,b might have or did change with in a group
change. The more precise the knowledge of the changing, the slower the
simulation will usually be. Most of the time these continuous
assignments appear between the always @(posedge clock) to copy signals
into DFlops which then drive another set of assigns.
An always @() block driving a set of assigns ,,; forms a pipeline
stage.
Such pipelines can be completely arbitrarily partitioned across any
hierarchy and have the same meaning. IE the hierarchy is smashed 1st
and the analysis is done on the whole flattend source tree (which might
be very large indeed).
The Lisp saying often repeated is that .<plz fill in>. doomed to
reinvent Lisp.
One might conclude the software world is busily doing the same thing
with concurrency reinventing something the hardware people have had for
maybe 40-50yrs in simulation. Not that HDLs are of much use yet to seq
coders.
johnjakson at usa dot.. |
|
| Back to top |
|
|
Hank Oredson
Guest
|
| Posted:
Fri Sep 16, 2005 12:15 am Post subject:
Re: Not enough parallelism in programming |
|
|
"JJ" <johnjakson@yahoo.com> wrote in message
news:1126799381.928038.11370@o13g2000cwo.googlegroups.com...
| Quote: |
Andy Glew wrote:
Elaborating on my previous posts: I want somebody to define a parallel
or concurrent language where the meaning of not only the simple
statements such as are defined:
I will come back to this later after the cpa2005 conference.
Of the 25 or so odd papers I and another paper from U of CA propose a
Verilog + C hybrid, I want to see where these researchers are going
before I say anything. Most folks here won't know what Verilog or RTL
is all about or will take the time the time to look but VHDL might be
better known. Same is somewhat true for occam but a few here do know
that but occam is treated as a dead language dragged up by tired old
ranters like me and Rupert.
Now combine the set of people that can talk of Verilog and occam, you
are down to 2 I know of and others who never come here. Switch to VHDL
I drop out and others might drop in.
The real question is what is an object.
Many years ago I had the pleasure and time to write a full custom VLSI
layout editor for the Mac, I wanted this to do VLSI layout ofcourse, I
couldn't afford the Calma type stuff. I learned all about Event driven
programming, and later C++ OO came along. I am so glad I did this on
the Mac before OO came otherwise I suspect the whole thing might have
been a monster.
This full blown VLSI editer (used on a no of real fabbed chips) took up
a whopping 37KBytes. Today if I fire up an MFC or other framework and
auto build a template GUI program with zero content, I start at 400K
for bloody nothing.
|
Something wrong here. I do some simple GUI stuff using MFC
and my usual template "Hello world Click OK to exit" is just a
tad over 30k, and my telenet client is a whopping 40k.
| Quote: | One can see why SW is in a mess when nothing is 10x bigger than a
finnished product. Even interpreted on Windows under Basilisk, it rocks
way more than the original 68K it was written for.
Later I learnt Verilog, I was a bit sad to see the schematic appoach to
VLSI go away, but the synthesis justifies it, otherwise I might still
be hacking manual shift driven EDA SW.
Recently for this Transputer project that is supposed to run a hybrid
Verilog C occam subset I was thinking about how a GUI OS like say BeOS
would be written for it. Well any respectable SW engineer would say C++
right away and indeed BeOS API is a nice looking C++ kit while MFC is a
stinkin...
I actually think now that if GUIs use real world hardware models of
widgets like buttons (1,0), sliders (1.0--0.0), and a myriad of other
widget types, I can see the natural way to do that would be with
Verilog for all the event driven stuff and C for the lower level stuff.
module menuBar(in mouseUpDOwn, in mouseXY, out startPaneDownTrack..)
always @(mouseUpDOwn) {
// start
}
I am still getting my arms around this one, clearly C and occam can fit
in here too. Some will suggest occam !? PAR ALT framework copuld build
a GUI too, but GUIs are all about
.
I can see a set of modules instanced in a hierarchy as any chip would
be, but the signals connecting them up are as live as one can get, they
are real event driven wires carrying 1,0,z,x values or possibly objects
too. Verilog doesn't have the object idea just raw wire types.
The natural way to draw the GUI app would be with something that looks
remarkably like a VLSI editor too, attaching (instancing widgets) to
parent cells (panes) and so on. What needs to be added to the VLSI
editer are more object types besides boxes, polygons, such as pixmaps
and live signals.
I am reminded of Electric tools that had live VLSI editing, ie the
signals could be active while working with it.
The funny thing is that due to synthesis all research in VLSI graphics
except P/R is dead, no more schematics. While the SW crowd keeps
reiventing schematics with a sense of liveness.
Now put a bunch of people with vastly different backgrounds like that
in a company and crazy things pop out like occam and a Transputer.
talk later on specific points you make.
|
--
... Hank
http://home.earthlink.net/~horedson
http://home.earthlink.net/~w0rli |
|
| Back to top |
|
|
David C. DiNucci
Guest
|
| Posted:
Fri Sep 16, 2005 12:15 am Post subject:
Re: Not enough parallelism in programming |
|
|
Andy Glew wrote:
| Quote: | Elaborating on my previous posts: I want somebody to define a parallel
or concurrent language where the meaning of not only the simple
statements such as are defined:
pre.nxt := insertee,
insertee.nxt := pre.nxt,
insertee.prev := pre,
pre.nxt.prev := insertee;
But where there is also a consistent definition of what it means to
say the concurrent statement:
obj1.method1(), obj2.method2();
|
Consistent in what sense? There are plenty of "parallel-aware"
languages that define what happens when two methods execute in parallel.
If by "consistent" you mean "sequentially consistent" or
"deterministic", in many cases that is not desirable. "Desirable" can
only be defined by the programmer and the user, so what is important is
that the outcome is defined well enough that the programmer and user can
agree on what it will/should do. That usually means satisfying some
invariant. The utility of various languages is often in how much they
facilitate the specification and verification of such invariants.
| Quote: | Plus, I'd like there to be defined efficient ways of computing such
parallel statements, on both parallel and uniprocessor machines.
|
That really comes down to the platform knowing enough about how and
where and when data is being used that it can be where it is needed next
before it is needed there, or as soon thereafter as possible. Whether
that how/where/when information comes from static dataflow analysis or
from user declarations is relatively unimportant. What is important is
that the programmer or user isn't tasked with saying how to get the data
to where it is needed (as with existing shared memory or message-passing
tools), or with overspecifying the order in which independent data
accesses occur (as is done with existing sequential languages). That
way, on uniprocessor machines, it can all be sequentialized without data
being copied around or locked needlessly, and on parallel machines, the
appropriate communication and synchronization can be used while using
using advantageous orderings.
| Quote: | What's so hard about
obj1.method1(), obj2.method2();
?
Mainly, in any reasonable language such as C++ or Java, obj1 may
contain a reference to obj2, or vice versa. Or, if not a direct
reference, obj1 and obj2 may refer to linked data structures that
overlap.
So people say "that's a programmer error - you aren't supposed to try
to execute in parallel two pieces of code that might overlap and
hence not be parallelizable."
|
The only people who can say whether the result is an error or not are
the programmer and the user, in the context of the programming model. If
the programming model doesn't provide any hint of what the result will
be, then it is unlikely that the programmer and user will agree that
it's OK, so it may feel universally like an error, but if the model does
define it, you don't have enough info to call it an error.
| Quote: | If the parallel language or system cannot handle something
like
obj1.method1(), obj2.method2();
then it cannot handle the simplest possible concepts of modern
object oriented languages.
Most of the time, even the programmer doesn't know whether ob1 and
obj2 overlap. Sure, they may not seem to... overlapping may not seem
to be an important aspect. E.g. they may be non-overlapping linked
lists.
But say that the Object1 and Object2 classes have been instrumented
to do something like record into a logfile. Or maybe update some counter.
Then they are not independent, but the cross-dependence is invisible to
the programmer who writes
obj1.method1(), obj2.method2();
It is visible only to the guys who implemented the classes, or the
language system.
|
If it is necessary to pass a reference to the logfile or counter to
these objects in order for the objects to access it, then the call chain
can be traversed to find that the same data is being passed into both.
If that (reference to that) logfile or counter is hidden within other
objects being passed to both obj1.method1() and obj2.method2, then the
immediate caller may not know, but so what? There is no need for the
caller to know as long as the caller is getting what it expects out of
the object.
| Quote: |
I conclude that THERE IS NO SUCH THING AS PARALLEL SEMANTICS
that obeys one of the most basic principles of software engineering:
data hiding or modularity.
|
A bigger problem for parallel software engineering lies in hiding
behavior/timing. For example, I can ask two programmers to implement a
module that takes value on two ports, A and B, and produces a result on
port C that is their sum and one on D which is their difference (A-B).
Even if both programmers implement the module to this spec, with no
funny side effects or access to global info, one might work in my app
and one might not solely due to the order in which they read their
inputs from ports A and B and/or produce their results. Adding this
sort of info to the spec (e.g. in temporal logic) can get very complex
and error prone. I have wondered, in my ScalPL work, whether it's
actually more convenient for the user and programmer to communicate the
behavior in terms of a partial implementation than a spec in something
like temporal logic. In other words, maybe it's OK for the user to take
a peek under the covers as long as they can't see too much. This would
only seem to work if you put behavioral layers (which you want them to
see) above transformational layers (which you don't), as ScalPL tends to
do (strategies above tasks).
| Quote: | The simple parallel statement
pre.nxt := insertee,
insertee.nxt := pre.nxt,
insertee.prev := pre,
pre.nxt.prev := insertee;
works only because potential overlaps between the data
structures are visible to the compiler.
obj1.method1(), obj2.method2();
doesn't work because the overlaps are invisible
- and MUST be inivisible for data hiding.
What about making the parallelism, the full list of data structures
modified, part of the definition of the function. Sure... but then
making some simple modifications to a class, like instrumenting it,
require changing the programs that use it. Not acceptable.
|
That's a big jump. Just as information can be hidden within the object
being called, it can also be hidden within objects that are passed to
its methods/functions as arguments. The caller of the function/method
doesn't need to (and often does not want to) know what is in those
argument objects.
| Quote: | I.e. I conclude that the parallel
statement1, statement2;
with desired semantics "statement1 is completely independent
of statement2 and can be run in parallel"
is not useful, if software modularity is also desired.
|
I completely agree that it is wrong-headed to make it the user's
responsibility to determine whether two things should be *allowed to* be
initiated in parallel. A better way is to simply provide semantics for
what things will do when they run in parallel, whether they share
resources or not.
| Quote: | The first thing that I am looking for is a language definition
that gives meaning to a statement such as
obj1.method1(), obj2.method2();
Sequential semantics does.
Speculative parallelization does, but that's really just an implementation
of sequential semantics.
Transactional might try to do both in parallel, and, failing that, do
first one and then the other. In some way that is "semantic": it says
that we can't rely on the order, but it will be as if one was done
first, then the other. Non-deterministic.
I wonder if there are definitions that are not quite so all or nothing
as transactions.
|
Of course. You're referring to atomic transactions. Non-atomic
transactions can be built of atomic ones. The non-atomic ones will lose
their serializability properties (i.e. your "as if one was done first,
then the other"), but there are other ways of reasoning that don't
require the overall transactions to be serializable in order to ensure
that important invariants are still preserved during their concurrent
execution.
| Quote: | Myrias has a consistent, deterministic, semantic: both are done in
parallel, and then the writes are merged in some prioritization,
possibly at byte granularity. It is not clear to me that the Myrias
behavior is useful: merging on a byte by byte basis might corrupt some
data structures. I wonder for what cases it would be correct.
|
I see no reason to believe that this approach would be highly fruitful,
though there are lots of examples in database and version control
systems where multiple users are allowed to update concurrently (e.g.
after checkout) and re-integration is attempted later, often using
"diffs". Without invariants referring to the data structure, it would
be hard/impossible to ensure sequential consistency--i.e. even if
updates don't overlap, the writes of one might have been different if
they depended on writes in the other and vice versa.
-Dave |
|
| Back to top |
|
|
JJ
Guest
|
| Posted:
Fri Sep 16, 2005 12:15 am Post subject:
Re: Not enough parallelism in programming |
|
|
Hank Oredson wrote:
| Quote: | "JJ" <johnjakson@yahoo.com> wrote in message
news:1126799381.928038.11370@o13g2000cwo.googlegroups.com...
|
snipping
| Quote: |
This full blown VLSI editer (used on a no of real fabbed chips) took up
a whopping 37KBytes. Today if I fire up an MFC or other framework and
auto build a template GUI program with zero content, I start at 400K
for bloody nothing.
Something wrong here. I do some simple GUI stuff using MFC
and my usual template "Hello world Click OK to exit" is just a
tad over 30k, and my telenet client is a whopping 40k.
|
I was playing with an old Metrowerks CodeWarrior on Windows, almost all
the MFC templates give 440K+ and the plain old Win32 templates give
around 40K.
I have seen it before in other setups esp on cross platform ones but
didn't check VC6 to see what it does either way MFC/Win not that I plan
on doing any gui apps. I do like to use the old Mac ported to Win apps
since they often play nice with the user and just drag install, often
very consise.
johnjakson at usa .. |
|
| Back to top |
|
|
Hank Oredson
Guest
|
| Posted:
Fri Sep 16, 2005 8:15 am Post subject:
Re: Not enough parallelism in programming |
|
|
"JJ" <johnjakson@yahoo.com> wrote in message
news:1126816806.359507.50100@z14g2000cwz.googlegroups.com...
| Quote: |
Hank Oredson wrote:
"JJ" <johnjakson@yahoo.com> wrote in message
news:1126799381.928038.11370@o13g2000cwo.googlegroups.com...
snipping
This full blown VLSI editer (used on a no of real fabbed chips) took up
a whopping 37KBytes. Today if I fire up an MFC or other framework and
auto build a template GUI program with zero content, I start at 400K
for bloody nothing.
Something wrong here. I do some simple GUI stuff using MFC
and my usual template "Hello world Click OK to exit" is just a
tad over 30k, and my telenet client is a whopping 40k.
I was playing with an old Metrowerks CodeWarrior on Windows, almost all
the MFC templates give 440K+ and the plain old Win32 templates give
around 40K.
I have seen it before in other setups esp on cross platform ones but
didn't check VC6 to see what it does either way MFC/Win not that I plan
on doing any gui apps. I do like to use the old Mac ported to Win apps
since they often play nice with the user and just drag install, often
very consise.
|
Very interesting. The telnet client was a quick hack since
I wanted one with some special features. Was a bit surprised
it came in at 40k. So perhaps this is a CodeWarrior issue.
I used the native VC6 IDE, and did specify shared libraries.
--
... Hank
http://home.earthlink.net/~horedson
http://home.earthlink.net/~w0rli |
|
| Back to top |
|
|
David C. DiNucci
Guest
|
| Posted:
Fri Sep 16, 2005 2:19 pm Post subject:
Re: Not enough parallelism in programming |
|
|
JJ wrote:
| Quote: | David C. DiNucci wrote:
A bigger problem for parallel software engineering lies in hiding
behavior/timing. For example, I can ask two programmers to implement a
module that takes value on two ports, A and B, and produces a result on
port C that is their sum and one on D which is their difference (A-B).
Even if both programmers implement the module to this spec, with no
funny side effects or access to global info, one might work in my app
and one might not solely due to the order in which they read their
inputs from ports A and B and/or produce their results. Adding this
sort of info to the spec (e.g. in temporal logic) can get very complex
If you ask a hardware EE in Verilog (or VHDL) the precise answer is
assign
c = a+b, d = a-b;
snip
Trying to model this in occam and I suspect in most any SW par language
is just doomed to reinvent only partially what timing accurate HDLS
already have.
|
But there's a reason for that. SW languages don't want or need the
majority of what's in timing accurate HDLS--especially the notion of a
clock.
| Quote: | Now when I do this in C, to be cheap & fast, the code looks exactly the
same but presumes that a,b are atatic and also only binary,
|
Pretty valid presumptions in my book.
| Quote: | so c,d get
reavualated whenever a,b might have or did change with in a group
change.
|
I don't know how you came to that conclusion. It depends completely on
the context in which those statements are written.
snip
| Quote: | One might conclude the software world is busily doing the same thing
with concurrency reinventing something the hardware people have had for
maybe 40-50yrs in simulation. Not that HDLs are of much use yet to seq
coders.
|
Nor to parallel coders, I would conclude.
Note that I was certainly not saying that it was impossible, or even
difficult, to more carefully specify the problem above, or to code the
solution in existing parallel languages, such that there wouldn't be any
problem. It was meant just to illustrate that with only a specification
based on inputs and outputs and not on relative timings, it can lead to
a problem in software languages, just as it could in an HDL. For more
info, google "Brock-Ackerman Anomaly".
I'm pretty certain we tossed this "HDL as parallel programming language"
notion around quite a bit in The Thread That Would Not Die some time ago
(2 years?). I didn't believe it then, and I still don't.
-Dave |
|
| Back to top |
|
|
Andy Freeman
Guest
|
| Posted:
Fri Sep 16, 2005 4:15 pm Post subject:
Re: Not enough parallelism in programming |
|
|
| Quote: | If one of the parallel processes in an occam2 PAR writes to a variable,
no other process is allowed to reference it. Multiple readers are allowed.
Multiple instantions of the same procedure count seperately, of course.
Restrictive? Yes, but the only way to guarantee that things work properly.
|
It's not the only way, but it is sufficient. (It actually just moves
the
bugs to process interaction, which programmers can't do correctly
either.)
And, it means that that creating large structures is unnecessarily
slow,
leading to programs that use buggy aggregates of small structures to
simulate large ones. |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in