Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #72539 > unrolled thread
| Started by | Sturla Molden <sturla.molden@gmail.com> |
|---|---|
| First post | 2014-06-03 17:28 +0000 |
| Last post | 2014-06-08 13:09 +1200 |
| Articles | 20 on this page of 132 — 27 participants |
Back to article view | Back to comp.lang.python
OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-03 17:28 +0000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-05 10:14 +0200
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-05 18:38 +1000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-05 11:42 +0200
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-05 22:48 +1000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-05 22:27 +0200
Re: OT: This Swift thing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-05 22:28 +0100
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 23:03 +0000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-06 13:21 +0200
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-07 01:54 +0000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-07 10:20 +0200
Re: OT: This Swift thing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-07 09:32 +0100
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-07 11:54 +0200
Re: OT: This Swift thing Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-06-15 10:55 +0200
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 08:52 -0400
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-07 11:13 -0400
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 11:54 -0400
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-07 17:10 -0400
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-07 23:32 +0000
Re: OT: This Swift thing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-06 00:41 +0100
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-06 01:54 +0200
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-05 20:13 -0400
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-06 02:35 +0200
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-06 05:45 +0000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-06 13:39 +0200
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-07 01:54 +0000
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-06 02:03 +0200
Re: OT: This Swift thing wxjmfauth@gmail.com - 2014-06-05 02:09 -0700
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 16:10 +0200
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-05 22:07 +0200
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 06:18 +1000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-05 23:12 +0200
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 23:02 +0000
Re: OT: This Swift thing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-05 22:23 +0100
Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-06 00:53 +0300
Re: OT: This Swift thing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-05 23:13 +0100
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-06 02:52 +0000
Re: OT: This Swift thing Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-06-15 11:33 +0200
Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-15 16:10 +0300
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 07:36 +1000
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-06 13:20 +0200
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 22:23 +1000
Re: OT: This Swift thing Christian Gollwitzer <auriocus@gmx.de> - 2014-06-07 09:30 +0200
Re: OT: This Swift thing Terry Reedy <tjreedy@udel.edu> - 2014-06-05 18:18 -0400
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-06 13:11 +0200
Re: OT: This Swift thing Terry Reedy <tjreedy@udel.edu> - 2014-06-06 13:06 -0400
Re: OT: This Swift thing alex23 <wuwei23@gmail.com> - 2014-06-10 15:32 +1000
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 23:02 +0000
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-05 23:08 +0000
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 23:08 +0000
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 09:21 +1000
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-06 03:16 +0000
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 13:27 +1000
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-05 08:33 -0600
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-06 01:44 +1000
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-05 18:09 +0200
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-05 11:18 -0600
Re: OT: This Swift thing Mark H Harris <harrismh777@gmail.com> - 2014-06-05 13:49 -0500
Re: OT: This Swift thing Travis Griggs <travisgriggs@gmail.com> - 2014-06-05 23:28 -0700
Re: OT: This Swift thing Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-06-06 10:25 +0200
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-06 20:41 -0600
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-07 04:57 +0000
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-07 11:23 -0400
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 11:51 -0400
Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-07 19:18 +0300
Re: OT: This Swift thing MRAB <python@mrabarnett.plus.com> - 2014-06-08 15:10 +0100
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-07 11:37 -0600
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 14:11 -0400
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-07 13:00 -0600
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 15:11 -0400
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-07 17:59 -0400
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-08 13:25 +1200
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-07 23:38 +0000
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-07 20:09 -0400
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-08 10:37 +1000
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-08 03:50 +0000
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-08 10:51 -0400
Re: OT: This Swift thing Gene Heskett <gheskett@wdtv.com> - 2014-06-08 11:21 -0400
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-08 12:09 -0400
Re: OT: This Swift thing Gene Heskett <gheskett@wdtv.com> - 2014-06-08 13:14 -0400
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-09 03:25 +1000
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-08 18:09 +0000
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-09 04:16 +1000
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-09 01:44 +0000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-08 19:24 -0700
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-09 04:20 +0000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-08 23:32 -0700
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-09 09:27 +0000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-09 04:51 -0700
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-11 19:41 +1200
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-11 13:44 +0000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-11 08:28 -0700
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-12 02:08 +0000
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-12 12:16 +1000
Re: OT: This Swift thing Steven D'Aprano <steve@pearwood.info> - 2014-06-12 09:06 +0000
Re: OT: This Swift thing alister <alister.nospam.ware@ntlworld.com> - 2014-06-12 09:34 +0000
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-12 23:32 +1200
Re: OT: This Swift thing Anssi Saari <as@sci.fi> - 2014-06-16 13:57 +0300
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-17 10:12 +1200
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-17 08:34 +1000
Re: OT: This Swift thing alister <alister.nospam.ware@ntlworld.com> - 2014-06-17 11:16 +0000
Re: OT: This Swift thing Bob Martin <bob.martin@excite.com> - 2014-06-18 07:41 +0100
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-12 05:54 -0700
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-12 17:04 +0000
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-13 03:18 +1000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-12 18:59 -0700
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-13 03:26 +0000
Re: OT: This Swift thing Gene Heskett <gheskett@wdtv.com> - 2014-06-12 14:43 -0400
Re: OT: This Swift thing albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-27 23:21 +0000
Re: OT: This Swift thing Joshua Landau <joshua@landau.ws> - 2014-06-15 02:51 +0100
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-15 03:33 +0000
Re: OT: This Swift thing Gene Heskett <gheskett@wdtv.com> - 2014-06-09 10:11 -0400
Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-09 17:27 +0300
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-11 18:56 +1200
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-09 09:14 -0400
Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-09 07:56 -0600
Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-09 17:30 +0300
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-08 19:35 -0700
Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-09 12:23 +1000
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-11 19:50 +1200
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-11 12:34 +0000
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-11 08:48 -0400
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-11 20:17 -0400
Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-12 01:25 +0000
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-12 14:11 +1200
Re: OT: This Swift thing Gene Heskett <gheskett@wdtv.com> - 2014-06-11 23:06 -0400
Re: OT: This Swift thing Roy Smith <roy@panix.com> - 2014-06-13 08:55 -0400
Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-09 21:51 -0400
Re: OT: This Swift thing Carlos Anselmo Dias <carlos@premium-sponsor.com> - 2014-06-08 18:56 +0100
Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-08 23:34 +0000
Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-08 19:32 -0700
Re: OT: This Swift thing Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-06-08 13:09 +1200
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | alister <alister.nospam.ware@ntlworld.com> |
|---|---|
| Date | 2014-06-17 11:16 +0000 |
| Message-ID | <qsVnv.355704$hK2.78291@fx04.am4> |
| In reply to | #73328 |
On Tue, 17 Jun 2014 08:34:13 +1000, Chris Angelico wrote: > > Partly that. But also, people want to know how long that will *really* > last. For instance, 10 hours of battery life... doing what? Can I really > hop on a plane for ten hours and write code the whole way without > external power? Or will each minute spent recompiling Python (with the > CPU pegged) cost 2-3 minutes out of those ten hours? What if I watch > videos (on headphones, probably, given how noisy airliners are!)? > That'll surely take more power than the manufacturers estimate. > And what happens six months from now? Will battery life decay to the > point where it's no longer interesting? (Obviously it'll decay some. But > how much?) > I bought a 12 cell battery for my Acer Once netbook & did exactly that (LHR to LAX), listening to music playing supertuxcart & reading ebooks for most of the flight. It was a life saver as the on-board entertainment from American Airlines was terrible, next time i will happily pay the extra 100 for a Virgin flight LWG to LAS instead. -- Distance doesn't make you any smaller, but it does make you part of a larger picture.
[toc] | [prev] | [next] | [standalone]
| From | Bob Martin <bob.martin@excite.com> |
|---|---|
| Date | 2014-06-18 07:41 +0100 |
| Message-ID | <c0cqk4FmbdqU1@mid.individual.net> |
| In reply to | #73338 |
in 723903 20140617 121638 alister <alister.nospam.ware@ntlworld.com> wrote: >On Tue, 17 Jun 2014 08:34:13 +1000, Chris Angelico wrote: > >> >> Partly that. But also, people want to know how long that will *really* >> last. For instance, 10 hours of battery life... doing what? Can I really >> hop on a plane for ten hours and write code the whole way without >> external power? Or will each minute spent recompiling Python (with the >> CPU pegged) cost 2-3 minutes out of those ten hours? What if I watch >> videos (on headphones, probably, given how noisy airliners are!)? >> That'll surely take more power than the manufacturers estimate. >> And what happens six months from now? Will battery life decay to the >> point where it's no longer interesting? (Obviously it'll decay some. But >> how much?) >> > >I bought a 12 cell battery for my Acer Once netbook & did exactly that >(LHR to LAX), listening to music playing supertuxcart & reading ebooks >for most of the flight. > >It was a life saver as the on-board entertainment from American Airlines >was terrible, next time i will happily pay the extra 100 for a Virgin >flight LWG to LAS instead. c/LWG/LGW/ ;-)
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-06-12 05:54 -0700 |
| Message-ID | <4d836855-08a0-434d-b3ee-c1ff17057678@googlegroups.com> |
| In reply to | #73212 |
I am bewildered by this argument...
[Heck Ive recently learnt that using ellipses is an easy way to
produce literature... So there...]
On Thursday, June 12, 2014 2:36:50 PM UTC+5:30, Steven D'Aprano wrote:
> It is my contention that, had Intel and AMD spent the last few decades
> optimizing for power consumption rather than speed, we probably could run
> a server off, well, perhaps not a watch battery, but surely a factor of
> 100 improvement in efficiency isn't unreasonable given that we're just
> moving a picogram of electrons around?
This is fine and right.
I personally would pay more if my PCs/laptops etc were quieter/efficient-er.
So we agree... upto here!
> On Thu, 12 Jun 2014 12:16:08 +1000, Chris Angelico wrote:
> > On Thu, Jun 12, 2014 at 12:08 PM, Steven D'Aprano wrote:
> >> I'm just pointing out that our computational technology uses over a
> >> million times more energy than the theoretical minimum, and therefore
> >> there is a lot of room for efficiency gains without sacrificing
> >> computer power. I never imagined that such viewpoint would turn out to
> >> be so controversial.
> > The way I understand it, you're citing an extremely theoretical minimum,
> > in the same way that one can point out that we're a long way from
> > maximum entropy in a flash memory chip, so it ought to be possible to
> > pack a lot more data onto a USB stick.
> Um, yes?
> Hands up anyone who thinks that today's generation of USB sticks will be
> the highest capacity ever, that all progress in packing more memory into
> a thumb drive (or the same memory into a smaller drive) will cease
> effective immediately?
> Anyone?
> > The laws of physics tend to put
> > boundaries that are ridiculously far from where we actually work - I
> > think most roads have speed limits that run a fairly long way short of
> > c.
> "186,000 miles per second: not just a good idea, it's the law"
> There's no *law of physics* that says cars can only travel at the speeds
> they do. Compare how fast a typical racing car goes with the typical
> 60kph speed limit in suburban Melbourne. Now compare how fast the
> Hennessey Venom GT goes to that speed limit.
> http://www.autosaur.com/fastest-car-in-the-world/?PageSpeed=noscript
Now you (or I) are getting completely confused.
If you are saying that the Hennessey Venom (HV) is better than some
standard vanilla Ford/Toyota (FT) based on the above, thats ok.
In equations:
maxspeed(HV) = 250 mph
maxspeed(FT) = 150 mph
so HV is better than FT.
Ok...
But from your earlier statements you seem to be saying its better
because:
250 mph is closer to 186,000 mps (= 670 million mph) than 150 mph
Factually this is a correct statement.
Pragmatically this is as nonsensical as comparing a mile and a
kilogram.
> Speed limits for human-piloted ground-based transport ("cars") are more
> based on social and biological factors than engineering ones. Similarly,
> there are biological factors that force keyboards to be a minimum size.
> We probably could build a keyboard where the keys were 0.1mm square, but
> what would be the point? Who could use it? Those social and biological
> factors don't apply to computing efficiency, so it's only *engineering*
> factors that prevent us from being able to run your server off a watch
> battery, not the laws of physics.
As best as I can see you are confused about the difference between
science and engineering.
Saying one car is better engineered than another on direct comparison
(150mph<250mph) is ok
Saying one car is better than another because of relation to physics
limits (c-150>c-250) is confusing science and engineering.
Likewise saying AMD and Intel should have done more due diligence to
their clients (and the planet) by considerging energy efficiency is right
and I (strongly) agree.
But compare their products' realized efficiency with theoretical limits like
Landauers is a type-wrong statement
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-06-12 17:04 +0000 |
| Message-ID | <5399ddaf$0$29988$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #73217 |
On Thu, 12 Jun 2014 05:54:47 -0700, Rustom Mody wrote:
> On Thursday, June 12, 2014 2:36:50 PM UTC+5:30, Steven D'Aprano wrote:
[...]
>> > The laws of physics tend to put
>> > boundaries that are ridiculously far from where we actually work - I
>> > think most roads have speed limits that run a fairly long way short
>> > of c.
>
>> "186,000 miles per second: not just a good idea, it's the law"
>
>> There's no *law of physics* that says cars can only travel at the
>> speeds they do. Compare how fast a typical racing car goes with the
>> typical 60kph speed limit in suburban Melbourne. Now compare how fast
>> the Hennessey Venom GT goes to that speed limit.
>
>> http://www.autosaur.com/fastest-car-in-the-world/?PageSpeed=noscript
>
> Now you (or I) are getting completely confused.
>
> If you are saying that the Hennessey Venom (HV) is better than some
> standard vanilla Ford/Toyota (FT) based on the above, thats ok.
I'm not making any value judgements ("better" or "worse") about cars
based on their speed. I'm just pointing out that the speed limits on our
roads have very little to do with the speeds cars are capable of
reaching, and *nothing* to do with ultimate limits due to the laws of
physics.
Chris made the argument that *the laws of physics* put limits on what we
can attain, which is fair enough, but then made the poor example of speed
limits on roads falling short of the speed of light. Yes, speed limits on
roads fall considerably short of the speed of light, but not because of
laws of physics. The speed limit in my street is 50 kilometres per hour,
not because that limit is a law of physics, or because cars are incapable
of exceeding 50kph, but because the government where I live has decided
that 50kph is the maximum safe speed for a car to travel in my street,
rounded to the nearest multiple of 10kph.
In other words, Chris' example is a poor one to relate to the energy
efficiency of computing.
A more directly relevant example would have been the efficiency of heat
engines, where there is a fundamental physical limit of 100% efficiency.
Perhaps Chris didn't mention that one because our technology can build
heat engines with 60% efficiency, which is probably coming close to the
practical upper limit of attainable efficiency -- we might, by virtue of
clever engineering and exotic materials, reach 70% or 80% efficiency, but
probably not 99.9% efficiency. That's a good example.
Bringing it back to computing technology, the analogy is that our current
computing technology is like a heat engine with an efficiency of
0.000001%. Even an efficiency of 1% would be a marvelous improvement. In
this analogy, there's an ultimate limit of 100% imposed by physics
(Landauer's Law), and a practical limit of (let's say) 80%, but current
computing technology is so far from those limits that those limits might
as well not exist.
> In equations:
> maxspeed(HV) = 250 mph
> maxspeed(FT) = 150 mph
> so HV is better than FT.
"Better" is your word, not mine.
I don't actually care about fast cars, but if I did, and if I valued
speed above everything else (cost, safety, fuel efficiency, noise,
environmental impact, comfort, etc) then yes, I would say 250 mph is
"better" than 150 mph, because 250 mph is larger.
> Ok...
>
> But from your earlier statements you seem to be saying its better
> because:
> 250 mph is closer to 186,000 mps (= 670 million mph) than 150 mph
>
> Factually this is a correct statement.
And yet you're going to disagree with it, even though you agree it is
correct?
> Pragmatically this is as nonsensical as comparing a mile and a kilogram.
This makes no sense at all.
Your two statements about speeds are logically and mathematically
equivalent. You cannot have one without the other.
Take three numbers, speeds in this case, s1, s2 and c, with c a strict
upper-bound. We can take:
s1 < s2 < c
without loss of generality. So in this case, we say that s2 is greater
than s1:
s2 > s1
Adding the constant c to both sides does not change the inequality:
c + s2 > c + s1
Subtracting s1 + s2 from each side:
c + s2 - (s1 + s2) > c + s1 - (s1 + s2)
c - s1 > c - s2
In other words, if 250mph is larger than 150mph (a fact, as you accept),
then it is equally a fact that 250mph is closer to the speed of light
than 150mph. You cannot possibly have one and not the other. So why do
you believe that the first form is acceptable, but the second form is
nonsense?
>> Speed limits for human-piloted ground-based transport ("cars") are more
>> based on social and biological factors than engineering ones.
>> Similarly, there are biological factors that force keyboards to be a
>> minimum size. We probably could build a keyboard where the keys were
>> 0.1mm square, but what would be the point? Who could use it? Those
>> social and biological factors don't apply to computing efficiency, so
>> it's only *engineering* factors that prevent us from being able to run
>> your server off a watch battery, not the laws of physics.
>
> As best as I can see you are confused about the difference between
> science and engineering.
>
> Saying one car is better engineered than another on direct comparison
> (150mph<250mph) is ok
>
> Saying one car is better than another because of relation to physics
> limits (c-150>c-250) is confusing science and engineering.
I do not understand what confusion you think you see here.
If we agree on the value judgement "greater top speeds are always
better", and the law of physics "c is the upper-limit to speeds", then
the following two statements are logically equivalent:
"Car HV is better than car FT because the HV has the greater top speed."
"Car HV is better than car FT because the HV's top speed is closer to c
than the FT's top speed."
These sorts of value judgments are independent of the *cause* of the
upper limit. Sticking to Chris' example of speed, if we agree that faster
travel is better than slower travel, then in the state of Victoria,
Australia, the ultimate upper-limit on (legal) speed is 110kph. If we
decide to value faster speeds, then the Hume Freeway with its 100kph
speed limit is better than my suburban back street with a 50kph speed
limit, even though the limit is a social restriction, not an engineering
limit or physics limit.
> Likewise saying AMD and Intel should have done more due diligence to
> their clients (and the planet) by considerging energy efficiency is
> right and I (strongly) agree.
>
> But compare their products' realized efficiency with theoretical limits
> like Landauers is a type-wrong statement
If I were arguing that there are no engineering limits prohibiting CPUs
reaching Landauer's limit, then you could criticise me for that, but I'm
not making that argument.
I'm saying that, whatever the practical engineering limits turn out to
be, we're unlikely to be close to them, and therefore there are very
likely to be many and massive efficiency gains to be made in computing.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-06-13 03:18 +1000 |
| Message-ID | <mailman.11037.1402593488.18130.python-list@python.org> |
| In reply to | #73225 |
On Fri, Jun 13, 2014 at 3:04 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > Chris made the argument that *the laws of physics* put limits on what we > can attain, which is fair enough, but then made the poor example of speed > limits on roads falling short of the speed of light. Yes, speed limits on > roads fall considerably short of the speed of light, but not because of > laws of physics. The speed limit in my street is 50 kilometres per hour, > not because that limit is a law of physics, or because cars are incapable > of exceeding 50kph, but because the government where I live has decided > that 50kph is the maximum safe speed for a car to travel in my street, > rounded to the nearest multiple of 10kph. > > In other words, Chris' example is a poor one to relate to the energy > efficiency of computing. The point isn't so much the legal or safe limit as that that's the speed of most driving. That is to say: Around here, most cars will travel at roughly 50 kph, which is a far cry from c. There are other reasons than physics for choosing a speed. > Take three numbers, speeds in this case, s1, s2 and c, with c a strict > upper-bound. We can take: > > s1 < s2 < c > > without loss of generality. So in this case, we say that s2 is greater > than s1: > > s2 > s1 > > Adding the constant c to both sides does not change the inequality: > > c + s2 > c + s1 As long as we accept that this is purely in a mathematical sense. Let's not get into the realm of actual speeds greater than c. > Subtracting s1 + s2 from each side: > > c + s2 - (s1 + s2) > c + s1 - (s1 + s2) > c - s1 > c - s2 > > In other words, if 250mph is larger than 150mph (a fact, as you accept), > then it is equally a fact that 250mph is closer to the speed of light > than 150mph. You cannot possibly have one and not the other. So why do > you believe that the first form is acceptable, but the second form is > nonsense? And at this point the calculation becomes safe again, and obvious common sense. (Or alternatively, substitute Mach 1 for c; it's not a hard limit, but there are good reasons for staying below it in practical application - most airliners cruise a smidge below the speed of sound for efficiency.) > If I were arguing that there are no engineering limits prohibiting CPUs > reaching Landauer's limit, then you could criticise me for that, but I'm > not making that argument. > > I'm saying that, whatever the practical engineering limits turn out to > be, we're unlikely to be close to them, and therefore there are very > likely to be many and massive efficiency gains to be made in computing. And this I totally agree with. The limits of physics are so incredibly far from where we now are that we can utterly ignore them; the limits we face are generally engineering (with the exception of stuff designed for humans to use, eg minimum useful key size is defined by fingers and not by what we can build). ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-06-12 18:59 -0700 |
| Message-ID | <5735bfaa-46a7-4995-81dd-f8fd82792ff5@googlegroups.com> |
| In reply to | #73229 |
On Thursday, June 12, 2014 10:48:00 PM UTC+5:30, Chris Angelico wrote: > On Fri, Jun 13, 2014 at 3:04 AM, Steven D'Aprano > > Take three numbers, speeds in this case, s1, s2 and c, with c a strict > > upper-bound. We can take: > > s1 < s2 < c > > without loss of generality. So in this case, we say that s2 is greater > > than s1: > > s2 > s1 > > Adding the constant c to both sides does not change the inequality: > > c + s2 > c + s1 > As long as we accept that this is purely in a mathematical sense. > Let's not get into the realm of actual speeds greater than c. You got a keen eye Chris -- didn't notice that! And captures my point better than my long-winded attempts
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-06-13 03:26 +0000 |
| Message-ID | <539a6f71$0$29988$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #73229 |
On Fri, 13 Jun 2014 03:18:00 +1000, Chris Angelico wrote: > On Fri, Jun 13, 2014 at 3:04 AM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: [...] >> Take three numbers, speeds in this case, s1, s2 and c, with c a strict >> upper-bound. We can take: >> >> s1 < s2 < c >> >> without loss of generality. So in this case, we say that s2 is greater >> than s1: >> >> s2 > s1 >> >> Adding the constant c to both sides does not change the inequality: >> >> c + s2 > c + s1 > > As long as we accept that this is purely in a mathematical sense. Let's > not get into the realm of actual speeds greater than c. Well, yes, it is in the mathematical sense, and it doesn't require any actual physical thing to travel at faster than light speed. There is no implication here that there is something travelling at (c + s1). It's just a number. But note that even in *real* (as opposed to science fiction, or hypothetical) physics, you can have superluminal speeds. Both the phase velocity and group velocity of a wave may exceed c; the closing velocity of two objects approaching each other is limited to 2c. Distant galaxies are receding from us at greater than c. There are other situations where some measurable effect can travel faster than c, e.g. the superluminal spotlight effect. https://en.wikipedia.org/wiki/Faster-than-light -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@wdtv.com> |
|---|---|
| Date | 2014-06-12 14:43 -0400 |
| Message-ID | <mailman.11043.1402604932.18130.python-list@python.org> |
| In reply to | #73225 |
On Thursday 12 June 2014 13:18:00 Chris Angelico did opine And Gene did reply: > On Fri, Jun 13, 2014 at 3:04 AM, Steven D'Aprano > > > I'm saying that, whatever the practical engineering limits turn out > > to be, we're unlikely to be close to them, and therefore there are > > very likely to be many and massive efficiency gains to be made in > > computing. > > And this I totally agree with. The limits of physics are so incredibly > far from where we now are that we can utterly ignore them; the limits > we face are generally engineering (with the exception of stuff > designed for humans to use, eg minimum useful key size is defined by > fingers and not by what we can build). > > ChrisA Thats a bit too blanketish a statement, we do see it in the real world. Some of the electronics stuff we've been using for nearly 50 years actually runs into the e=MC^2 effects, and it affects their performance in pretty deleterious ways. A broadcast power klystron, like a 4KM100LA, which is an electron beam device that does its amplifying by modulating the velocity of an electron beam which is being accelerated by nominally a 20,000 volt beam supply. But because of the beam speed from that high a voltage brings in relativity effects from e=MV^2 mass of the electrons in that beam, an equal amount of energy applied to speed it up does not get the same increase in velocity as that same energy applied to slow it down decreases it. This has the net effect of making the transit time greater when under high power drive conditions such as the sync pulses of the now out of style NTSC signal. The net result is a group delay characteristic that is uncorrectable when the baseband video is where you are trying to correct it. In a few words, the shape of the sync signal is damaged. Badly. Because most transmitters of that day used separate amplifiers for the audio, and the receivers have used the 4.5 mhz difference signal to recover the audio in the receiver for the last 63+ years, this "Incidental Carrier Phase Modulation" noise is impressed into the detected audio. And I am sure that there are many here that can recall back a decade that the UHF stations in your area, all had a what was often called "chroma buzz" in the audio that was only about 50 db down. Ear fatiguing at best. Market share effecting too. And that translates directly into station income minus signs. It was fixable, but at an additional cost in efficiency of about -20%, but consider what that 20% costs when a station using a 30kw rated transmitter, actually pulls around 225 kwh from the powerline for every hour it is on the air. Bean counters have heart attacks over such figures. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-06-27 23:21 +0000 |
| Message-ID | <53adfc72$0$4672$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #73201 |
In article <mailman.11028.1402548495.18130.python-list@python.org>, Chris Angelico <rosuav@gmail.com> wrote: >On Thu, Jun 12, 2014 at 12:08 PM, Steven D'Aprano ><steve+comp.lang.python@pearwood.info> wrote: >> I'm just pointing out that our computational technology uses >> over a million times more energy than the theoretical minimum, and >> therefore there is a lot of room for efficiency gains without sacrificing >> computer power. I never imagined that such viewpoint would turn out to be >> so controversial. > >The way I understand it, you're citing an extremely theoretical >minimum, in the same way that one can point out that we're a long way >from maximum entropy in a flash memory chip, so it ought to be >possible to pack a lot more data onto a USB stick. The laws of physics >tend to put boundaries that are ridiculously far from where we >actually work - I think most roads have speed limits that run a fairly >long way short of c. As a physicist I'm well aware that houses need no heating. With a suitable isolation and top-notch heat-exchangers in the ventilation system, our bodies generate enough heat to keep our houses at a comfortable 21 degrees. (Well, and there is the disk washer.) In the same vain cars need very little fuel, we just must accept that cars move slightly slower than we could walk. > >ChrisA -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Joshua Landau <joshua@landau.ws> |
|---|---|
| Date | 2014-06-15 02:51 +0100 |
| Message-ID | <mailman.11067.1402800753.18130.python-list@python.org> |
| In reply to | #73194 |
On 12 June 2014 03:08, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > We know *much more* about generating energy from E = mc^2 than we know > about optimally flipping bits: our nuclear reactions convert something of > the order of 0.1% of their fuel to energy, that is, to get a certain > yield, we "merely" have to supply about a thousand times more fuel than > we theoretically needed. That's about a thousand times better than the > efficiency of current bit-flipping technology. You're comparing a one-use device to a trillion-use device. I think that's unfair. Tell me when you find an atom splitter that works a trillion times. Then tell me what it's efficiency is, because it's not nearly 0.1%.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-06-15 03:33 +0000 |
| Message-ID | <539d1416$0$29988$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #73284 |
On Sun, 15 Jun 2014 02:51:49 +0100, Joshua Landau wrote: > On 12 June 2014 03:08, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> We know *much more* about generating energy from E = mc^2 than we know >> about optimally flipping bits: our nuclear reactions convert something >> of the order of 0.1% of their fuel to energy, that is, to get a certain >> yield, we "merely" have to supply about a thousand times more fuel than >> we theoretically needed. That's about a thousand times better than the >> efficiency of current bit-flipping technology. > > You're comparing a one-use device to a trillion-use device. I think > that's unfair. > > Tell me when you find an atom splitter that works a trillion times. > Then tell me what it's efficiency is, because it's not nearly 0.1%. Nuclear bombs may only get used once, but nuclear reactors get used continuously for years or decades, and like I already said, their efficiency is around 0.1% (mass converted to energy). There are also various types of atomic batteries, such as radioisotope thermoelectric generators, which convert the radiation given off by radioactive substances to electricity. They are typically expected to have an effective working life of a decade or more. -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@wdtv.com> |
|---|---|
| Date | 2014-06-09 10:11 -0400 |
| Message-ID | <mailman.10912.1402323097.18130.python-list@python.org> |
| In reply to | #73009 |
On Monday 09 June 2014 02:32:33 Rustom Mody did opine And Gene did reply: > On Monday, June 9, 2014 9:50:38 AM UTC+5:30, Steven D'Aprano wrote: > > On Sun, 08 Jun 2014 19:24:52 -0700, Rustom Mody wrote: > > > On Monday, June 9, 2014 7:14:24 AM UTC+5:30, Steven D'Aprano wrote: > > >> CPU technology is the triumph of brute force over finesse. > > > > > > If you are arguing that computers should not use millions/billions > > > of transistors, I wont argue, since I dont know the technology. > > > > No. I'm arguing that they shouldn't convert 90% of their energy input > > into heat. Looking at the whole system, about the only energy input that is not converted to heat, would be the milliwatt or 3 of sound from the speaker when it beeps at you, and the additional energy to spin the fans. That is all calculate able if you have experience in air moving, as in HVAC. > Strange statement. > What should they convert it into then? > > JFTR: Information processing and (physics) energy are about as > convertible as say: "Is a kilogram smaller/greater than a mile?" ;-) Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-06-09 17:27 +0300 |
| Message-ID | <87y4x6qhst.fsf@elektro.pacujo.net> |
| In reply to | #73028 |
Gene Heskett <gheskett@wdtv.com>: > Looking at the whole system, about the only energy input that is not > converted to heat, would be the milliwatt or 3 of sound from the speaker > when it beeps at you, and the additional energy to spin the fans. That all becomes heat as well. The dust particles that stick to the ceiling would be an example of energy not wasted as heat (gravitational potential energy). Marko
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2014-06-11 18:56 +1200 |
| Message-ID | <bvqctjFq9gkU1@mid.individual.net> |
| In reply to | #73009 |
Rustom Mody wrote: > JFTR: Information processing and (physics) energy are about as convertible > as say: "Is a kilogram smaller/greater than a mile?" Actually, that's not true. There is a fundamental thermodynamic limit on the minimum energy needed to flip a bit from one state to the other, so in that sense there's a relationship between watts and bits per second. We're nowhere near reaching that limit with current technology, though. In principle, our CPUs could be a lot more energy-efficient. (That doesn't mean they would convert a smaller proportion of their energy input into heat. It means they would need less energy input in the first place). -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-06-09 09:14 -0400 |
| Message-ID | <roy-1947C1.09141009062014@news.panix.com> |
| In reply to | #73004 |
In article <53953616$0$29988$c3e8da3$5496439d@news.astraweb.com>, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > Moore's Law observes that processing power has doubled about every two > years. Over the last decade, processing power has increased by a factor > of 32. If *efficiency* had increased at the same rate, that 500W power > supply in your PC would now be a 15W power supply. I think you're using a strange definition of efficiency. I would define it as electric_power_in / processing_power_out. If processing power has gone up by a factor of 32, and electric power used has stayed more or less the same (which it has), then efficiency has gone up. > Your mobile phone would last a month between recharges, not a day. > Your laptop could use a battery half the size and still last two > weeks on a full charge. One of the real industrial problems facing today's society is storage of electrical energy in batteries. The lead-acid batteries in our cars are not terribly different from the ones in our grandparents' cars (or even our great-grandparents', if they had cars). The storage capacity has gone up a little, mostly because the plastic shells we use now are thinner than the bakelite shells they used to use, so there's more internal volume for the same external size container. And, yes, we now have other chemistries (lithium ion, metal hydride, etc) which are better in various ways, but the energy density (joules / kg) really hasn't changed much in 100 years. > No. I'm arguing that they shouldn't convert 90% of their energy input > into heat. Actually, they convert 100% of their energy input into heat. The trick is having them do something useful along the way.
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2014-06-09 07:56 -0600 |
| Message-ID | <mailman.10913.1402323560.18130.python-list@python.org> |
| In reply to | #73004 |
On 06/08/2014 10:20 PM, Steven D'Aprano wrote: > A typical desktop computer uses less than 500 watts for *everything* > except the screen. Hard drives. DVD burner. Keyboard, mouse, USB devices, > network card, sound card, graphics card, etc. (Actually, 350W is more > typical.) > > Moore's Law observes that processing power has doubled about every two > years. Over the last decade, processing power has increased by a factor > of 32. If *efficiency* had increased at the same rate, that 500W power > supply in your PC would now be a 15W power supply. Your mobile phone > would last a month between recharges, not a day. Your laptop could use a > battery half the size and still last two weeks on a full charge. Actually that's not what Moore's law is about. Moore's law states that the number of transistors on the die doubles every 18 months. Any other doubling of something else is entirely coincidental. > <snip> > > No. I'm arguing that they shouldn't convert 90% of their energy input > into heat. All electronic circuits that don't create a motive force that performs work convert 100% of their electrical energy into heat. I'm using "work" defined in the physics sense. CPUs take in electricity and expire 100% of it as heat, and do so immediately. This conversion to heat does happen to do something useful along the way (flipping states on transistors that represent information). We used to tell people that computers make very efficient space heaters. Because in fact they do.
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-06-09 17:30 +0300 |
| Message-ID | <87tx7uqhno.fsf@elektro.pacujo.net> |
| In reply to | #73029 |
Michael Torrie <torriem@gmail.com>: > We used to tell people that computers make very efficient space > heaters. Because in fact they do. And that's no joke. Our home in Finland is heated with electric radiators. They are on 8-9 months a year. During those months, the use of all electrical appliances is free (apart from wear and tear). Marko
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-06-08 19:35 -0700 |
| Message-ID | <e4f36f7e-f71c-4618-9d3a-7a858636999c@googlegroups.com> |
| In reply to | #72996 |
On Monday, June 9, 2014 7:14:24 AM UTC+5:30, Steven D'Aprano wrote: > On Mon, 09 Jun 2014 04:16:24 +1000, Chris Angelico wrote: > > wrote: > The fact that CPUs need anything more than a passive heat sink is > *exactly* the problem. A car engine has to move anything up to a tonne of > steel around at 100kph or more, and depending on the design, they can get > away with air-cooling. In comparison, a CPU just moves around a trickle > of electric current. > (No currently designed car with an internal combustion engine uses air- > cooling. The last mass market car that used it, the Citroën GS, ceased > production in 1986. The Porsche 911 ceased production in 1998, making it, > I think, the last air-cooled vehicle apart from custom machines. With the > rise of all-electric vehicles, perhaps we will see a return to air- > cooling?) > CPU technology is the triumph of brute force over finesse. BTW people are going this way: http://www.silentpcreview.com/ http://www.endpcnoise.com/
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-06-09 12:23 +1000 |
| Message-ID | <mailman.10904.1402288428.18130.python-list@python.org> |
| In reply to | #72996 |
On Mon, Jun 9, 2014 at 11:44 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > The fact that CPUs need anything more than a passive heat sink is > *exactly* the problem. A car engine has to move anything up to a tonne of > steel around at 100kph or more, and depending on the design, they can get > away with air-cooling. In comparison, a CPU just moves around a trickle > of electric current. So, let me get this straight. A CPU has to have a fan, but a car engine doesn't, because the car's moving at a hundred kays an hour. I have a suspicion the CPU fan moves air a bit slower than that. *dives for cover* ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2014-06-11 19:50 +1200 |
| Message-ID | <bvqg1sFqu68U1@mid.individual.net> |
| In reply to | #73006 |
Chris Angelico wrote: > So, let me get this straight. A CPU has to have a fan, but a car > engine doesn't, because the car's moving at a hundred kays an hour. I > have a suspicion the CPU fan moves air a bit slower than that. If the car were *always* moving at 100km/h, it probably wouldn't need a fan. In practice, all cars do have fans (even the ones that aren't air-cooled), for the occasions when they're not moving that fast. (BTW, so-called water-cooled engines are really air-cooled too, just not by air flowing directly over the engine block. (Although marine engines may be an exception.)) -- Greg
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.python
csiph-web