Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.perl.misc > #8801
| From | Uri Guttman <uri@stemsystems.com> |
|---|---|
| Newsgroups | comp.lang.perl.misc |
| Subject | Re: three computing drawbacks |
| Date | 2013-07-22 03:54 -0400 |
| Organization | albasani.net |
| Message-ID | <87zjtfvxkt.fsf@stemsystems.com> (permalink) |
| References | <ksij93$f0k$1@news.ntua.gr> |
>>>>> "GM" == George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> writes: GM> Not exactly a perl thread. Here are the three drawbacks (I think) GM> that have kept computing back GM> 1) Binary system. For digital processors should be three or four GM> states so with the same hardware everything would be four times GM> faster. been tried. some old russian system had 3 voltage states. much harder to create in general and likely almost impossible on the scale of todays chips. having a transistor go all the way on or off is easy. having a circuit to check the level of voltage accurate is much more complex. also the logic tables are not easily coded for. what are the 'tri-boolean' function results? also you don't get speedup, you gain 'density' but density is very very cheap now. GM> 2) Bytes should have arbitrary length of “tribits” or “tetrabits GM> (Unicode is a definition because of the fixed 8bit bytes) already done. see PDP-10/decsystem 10 or 20. so unusable that a c compiler on a dec 20 i used had to put each char in a 36 bit word. bytes are any size you want on that cpu and sequential access support is built in. random access is very tricky and slow as code has to do it. GM> 3) Clocks. Everything should be absolute asynchronous so the GM> chips/electronic would utilized only when needed. Less energy GM> greedy and faster also done already. it is a known thing that async hw will be faster and use lower power. the problem is with design. sync systems are easier to design with everything being latched at one time. you can isolate sections and such. an async chip is much harder to design and it still needs sync parts to connect to the outside world. any other 'new' ideas that are actually very old?? :) thanx, uri
Back to comp.lang.perl.misc | Previous | Next — Previous in thread | Next in thread | Find similar
three computing drawbacks George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> - 2013-07-22 09:26 +0300
Re: three computing drawbacks Uri Guttman <uri@stemsystems.com> - 2013-07-22 03:54 -0400
Re: three computing drawbacks Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2013-07-23 08:39 -0400
Re: three computing drawbacks "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> - 2013-07-24 02:06 +0300
Re: three computing drawbacks Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2013-07-24 09:31 -0400
Re: three computing drawbacks Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2013-07-23 08:32 -0400
Re: three computing drawbacks "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2013-07-23 18:33 +0200
Re: three computing drawbacks Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2013-07-23 17:43 -0400
Re: three computing drawbacks "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> - 2013-07-26 23:14 +0300
Re: three computing drawbacks Charlton Wilbur <cwilbur@chromatico.net> - 2013-07-26 17:23 -0400
Re: three computing drawbacks "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> - 2013-07-27 01:21 +0300
Re: three computing drawbacks Jim Gibson <jimsgibson@gmail.com> - 2013-07-26 17:13 -0700
Re: three computing drawbacks Scott Bryce <sbryce@scottbryce.com> - 2013-07-27 08:57 -0600
Re: three computing drawbacks Charlton Wilbur <cwilbur@chromatico.net> - 2013-07-27 18:59 -0400
Re: three computing drawbacks Ben Morrow <ben@morrow.me.uk> - 2013-07-28 03:54 +0100
Re: three computing drawbacks Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2013-07-28 09:41 -0400
Re: three computing drawbacks Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2013-07-28 13:15 -0400
csiph-web