Board index » cppbuilder » Re: Standard C++ programming will be difficult under Longhorn

2004-12-09 10:00:31 AM
cppbuilder50
Randall Parker < XXXX@XXXXX.COM >wrote:
even 8bit are much to many. So what?
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Tamas Demjen < XXXX@XXXXX.COM >writes:
tranport speed must grow at a rate of 2^66 ~= 73*10^18 every 100
years.
But even accepting your numbers, the vehicles involved should be the
space shuttle for 6 mph on the 18th century and a donkey for 6000 mph
on the 20th century.
--
Oscar
 

"Hendrik Schober" < XXXX@XXXXX.COM >writes:
I think you don't qualify as a MS-only shop, but I see what you mean
and I agree for the most part. However, the OP says "Windows with
VC7.1 has very high portability rank - good conformance, excellent
optimization" which smells very different of what you say. The mention
of optimization is very odd, too.
--
Oscar
 

{smallsort}

"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >writes:
bps, which speaks immensenly about how they can influence the
legislative power to their benefit.
[snip]
police to knock on your door. On the USA it seems different. Seems
that the FBI is some kind of private police force at the service of
large corporations, no questions asked. I know first hand a case where
the poor victim was involved on a truely kafkian experience. At least,
the case was simple enough that he was able to demonstrate his total
innocence and the consequences were "only" the lost of a bunch of
personal stuff, a serious damage to the company where he worked and
several months living on a state of extreme anxiety. Some hackers on
the first nineties were not so fortunate.
--
Oscar
 

Chris Uzdavinis (TeamB) wrote:
additional thru-put then what is the point? If the additional size increases silicon
acreage dedicated to more transistors then that increases distance and increased
distance means increased latency.
access speeds for years. Apple II 6502 processors were so slow compared to memory
that every other main memory cycle could be dedicated to video refresh. Now we have
processor cycling that is many times faster than main memory access speeds.
is the biggest problem. Intel has been abandoning design efforts on new chips left
and right. They can't get past the heat problem.
registers are transistors that could have been used for something else or by their
removal stuff could have been brought closer together.
tricks can only do so much. SMP on a chip does not solve that problem. Rather, it
creates more CPUs competing to access the same main memory.
transistors are from each other. That increases latency.
Size can't be scaled up without scaling up latency.
bit for years because the demand is not that great.
CPU chip register sizes and instruction sets. I've had many discussions with CPU
designers about lots of trade-offs.
hitting up against latency problems and heat problems. Fancier cache schemes are
running out of steam as ways to deal with the latency problem. Fancier cooling has
its limits and people do not want their computers using ever larger numbers of watts
for cost and portability reasons anyway.
I even see limits to the current trend toward SMP on a chip because of the
competition this creates for the address and memory busses. Better to move each CPU
closer to its own dedicated memory and have more of an ASMP architecture (asymmetric
rather than symmetric memory access). Though that makes coding harder.
 

Hendrik Schober wrote:
Imagine you have ten million records that have, say, 20 fields in them. Suppose each
of the fields is an integer and that you know each value doesn't even need 8 bits.
Well, you can declare them all as byte fields or, say, as 128 bit native integer
fields on some future 128 bit processor.
The difference between the choices is 200 megs versus 2^7 * 200 megs. Well, why make
your data 2^7 times larger? That slows down disk reads and CPU processing. The fact
that the variables load into native 128 bit registers doesn't help performance any.
It hurts performance.
 

Oscar Fuentes wrote:
numbers of applications for which this is the case) 32 bits is not too small.
If you have a 64 bit processor and compile a 32 bit app on it then for many classes
of applications it may well be faster than if you compile a 64 bit app (compiling the
same source code). The 32 bit app is going to have smaller variables. So more stuff
will fit in L1, L2, L3 cache. Each memory cycle out to main memory will bring in more
variables. More of each data structure will fit into a cache page.
 

Randall Parker < XXXX@XXXXX.COM >wrote:
year, FTM) for this task? If you're not
arguing against 32bit if the data doesn't
even take 8bit, what's the point in arguing
against 128bit? And if you pack this to
8bit today, why not do the same on a 128bit
platform?
Where you use 8bit for a task on a 32bit
platform, you might just as well use 8bit
for the same task on a 128bit platform.
Where you use 32bit today because that's
exactly what you need, you might just as
well use 32bit on a 128bit platform tomorrw.
And where you use 32bit today just because
'int' just seemed easier or because it is
good enough or because it isn't slower
/despite/ the fact that you actually would
only need 23bit for the task as hand, you
might just as well use 128bit on a 128bit
platform.
Again, what is your point?
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Randall Parker < XXXX@XXXXX.COM >wrote:
would need a lot less than 2GB of space --
still they are done in 32bit. So what?
exact measurements have been done. Then if
some app that only needs 32bit indeed turns
out to run faster as a 32bit app even on a
64bit platform, then it should of course be
compiled as a 32bit app.
I don't think anyone here would dispute that.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Oscar Fuentes < XXXX@XXXXX.COM >wrote:
compares to what I have on my desk
as a donkey to a space shuttle. :o>
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Oscar Fuentes < XXXX@XXXXX.COM >wrote:
I work for does. :o>
(You weren't nitpicking in any way, were
you? <g>)
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
 

Randall Parker < XXXX@XXXXX.COM >writes:
programs, it's still undenyable that the trend of software is getting
bigger. If not the applications themselves, then the data sets that
they work on.
I wouldn't be suprised in the least that in 20 years a single movie
takes terabytes of data. The sound encoding gets more complicated for
the different channels, and possibly for multiple languages, alternate
storylines, viewer-selectable customizations for movie elements, etc.
That's just the trend, and it probably won't slow down.
Maybe we are reaching the upper-bounds of what silicon can handle.
I've read some reports about home-grown diamonds which are basically
impervious to heat, and once they become economical to produce would
be a vast improvement over silicon. Other technologies may also work
around the limitations of what we have today.
Be careful about being too skeptical... think of all the (now)
humorous quotes by "visionaries" from the past who estimated what our
needs were based on what was currently available.
But ultimately, the push to progress to the machines I am envisioning
won't happen until there is a perceived need.
--
Chris (TeamB);
 

"Hendrik Schober" < XXXX@XXXXX.COM >wrote in message news: XXXX@XXXXX.COM ...
Regarding the performance i doubt that the 64 bit applications will be always slower.
E.g. the 64 bit processor has more registers, so it can pass more function parameters in
registers, than pushing most of them on the stack.
Andre
 

Hendrik Schober wrote:
problem will grow in the meantime.
Howver, I already do declare smaller fields in in structs or classes when I know I'm
going to have a lot of something.
 

Chris Uzdavinis (TeamB) wrote:
power needs and heat levels kept on rising at the historical rate then in 10 or 20
years (I forget when) the processors would become as hot as the surface of the sun.
Obviously, there is a practical limit to how hot things can get.