On 10/28/2011 2:27 PM, karl ramberg wrote:
On Fri, Oct 28, 2011 at 6:36 PM, BGB<cr88...@gmail.com> wrote:
On 10/28/2011 7:28 AM, K. K. Subramaniam wrote:
On Thursday 27 Oct 2011 11:27:39 PM BGB wrote:
most likely, processing power will stop increasing (WRT density and/or
watts) once the respective physical limits are met (basically, it would
no longer be possible to get more processing power in the same space or
using less power within the confines of the laws of physics).
The adoption of computing machines at large is driven primarily by three
needs
- power (portable), space/weight and speed. The last two are now solvable
in
the large but the third one is still stuck in the "dark ages". I recollect
a
joke by Dr An Wang (founder of Wang Labs) in keynote during the 80s that
goes
something like this:
A man struggled to lug two heavy suitcases into a bogie in a train that
was
just about to depart. A fellow passenger helped him in and they start a
conversation. The man turns out to be a salesman from a company that made
portable computers. He showed one that fit in a pocket to his fellow
passenger.
"It does everything that a mainframe does and more and it costs only
$100".
"Amazing!" exclaimed the passenger as he held the marvel in his hands,
"Where
can I get one?". "You can have this piece," said the gracious gent, "as
thank
you gift for helping me." "Thank you very much." the passenger was
thrilled
beyond words as he gingerly explored the new gadget. Soon, the train
reached
the next station and the salesman stepped out. As the train departed, the
passenger yelled at him. "Hey! you forgot your suitcases!". "Not really!"
the
gent shouted back. "Those are the batteries for your computer".
;-) .. Subbu
yeah...
this is probably a major issue at this point with "hugely multi-core"
processors:
if built, they would likely use lots of power and produce lots of heat.
this is sort of also an issue with video cards, one gets a new/fancy nVidia
card, which is then noted to have a few issues:
it takes up two card slots (much of this apparently its heat-sink);
it is long enough that it partially sticks into the hard-drive bays;
it requires a 500W power supply;
it requires 4 plugs from the power-supply;
...
so, then one can joke that they have essentially installed a brick into
their computer.
nevermind it getting high framerates in games...
however, they would have an advantage as well:
people can still write their software in good old C/C++/Java/...
it is likely that the existence of existing programming languages and
methodologies will continue to be necessary of new computing technologies.
also, likewise people will continue pushing to gradually drive-down the
memory requirements, but for the most part the power use of devices has been
largely dictated by what one can get from plugging a power-cord into the
wall (vs either running off batteries, or OTOH, requiring one to plug in a
240V dryer/arc-welder/... style power cord).
elsewhere, I designed a hypothetical ISA, partly combining ideas from ARM
and x86-64, with a few "unique" ways of representing instructions (the idea
being that they are aligned values of 1/2/4/8 bytes, rather than either more
free-form byte-patterns or fixed-width instruction-words).
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
This is also relevant regarding understanding how to make these computers work:
http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute
seems interesting, but is very much a pain trying to watch as my
internet is slow and the player doesn't really seem to buffer up the
video all that far when paused...
but, yeah, eval and reflection are features I really like, although
sadly one doesn't really have much of anything like this standard in C,
meaning one has to put a lot of effort into making a lot of scripting
and VM technology primarily simply to make up for the lack of things
like 'eval' and 'apply'.
this becomes at times a point of contention with many C++ developers,
where they often believe that the "greatness of C++ for everything" more
than makes up for its lack of reflection or dynamic features, and I hold
that plain C has a lot of merit if-anything because it is more readily
amendable to dynamic features (which can plug into the language from
outside), which more or less makes up for the lack of syntax sugar in
many areas...
although, granted, in my case, the language I eval is BGBScript and not
C, but in many cases they are "similar enough" that the difference can
be glossed over. I had considered, but never got around to, creating a
language I was calling C-Aux, which would have taken this further, being
cosmetically similar to and mostly (85-95% ?) source-compatible with C,
but being far more dynamic (being designed to more readily allow quickly
loading code from source, supporting eval, ...). essentially, in a
practical sense C-Aux would have been mostly just an alternate
parser/front-end for the BGBScript VM (and for now has not been a
terribly pressing issue, but I may eventually do something with the
idea, but for now there are more relevant matters to try to address).
granted, the design apparently created a lot of controversy (a language
which looks like C, but does not work or behave much like C, was not
regarded favorably by those I wrote to about the idea...).
ultimately, there may well be a general solution to this crop of issues.
no, moving to Java (or the JVM) is not the solution...
also, the ability to use dynamic features should ideally not come at a
100x to 1000x or more slowdown, nor deprive people from the ability to
make use of existing code (in existing languages), nor result in huge
increases in memory usage, ...
for example, in the case of eval, one can use a JIT, and in many cases
dynamic types can be reduced to static types by the JIT (and in the
cases they can't, the JIT may well still try to optimize them).
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
