[extropy-chat] more moore

Eugen Leitl eugen at leitl.org
Wed Sep 1 12:09:31 UTC 2004


On Wed, Sep 01, 2004 at 08:02:21PM +1000, Alejandro Dubrovsky wrote:

> > Current machines are too slow for even current HDTV codecs.
> 
> Well, something's encoding them in real time, otherwise there would be

No, coding/decoding resources are asymmetrical. H.264 realtime HDTV
encoding in studio can take 100 k$ of hardware (if there is such a thing yet,
haven't looked), it doesn't matter. What matters is that how much
hardware I need to replay H.264 off vanilla DVD or broadband video stream at
the user end, codec's/container's sundry bells and whistles included, of course.

> no live transmission.  Too slow for PC encoding maybe (but only if you
> don't have a suitable card i assume)

By the time you can buy a card for H.264 realtime encoding the codec will be
thoroughly obsolete. Synthesizing fully immersive realtime 3d environments
for each viewer will be required, then. With current CPU you'd be hard
pressed to render immersive audio (not even with physical modelling) aspect
of that. Video? Oooh boy...
 
> > Current machines are too slow for even Eclipse at compiled C speed.
> 
> I don't think there is any compiled C version of eclipse available (gcj
> is compiled java, and not even faster than interpreted java at that) (or
> maybe we are talking about different Eclipse's).  (If i'm wrong, please
> do post a url)

There's no native version of Eclipse available, apert from gcj you've
mentioned. What I meant equivalent execution times for the usual JIT Java.
This will take at least 3-4 times the CPU speed, if not more.
 
> > Current machines are too slow for even X at speed of Windows XP desktop
> > . 
> 
> This is independent of machine speed (but not independent of setup.  my
> X runs fine)

I meant unmodified (no xfce) default Fedora Core 2 Gnome end user reaction
times. It will take at least an order of magnitude faster CPU to render that
at XP desktop speed, all other things being equal.
 
> > Current machines are too slow for even current crude FPS. (Why do you think
> > Sony PS3 needs 1000x the speed of PS2 to succeed?)
> 
> Current crude FPSs run perfectly fine in current top of the line
> computers (saw it demonstrated nicely a couple of weeks ago.  i've been

Haven't checked, I presume you'll drop below 50-60 fps if you enable every
bell and whistle.

> out of touch from the gaming world for a number of years now, but they
> are doing fine without me. crude's come a long way). You must mean next
> gen fine FPSs.  

This is what I've actually meant, yes.
 
> > Current machines are too slow for even the DARPA race challenge.
> 
> too slow for it to be solved in about a year and a half by mostly uni
> students.

Agreed, but highway routine vehicle navigation with error rate low 
enough to be acceptable for insurers is distinctly beyond a machine 
hall full of megabucks worth of current state of the art in beowulfery. 

DARPA's challenge is easier in comparison, grad students or no. They will
manage that, in the next race, or the next after the next one, eventually.
 
> > Current machines are too slow for realtime body capturing from video.
> > Current machines are too slow for a current desktop in a mobile phone
> > performance.
> > 
> Again, independent of machine speed.  At all times desktop will be
> faster than mobile phones.  But current mobile phones kick the shit out
> of 286s.

Absolutely. But there are lots of applications currently only available on
desktops which would be very useful on a wearable platform, with the limited
footprint, especially energetically. 

By the time 2 GHz dual Opterons fit into your shirt pocket (without burning a
hole in your skin), how many desktop generation years have passed in the
land?
 
> > Need I to go on?
> > 
> No.  I agree completely with the intent of the message.

Good for you! :)

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.extropy.org/pipermail/extropy-chat/attachments/20040901/74d03f9f/attachment.bin>


More information about the extropy-chat mailing list