Theo Verelst Diary Page

Latest: March 2 2001

I've decided after good example to write some diary pages with toughts and events.

Oh, in case anybody fails to understand, I'd like to remind them that these pages are copyrighted, and that everything found here may not be redistributed in any other way then over this direct link without my prior consent. That includes family, christianity, and other cheats. The simple reason is that it may well be that some people have been ill informed because they've spread illegal 'copies' of my materials even with modifications. Apart from my moral judgement, that is illegal, and will be treated as such by me. Make as many references to these pages as you like, make hardcopies, but only of the whole page, including the html-references, and without changing a iota or tittel...

And if not? I won't hesitate to use legal means to correct wrong that may be done otherwise. And I am serious. I usually am. I'm not sure I could get 'attempt to grave emotional assault' out of it, but infrigement on copyright rules is serious enough. And Jesus called upon us to respect the authorities of state, so christians would of course never do such a thing. Lying, imagine that.

Previous Diary Entries

March 2, 2001

Wanna buy a little keyboard prototype? I would maybe run me into problems with yamaha and some sound programmers for patent and copyright infringements, but at least for noncommercial use csound and my microcomputer sys with the black and white keys are working together to do dx7 sound samples good enough.

A keyboard ?!?

No, not realy, just playing with ideas hearing the result of making little samples for the setup I have, I've made some more DX7 sounds into samples by csound and the fm emulator orchestra, and with the mp sys they make sounds with also keyboard associations, which isn't bad. Sort of a limited but musical sound idea, and ltsof known instrument simulations. I tried a dx7 trombone and brass sound, and a 'tine' electrical piano, which all sound nice.

I think the drum samples I have would make a keyboard not happy in the right way, one expects nice drums, not a the stuff I've been trying with the linn and sample other samples, but then again, a memory upgrade and some samples, and preferably a little more sample replay hardware to compensate for the only 10 MHz of the Z80 would make a fun enough integrated music station in the small keyboard leage, with many sound possiblities when linked with a pc.

Of course the sounds can also be used in high quality 44.1kHz stereo samples with effects when the processing power is available, which I'll be into, just to make the equivalent of a soundcard and sample replay software to work with. The stereo isn't needed, but playing a sample from some more memory may be a good idea, and the pc is now the faster computation device, so maybe I could make the z80 sys buffer good enough samples generated in real time or from memory for replay, just a a temporary measure that could make me replay some longer wav files for research purposes.

The buffering would be to make the output stream regular, so that no interupts of the pc make the samples sound miserable by interupting the continuous stream at every heartbeat or otherinterrupt, and so that maybe even the replay can be be done as background task, though I'm not sure I want to spent much effort in doing this with not very up to date equipment and software, but a basic 22.1 kHz playback for at least a few seconds, maybe a few tens would be fine.

I rendered a bach piece with csound, of considerable length, with nice sounding guitarish sounds, and it would be nice to play back bigger portions of it continuously, without loading and playing little portions on a row. Will see.

What's the level of all this? Mainly the use of csound is at least at good enough scientific and general use level, and once I get into some of the advanced modules, of which dx7 simulation is one as well, it can at least be seen amoung the most advanced things in the atea. I hope the facilities for pitch tracked and interpolated resynthesis and such operate good enough, I'll try the basic filtering and lets say sample manipulation facilities soon enough, that is good for thinking about my own software and the various sound generator possibilities I think about including in a faster synth infrastructure. Effects, including possible analog ones (such as compression and automated mixing for live appication) are in this picture as well, I think that some of the things I've been reading about like waveguides for reverb and the diffusion computations may be not the latest thoughts, but there is quite some interesting material to be made applying good enough models, and at least the csound stuffmay well be of good use.

Hardware versus software

This has been an official enough theme in the graphics project I've been in, and is a subjects I was into long, long before, for instance when I was quite aware that I might make a complete microprocessor system to make decimal numbers, or simply make two sets of counters, one binary, one decimal, and let one count down until a zero borrow, while the other counts up to display the decimal result, and that such a solution with a handfull of cheap and available ttl parts works fine, especially because the speed they can do the counting is up to going to 2 bytes and more easily. In software, one would go about this different. Important enough an example, since I was into such comparisons, and quite some like it, in lets say '78 or so, long, long before that project.

And I built them, too, that is they were not high thoughts, I'd sit down after or before my homework and make such circuits for fun and in no time, maybe in a few hours, and even less, I knew the 193 and 192 pins by heart. Not that that prooves I understand the essence of computers, but that was the level I was experienced in that time, and I expected university to make me aware of more elevated roots, and make me so advanced I'd never much need that stuff again probably. In other words, I didn't think too highly about those achievements, except I knew I was good enough at the subjects, and never learned much new in my first years at university in those areas.

I though it would be the same as with mathematics, that in 3 weeks highschool knowledge becomes a passed station and more or less obsolete, which is indeed true for the ee math I had, and which is fine enough. I don't think I'll ever again learn the same skills to learn all kinds of differential equations of 2d order by heart, and a number of tricks to solve certain classes of exercises with, but when I delved into theoretical physics the once having had the skills made me more than effective enough at that level of math for which I can have practical interest completely.

So I didn't learn much news in digital computer design? I learned a lot from using and the internals of multitasking os'es, some supercomputer ideas, and was forced to learn pascal, which I did know about, and which isn't bad, but conceptually, it wasn't that incredibly new or innovative for me. Learning to use C practically as a streaming programming language on a multiuser/tasking system, and making it portable, and reliable as well as efficient for various types of computations I learned mainly because I had the interest, and a 68000 sys with modem and mini access, and not so much in some course, though a good computer architecture course never hurts, including some historic awareness. For the rest, the end of the story has been pretty much that my pre university knowledge in the field of digital design and architectures is probably the best basis, and worth more than most other things. Of course learning industry standards and thoughts such as bist and the way a chip contains various types of gates, and lets say supercomputer consideration are of interest, but mainly the building blocks and my idea of how they can work was more than good enough to be completely applicable today still to understand at least the logic design of most things there are.

The hardware versus software question can be taken as a 'formal' design idea, though in the env I was it never led to many working results, and of course the idea is in essence simple enough: on a computer one can do various types of processing, at a certain rate, that is so many operations of a certain kind per second, because certain hardware building blocks are available in the cpu where the program runs on, which have a certain maximum throughput, and can recieve data at a rate limited by the infrastructure of the processor system, and the way this infrastructure is used depends on the program running on the computer, and how that makes god use of the processors' facilities, mainaly the computational units.

This is made more complicated by the fact that most programs are not written in a language that directly refers to the processor architecture, that would be machine language, but in a higher level language with automatic translation in between that may not be very optimal, and that many processors of the more advanced kind deal with some kind of parallel processing options in a few ways. The latter means that for instance the data going in a computer unit like an adder may be prepared for the next addition while the current one is still in progress. Alternatively, there may be two adder circtuits available that can operate on different data simulaneously.

The idea in the project I was in was to make fast units, make them into a suitable architecture with both types of parallel computations applied in it, and make the whole machine work, and efficiently so. The idea seems clear enough, the main problem lies in the choice of computer units to do the jobs required, which are usually of mathematical basic kind such as logical operations, adders, multipliers, and maybe some more advanced mathematical functions, how to make them work efficiently, and mainly how to formulate the problem such that sensible computations can be done effeciently to make the system solve the problem fast.

That is mainly the thinking about lets say the algorithm one uses to solve the problem, and how such an algorithms can be made to work on a machine effectively. And lets say the size of a machine is fixed, than we can have so many digital computer parts in it, which should then be chosen such that such algorithms work efficiently on it. And of course knowing which things computer circuits can do makes one chose better algorithms.

Say I want to compute samples made out of fourier components, then I want to compute sine waves at high speed, multiply them to get the amplitude, and add them together, and maybe I'd like to interpolate the multipliers to make spectrum shifts in gradual sense, and of course the sine waves are of different frequency. The next thing is to know wether the problem is of a off line or direct response nature, if the system gets data that in as short as possible time must compute the next output sample set on the basis of, maybe even per sample, the ways one can organize computations are limited, and when the whole problem for a large set of samples is known beforehand, we may decide on various compuation schemes all leading to the same result.

The amount of memory available is of interest to make the tradeof of using sine generators with mathematical operations (like the 'sin' function on a calculator), or to store the shape of a sine wave before the program starts in a long enough table in memory and simply look the values up. Under certain conditions, we may make good use of a discretized 2d order difference equation, one of 4 possiblities, to generate a sine wave in consequetive samples when that is usable in the algorithm, by only a few additions, instead of quite lengthy other approximation methods requiring quite some complicated computations for one sine value.

This practical example makes clear how good thinking, and knowledge about the disciplines involved may make quite a difference in the complexity and effectiveness of the resulting machine. Suppose we have a machine with great multipliers while when we make an effective algorithms we only need loads of additions, we bought the multipliers for nothing, and good have better gotten some more adder circuits. Or suppose we have more than enough adders, but no way to drive them with enough data, because the driveways for information in the system are not up to high enough data trafic per time unit, which is a common situation in computers.

Or the algorithms we use lets us only do additions on a row, because every next one needs the previous, allowing no parallel computations.

Those are roughly the considerations for designing such machines, and the next idea any good engineer/researcher in the field with ample computer knowledge would have is how we can make such machines automatically, or at least make a computer design major parts of it, and how we can make good descriptions for such types of machines, and ways to define problems that may run on them that are easy enough to use.

The equivalent is that without good programming languages and only machine language, a lot of programs would never be written, because they would not be overseeable. Programming languages make it possible to use complicated data strucures, define structures in the program that are easy to understand, and take away the tedious and hard parts of managing the computer's operations as much as possible.

For parallel computer systems, languages are not as completely defined and known as for lets say archetypical 'normal' ones, like pc, workstations, etc. There are various ways of making parallel computers which are parallel in the sense that they have more than one or a few CPU (central processing units, like a pentium or a 68040), instead of having more than one basic computational unit (alu of fp unit), and their use has been pioneered and prototyped for long already, professionally in supercomputers, which usually have a fixed, high speed structure optimized for stream, batch oriented operations, in for instance transputer machines fashionable 15 years ago, and lately in the form of distributed computing with any kind of computers connected to a network taking part in the same computations togeter.

The main considerations are how to distribute the work, how to run-time (preferably) communicate the data between the various computer systems, and practically very much: how to get around the quite stringent limitations imposed by the limited bandwidth and relatively slow responsiveness of most networks.

This is apart fromthe whole idea of thinking in parallel programs instead of quite stricly serial ones. People with experience in process based operating systems know quite well about the concepts involved in parallel processing, messaging, communication streams, signalling, the idea of address space sharing, execution order and probably also the idea of traces and ordering of events, process hierarchies, and input output based on streams, both at user level and at inter process level. Various flavours of Unix and some other well known operating systems offers these facilities seriously professional for decades already, and the principles are fine and even work well enough in practice. Applying the idea of multiprocessing is easier with such background knowledge, and the technical and quite good enough ideas in the programming libraries are directly applicable even for high speed and flexible problems.

The idea of using the process model and sockets as communication channels is still valid completely, and it may be used to efficiently even for high capacity network standards exchange information between computers taking part in parallel computations. The select and derived mechanisms function in C is sufficient to make all this work, and the only but or limitation is that there is no complete control over the ordering of events or actions on the various channels a program can communicate over, and that there is no guaranteed quality of service, that is it is not specified or guaranteed how much data will be transfered at what rate and point in time, just that at some point the process transfering data will receive more cpu time, and that at some point the network bandwidth will for some portion be ised for each processes communication needs, so that in the end all communication will receive some time and network access, assuming nothing is wrong with the system and the network isn't down.

How to program a parallel application on such a distributed set of computers is another story. I've looked at various lets say support programs and libraries to make it easier to communicate non trivial data structures between different computer systems, make sure that all parties available for the computations are reliable and performing, and for making computers wait for eachother when needed.

Parallel compilers exist, they take a 'normal' program and make a program for a parallel machine out of it, but in general this method does not take into account that certain things should or could be done differently when making a parallel program, and normal languages don't include the idea of parallel programming constructs. It is in fact mostly a technology matter to make parallel programs, except when parallel behaviour is integral part of the problem, which is often not the case. When that is not the case, the whole idea is subdued to making an as efficient as possible parallel version of a program with as little as possible extra effort. Programming decently is hard enough already.

Mainly there are 3 reasons to go parallel/distributed, first when more processing horsepower is needed, second when more memory or other storage is needed, and third when the problem is distributed in nature, such as accessing web servers all over the world. The latter is not to make things more efficient, they just happen to be distributed and require communication for remote access.

In terms of computer design, parallel strucures are completely normal, any electronical or digital circuit is by its nature composed of parts that are active in parallel. Every transistor, every gate, every logic unit is active all the time, and is part of a machine that makes it of use by putting it to work in the right way. The normal way of dealing with such circuits and their complexity is to make circuit diagrams and identify communication behaviour and various units and their connections.

The question of hardware versus software in that context boils down to making a machine with the parts at hand, and hopefully finding enough processing power in them to do the work, either in the form of hardware units, or procedures in software that take up a certain amount of time on a certain computer system. Usually cpu's are made in advanced chip manufacturing techniques, so the units for computations they have on board are quite up to standard of the state of technology in the field, and are hard to compete with by other parts with similar circuits in them, but there are many ways to make digital designs that make good use of the properties of hardware building blocks to outperform software solutions by far, very far.

As an example, a software 'and' function between two variables takes one instruction on a CPU, whereas in logical circuits, it requires a little circuit which run quite some faster than most processors ever do, and it can easily be applied to many signals coming from various sources. On a cpu there is usually an and instruction, but it will act on the bits of processor words, 32 or 64, or on the bits of two memory locations, and for making logical functions of more data, the instructions are executed in sequence, being a lot slower than the hardware equivalent gates.

On a large scale level, the idea of parallel programming can be applied in a rigid way for for instance radar systems, video compression, and such by inventing building blocks of a certain complexity that can be composed in to parallel computing strucuters solving various classes of problems, for instance the inversion of a matrix can be done in such a way the adder/multiplier units can be put on a row in various ways to perform those computations much faster than if only one unit is available. Designing the lets call it datapath, or stream in which the data flows between the units, is not trivial, though usually there are mathematical ways to make generally applicable formulas to do so automatically for various system sizes and numbers of computation units.

The main characteristics to keep in mind are that a connection can take a certain amount of data per second, and that it takes a certain amount of time to perform an operation. For various problems various structures may be optimal in the sense of making efficient percentage wise use of all units.

For certain problems, these structures are regular, meaning there take on a repeating strucure, while others are not, they might want to reconnect, or have data halted and stored at irregular times.

The overriding idea in computer builder land is to prevent as much as possible having to go into such structures, and make as general as possible processor units, with simply as short as possible throughput time of a limited number of parallel operations in them, and leave it to special system designers to include them in communicating strucures (wires or electronical switches) to connect them up when so desired, the days of supercomputers with specific strucures for special problems are not numbered, but they are not themost popular computers, and not generally so much faster that many want to afford them.

The main challenge for parallel computers and programming, apart from the normal idea of parallel units in any digital or electronical system, is to use the many computers in a networks idle time for high speed computations, and to implement inherently parallel tasks, such as associative behaviour, in a generally usefull, effective way. Inherent parallel characteristics of programs and their behaviour are usually related to communication, for which a lot of profi solutions exist for many years.

There are problems which by nature are hard to express in another form than parallel, which can then be used to make a parallel implementation as the result of not knowing a better way. The traveling salesmen problem for instance, can easily grow so complicated that guessing strucures which suggest parallel trying may at least give good enough estimates. As far as parallel programming is concerned, this may not be the most insightfull.

There are problems which are parellel in nature. Not that many are very usefull from programming point of view, but the ideas are important to deal with the problems that arise when we make parallel programs for some reason. An example is exclusion problem, for instance the dining philosophers problem. Also, every network of dependent units can be seen as a parallel definition of a problem, for which a wealth of theory exists in mathematics, electrical engineering, and physics, for analysis, characterisation, synthesis, composition and simulation.

A relatively new direction is this field is the idea of parallel communicating agents, not as analog components, but as components exchanging messages with eachother.

The theory for such ideas I'll go into next, because there are reasons to at least take it serious as means of describing certain types of computer systems, and for the theoretically founded design of communicating digital machines, lets say as opposed to general logic designs, for which the behaviour is usually quite well defined by traditional means.