Seriously. Try going without television for a month. Just unhook the thing, put it in your basement, and, if you feel the need to kick back and relax, pick up a book. Go reaquaint yourself with your local library.
Given than most Americans have cable, you'll save money every month. You'll be cutting support for the media companies that depend on your mindless patronage. You'll find yourself with a whole lot of time to try all sorts of new hobbies that will end up being a lot more rewarding than sitting back with a remote control ever did.
It's always surprising to me how many people waste so much of their lives watching stuff they acknowledge is not worth their time.
But the numbers just don't work. From Apple's website, I would want a 2-processor 1Ghz G4 Powermac, 17" LCD, 512MB of memory, 80GB hard drive. Pretty reasonable specs.
That computer would cost me over $3000. Looking over at Dell's website, a similary configured PC, which a better video card, and a 2 Ghz P4 instead of the 2x1Ghz G4's, would run me about half that.
Some specifics that jump out at me: Apple wants $400 for 512MB of PC2700 memory. Dell wants $200. I can get the appropriate module from crucial for $170, so Apple's markup is well over 100%.
The LCD is similar; apple's 17" LCD display runs $1000. Dell will charge me $500. I can get a nice samsung model for about $590 online.
I really, REALLY like what I've seen of OS X, but I won't pay 100% premiums on hardware just to be able to run it.
I disagree. AI may have this making-artificial-people mythos about it, but if you look at the direction of AI research in the past 20 years, that's not really what the field is about.
There are exceptions; people are trying to make magical leaps over some percieved barrier, usually self-awareness. The cyc project works along those lines.
By and large, though, AI research occurs in little steps, and most of those steps are like this one. There is a need for a good understanding of what works and what doesn't work for smaller tasks before we're going to solve the bigger problems. What you seem to call "Cognitive Imitation" I would often call "Trying to understand cognition".
In other words, when it comes to "AI", these things tend to be really heavy on the "A" and really light on the "I".
I'd like to hear of an approach that you think is light on the "A" and heavy on the "I".
The only left wing radio I can think of is National Public Radio [npr.org] and it only stays in business because of the US Taxpayer [irs.gov].
Putting aside for the moment that I think your characterization of NPR as "left-wing" is misplaced, you're perpetuating the myth that NPR only exists due to government funding.
The real deal is here.
As a portion of its budget, government sources amount to about 2%. That 2% is primarily in the form of grants from the NSF and NEA.
If the government were to cut off those sources of funding tomorrow, NPR would take a hit, but it certainly wouldn't be fatal.
1) A standard hardware acceleration layer for 2D and 3D cards, something we can ask the NVidia people to add to their drivers and code equivalents for other cards.
I agree with this, and hope that the future holds running XFree86 (or Berlin or whatever) on top of the standard Framebuffer/DRM interface. It's already possible to run XFree86 on the framebuffer driver, but the system needs to have kinks ironed out; most of that work is happening on non-x86 ports, though.
2) Wine intergration. Routing Win32 messages through the kernel would be kinda nice.
3) Java acceleration. Hooks for some standard Java functions: this would help a lot in some specific embedded situations.
No. Just no. There's no significant gain to be had from putting any of that in the kernel. Furthermore, this is userspace stuff. The fact that the kernel has good stuff in it doesn't mean everything should go into the kernel...
4) ACL support for ports and stuff (like the security patches).
I've mixed feelings about this. It seems that the current security model is fine for the typical user, even though ACLs are really wonderful for larger servers with more nebulous administration structures. Overall, though, I think you're right, this stuff should get in eventually.
5) A standard "driver package" format containing the kernel module, user-mode tools and installation instructions for binary only (yecc) drivers. (One driver fits all distros!)
This is a complete don't care for me. If it comes with a binary-only module, I don't buy it. I'm still running a Matrox G400 at home as a result.
Generally, I think kernel developer sentiment is turning more and more negative towards binary-only drivers--I wouldn't expect the community to do much, if anything, to make it easier for such developers.
This story sounded a bit odd to me, so I ran some numbers:
Generously assuming a 10-ton strangelet moving at 900,000 MPH, that strangelet has a kinetic energy of approximately 1.75 x 10^14 Joules, roughly equivalent to 25,000 tons of TNT.
The story goes on to state that the entry impact released "several thousand tons of TNT" worth of energy. Let's be conservative here, and say that surface conversion was 3,000 tons of TNT. in the top 50 miles of the earth's crust.
The strangelet would never have exited the earth, having expelled all it's energy on the interior!
Unless I'm overlooking something pretty significant, either those strangelets must be moving at a bit faster clip, or must be quite a bit more massive to cause the sited effects.
How so ? After all, it's easy enough to translate the conditional instructions back into hypothetical jumps. Where does the problem lie ?
There's no showstopper, but there are two fundamental problems.
The first is the setup of the conditionals. Conditional flags are kept in a special register which is then checked by all successive instructions. This makes the interlocking on going superscalar significantly more complicated, whereas on MIPS or Alpha conditionals use GPRS. This means on MIPS or Alpha you can use register renaming in a generic, clean way and it works for going out of order. It also makes it easier for the compiler to generate code which is parallelizable...if you have to do multiple checks and conditionals, on ARM you are forced to serialize to some extent.
The second major problem is the existance of the stack-helping instructions on ARM. These instructions are used to save and load multiple registers, and just don't fit nicely into a superscalar context (much less an OOO one). In typical current implementations (such as StrongARM) these instructions just stall the pipe until completed. This isn't a huge deal for single-issue inorder machines, and actually works quite well. But it doesn't map well to higher-performance implementation techniques.
Like I said, these aren't showstoppers. The ARM architecture has significantly less in the way of high-performance impediments than, say, x86, and look at what's being done with that behemoth.
In the embedded world, though, there's typically a lot less architecture loyalty; you use whatever architecture gets the job done, be it MIPS/PPC/x86/ARM/whatever. The current field of MIPS implementations is looking pretty healthy, and I think the architecture is going to be around for a while...
Having worked on the SB1 (which is the core) and the SB1250 (the full chip you're talking about), I have to agree. Not that I'm biased or anything.
I'm hoping in a year or two this well be cheap enough that someone will pick it up and make a cool little embedded fanless computer with a hard drive and 2 GigE macs. It would make a really sweet little embedded linux webserver/NAT router/NFS server/whatever. All with SMP at a nice little clip! It wouldn't be as fast as a high-end PC, but it wouldn't need to be.
With regards to this article, I don't think it's big news. MIPS is very much alive and well, and not going anywhere. It's got the second-cleanest architecture definition around (behind Alpha, IMHO), and is much easier to implement in high performance incarnations than ARM. There's a good reason no one has done a superscalar ARM...the conditional execution that's so cool in some respects makes going superscalar (and, eventually, out of order) a real pain...
Woohoo! Someone who knows what they are talking about. Unfortunately, I think you're still wrong in the larger picture:)
Well, your just plain wrong. The C++ spec only requires non-trivial constructors/destructors (12.1 paragraph 6) as per section 12.2 paragraph 3.
From the spec:
A constructor is trivial if it is an implicitly-
declared default constructor and if:
--its class has no virtual functions (_class.virtual_) and no virtual
base classes (_class.mi_), and
--all the direct base classes of its class have trivial constructors,
and
--for all the nonstatic data members of its class that are of class
type (or array thereof), each such class has a trivial constructor.
6 Otherwise, the constructor is non-trivial.
So, in other words, yes, you can avoid the overhead of the constructor and destructor iff the constructor and destructor aren't explicitly implemented! This would never be true for any reasonable matrix class, nor for most class types.
And, recently added to the spec is the ability for even named objects that are used as return values to be optimized away so what ends up happening for:
a = b + c
is that the temporary used by operator+ is actually replaced with a. Inlined correctly and there is absolutely no overhead whatsoever.
I haven't heard about this. Assuming it's true, it's at least a step in the right direction.
C++ is efficent if you know how to use it.
And use it in nonintuitive ways. And being intuitive was kind of the original point, no?
Then are you meaning the construction/destruction of r when using
a = b + c ??
(The compiler is smart enough to eliminate the contruction of a temporary for return in this case)
Yes, that's exactly what I'm talking about. And if you're compiler is smart enough to eliminate the constructor/destructor calls, then your compiler thinks it is smarter than the C++ spec. g++ doesn't eliminate those calls at any level of optimization, for the precise reason that they are required to be called by the C++ spec. It's valid (albeit completely dumb) to have code in a constructor or destructor that has global side effects, and so correctness means we can't just get rid of the calls willy-nilly.
In the code you're giving as an example, there is no advantage to an::add implementation. But I'd argue that's because you're overlooking the simple fact that there is an implicit overloading of the assignment operator. And it's still hiding implicit calls to other functions that may be computationally expensive. If there is a good answer to keeping computational efficiency in such situations using C++, I haven't seen it.
As you may have guessed by now, I don't use C++ for anything that needs to be super-efficient. It's not for lack of trying.:)
(BTW, your::add function is messed up. I think you either meant to declare it static and use scoping in the invocation, or leave out one of the arguments and use this referenced data).
You just given a great case in point of why operator overloading is often just a Bad Idea.
Matrix a, b, c;
a = b + c;
Did you realize that, in coding this way, you invoke a Matrix constructor and destructor every single time you use such syntax? This is the kind of hidden cost that just kills program efficiency. C++ allows you to define a copy constructor which would alleviate some of the superfluous constructor overhead iff you use this syntax:
Matrix b, c; ...
Matrix a = b + c;
Anyone who argues that's intuative ought to be taken out and put out of their own misery. Beyond that, though, There is no way to get rid of the destructor overhead when using operator overloading. Nope. Can't do it. Not supported by the language.
Operator overloading arguably makes for more intuitive correct code. But it makes for far less intuative efficient code.
Re:What's so difficult?
on
Video with Depth
·
· Score: 4, Informative
The concepts behind it aren't too difficult, a google search for epipolar geometry is a good place to start.
The biggest problems are computational; it's hard to do a good job of stereo reconstruction at high frame rates in real time. It's by no means impossible, and there are commercial out there that do it, like this one.
Two cameras aren't really necessary, either, if your camera is moving in the scene. It's possible to recover both the movement of a camera and 3-d information about a scene just by moving a camera through it. Googling for structure from motion is a good place to start looking into those techniques, and there's a pretty cool page about one groups application here.
In short, this company may have an interesting prodect (depending on cost and more details on the error characteristics) but this isn't something that couldn't be done with existing methods.
Also, as an aside, I find it interesting that they take a swipe at laser rangefinders as requiring a spinning mirror, when just about all IR cameras have a spinning "chopper" as an integral part of the exposure system...:)
Unfortunately, they didn't honor the price from their mistake. Can't really blame 'em, though!
Still, it would have been nice...
Re:Let's look at that clunky 800-MHz G4
on
New iMac Announced
·
· Score: 1
From that same page:
DEC Alpha 21264 @ 725 Mhz: 1.4 million RC5 keys/sec
SUN UltraSparc III @ 750 Mhz: 1.5 million RC5 keys/sec
Wow! You've opened my eyes! An RC5 benchmark, which has at it's core under 100 instructions, along with similarly representative kernels from Photoshop benchmark tests which are extremely suited to Altivec optimization clearly show that the PowerPC is more than 6 times as fast as the servers sold by Sun and Compaq today! We can really trust Apple to select good impartial benchmarks of processor performance because those Apple folks are just such nice people! All those industry standard metrics of processor performance, such as SpecBench, which show the PowerPC to be roughly on par with the Athlon/PIII in core efficiency must be bogus!
In related news, the tobacco industry tells me that their tests not only show that smoking is not addictive, it doesn't cause cancer or anything else bad, either. Now I get to go be like the Marlboro man!
The Cyclone compiler will rewrite the code or suggest fixes to avoid potential bugs. Even if a bug still occurs, the compiled system will lead the program to halt safely, not crash.
Am I the only one to whom this sounds like potentially a really bad idea? I mean, think about it, coding along one day:
#include
int main() {
printf("He
At this point, small, cute cartoon versions of Kernighan and Ritchie pop onto the screen and say "It looks like you're writing a Hello World program! Click here to check this program for bugs automatically..."
I don't know the guy personally, but having worked for Compaq in the past and being familiar with some of his past work, I'm glad to see his name on the list. Something he was involved in that many./ readers may remember is the Itsy project, which can be found here.
If I were a voting member (which, sadly, I'm not), he'd definitely get my vote. So instead, I'll just lobby for him here.:)
At CMU, there's work being done with ~60 cameras capturing synchronized data in real-time to reconstruct 3-d mapped images of arbitrary scenes. As far as I know, they only capture about 10-seconds at a time, though.
Everyone in the high-performance CPU market (except itanic) is doing either this or multiple concurrent thread contexts to speed overall system computational throughput.
I find it interesting that the crowd here, usually so quick to cry "trying to legislate against cracking/malicious users is pointless" is crowing about suing the RIAA for something akin to a DoS attack.
Why not follow our own advice and look for a technological solution? It would be an interesting project to combine something like Advogato's trust metric with cryptographic signatures and connection quotas. In such a system, the hosers that are trying to screw things up would quickly end up locked out of most hosts.
The downside of needing someone on the system to "vouch" for you to start would be relatively minor for the overall gains, methinks.
The bigger downside might be the lessening of anonymity on a transfer; if you have to prove who you are before starting a transfer, then there's the potential for someone to put together a client that logs who you are and what you've downloaded. There would have to be a strict seperation between identity information and digital signature...
There are a lot of researchers and engineers around the world hard at work designing reconfigurable, programmable active memories PAM). These memories are asynchronous processor arrays that are data (signal or
event) driven as opposed to being clock driven. They are not only orders of magnitude faster than conventional processors, but they are also non-algorithmic: every active cell executes its instruction as soon as its data is
ready. This is called event dirven or data-driven parallelism. It's analogous to the way the brain works. It's the future of computing, IMO.
I think your definition of algorithmic is, well, odd. There are a few interesting asynchronous designs out there, such as the amulet ARM implementation, but, at least in every case I know about, they are just as algorithmic as any common software package.
An adder, be it synchronous or not, is still just a binary addition algorithm implemented in hardware. That's part of the nature of digital design; it draws its function from binary logic and algorithms.
Hardware tends to be less buggy than software because it is more pedantically verified; it has to be. It's much easier for joe software company to issue a patch than for joe hardware company to replace parts...
Anyone else have more to say about FX!32? I'd be interested in more info.
FX!32 we pretty cool. It was made up of 3 basic components: an emulator, a binary translator, and
a system call hack.
The emulator was used the first time an x86 program was run. It was pretty dog slow, as most instruction-level emulators are.
The binary translator was used to recompile that binary code into native alpha code, eliminating the emulation overhead. This was done on the fly; chunks of code that were emulated were translated and stored to eliminate the need for further emulation.
Finally, the system calls were trapped and mapped to the native Alpha system calls, meaning you took basically no performance penalty for any windows
API calls.
Together, this let you run x86 applications at about 70% of native speed (once you were out of emulation). It worked really well. Unfortunately, those NT Alphas weren't cost effective when compared to their x86 counterparts, except for in some pretty specialized, floating point intensive fields.
It's true. When you are grocery shopping and you see two kinds of butter. One is more expensive than the other. You may buy the least expensive one, but isn't there a little voice inside of you that says that the more expensive one was probably of better quality? Even if you know better, the feeling is still there.
You should try PemdOS, the new operating system!
Major Features:
Kernel is lean...0KB! This is a 100% reduction in size from any other kernel!
Won't crash. Ever. (That would require it to run)
Completely cross-platform; will run on anything from a DEC TurboLaser on down to an ARM7 core equally well.
All this can be yours for the incredible price of $75,000,000. 40% educational discount available.
First of all, what type of security is going to be implemented to prevent hacks. It seems that it would be pretty easy to shore up a single server, or even several in a single datacenter, but it would be a daunting task to protect thousands of machines spread thoughout the world against hackers.
So long as the swarmcast client software doesn't have any holes, how is this an issue? If it does have holes, yes, this is a big deal, but if you've got a machine on the net with other security holes, that's an entirely different problem.
Secondly, what type of redundancy is going to be built into this system. Again, if a file is going to be served from a single centralised machine, it should ideally be fairly reliable, with multiple connections, and RAID to ensure continuous uptime. However, if you're serving tiny pieces of a file from thousands of boxen, it seems to me that if even one of those fragments doesn't make it all the way downstream, the whole file would be worthless. Has Swarmcast done anything to prevent this from happening.
This is a pretty trivial problem to solve. There's still got to be a central server somewhere that tells you where to look for the peer bits. I don't know the details of their setup, but it certainly seems trivial to implement MD5-checking per chunk, so you can tell if there are bad chunks in your download. You just have to trust the main server's md5 signatures, and never end up trusting the peer servers.
This applies to the first point, too. If a serving machine is hacked, it's not a problem beyond that box because the real security comes from the MD5 key, or equivalent. It may be possible for a hacked server to serve bad code, but, given reasonable client design, it should be impossible for this bad data to actually be used by another machine. (Or, at least, should be impossible without big flashing lights and sirens screaming "You fool, don't do that!":)
I think that's the whole idea, at least to some extent. UO2 got behind schedule under the "management" of EA's Origin Assimilation Team, not RG. Origin was doing pretty well (deadline wise and product wise, not necessarily money wise) until EA scooped them up. Perhaps when you speak of missed deadlines and buggy releases on Richard's watch, you're thinking Ultima 9, but IIRC, EA was primarily responsible for that bungle too.
In any case, it's gonna be a fun ride. I can't wait to see what Destination comes up with.
I'm not so willing to lay the blame squarely on EA. I'm a big fan of Origin's games, especially the earlier stuff. Ultima IV was, IMHO the best game they produced, adjusted for game inflation.
The world has moved since then. No one wants to blame RG for the problems, but I'm not so sure he's not very much to blame for the last couple of debacles. I'm not trying to blame RG over EA, I just think there are very few (if any) people that have both the closeness to the situations and the lack of bias to really say who was to blame.
While I'm very much convinced that RG is a master of the older kind of computer game, I've not seen the evidence that mastery applies in today's game production process.
I'm still going to take a very close look at anything he comes out with, but it's not going to be an automatic "RG made this, I"m going to buy it". I really, really hope his next release removes all doubt of his skills, but for now, at least, he's got something to prove.
Slashdot Mirror
Given than most Americans have cable, you'll save money every month. You'll be cutting support for the media companies that depend on your mindless patronage. You'll find yourself with a whole lot of time to try all sorts of new hobbies that will end up being a lot more rewarding than sitting back with a remote control ever did.
It's always surprising to me how many people waste so much of their lives watching stuff they acknowledge is not worth their time.
That computer would cost me over $3000. Looking over at Dell's website, a similary configured PC, which a better video card, and a 2 Ghz P4 instead of the 2x1Ghz G4's, would run me about half that.
Some specifics that jump out at me: Apple wants $400 for 512MB of PC2700 memory. Dell wants $200. I can get the appropriate module from crucial for $170, so Apple's markup is well over 100%.
The LCD is similar; apple's 17" LCD display runs $1000. Dell will charge me $500. I can get a nice samsung model for about $590 online.
I really, REALLY like what I've seen of OS X, but I won't pay 100% premiums on hardware just to be able to run it.
There are exceptions; people are trying to make magical leaps over some percieved barrier, usually self-awareness. The cyc project works along those lines.
By and large, though, AI research occurs in little steps, and most of those steps are like this one. There is a need for a good understanding of what works and what doesn't work for smaller tasks before we're going to solve the bigger problems. What you seem to call "Cognitive Imitation" I would often call "Trying to understand cognition".
In other words, when it comes to "AI", these things tend to be really heavy on the "A" and really light on the "I".
I'd like to hear of an approach that you think is light on the "A" and heavy on the "I".
Putting aside for the moment that I think your characterization of NPR as "left-wing" is misplaced, you're perpetuating the myth that NPR only exists due to government funding.
The real deal is here. As a portion of its budget, government sources amount to about 2%. That 2% is primarily in the form of grants from the NSF and NEA.
If the government were to cut off those sources of funding tomorrow, NPR would take a hit, but it certainly wouldn't be fatal.
1) A standard hardware acceleration layer for 2D and 3D cards, something we can ask the NVidia people to add to their drivers and code equivalents for other cards.
I agree with this, and hope that the future holds running XFree86 (or Berlin or whatever) on top of the standard Framebuffer/DRM interface. It's already possible to run XFree86 on the framebuffer driver, but the system needs to have kinks ironed out; most of that work is happening on non-x86 ports, though.
2) Wine intergration. Routing Win32 messages through the kernel would be kinda nice. 3) Java acceleration. Hooks for some standard Java functions: this would help a lot in some specific embedded situations.
No. Just no. There's no significant gain to be had from putting any of that in the kernel. Furthermore, this is userspace stuff. The fact that the kernel has good stuff in it doesn't mean everything should go into the kernel...
4) ACL support for ports and stuff (like the security patches).
I've mixed feelings about this. It seems that the current security model is fine for the typical user, even though ACLs are really wonderful for larger servers with more nebulous administration structures. Overall, though, I think you're right, this stuff should get in eventually.
5) A standard "driver package" format containing the kernel module, user-mode tools and installation instructions for binary only (yecc) drivers. (One driver fits all distros!)
This is a complete don't care for me. If it comes with a binary-only module, I don't buy it. I'm still running a Matrox G400 at home as a result. Generally, I think kernel developer sentiment is turning more and more negative towards binary-only drivers--I wouldn't expect the community to do much, if anything, to make it easier for such developers.
Generously assuming a 10-ton strangelet moving at 900,000 MPH, that strangelet has a kinetic energy of approximately 1.75 x 10^14 Joules, roughly equivalent to 25,000 tons of TNT.
The story goes on to state that the entry impact released "several thousand tons of TNT" worth of energy. Let's be conservative here, and say that surface conversion was 3,000 tons of TNT. in the top 50 miles of the earth's crust.
The strangelet would never have exited the earth, having expelled all it's energy on the interior!
Unless I'm overlooking something pretty significant, either those strangelets must be moving at a bit faster clip, or must be quite a bit more massive to cause the sited effects.
There's no showstopper, but there are two fundamental problems.
The first is the setup of the conditionals. Conditional flags are kept in a special register which is then checked by all successive instructions. This makes the interlocking on going superscalar significantly more complicated, whereas on MIPS or Alpha conditionals use GPRS. This means on MIPS or Alpha you can use register renaming in a generic, clean way and it works for going out of order. It also makes it easier for the compiler to generate code which is parallelizable...if you have to do multiple checks and conditionals, on ARM you are forced to serialize to some extent.
The second major problem is the existance of the stack-helping instructions on ARM. These instructions are used to save and load multiple registers, and just don't fit nicely into a superscalar context (much less an OOO one). In typical current implementations (such as StrongARM) these instructions just stall the pipe until completed. This isn't a huge deal for single-issue inorder machines, and actually works quite well. But it doesn't map well to higher-performance implementation techniques.
Like I said, these aren't showstoppers. The ARM architecture has significantly less in the way of high-performance impediments than, say, x86, and look at what's being done with that behemoth.
In the embedded world, though, there's typically a lot less architecture loyalty; you use whatever architecture gets the job done, be it MIPS/PPC/x86/ARM/whatever. The current field of MIPS implementations is looking pretty healthy, and I think the architecture is going to be around for a while...
I'm hoping in a year or two this well be cheap enough that someone will pick it up and make a cool little embedded fanless computer with a hard drive and 2 GigE macs. It would make a really sweet little embedded linux webserver/NAT router/NFS server/whatever. All with SMP at a nice little clip! It wouldn't be as fast as a high-end PC, but it wouldn't need to be.
With regards to this article, I don't think it's big news. MIPS is very much alive and well, and not going anywhere. It's got the second-cleanest architecture definition around (behind Alpha, IMHO), and is much easier to implement in high performance incarnations than ARM. There's a good reason no one has done a superscalar ARM...the conditional execution that's so cool in some respects makes going superscalar (and, eventually, out of order) a real pain...
Well, your just plain wrong. The C++ spec only requires non-trivial constructors/destructors (12.1 paragraph 6) as per section 12.2 paragraph 3.
From the spec:
A constructor is trivial if it is an implicitly- declared default constructor and if:
--its class has no virtual functions (_class.virtual_) and no virtual base classes (_class.mi_), and
--all the direct base classes of its class have trivial constructors, and
--for all the nonstatic data members of its class that are of class type (or array thereof), each such class has a trivial constructor.
6 Otherwise, the constructor is non-trivial.
So, in other words, yes, you can avoid the overhead of the constructor and destructor iff the constructor and destructor aren't explicitly implemented! This would never be true for any reasonable matrix class, nor for most class types.
And, recently added to the spec is the ability for even named objects that are used as return values to be optimized away so what ends up happening for:
a = b + c
is that the temporary used by operator+ is actually replaced with a. Inlined correctly and there is absolutely no overhead whatsoever.
I haven't heard about this. Assuming it's true, it's at least a step in the right direction.
C++ is efficent if you know how to use it.
And use it in nonintuitive ways. And being intuitive was kind of the original point, no?
(The compiler is smart enough to eliminate the contruction of a temporary for return in this case)
Yes, that's exactly what I'm talking about. And if you're compiler is smart enough to eliminate the constructor/destructor calls, then your compiler thinks it is smarter than the C++ spec. g++ doesn't eliminate those calls at any level of optimization, for the precise reason that they are required to be called by the C++ spec. It's valid (albeit completely dumb) to have code in a constructor or destructor that has global side effects, and so correctness means we can't just get rid of the calls willy-nilly.
In the code you're giving as an example, there is no advantage to an ::add implementation. But I'd argue that's because you're overlooking the simple fact that there is an implicit overloading of the assignment operator. And it's still hiding implicit calls to other functions that may be computationally expensive. If there is a good answer to keeping computational efficiency in such situations using C++, I haven't seen it.
As you may have guessed by now, I don't use C++ for anything that needs to be super-efficient. It's not for lack of trying. :)
(BTW, your ::add function is messed up. I think you either meant to declare it static and use scoping in the invocation, or leave out one of the arguments and use this referenced data).
Matrix a, b, c;
a = b + c;
Did you realize that, in coding this way, you invoke a Matrix constructor and destructor every single time you use such syntax? This is the kind of hidden cost that just kills program efficiency. C++ allows you to define a copy constructor which would alleviate some of the superfluous constructor overhead iff you use this syntax:
Matrix b, c;
...
Matrix a = b + c;
Anyone who argues that's intuative ought to be taken out and put out of their own misery. Beyond that, though, There is no way to get rid of the destructor overhead when using operator overloading . Nope. Can't do it. Not supported by the language.
Operator overloading arguably makes for more intuitive correct code. But it makes for far less intuative efficient code.
The biggest problems are computational; it's hard to do a good job of stereo reconstruction at high frame rates in real time. It's by no means impossible, and there are commercial out there that do it, like this one.
Two cameras aren't really necessary, either, if your camera is moving in the scene. It's possible to recover both the movement of a camera and 3-d information about a scene just by moving a camera through it. Googling for structure from motion is a good place to start looking into those techniques, and there's a pretty cool page about one groups application here.
In short, this company may have an interesting prodect (depending on cost and more details on the error characteristics) but this isn't something that couldn't be done with existing methods.
Also, as an aside, I find it interesting that they take a swipe at laser rangefinders as requiring a spinning mirror, when just about all IR cameras have a spinning "chopper" as an integral part of the exposure system...:)
Still, it would have been nice...
DEC Alpha 21264 @ 725 Mhz: 1.4 million RC5 keys/sec
SUN UltraSparc III @ 750 Mhz: 1.5 million RC5 keys/sec
Wow! You've opened my eyes! An RC5 benchmark, which has at it's core under 100 instructions, along with similarly representative kernels from Photoshop benchmark tests which are extremely suited to Altivec optimization clearly show that the PowerPC is more than 6 times as fast as the servers sold by Sun and Compaq today! We can really trust Apple to select good impartial benchmarks of processor performance because those Apple folks are just such nice people! All those industry standard metrics of processor performance, such as SpecBench, which show the PowerPC to be roughly on par with the Athlon/PIII in core efficiency must be bogus!
In related news, the tobacco industry tells me that their tests not only show that smoking is not addictive, it doesn't cause cancer or anything else bad, either. Now I get to go be like the Marlboro man!
[cue Rawhide theme]
Am I the only one to whom this sounds like potentially a really bad idea? I mean, think about it, coding along one day:
#include
int main() {
printf("He
At this point, small, cute cartoon versions of Kernighan and Ritchie pop onto the screen and say "It looks like you're writing a Hello World program! Click here to check this program for bugs automatically..."
I'm just shuddering at the thought...
If I were a voting member (which, sadly, I'm not), he'd definitely get my vote. So instead, I'll just lobby for him here. :)
Still, it's fun to read about
EEtimes Story
Everyone in the high-performance CPU market (except itanic) is doing either this or multiple concurrent thread contexts to speed overall system computational throughput.
Why not follow our own advice and look for a technological solution? It would be an interesting project to combine something like Advogato's trust metric with cryptographic signatures and connection quotas. In such a system, the hosers that are trying to screw things up would quickly end up locked out of most hosts.
The downside of needing someone on the system to "vouch" for you to start would be relatively minor for the overall gains, methinks.
The bigger downside might be the lessening of anonymity on a transfer; if you have to prove who you are before starting a transfer, then there's the potential for someone to put together a client that logs who you are and what you've downloaded. There would have to be a strict seperation between identity information and digital signature...
Am I the only one who finds this comment ironic, given the poster's .sig?
Just curious...
I think your definition of algorithmic is, well, odd. There are a few interesting asynchronous designs out there, such as the amulet ARM implementation, but, at least in every case I know about, they are just as algorithmic as any common software package.
An adder, be it synchronous or not, is still just a binary addition algorithm implemented in hardware. That's part of the nature of digital design; it draws its function from binary logic and algorithms.
Hardware tends to be less buggy than software because it is more pedantically verified; it has to be. It's much easier for joe software company to issue a patch than for joe hardware company to replace parts...
FX!32 we pretty cool. It was made up of 3 basic components: an emulator, a binary translator, and a system call hack.
The emulator was used the first time an x86 program was run. It was pretty dog slow, as most instruction-level emulators are.
The binary translator was used to recompile that binary code into native alpha code, eliminating the emulation overhead. This was done on the fly; chunks of code that were emulated were translated and stored to eliminate the need for further emulation.
Finally, the system calls were trapped and mapped to the native Alpha system calls, meaning you took basically no performance penalty for any windows API calls.
Together, this let you run x86 applications at about 70% of native speed (once you were out of emulation). It worked really well. Unfortunately, those NT Alphas weren't cost effective when compared to their x86 counterparts, except for in some pretty specialized, floating point intensive fields.
You should try PemdOS, the new operating system!
Major Features:
- Kernel is lean...0KB! This is a 100% reduction in size from any other kernel!
- Won't crash. Ever. (That would require it to run)
- Completely cross-platform; will run on anything from a DEC TurboLaser on down to an ARM7 core equally well.
All this can be yours for the incredible price of $75,000,000. 40% educational discount available.First of all, what type of security is going to be implemented to prevent hacks. It seems that it would be pretty easy to shore up a single server, or even several in a single datacenter, but it would be a daunting task to protect thousands of machines spread thoughout the world against hackers.
So long as the swarmcast client software doesn't have any holes, how is this an issue? If it does have holes, yes, this is a big deal, but if you've got a machine on the net with other security holes, that's an entirely different problem.
Secondly, what type of redundancy is going to be built into this system. Again, if a file is going to be served from a single centralised machine, it should ideally be fairly reliable, with multiple connections, and RAID to ensure continuous uptime. However, if you're serving tiny pieces of a file from thousands of boxen, it seems to me that if even one of those fragments doesn't make it all the way downstream, the whole file would be worthless. Has Swarmcast done anything to prevent this from happening.
This is a pretty trivial problem to solve. There's still got to be a central server somewhere that tells you where to look for the peer bits. I don't know the details of their setup, but it certainly seems trivial to implement MD5-checking per chunk, so you can tell if there are bad chunks in your download. You just have to trust the main server's md5 signatures, and never end up trusting the peer servers.
This applies to the first point, too. If a serving machine is hacked, it's not a problem beyond that box because the real security comes from the MD5 key, or equivalent. It may be possible for a hacked server to serve bad code, but, given reasonable client design, it should be impossible for this bad data to actually be used by another machine. (Or, at least, should be impossible without big flashing lights and sirens screaming "You fool, don't do that!" :)
In any case, it's gonna be a fun ride. I can't wait to see what Destination comes up with.
I'm not so willing to lay the blame squarely on EA. I'm a big fan of Origin's games, especially the earlier stuff. Ultima IV was, IMHO the best game they produced, adjusted for game inflation.
The world has moved since then. No one wants to blame RG for the problems, but I'm not so sure he's not very much to blame for the last couple of debacles. I'm not trying to blame RG over EA, I just think there are very few (if any) people that have both the closeness to the situations and the lack of bias to really say who was to blame.
While I'm very much convinced that RG is a master of the older kind of computer game, I've not seen the evidence that mastery applies in today's game production process.
I'm still going to take a very close look at anything he comes out with, but it's not going to be an automatic "RG made this, I"m going to buy it". I really, really hope his next release removes all doubt of his skills, but for now, at least, he's got something to prove.