Re: Vectors (cpu type idea)
- From: "cr88192" <cr88192@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 30 Jul 2008 23:41:01 +1000
"Wolfgang Kern" <nowhere@xxxxxxxx> wrote in message
news:g6pmuo$u6h$1@xxxxxxxxxxxxxxxxxxxxxxxx
"cr88192" wrote:
[...code styles and performance]
...>>> if we write in C, ...
...>>> if we target system libraries, ...
I can't agree on this one.
Hardware-drivers can be written totally independent from OS and of
course every brand will need its own driver.
You probably mean the function-links to the OS's API which usually
come as a set of DLLs that show only part of hardware capabilities.
And I see no way in windoze to overcome this detours.
Unlike ATAPI, VESA and legacy ports, standards for 2D/3D Graphic
are unfortunately still missing, so I heavy daubt that a compiler
can optimize hardware related code without knowing all details.
it can optimize most user-written code fairly well, and compete fairlywell
with "mundanely written" assembler code, as was demonstrated long ago
with
early FORTRAN compilers, and later with C.
most people who write assembler, just work on getting it done, and so
produce code that is on average slower than the compiler output.
Yes, but let aside hobby coders yet, I think professional programmers
reason for using ASM instead of any HLL "is" performance.
but, typically this is for very confined and specific tasks (where the
effort can be directed into making it fast, rather than making it in the
first place).
it is likely that few, if any, modern large-scale commercial projects are
done purely in assembler.
for example, it was commonly the case that, for example, much of a 3D engine
would be done in C, and some of the core rendering code (such as the
rasterizer, ...) was done in assembler.
Ok, assembler isn't the lowest possible level and will lack on limits
given by used libraries, but we can always avoid Libs.
usually, there is not much good reason to use machine code, unless for some
reason assembler isn't conviniently available (such as in many JIT
compilers, ...).
even then, for example, I started out writing specific functions for munging
together specific opcodes, and eventually ended up writing a whole damn
assembler anyways...
[portability of hw-drivers ...]
...
now, these are not compiler optimizations, but library and OS-level
optimizations.
Who will optimises these (dll) libraries ?
Vendor drivers are obviously written in HLL and whenever I disassemble
one of these, I find bloated detouring BS for no reason.
Feel free to check this yourself on any windoze driver.
but, the question is whether or not the drivers are actually faster and
smaller this way than they would have been otherwise?...
likewise, do we really expect each and every app to need to worry aboutthe
details of, for example, the ATA and SATA interfaces, how FAT32 and NTFSdrivers?...
work, ... or is it better, to leave most of this up to the OS's
Ok, this are well defined standards and may be optimised for a few OS.
I suspect that these are probably decently optimized for the most part.
many things are often done in the kernel (buffering, lookup hashes, caching
directory trees, ...) that are unlikely if this stuff were being done in
user code.
[...power]
I think the fusion generator above our heads got enough power forthe problem is getting it in usably large amounts...
all our needs and may last for 'some' time.
1..4 KiloWatt/square-meter sound a lot when I look at the roof surface
of a small house. The problem is still how to store it, we could
use anchient methods like lift a huge stone or what's already in use
for decades: Hydroelectric plants use spare energy to pump water uphill.
here, I use some lead/acid batteries, and really thecapacity/volume/weight
tradeoffs are pretty poor, for example, 72 cubic inches only holds around
500VA (approx 500W).
lithium ion and NiMH batteries are a lot better, but still fairly lowlikely
density, and I suspect a reasonable-sized capacity for an android is
to to be closer to around 850kVA (or, about a whole damn car full of
lead-acid batters, or a large backpack of NiMH batteries).
several orders of magnitude more power could be extracted from 1L of
gasoline (or ethanol, or whatever else).
for example, assuming an approx 25% conversion efficiency (poor quality
4-cycle and a generator) and butanol fuel (lower energy than gasoline),
we
still get around 7.5MW, or around 9x the storage of a backpack full of
batteries.
Yes, at the very moment it is that way.
Let's wait for better results from reseach on:
Piezo, Peltier, organic photovoltaic...'moving field' motors/generators.
Things are already in motion ..., also on the 'burning fuel' front.
yeah.
I have found info on tiny gasoline piston and rotary engines (for example,
those intended for model cars, planes, and helicopters).
if a rotary can be made that works well in a motorcycle, and also one that
works well in a toy helicoptor, then a medium scale version can probably
also be made (driving a generator and providing power...).
I guess it is possible that a low-efficiency "super-battery" could consist
of an electrolysis system, compressors, tanks, and using a small rotary
engine and generator, to convert stored hydrogen back into electricity.
on one hand, a person would be lucky to get much above 10% charging
efficiency, but they could store a good deal more power than in a
conventional battery (which could offset the horrible efficiency...).
could also be useful if there were a battery system using some kind of
catalytic gel or some kind of "soft" electrolysis.
basically, the gell is ionic, and for charging, and a charge is used to
split the gell, which is pumped into tanks. for discharging, the gell is
then somehow recombined and power is extracted (possibly either thermally,
or due to a differential created between metal plates when the gells come
into contact, as one gel will absorb electrons and the other will dump
them), with the then 'spent' gel being pumped into a 3rd tank (potentially,
metal meshes and a porous insulator, as well as a naturally insulating gell,
could be used for causing the ions to dump or pick up electrons before being
able to mix with the opposite ions).
if the bonds are weaker than in water, it would take less energy to split
them, although the energy to be released from recombining them is likely to
be lower as well.
an example of this could be, for example, an NaCl or HCl based process
vaguely similar to that of a fuel cell (splitting HCl being much easier than
splitting water).
so, for example, HCl being split, cathode gets H2O+H2, anode gets H2O+Cl.
during merging, we can charge the chlorine (it readily sheding electrons).
becoming Cl-, at the same time crossing the gradiant and fusing with the
hydrogen.
(can't say if this could be more or less efficient than a H2 O2
reaction...).
[nuclear power..] yes to pro and cons...
IMO, it is about like people being afraid of carrying a gun (fearingsomeone > might steal it and turn on them) in a crowd of people with guns.
it makes
little sense...
Guns aren't made to keep peace within neighbours ...
When you sow wind, expect to earn storm.
but, they do so fairly well.
it is a problem that the guns are so much taken away and restricted...
[robots and androids]
...
then they are hardly human-like...
Why should machines showup/act human like ?
I think machines are there to help humans rather than to replace 'em.
they can do both...
there is utility to be gained in approximating humans.
I look one more time on how Nature decided to power us.
Electricity is just used for sensing and control, while motions avoid
rotating at all and are driven really effective by chemical power.
Why not 'design' faster horses or grow big birds to ride on it ?
and for androids, we could train apes.... oh, another movie yet :)
possibly, but apes would still need better treatment than androids, and
could not be as effectively used (un-augmented) for tasks requiring a
good
deal of processing power.
Do you think about mechanical solders which kill each other for fun ?
what a waste..
well, people used to use actual humans for this, but following Constantine
this practice fell into rapid decline.
at the time of Nero, he also put many women and children in the fights as
well (watch little kids, watch little kids be slain by gladiators...).
even in the 18th and 19th century in the US, there are a few recorded
instances of similar taking place (often illegally), as well as staged
fights between humans and animals, ...
in modern times, there are also fight-clubs, but these are typically both
illegal and non-lethal.
take over our jobs ?
what is total humanship then at all good for ?
they can take jobs people don't really like anyways, such as being maids,
food-service, ...
or 37C warm cheap whores ?
yes, that is likely to be a market as well.
now I prefer the natural way, including the often fishy smell :)
some people will, others may well prefer androids as well...
__
wolfgang
.
- References:
- cpu type idea
- From: mcjason
- Re: cpu type idea
- From: mcjason
- Re: cpu type idea
- From: Wolfgang Kern
- Re: cpu type idea
- From: cr88192
- Re: cpu type idea
- From: Wolfgang Kern
- Re: cpu type idea
- From: cr88192
- Re: cpu type idea
- From: Wolfgang Kern
- Re: cpu type idea
- From: cr88192
- Re: Vectors (cpu type idea)
- From: Wolfgang Kern
- Re: Vectors (cpu type idea)
- From: cr88192
- Re: Vectors (cpu type idea)
- From: Wolfgang Kern
- Re: Vectors (cpu type idea)
- From: cr88192
- Re: Vectors (cpu type idea)
- From: Wolfgang Kern
- Re: Vectors (cpu type idea)
- From: cr88192
- Re: Vectors (cpu type idea)
- From: Wolfgang Kern
- Re: Vectors (cpu type idea)
- From: cr88192
- Re: Vectors (cpu type idea)
- From: Wolfgang Kern
- Re: Vectors (cpu type idea)
- From: cr88192
- Re: Vectors (cpu type idea)
- From: Wolfgang Kern
- Re: Vectors (cpu type idea)
- From: cr88192
- Re: Vectors (cpu type idea)
- From: Wolfgang Kern
- Re: Vectors (cpu type idea)
- From: cr88192
- Re: Vectors (cpu type idea)
- From: Wolfgang Kern
- cpu type idea
- Prev by Date: Re: prova
- Next by Date: Re: Atomic operations in 32 and 64 bit platforms
- Previous by thread: Re: Vectors (cpu type idea)
- Next by thread: Re: Vectors (cpu type idea)
- Index(es):
Relevant Pages
|