This is a bad idea on a number of levels. It will only be available to the more wealthy members of the population. There is likely a large overlap between the set of wealthy people and the set of SUV/large truck driving people. Not only does this idea discourage carpooling, it may very well increase the number of the worst polluting vehicles on the road.
I believe that the HOV lane idea has proven a dead-end. More traffic lanes just encourages more traffic. Lately I've been thinking that the most valuable asset of the HOV lanes is the right-of-way. Cities with such lanes have a pre-prepared corridor for light rail or other such mass transit. Even better, these corridors already exist along some of the most commuter-intensive routes. We ought to think about tearing up these lanes and installing rail.
Advantages of flat scheme:
- easy to create compiler
- do not need very tricky register optimizations
This is not an issue at all. Back in the 80's Bell Labs published some papers about the "C Machine" which had a hardware stack cache that replaced the register allocator in the compiler. Good performance was achieved, but this was in the days before register allocation was as well formalized as it is now. It's not really that difficult to write a compiler register allocator these days. Other transformations like instruction scheduling are much more difficult.
- easy to create chip logic
Despite what others have said, this is an issue, though perhaps not the fatal one some make it out to be. Not only is the circuitry complex, but it sucks power and lengthens the pipeline.
Disadvantages of flat scheme:
- large instruction word.
- Need intelligent cache or hints
And may be the compilers can gap this disadvantage
by more efficient code (one operation "add" instead of three: load into register, add, save).
Yes, it does help that the instruction count is reduced. But you need something more, like code compression. We're going to start seeing that sort of thing in embedded devices in the not-too-distant future.
When you do an "add" command, c=a+b, how do we tell the CPU where the 3 arguments come from? From main memory? Somehow store the addresses to 3 different integers (plus the opcode itself) inside a 64 bit op?
Some kind of "register" is needed, just so that the asm code doesn't get bloated up by constantly referencing to distant pieces of RAM.
A student here did an experiment looking at an instruction set with 1 register: the stack pointer. All instruction operands were 32-bit addresses (or base+offset encoded in 32 bits). It turns out that with simple code compression strategies, even a dumb compiler (i.e. one that doesn't try to minimize stack space usage for temporaries) can produce code that's about the same size or smaller than RISC code.
This is a short-sighted view. More registers is better, up to a point. More registers generally means fewer instructions, meaning a shorter critical path length and faster execution. More registers also means fewer cache accesses, which can save power and design cost (number of cache ports, etc.).
Hardware register renaming addresses none of these issues. It is there to address the false dependency problem and is useful no matter how large the logical register set is.
Could you clarify on this matter please?... Anyhow, my question is really what specifically caused your problem?
Unfortunately, I do not know. Because this is a large project there are several developers working on it and I don't "know" all of the code. I'm fairly confident the code I've written is standard-compliant but I have no idea about the other bits.
The trouble is there's no easy way to find out who is at fault. I can run through and try every -f option individually but often even that is not enough because optimizations interact with each other and it's usually the case that bugs are exposed only by sequences of optimizations.
From what I've observed, there is no legal C++ code that doesn't self-modify which gcc can't intelligently optimize without problems.
Legal C++...well, that's the trick, isn't it? I've seen at least one major failure in a complex project I work on that was exposed by -O2 optimization level using g++-3.2. Whether it's a bug in the code or a bug in the compiler I do not know. Unfortunately, g++ doesn't seem to have the command-line interface to systematically test things.
Further, many of the optimizations that gcc performs are rather simple things
:) Nothing is simple when it comes to optimization. Bugs creep in all the time.
Well, given that everyone else in my office has no problem accessing their site, I can only conclude that it has something to do with my setup. Since going through an anonymizer works, I don't think it's anything on my computer. I've even tried multiple browsers (mozilla, konqueror and lynx).
T-Mobile claims to have received no other reports of problems with the site.
I also have the wireless web for $5/month, allowing me to check my email by handpring Visor to my Samsung SCH-3500 with the use of a cable from Gomadic [gomadic.com].
I can't seem to find anything on their website about $5/mo wireless web. What service do you get, exactly? Where do I find the information about it?
While you are free to tell your friends/family about your experience, I think that your reaction is kinda extreme. I bet if you called Verizon, Sprint, etc and told them that their webpage was down, they'd either say "Who cares", "Oh, ok" or "Thanks for calling" and then prompty take the next call doing nothing.
You're probably right. The difference being, though, that T-Mobile has given me actual concrete proof while I can only speculate about the other companies because their customer service channels actually work.
If a telecom can't get a web site to work I really have to question their technical competence. If their customer service can't address such a trivial problem (just remove the damn IP from the blocked list!) then I shudder to think what would happen if I had a serious problem with my service.
Distinction between data minutes and voice minutes. You *HAVE* to get Wireless Web unless you want to pay 39 cents/minute for data calls whether they're microbrowser or simply using your phone as a modem. With Verizon, you only need Mobile Web if you need microbrowser capability. If you have an integrated PDA/phone such as the Kyo 6035 or use your phone as a modem for a laptop or other PDA, Mobile Office is free and simply uses your voice minutes for data calls.
AFAIK, Verizon is the only service provider to do this, and it's over CSD, not GSM/GPRS so you'll only get 14.4kbps max. But it's better than nothing, I suppose. See my comment above the clueless ATT salesman. I'm still looking for an acceptable data solution that doesn't cost a fortune. Suggestions, anyone?
Y'know, I thought about going with VoiceStream/T-Mobile except I can't access their web site to check their plans. I think they have my IP blocked as I get connection refused messages yet can get through using an anonymizer. When I called (twice) to tell them about the problem they claimed there was no one I could talk to to fix it. Even when I asked what would happed were I a customer they indicated I'd be SOL.
Sorry, but I won't go with a company that doesn't care about its customers. I'm telling everyone I know not to purchase service from them. T-Mobile, are you listening?
ATT in Ann Arbor, MI has some really good deals for students. I got a Nokia 8390 for $50 after rebate due to a student discount on the hardware (it's usually $150). It's not the top-of-the-line phone, but it will probably do what I need. They also have a nice 500 anytime + 3000 night/weekend minutes nationwide for $35/mo. limited time offer.
Unfortunately, the ATT salesguy misled me about the data capabilities of the plan. He insisted that I could charge my voice minutes to any data (GPRS) accesses. Even when I mentioned that the ATT web site sells separate data packages he wouldn't budge. He said I could buy an "unlimited megabyte" package from $99 per month but otherwise I would just be charged voice minutes.
I didn't believe him so I called ATT directly and sure enough, he was flat-out wrong. They don't even have an unlimited data plan. No CSD either.
It seems that no wireless provider has a reasonable (cost-effective) data plan in place. I'm not going to pay $20/mo. for 5 measly megabytes of data transfer.
Anyone have ideas on this one? Since my mobile is my primary voice line I'm running out of data options. Cable/DSL won't be in my area until I've already moved away.
I'm not normally a "me too" poster, but ChannelX is right on. There is nothing more enjoyable than a good Lindy Hop with a fun partner and great connection. As for intensity, while Lindy Hop can be done to faster music (it's quite challenging, though) there is more to creating energy than tempo.
Swing really will get one into shape, as will almost any type of dancing. Partner dancing is a wonderful way to meet new people and socialize in a relaxed atmosphere. I recommend progressive lessons to everyone that indicates the slightest interest in dance.
Moore's law is meant to describe expected increases in performance over time.
Nit: Moore's law is an observation of the increase in transistor density on a die over time. Perforance is a side-effect because smaller transistors generally operate faster.
I guess I'm a bit confused. It seems to me that to say something isn't doing better than Moore's law is like saying "this isn't better than the sort of improvement we expect to see."
I believe the above poster rightly thinks that we should expect a better-than-Moore's-Law improvement with IA64 because at this point, Itanium is behind the curve.
Itanium's increased number of registers should make register allocation faster because the interference graph can be colored much more easily (less spilling).
There are lots of compiler-related things that could make compiling code for Itanium slower, but traditional register allocation is not one of them.
OK, so here's a potential problem:
Entry level pay positions are going to experienced visa engineers instead of local entry level skills folks. This makes "breaking in" to tech work tougher, and folks just out of school can't get their foot in the door.
So is it a real problem? I dunno. As far as competition between visa workers and experienced workers goes, the answer seems simple.
Sharpen your skills or lower your price. No need to put a quota on competition.
The problem with this argument is that it lets the companies off easily. Hiring practice is not simply a matter of economics. Little in life is. More important is the matter of justness. A company that hires immigrant workers at low (below-market) wages is being unfair to both the native and immigrant worker.
This is very closely tied to the hubbub surrounding NAFTA and shipping jobs over the border. Usually this is cast from the perspective of U.S. unions, who rightly fear losing jobs for their workers.
What we don't think about is the consequences for the countries importing those jobs. We hear a bit about companies "exploiting" cheap labor. This is usually cast as an anti-NAFTA/sweatshop hippie argument by the media. But consider for a moment the consequences: the host country most probably gets more pollution from factories (lax environmental laws). Its workers, while probably earning a better wage than they were before, are still far below the standard of living in the U.S. and may live in constant fear of losing their job (not unlike the pre-union days in the U.S.). Unions are non-existant.
One may argue that "developing" nations can't expect a standard of living equal to the U.S. Well, why not? Isn't it our responsibility, as the most powerful nation on earth, to improve things for as many people as we can?
Back to the immigrant worker in the U.S. While things may be better for the worker in the U.S., if given a below-average wage, he or she is still not up to U.S. living standards. If the company is setting wages low expecting that only immigrant workers will take the jobs, that's discrimination.
Note that I am not calling for an end to immgration, nor for the repeal of NAFTA. Quite the contrary. I am simply calling for fair and just business practices.
This won't work. You're trying to use compile-time evaluation (int template argument) at run-time. You need a compile-time for loop. Check Generative Programming for an example. A compile-time loop will give you programmer-controlled loop unrolling. I suppose you could say this is the C++ equivalent of Duff's Device.:)
With the STL, C++ has finally aquired a part of what Smalltalk and Java have always had: a library of base classes.
The STL is a library of generics, not base classes. Unless you're talking about unary_function or something. Generally, one should not inherit from STL classes. Inheriting from traits classes is ok (encouraged?).
Why didn't we see these problems before the STL? Because we never tried to use C++ as much more than a superset of C.
This sounds like a second-system effect. Once your team got familiar with C++ and inheritance, the tendancy was to use it everywhere. Happens to everyone.:)
With the STL, we had the opportunity to build things that were more like our other OO systems, so we did. And that's where we started to get bogged down.
My experience was exactly the opposite. Before I learned about the STL and templates, I was trying to shoehorn designs into inheritance heirarchies. Now templates are becoming the preferred method of expression -- the curiously recurring template pattern, for example, can eliminate virtual function calls. Andrei Alexandrescu presents a nice synthesis of generic and object-oriented programming in Modern C++ Design.
Among the STL's (and C++ standard library's) deficiencies are...smart pointers (the only type included, auto_ptr, is not very useful)
Why does everyone knock auto_ptr? No, it's not a generalized smart pointer and it was never intended to be so. But it has some very important uses and serves as good documentation of those uses. Read Herb Sutter's Exceptional C++ for some excellent examples.
To say that the preprocessor is equivalent to the C++ template engine is...well...wrong.:) There's a lot more to templates than type-safe inline functions (which are nice, to be sure).
The great power of the template engine is specialization and pattern matching. This allows compile-time functional programming, known as template metaprogramming. Metaprogramming provides all sorts of cool possibilities, including program generation, type-safe, compiler-aware conditional compilation, blazingly fast numerical computation and embedded domain-specific languages. For examples of the latter two, check out Blitz++ and Spirit, respectively.
It may not be faster than C, but the Blitz++ numeric library compares well with C/FORTRAN in terms of speed while allowing solutions to be specified in the problem domain rather than in the solution domain (i.e. multiplies matrices directly rather than writing loops or making function calls). This is worth quite a bit.
You can't blame the STL for that. That's a compiler (possibly language) problem.
Memory High-water-marks: Some things don't really free the memory you want them to free, just hold onto it for next time.
That's what custom allocators are for. In my experience the default works well most of the time. But you're right that some nasty pathological cases can crop up.
Slashdot Mirror
This is a bad idea on a number of levels. It will only be available to the more wealthy members of the population. There is likely a large overlap between the set of wealthy people and the set of SUV/large truck driving people. Not only does this idea discourage carpooling, it may very well increase the number of the worst polluting vehicles on the road.
I believe that the HOV lane idea has proven a dead-end. More traffic lanes just encourages more traffic. Lately I've been thinking that the most valuable asset of the HOV lanes is the right-of-way. Cities with such lanes have a pre-prepared corridor for light rail or other such mass transit. Even better, these corridors already exist along some of the most commuter-intensive routes. We ought to think about tearing up these lanes and installing rail.
This is not an issue at all. Back in the 80's Bell Labs published some papers about the "C Machine" which had a hardware stack cache that replaced the register allocator in the compiler. Good performance was achieved, but this was in the days before register allocation was as well formalized as it is now. It's not really that difficult to write a compiler register allocator these days. Other transformations like instruction scheduling are much more difficult.
Despite what others have said, this is an issue, though perhaps not the fatal one some make it out to be. Not only is the circuitry complex, but it sucks power and lengthens the pipeline.
Yes, it does help that the instruction count is reduced. But you need something more, like code compression. We're going to start seeing that sort of thing in embedded devices in the not-too-distant future.
A student here did an experiment looking at an instruction set with 1 register: the stack pointer. All instruction operands were 32-bit addresses (or base+offset encoded in 32 bits). It turns out that with simple code compression strategies, even a dumb compiler (i.e. one that doesn't try to minimize stack space usage for temporaries) can produce code that's about the same size or smaller than RISC code.
Hardware register renaming addresses none of these issues. It is there to address the false dependency problem and is useful no matter how large the logical register set is.
Unfortunately, I do not know. Because this is a large project there are several developers working on it and I don't "know" all of the code. I'm fairly confident the code I've written is standard-compliant but I have no idea about the other bits.
The trouble is there's no easy way to find out who is at fault. I can run through and try every -f option individually but often even that is not enough because optimizations interact with each other and it's usually the case that bugs are exposed only by sequences of optimizations.
Yep, that's exactly the phrase I was going to point out to you. :)
Legal C++...well, that's the trick, isn't it? I've seen at least one major failure in a complex project I work on that was exposed by -O2 optimization level using g++-3.2. Whether it's a bug in the code or a bug in the compiler I do not know. Unfortunately, g++ doesn't seem to have the command-line interface to systematically test things.
:) Nothing is simple when it comes to optimization. Bugs creep in all the time.
T-Mobile claims to have received no other reports of problems with the site.
I can't seem to find anything on their website about $5/mo wireless web. What service do you get, exactly? Where do I find the information about it?
You're probably right. The difference being, though, that T-Mobile has given me actual concrete proof while I can only speculate about the other companies because their customer service channels actually work.
If a telecom can't get a web site to work I really have to question their technical competence. If their customer service can't address such a trivial problem (just remove the damn IP from the blocked list!) then I shudder to think what would happen if I had a serious problem with my service.
AFAIK, Verizon is the only service provider to do this, and it's over CSD, not GSM/GPRS so you'll only get 14.4kbps max. But it's better than nothing, I suppose. See my comment above the clueless ATT salesman. I'm still looking for an acceptable data solution that doesn't cost a fortune. Suggestions, anyone?
Sorry, but I won't go with a company that doesn't care about its customers. I'm telling everyone I know not to purchase service from them. T-Mobile, are you listening?
Unfortunately, the ATT salesguy misled me about the data capabilities of the plan. He insisted that I could charge my voice minutes to any data (GPRS) accesses. Even when I mentioned that the ATT web site sells separate data packages he wouldn't budge. He said I could buy an "unlimited megabyte" package from $99 per month but otherwise I would just be charged voice minutes.
I didn't believe him so I called ATT directly and sure enough, he was flat-out wrong. They don't even have an unlimited data plan. No CSD either.
It seems that no wireless provider has a reasonable (cost-effective) data plan in place. I'm not going to pay $20/mo. for 5 measly megabytes of data transfer.
Anyone have ideas on this one? Since my mobile is my primary voice line I'm running out of data options. Cable/DSL won't be in my area until I've already moved away.
Swing really will get one into shape, as will almost any type of dancing. Partner dancing is a wonderful way to meet new people and socialize in a relaxed atmosphere. I recommend progressive lessons to everyone that indicates the slightest interest in dance.
Nit: Moore's law is an observation of the increase in transistor density on a die over time. Perforance is a side-effect because smaller transistors generally operate faster.
I believe the above poster rightly thinks that we should expect a better-than-Moore's-Law improvement with IA64 because at this point, Itanium is behind the curve.
There are lots of compiler-related things that could make compiling code for Itanium slower, but traditional register allocation is not one of them.
The problem with this argument is that it lets the companies off easily. Hiring practice is not simply a matter of economics. Little in life is. More important is the matter of justness. A company that hires immigrant workers at low (below-market) wages is being unfair to both the native and immigrant worker.
This is very closely tied to the hubbub surrounding NAFTA and shipping jobs over the border. Usually this is cast from the perspective of U.S. unions, who rightly fear losing jobs for their workers.
What we don't think about is the consequences for the countries importing those jobs. We hear a bit about companies "exploiting" cheap labor. This is usually cast as an anti-NAFTA/sweatshop hippie argument by the media. But consider for a moment the consequences: the host country most probably gets more pollution from factories (lax environmental laws). Its workers, while probably earning a better wage than they were before, are still far below the standard of living in the U.S. and may live in constant fear of losing their job (not unlike the pre-union days in the U.S.). Unions are non-existant.
One may argue that "developing" nations can't expect a standard of living equal to the U.S. Well, why not? Isn't it our responsibility, as the most powerful nation on earth, to improve things for as many people as we can?
Back to the immigrant worker in the U.S. While things may be better for the worker in the U.S., if given a below-average wage, he or she is still not up to U.S. living standards. If the company is setting wages low expecting that only immigrant workers will take the jobs, that's discrimination.
Note that I am not calling for an end to immgration, nor for the repeal of NAFTA. Quite the contrary. I am simply calling for fair and just business practices.
Those Brits know their chips. Give it a try.
<pendant>
Always use standard C++ headers:
#include <iostream>
#include <cstdlib>
</pendant>
Oops, you're right. I missed "some of" in your original message. My apologies. It's been a late night of hacking. :)
The STL is a library of generics, not base classes. Unless you're talking about unary_function or something. Generally, one should not inherit from STL classes. Inheriting from traits classes is ok (encouraged?).
This sounds like a second-system effect. Once your team got familiar with C++ and inheritance, the tendancy was to use it everywhere. Happens to everyone. :)
My experience was exactly the opposite. Before I learned about the STL and templates, I was trying to shoehorn designs into inheritance heirarchies. Now templates are becoming the preferred method of expression -- the curiously recurring template pattern, for example, can eliminate virtual function calls. Andrei Alexandrescu presents a nice synthesis of generic and object-oriented programming in Modern C++ Design .
Why does everyone knock auto_ptr? No, it's not a generalized smart pointer and it was never intended to be so. But it has some very important uses and serves as good documentation of those uses. Read Herb Sutter's Exceptional C++ for some excellent examples.
The great power of the template engine is specialization and pattern matching. This allows compile-time functional programming, known as template metaprogramming. Metaprogramming provides all sorts of cool possibilities, including program generation, type-safe, compiler-aware conditional compilation, blazingly fast numerical computation and embedded domain-specific languages. For examples of the latter two, check out Blitz++ and Spirit, respectively.
It may not be faster than C, but the Blitz++ numeric library compares well with C/FORTRAN in terms of speed while allowing solutions to be specified in the problem domain rather than in the solution domain (i.e. multiplies matrices directly rather than writing loops or making function calls). This is worth quite a bit.
You can't blame the STL for that. That's a compiler (possibly language) problem.
That's what custom allocators are for. In my experience the default works well most of the time. But you're right that some nasty pathological cases can crop up.