I forgot to mention - "Instruction Power" assumes that you have a processor
executing the algorithm...
"Shiraz Kaleel" <s...@comcast.net> wrote in message
news:p...@comcast.com...
> I am surprised nobody really answered to the point!
>
> Software is when sequencing through the algorithm is done using
INSTRUCTION
> power
>
> Hardware is when sequencing through the algorithm is done using LOGIC
> power...!!!
>
>
>
> "Thomas Stanka" <u...@stanka-web.de> wrote in message
> news:e...@posting.google.com...
> > Hello OP,
> >
> > hope you got an better name in your next life.
> >
> > o...@hotmail.com (OP) wrote:
> > > Feeling really intelligent today.. I would like to know some basic
> > > stuff..
> > >
> > > What is the difference between a hardware implementation of an
> > > algorithm and a software one.
> >
> > HW & SW are uncomparable in general because SW w/o HW makes no sence.
> >
> > In some context you speak of HW or SW solution when you mean the
> > decission to use either
> > - a general purpose CPU (eg. micro controller) and write the
> > appropriate SW for this CPU
> > or
> > - build an ASIC (application specific IC, could of course be a fpga
> > too) that solves your problem.
> >
> > In general is an ASIC faster and fits better in your special needs for
> > reliability, power consumption and size, but tends to be more
> > expensive (unless  huge quantities) and you have big trouble when you
> > find a better algorithm for your problem.
> >
> > You would think twice before using an ASIC for data compression on the
> > other hand it's impossible to do very high speed realtime data
> > processing (eg. 10GB Switch) with a CPU.
> >
> > bye Thomas
>
>

In comp.arch.embedded Shiraz Kaleel <s...@comcast.net> wrote:
> I am surprised nobody really answered to the point!

That was because there really *was* no point to the original posting.

> Software is when sequencing through the algorithm is done using INSTRUCTION
> power

> Hardware is when sequencing through the algorithm is done using LOGIC
> power...!!!

And since "INSTRUCTION power" is just a special type of "LOGIC power",
we've come full circle back to the original question.

-- 
Hans-Bernhard Broeker (b...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

On Wed, 25 Feb 2004 23:39:28 GMT, Andrew Reilly wrote:

>> What is the difference between a hardware implementation of an
>> algorithm and a software one.  
>
>It's all hardware.  If it's not hardware, it's not doing
>anything (see question below).

So, if the software isn't doing anything, then the hardware should
perform identically if we remove it, yes?

>> How do you say an algorithm is faster in one and slower in other.. if
>> it's based on timing how do you do that?? What makes it faster in one
>> and not in other??
>
>The faster one is the one that takes less time to do whatever
>it was that you wanted done.  This involves actually doing
>the thing in question.  Only hardware actually does stuff,

What kind of "stuff" does a PC do without any software? It's a
reliable paperweight, but not much else.

No hardware will do anything at all unless it's instructed to do so.
Whether such instruction comes from software, firmware, or liveware
doesn't alter that.


This all reminds me of some "definitions" from way back in the '80s:

If you can see it, and you can touch it, then it's Real.
If you can touch it, but you can't see it, then it's Logical.
If you can see it, but you can't touch it, then it's Virtual.
If you can't see it, nor touch it, then it's Gone.

-- 
  Max

Max wrote:
> On Wed, 25 Feb 2004 23:39:28 GMT, Andrew Reilly wrote:
> 
> 
>>>What is the difference between a hardware implementation of an
>>>algorithm and a software one.  
>>
>>It's all hardware.  If it's not hardware, it's not doing
>>anything (see question below).
> 
> 
> So, if the software isn't doing anything, then the hardware should
> perform identically if we remove it, yes?

As other posters have indicated, yes.

>>>How do you say an algorithm is faster in one and slower in other.. if
>>>it's based on timing how do you do that?? What makes it faster in one
>>>and not in other??
>>
>>The faster one is the one that takes less time to do whatever
>>it was that you wanted done.  This involves actually doing
>>the thing in question.  Only hardware actually does stuff,
> 
> 
> What kind of "stuff" does a PC do without any software? It's a
> reliable paperweight, but not much else.

Who was talking about a PC?  The original poster was referring to "a 
hardware implementation of an algorithm and a software one."

> No hardware will do anything at all unless it's instructed to do so.
> Whether such instruction comes from software, firmware, or liveware
> doesn't alter that.

I'm sure, among others, ASIC manufactures would beg to differ... there 
are many hardware implementations (both within chips and as discrete 
circuits) that require no "instructions" in order to power up and be 
fully functional.

Have fun,

    Marc

I beg to differ.  Hardware need not be an instruction based processor, for
example one can create a circuit that does FIR filtering all day long
without any instructions.  Software runs on a special hardware design that
combines some basic elements, such as registers and a fancy adder called an
arithmetic-logic-unit (ALU) arranged so that the function of the ALU and
steering of data through the collection is controlled by some logic codes.
The sequence of logic codes is a 'program' created to perform some series of
operations with the collection of hardware to produce a useful result.  The
idea, of course is to create some set of hardware that can be controlled to
perform a series of elemental steps programmed by the user to be able to
compute solutions to a variety of problems.  Hardware in general is not
designed in this fashion, only hardware that is meant to be programmed.
Hardware can just as easily be a set of dedicated circuits to perform only
one task, and  wired permanently for a single application (and therefore
does not require any instructions).  That type of hardware came long before
programmable sequential machines, and is still used where performance or
power dictate a dedicated solution.

Max wrote:

> No hardware will do anything at all unless it's instructed to do so.
> Whether such instruction comes from software, firmware, or liveware
> doesn't alter that.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email r...@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

*sigh* - is speed the thing that everyone is concerned with?

Hands down, hardware is faster than software - most non-technical folks know
this.  End of story.  Now if you are looking at complex algorithm
implementations algorithm COMPLEXITY is of paramount concern.  Time
complexity is independent of platform: sw/hw.  It provides a designer with a
means of judging unit-less time efficiency.  Here is a classic example:
while bubble sorting 10 items is fine, 1 million items?  Uhhh... in this
case, an efficient SW implementation would be alot faster (even with the OS
overhead).  Complexity can allow a designer to come up with new algorithms
and make statements about room for improvement, algorithm comparisons, or to
simply offer others a platform-free metric by wich to judge suitability of
an algorithm to a given problem.  I am assuming you are more into algorithm
design so look it up properly since you are feeling smart.

Speed is not everything.  Reduced complexity is....  increased speed just
follows a good reduced (time) complexity design.  Once the algorithm is in
place, then once again - hw wins for speed.  At this point, the hardware
boys can start looking at their bread and butter: space complexity.

Sorry for throwing theory in.  I figure I should post as many times as
possible to technical forums before I quit engineering for med school.
*sigh*  I will miss it dearly.

J.


"OP" <o...@hotmail.com> wrote in message
news:a...@posting.google.com...
> Hi,
>
> Feeling really intelligent today.. I would like to know some basic
> stuff..
>
> What is the difference between a hardware implementation of an
> algorithm and a software one.
>
> How do you say an algorithm is faster in one and slower in other.. if
> it's based on timing how do you do that?? What makes it faster in one
> and not in other??
>
> all the help is appreciated.
>
> OP.

In article <zmU3c.38500$6...@news20.bellglobal.com>,
Invisible One <I...@sympatico.ca> wrote:
>*sigh* - is speed the thing that everyone is concerned with?

>Hands down, hardware is faster than software - most non-technical folks know
>this.  End of story.  Now if you are looking at complex algorithm
>implementations algorithm COMPLEXITY is of paramount concern.  Time
>complexity is independent of platform: sw/hw.

What is complexity?  This is not a vacuous question; the 
computational complexity of generating random variables 
with "most" distributions from uniform random input by
the usual methods goes up rapidly with the length, but
it one is allowed to use bit methods, it is random finite,
usually with finite expectation.  However, it can be so
slow as not even to be considered.  This is the case even
if no roundoff is allowed, other than restricting the 
number of bits output.
-- 
This address is for information only.  I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Department of Statistics, Purdue University
h...@stat.purdue.edu         Phone: (765)494-6054   FAX: (765)494-0558

Sounds like you are talking about finite word length effects.... not what
the original posting was referring to.  Since you brought it up I suppose it
can be discussed.

Well, it looks like you are saying that in general, bit symbols are
uniform... depends on the processing that is going on (distributions can get
transformed!).  It says nothing about the complexity of the algorithm.  The
distribution along with the word lengths do contribute to the information
throughput (in an information-theoretic sense).  And as for your reference
of word length complexity:  I am sure that you are refering to a specific
class of algorithms - perhaps one that you were working on recently.  But
this is generally not the case.  Regardless, your arguement along with your
reasoning very strongly state my case.  You are making statements about a
method based on its complexity.  In more familiar terms here are some
examples:

Look up table (search):   O(n) - Linear complexity with the length of the
table.
Stack Push/Pop: O(1) - Constant complexity.
Tree Search: O(n log n) - Log-linear complexity.

Bubble Sort: O(n^2) - Quadratic complexity.
Insertion Sort: O(n log n)
Shell Sort: O(n)

These were simple examples, but I left the classic sorting algorithms for
last.  QUESTION:  You have a 1k buffer that needs to be sorted.  Which
method do you use?  Bubble is the most abused one and will give you the
worst possible (timing) performance and once working, and if one is none the
wiser, than it will appear as an operational upper bound.  Too bad I have
seen this one in a few designs.  The bubble sort would take about a*(1k)^2
units of time, while shell sort would take b*(1k) units of time... where a
and b are constants that reflect the timing of the associated sub-circuits,
but are very close to each other.

Anyhow, I think that the complexity issue is more interesting to those that
are in industrial R&D and the associated academics.  It is important if
timing is of concern, expecially where speed performance is bounded by
deadlines, ie. real time systems.

Thanks for your patience in hearing me ramble.  I will now get breakfast.
Mmmmmmm.....






"Herman Rubin" <h...@odds.stat.purdue.edu> wrote in message
news:c2qf0u$2...@odds.stat.purdue.edu...
> In article <zmU3c.38500$6...@news20.bellglobal.com>,
> Invisible One <I...@sympatico.ca> wrote:
> >*sigh* - is speed the thing that everyone is concerned with?
>
> >Hands down, hardware is faster than software - most non-technical folks
know
> >this.  End of story.  Now if you are looking at complex algorithm
> >implementations algorithm COMPLEXITY is of paramount concern.  Time
> >complexity is independent of platform: sw/hw.
>
> What is complexity?  This is not a vacuous question; the
> computational complexity of generating random variables
> with "most" distributions from uniform random input by
> the usual methods goes up rapidly with the length, but
> it one is allowed to use bit methods, it is random finite,
> usually with finite expectation.  However, it can be so
> slow as not even to be considered.  This is the case even
> if no roundoff is allowed, other than restricting the
> number of bits output.
> -- 
> This address is for information only.  I do not claim that these views
> are those of the Statistics Department or of Purdue University.
> Herman Rubin, Department of Statistics, Purdue University
> h...@stat.purdue.edu         Phone: (765)494-6054   FAX: (765)494-0558

In article <Kx_4c.73$Q...@news20.bellglobal.com>,
Invisible One <I...@sympatico.ca> wrote:
>Sounds like you are talking about finite word length effects.... not what
>the original posting was referring to.  Since you brought it up I suppose it
>can be discussed.

>Well, it looks like you are saying that in general, bit symbols are
>uniform... depends on the processing that is going on (distributions can get
>transformed!).

No, I am not saying that.  The algorithms to produce
non-uniform random variables start out assuming that one
has uniform bits in the first place.  The classical
algorithms use arithmetic operations on numbers.

For example, to generate exponential random variables,
one can take the negative logarithm of a uniform one.
There are other faster methods, but they involve such
things as rounded tables, and use up random bits at a
rate O(n), where n is the length, and computations on
numbers of length n.

Let me give a simple and not too efficient algorithm
for which it is not difficult to show that the 
expected number of bits used is finite.  I have 
substantially better ones around.  This one is taken
from a modification of von Neumann's.

In this, n is an integer, k is a 0-1 switch, and the other
quantities are as indicated.  It is assumed that there is a
random bit stream available, from which bits can be taken
as needed.  Once bits are used, they are no longer available.

start:	n = 0;
oloop:	J = distance to the first 1 in bit stream;
	b = bit;
	x = J-1 bits, followed by b;
	if(b=0) go to fin;
	z = x with b replaced by 0;
	L = length(z);
	k = 0;
iloop:	J = distance to first 1 in bit stream;
	if(J <= L) {b = J-th bit of x;
	if(b=0) goto endi;
	else {z = first J bits of z with bit J made 0:
		k = 1-k; go to iloop}}
	if(L < J) {b = bit; if b = 1 goto endi;
		else {z = z followed by J-L-1 bits followed by b:
		k = 1-k; go to iloop}}
endi:	if(k = 1) goto fin;
	n = n+1;
	goto oloop;
fin:	the output is the integer n, followed by x, followed by
	as many bits as needed to fill out the output

It is not difficult to show that the expected number of
bits used in this procedure is finite, so the computational
complexity is "random finite", and the number of bits "wasted"
has a finite expectation.  From the practical standpoint, I
do not believe that this particular algorithm, or any of the
better ones, is worthwhile with present word lengths, but for
some other situations, it can be better if the bit operations
are fast.  One problem with this, or other procedures with
random numbers, is that the number of bits or numbers used in
an operation are themselves random, which adds to bookkeeping.
-- 
This address is for information only.  I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Department of Statistics, Purdue University
h...@stat.purdue.edu         Phone: (765)494-6054   FAX: (765)494-0558