"cr88192" wrote:
....
>> Lowest level coding doesn't neccessarily mean 'simple',
>> but it can avoid delays like useless paranoid protection
>> and weird code detours given by HLL-abstractions.
> I had meant here:
> big winding complicated code.
> for example, consider the big complicated mess that is BSP generation,
> ****tal generation, and visibility culling, vs the much simpler "just
draw
> everything" route.
> all of the BSP-related code is complicated and ugly, but does tend to
run
> faster...
What I saw so far, in the AMD/ATI register set description, looks
'complicated enough' and it will need detailed study to figure
out best fitting structure organistaion.
But I think it will perform much faster with low level coding.
[GL vs. DX]
>> Yeah, and I think at least hardware drivers should be written at lowest
>> level, even windoze may have problems with direct hw-access.
> this is a tradeoff.
> for example, often lower-level access is harder to optimize...
> with a higher level of abstraction, often a lot more room is given to
the
> implementation to figure out how to best optimize things, wheras with a
> lower level of abstraction, it is up to the asumption that the input
code
> is already fairly well optimized.
There might be optimising tools around, but I'm confident sure that I
could do it shorter/faster/smarter in machine code if I had all info.
By 'input code' you mean the GPU-commands (instruction/parameters) ?
[AGP .vs VESA..] ok
[single chip...] ok
[future CPU...]
> these early stages are mostly represented by the gradual transition to
> multithreading and concurrent programming.
Yes,
MP with isolated busses (in addition to the shared bus) wouldn't
much suffer on concurrency or lock/block issues.
> for example, my physics engine is now being altered to follow a
> multithreaded design, and is adding some features for concurrent message
> passing. one minor issue is how to do this without some possible
performance > impact due to competition and locking issues.
Performance penalties depend on the multithreading model and OS features,
ie: my OS allow all actual instances to direct communicate which each
other, share data and read global system flags at any time.
So there can't be any concurrency, because the OS decides the 'when'
and only switches if a certain part of a thread is finished and never
somewhere inbetween.
[the walking stove...] ok
[power..]
>> For future power issues I'd pray:
>> 'may Lord Light be on our way and protect us!'
> I don't think the current petroleum issues will be a killer,
> more just a bit of a setback humans have gotten themselves into.
> my thought is that in not too long, people will have largely
transitioned
> to biofuels and nuclear reactors, but these have tradeoffs. fuels (oils,
> alcohols, ...) have a generally high energy density, and are easy to
> trans****t, but are difficult to produce.
I think the fusion generator above our heads got enough power for
all our needs and may last for 'some' time.
Hydrogen could be the key, create it with solar-panels or similar
natural 'tools' (plants/bacteria may know better than silicon).
Then first burn it, feed motors or O-H cells with it, and after that
reuse (we may even drink) the resulting waste.
[Batteries]
When I look at a toy of my son (battery powered helicopter)
this tiny accus can store immense power and reload really fast.
Recently I had to replace the accu in my mobile phone and wondered about
a four times larger capacity for only half the price as for the previous.
Electrical cars are available and aren't too bad on milage/load.
We just haven't enough reload/replace stations yet.
Another idea is to have power-rails on highways...
> in general, liquid fuels could be the most practical means of energy
storage > (and, an android being human-like, could possibly justify using
much of its
> body volume as fuel storage). as noted though, the body would need to be
> designed in such a way as to prevent the thing from burning violently if
> ignited.
Don't say this too loud, future terrorists may read us...
liquid gas ie: hydrogen holds a vast amount of burnable power.
[the self repairing android solder...]
plagiat! :) mother Nature's invention ...
[interesting ideas ...]
We will see many failed attempts to create human like machines before
a 'tem****ary final' solution brings us back to where we once started.
The design of current humans took nature several aeons, perhaps computers
can help to shorten the evaluation time now.
> fuel cells would be better, if they can be made to work effectively with
> liquid fuels (and be made cheap enough...).
I'm sure they can be made effective and cheap as well, but the obstacles
for more research are the big oil companies and their brothers in greed.
__
wolfgang
|
