Board index » delphi » Simulating a (massively) concurrent programming environment

2007-09-21 02:32:13 PM
delphi78
The day is coming soon when servers with 64 to 256 cores will be
common-place. However, I doubt our development machines will be so
well-endowed. Wouldn't it be great to be able to program with a simulation
of a "massively" concurrent environment?
Who's got ideas on how to make that happen?
Perhaps we could deploy to our new "Concurrent Environment De{*word*81}" that
runs the simulation...
Talk amongst yourselves!
-d
 

"Dennis Landi" writes:
well-endowed. ;-)
 

Dennis Landi writes:
processing -- we shall see.
We need a fast solution for processing magnetic field data. Now if
Delphi had Complex numbers (a + ib) and parallel processing -- then it
would be ideal!
--
Will R
PMC Consulting
 

Dennis Landi writes:
create this effect.
Actually on that note, that is something that would be a nice addition
to Delphi. Some sort of compiler / VCL support for multi machine
environments (server farms).
--
Dean
 

"WillR" <willrNo.Spam.pmccl.noSpam.com>writes
compiler in my application and it does make a difference. This being said,
the generated code is not always suitable for non-Intel based systems (hence
I use Microsoft's C++ compiler for those systems). I wish I could use
CodeGear's C++ compiler, but... yes, you got it: it generates *very*
inefficient code. At least, I use Delphi for the frontend... :)
Alan.
 

processing package with good complex number support. it is based on the Intel
ipp and mkl libraries. I highly recommend it.
Dan Sox
 

Dennis Landi writes:
different environment than your CPU, but it /is/ hugely multi-core.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
All the great TeamB service you've come to expect plus (New!)
Irish Tin Whistle tips: learningtowhistle.blogspot.com
 

Dennis Landi writes:
Just a random thought, VMWare with an emulation layer wedged in between?
--
 

"Marco Caspers" <XXXX@XXXXX.COM>writes
-d
 

But this is missing the point of general concurrency, which means that a
unit of computing power can be grabbed and organized no matter where it's
living - on the same machine, or another machine in the same room, or on the
other side of the world. Erlang is already attempting to address this, which
brings up an obvious thorn: we think that if the problem can not be properly
framed in Delphi, then it hasn't been addressed in general yet. I think
we've got to come to grips with the possibility that all the popular
language efforts (C#, Delphi, Java) will end up being intellectual deadends
for computing challenges in the future. How these challenges will change the
programming tools we use is actually pretty exciting when you think about
it.
James
 

Dennis Landi writes:
framework classes in this programming tip:
www.folding-hyperspace.com/program_tip_15.htm
The VCL AnsiString is just such a class, so be careful how you use it
between threads.
Considering that my test case program can run for hours or days without
any problems on some systems and not others says that any simulation of
a highly concurrent system is never going to answer the question: is my
code free of concurrency bugs?
The whole key to making the test case crash is for a dual core machine
to execute the error sequences at exactly the right time and order. If
part of the sequence doesn't happen very often, then the crash frequency
will be very low. Having more threads running and interacting, as on 64
or 256 core processors, should increase the crash frequency, but the
laws of statistics don't always behave the way we want them to.
Depending on OS API calls and other factors, threads can become
synchronized and may not execute statistically in a way that will crash
often.
I don't really think such a "Concurrent Environment De{*word*81}" running on
a low core count processor will actually be possible. You need the real
cores running code on real hardware to simulate the conditions that can
cause these problems. For example, it should be fairly easy to prove
that a single core processor could never simulate some types of
concurrency problems that occur on dual cores. I wouldn't want to try to
prove this right now, but the fact that some programs work well on
single cores but not multiple cores seems to point in that direction.
My simple example code is not really this type of problem as it will
fail on a single core. I am thinking about some of the more complex
problems that occur inside kernels where spin locks are used that really
require multiple cores to show up errors.
James
 

"James Gibbons" <"james at ventek-inc.com">writes
Thanks for the message.
Its seems like your are trying to frame the problem as "How do I write a
de{*word*81} that will trap all error conditions".
Correct me if I am wrong.
Whereas, Perhaps framing the problem differently would be helpful:
"Let us assume errors will occurs in a Concurrent Environment. Let us
predict what these types of errors will be, and then build a framework to
handle them without crashing the system".
And then in a SIMULATION environment, we actually simulate the error
conditions (the root cause does not have to be "real" just real to the code
excecuting)... Against which we can write our code...
-d
 

Hi!
Last year I took a course at the University og Aarhus in Denmark where we
worked on exactely these types of problems. We used a tool called CPN Tools
(wiki.daimi.au.dk/cpntools/cpntools.wiki). CPN stands for Coloured
Petri Nets and it utilizes the CPN ML language which is a deriviate of SML.
Regards,
Erik
"Dennis Landi" <XXXX@XXXXX.COM>skrev i en meddelelse

James K Smith writes:
I am not aware of what MS is doing with C# on this front but Java has
concurrency libs as part of the core of the SDK and especially in the
J2EE core.
If that is not efficient enough for you (and it may not be, depending
upon your needs or model of threaded instructions for sub routines
processing), look only as far as X10 project, sponsored by IBM.
X10 is based on a very short instruction set algorithm, where
concurrency is not handled through standard syncs and locks, but through
a more simple construct by joining activities and through atomicity.
In X10, execution can occur as a single step, while other activities are
frozen. Monitors are provided through wait/notify behavior. However push
and pop doesn't require explicit coding, it is handled by the lib
framework using a simple keyword, namely when.
For more on X10 (which may open up other ideas and concepts for other
compilers or compiler libs, look for the open source X10 project on
sourceforge (x10.sourceforge.net)
How these challenges will change the

Dennis Landi writes:
system to find bugs on a lower core number development machine.
system, there are limits to how good the simulation can be. A long time
ago I did some 8051 programming and had a cross assembler and simulator
that would run under DOS. Trouble was, the simulator only provided basic
simulation and couldn't deal with the actual hardware I was using, so I
never used it. I just looked over the code carefully and debugged it by
guesswork.
The same is true in hardware logic design. There are lots of great
analog and digital design tools that will simulate chip designs. They
are used quite a bit, but the proof is when the chip is built and
actually run.
The trouble with trying to simulate a high number of cores on a low core
count machine is that you won't get the same mix of threads and sequence
of operations, and the results won't be the same. Any simulation would
need to be much more abstract and high level and then you find that
proper simulation of the hardware and other external factors (like the
human GUI input) matter.
It would also be a large project, much like development of a virtual
machine. I can only guess how much work went into VMware and look at how
much trouble MS is having with their VM.
James
 

using a real-time GC is another interesting one.
I was speaking in terms of general applicability of a language (or a
descendant of that language) to solve new problems efficiently and move
computing forward. Java may prove that programmers and business are willing
to use it to develop substantive new software 20-30 years into the future,
but my guess is that it will be considered to be a legacy-supporting
language by then.
James