By Intel supporting "AMD64", they've admitted that AMD is better, as they have to support it. Since AMD exists, why would you buy someone else's chip if you can buy the real deal, especially at the same or cheaper cost? Intel has other issues as well, in that their chips until Conroe were barely in the ballpark of performance, which also hurt mindshare and market share.
They may soon. The major disaster of the teleco breakup etc was that the teleco's continue to own the lines and provide services. They do not own the lines, they were paid for by gov provided monopoly grants, and thus should truly be owned by the governments (local/state/fed) anyways. If cables are municipality owned, and service is provided by separate companies, then you can have true competition.
Of course, and the thing that keeps this from happening, is that then the affluent areas that desire the "best" will get it, while "under-privledged" areas (defined as those that have something less) will then "unlawfully be discriminated" against.
That could be regulated by imposing line fees to maintain and upgrade the network as needed, while allowing the affluent areas to upgrade when they want by paying for it themselves. A sort of public/private partnership where the public sector maintains ownership. It's not like they public "owner" can shift the cabling to another area, much like a road or water main cannot be shifted to another area. The output of power generation plants, however, can be.
He rants about UML as well, and the effects of UML and XML and WSDL and WebServices and design issues such as strong typing versus weak typing, although I couldn't figure out if he was for or against weak typing. For API/integration layers, I prefer "weak" typing, as your API becomes cleaner by passing more generic data. I've personally seen a project where the integration API was around 400 methods defined for the API to essentially support about 5 functions, because there were multiple parameters possible for each call.
What he was really ranting about was the "integration" problem, via data modeling, protocols, and architecture, and the fact that all the silver bullets for this have pretty much just shifted the burden of real work somewhere else. I agree with him on this. Whether that was intentional, I don't know, but everything he lists was pretty much spot on for integration. (He did mention a couple of side uses: XML for configuration and UML for Use Cases which do not necessarily apply to integration).
I recall one project where we had to write the design doc and use cases for a bit of code first, to follow process. The problem? Well, this particular design was an adapter for a properietary internal undocumented API. That means that to be able to write the design doc accurrately, we had to write the code.
Process violation! Alarm bells going off. Men in black suits swing down from the ceiling.
Ok, so it wasn't that bad - but we wrote the code while doing the design doc, and then spent the 4 weeks of "build" time refactoring the code to actually be maintainable at a leisurely rate. Actually wound up being a win-win situation. The only reason we were able to do this was because the normal UML guys (BAs in our case) were completely clueless about the internals of the system and didn't even know where to begin drawing use case diagrams. Otherwise, I'm sure we would have gotten a nice set of useless diagrams like "user sits at computer", "magic happens", "user happy", please fill in "magic happens".
Since AMD invented the tech, they can call it anything they want. AMD's original name was x86-64, and they then changed it to AMD64.
Intel probably has to use a different name, as EM64T does not fully implement everything in AMD64, not to mention the marketing disaster for Intel in supporting "AMD64".
So the names are what they are, and Intel mostly supports AMD64, much to their chagrin.
The point is that Google handles threads differently, as evidenced by the problems that occur when trying to import emails from Gmail into a traditional email client, Outlook or otherwise. Thunderbird does not handle GMail all that well either.
I'll have to admit I've never bothered. I use gmail whenever it's useful, and a host of other email addresses/clients when they're useful. Gmail, shockingly, isn't my primary email service provider.:)
Then the entire idea of your inbox as a searchable repository is immensely useful.
I'm not entirely sure what you mean by this. Thunderbird, Outlook, and Eudora all allow searches, although Google's search is more straight forward (single line for all contents of an email). Additionally, the reason Outlook/Exchange's mail store is such a cluster is because it's a DB (I believe Outlook's PSTs also are deconstructed, just not as severely). Even Eudora, Elm, and Pine all offered search, with the search able to search all contents, as the mailbox was a single text file containing all messages.
Think of where this could go in 20 or so years. Self structuring data, you plop data into your computer, it organizes itself appropriately and adds the proper UI hooks in to make itself accessible.
I think this is the purpose of XML with XSLT currently. Except, in that case, it's self defining data (supposedly) with multiple possible transforms (XSLTs) that can convert that data into just about anything else.
What use does research that gives users easy access to giga(tera)bytes of information have?
I'm not sure I'm following your point on this question either. Is it supposed to be rhetorical? If so, it falls flat, as we've had the capability for at least a decade, and it's been widely available for at least 6 years. Heck, in 1999, I had a GB DB on my personal dev box. Matter of fact, in 1997, I had a TB of production data. I'm sure others were way way way larger earlier than I.
My mind's open, waiting for the next big thing. I'm also skeptical enough not to jump on every latest bandwagon. Ruby on Rails, for example, looks nice. However, it appears to suffer from all scripting langugage issues, namely performance and scalability. ESB/SOA sounds great, but it's no different than using a DB as your "bus". It has to be designed and built, today's version of ERP software..Net is just.NotEnterpriseTested.
I recall F5's BigIP Pro back in the late 90s. A really nice slick purple and silver box. Big "F5" on the front. Opened the $25+K box up and lo and behold - a P2-233. Oh, and that box was precisely what you think it was now that you know what was in it. A $25K boat anchor. (apoligies to respectable boat anchors everywhere).
I've heard recently that new deployments of F5's products still suffer some of the same faults we ran across in 99.
Which also represents a new form of interaction with threaded information. Not the most revolutionary thing in the world, but hey, technically the LED is just another form of light.
Give me a break. Threaded information has been in various clients since at least the late 80s in UNIX mail clients. Some of the best USENET readers were threaded as well, in the early 90s.
Just because mass-market MS doesn't know how to thread worth a shit doesn't make this new or revolutionary. What Google did manage to do was copy the threaded mailer of the 80s and give it a web interface using AJAX (an MS tech, btw) supporting a broad browser spectrum.
What about a cell phone? Most of them have massive early-termination fees.
You know - I used to think that way. Guess why they have those fees. Might it have to do with the "free" phone you got when you signed the contract? If you buy your own phone, that contract is a lot different, of course, then you've paid your "early termination fee" in the cost of the phone, usually.
Pretty much all the companies suck in one way or another. You have to be a smart shopper, and "Caveat Emptor" has never applied more than today. If you consider that all these stores deal in merchandise that devalues the moment it ships, you realize that it's no wonder they try everything they can to stay in business, much less make a profit. (Yes, I'm aware of the profits some of these bozos make, but it's not from my purchases... heh heh;)
In general, though, I tend to favor one set of stores over others (I happen to be fortunte to live in an area that has multiple stores of most of the electronics/tech sellers within just a 5 mile radius of my house, although only 1 microcenter. This means I have to search multiple ads for best deals if I really want to save money. It's lead to the purchase of a nice laser printer for $8, for example.
I saw a pair of 242s for $120 a few weeks ago. I'm still debating exactly what I want to buy, and how future proof I want to be. I was not really waiting for the Conroe announcement, but now I'm glad I did. (because of the resulting price drops:) The more I've thought about this, the more likely I'm going with a bottom of the barrel budget 939 3800+ setup. At an expected $160 or so, that's just way too much bang for the buck (I've got the other comoponents sitting around waiting to be dropped in, I would have to buy some for the other systems under consideration, making it at least double this cost)
You're correct about the dual core Opterons: they have not dropped yet.:( I'm guessing you won't see significant drops in any of the Opteron 2x and 8x series until K8L comes out, or Intel actually has a chip that works in that space. (I've yet to see a benchmark of Woodcrest in a 2P config to match up against a 2P Opteron)
With AMD's 65W EE series and full power requirements, I don't see that as big as a concern. Do note that the E6x00 series ate more power @ idle.
I will sheepishly admit that like all good/.'s, I didn't read TFA.;) The GP was based on several articles referenced earlier from ars, anandtech, and THG, among others. They all agree that Conroe has 15-30% better performance than AMD's top FX chip. No one has done a 2P benchmark with the 5150 that I've seen, so the performance of the 2P solution is still out. 4P+, as far as I know, doesn't exist except with AMD's solutions. However, even with 15-30% better raw performance, game performance is largely tied to GPU, so any of these choices are fine for gamers.
Concerning THG's proclaimation, I don't buy it. After reading the reviews, I was gung-ho on the E6600. What a chip! Great overclocking abilities, etc. Then I started thinking about my needs over the next day or so. Hmm, $500-$700 for a new E6600 based system, at best, or a sub $200 to $300 AMD 3800+ X2 system? After some more thought, the $200 AMD 3800+ 939 based system seems to be the winner I have the RAM for this system on my desk, I'd have to buy it for any of the other systems, adding an additional $130 or so minimum to the price.
Working with 2+ year old tech sometimes really pays off, especially if that tech is still near enough to the top (20% maximum, with OC'ing the 3800 properly). There's the additional advantage that for uses like HTPC's, you don't require the top of the line system, and this tech fits in perfectly.
If your HTPC isn't $ limitted, the super low power small form factor AMD 3800 might be what you want. (HDTV requires more horsepower, so....) Also, the AM2 revision F EE series and Core 2 are both supposed to offer better hibernate/low power modes, although the drivers may not yet exist to harness these abilities (something I read in infoworld, I think). And there's always the potential to underclock one of these if you don't need full CPU capabilities.
The initial tests show even the E6600 handily beating the best AMD has - @ only $319 MSRP. I don't doubt that a shared 4MB L2 cache is the major reason for the tremendous jump in performance. However, on Friday, AMD's 3800+ X2 drops to $149, and that's a pretty decent OC'er.
So, while at first I was going - oooo - E6600, I started thinking about where AMD is going, and whether I'd like a 2P+ system, and AMD seems to be the better buy in that arena. (I have yet to see a single benchmark of a 2P+ Intel Core 2 system.) Now granted, I'd have to go Opteron for future proofing 2P. I was considering Opteron anyways, and their prices have dropped unbelievably low at this point.
There's also another benefit of going AMD - dirt cheap RAM. Even if I went socket AM2, which gives me some other benies besides being brand new, DDR2 is dirt cheap right now.
They've "re-invented" USENET by the sound of your description. Or rather, what USENET would have evolved into if AOL had not connected to the internet before the web was born.
As for multithreaded performance, the Core 2 Duo is still no slouch, though. I don't think AMD's going to be wiping any floors with Intel any day soon.
On the unified cache, having 4MB of L2 cache available across both processors also aids multi-threaded code greatly by allowing both cores to access the same items in cache.
My statement about AMD wiping the floor with Intel - 4+ processors only, with the current design. It's quite obvious that single chip to single chip (1P to 1P) - Intel's the winner for at least the next 6-9 months, unless AMD pulls a surprise. In the 2P arena, I've yet to see any benchmarks, but analysis given by sites such as ars and anandtech both lead me to strongly suspect that Intel's offering will only be competitive against AMD's 2P setup, and will perform worse at 4+P (if Intel even has a player in the 4P space with Core 2).
Let me also say that I'm right now debating about going cheap and picking up a E6600 for my next box, or whether I should go for the 2P AMD AM2 boards. Considering I can start with a single cheap Opteron, or a dual core Opteron, or 2 of each, there's a lot of flexibility there. Also, as it's the new socket, it will most likely be a safe choice for 2 or more years, as far as being able to upgrade to newer CPUs, given AMD's history.
Multimedia editing is why the latter is a potential choice, I just haven't decided if I want to invest that much cash at this time, or just wait another year to do the AMD upgrade, when the new processors (K8L) have come out. The picture will be much clearer then, and the E6600 will do nicely for almost everything I wish to do today.
The same goes with this technology. Whomever gets it out of the gate first wins the "mindshare war" as we call it now. IIRC, the book "Predatory Marketing" covers how this works in detail - but they don't use the "mindshare" term in it.
Well, I guess AMD won that too, by that logic. After all - their dual core offerings beat the Core Duo out the door by a significant margin.
Honestly, when it really comes down to real tests of multi-threaded applications (mostly in the multi-media arena at the moment) AMD will wipe the floor with Intel just based on 3 year old architecture. However, in the single thread arena, Intel holds the crown at the moment. Dual core chips still help with single thread apps, as it will allow the single thread to run on it's own CPU.
When Intel's 4 core chips come out - unless they up the clock rate, it won't help any of the game benchmarks. The same will be true of AMD's 4x4. However, the multimedia multi-threaded benchmarks should point to a winner.
First:
System.out
System.err They work just fine, and exactly like you'd expect. Now whether the developers used System.err is a different story. Personally, these two items should never be used in production code. (There are exceptions, but start with saying never, and then they'll hopefully only be used when they should be used)
As for logging in general, does anyone use anything but Log4J? Yes, I know a lot use commons-logging, why still boggles my mind. When's the last time you moved a logging system from log4j to anything else? You may have moved from something else (Sun's implementation, cough cough) to log4j however. And log4j can easily be configured to radically pinpoint whatever logging you actually want, provided it was properly implemented in the code, and not hacked by some "I read Learn Java in 24 Hours"architect who wrapped it because it seemed easier to code logs to a single static "Logger" class.
From another developer that has done multi-JDK/J2EE simultaneous development, ZorinLynx nailed many many issues.
For the novice/sysadmin.
To run Java apps, install the JRE.
To develop (ie, compile) Java apps, install the JDK.
To run/develop J2EE apps, including servlets/JSP (same thing under the hood) decide on a container to run them within. This would be an application server, commonly referred to as an app-server, Tomcat, Resin, JRun, BEA WebLogic, IBM Websphere, Sun's implementation are all examples). Which container you choose will determine whether you need a JDK or not, and which one(s) if you do.
Follow the above process for each version/type you require to be installed, and keep each in their own directory structure. Make sure JAVA_HOME is properly defined for each one, and most likely you will define JAVA_HOME appropriately in the startup scripts for the containers, if you have multi-JDK/container installations. This probably is not a bad idea to do in your situation as part of your best-practices, as it will safe-guard you in case of later changes.
Lastly, let me make this one statement: if a professor "requires" an older version to teach his lesson plan, he doesn't know what he's teaching, with the following two exceptions:
to show evolution of language features
2) to display bad programming practices that were fixed in later versions (the Thread stop/suspend deprecation in 1.1 or 1.2 comes to mind, as well as the Thread/Socket timeout problems in 1.3.x)
The only other valid reason to run older JDKs in an education environment is that you have a third party proprietary application that only runs on version x, which shouldn't be the case for material taught in classes. (Note - I don't submit to the thought that professors will have custom code that can only run on version 'x'. They're teachers, keeping stuff current is what they're paid to do)
One of the things that kept me with the original Mozilla suite for so long, rather than switching to Firefox was the ability to trigger a search from the address bar. Now that Firefox can do the same (and not waste screen real estate with an unneccesary extra box), I've switched.
It's been possible for a long long long time. Create a Bookmark for Google with this as the URL: http://www.google.com/search?hl=en&btnG=Google+Sea rch&q=%s (minus the spaces/. puts in) and in the keyword field, type something you'll remember, like 'g'. Save and close the bookmark/manager.
Now, in the address bar, type "g <something to search for>" and hit return.
Voila - Google results page for <something to search for>.
PS: this can also be used for sites like dictionary.com (prefaced with 'd' for me), and any other site that uses a parameter in the URL.
You're absolutely right - SQL injection attacks are extremely simple to avoid (note - avoid, as in never being able to do them) Mostly it is incompetent and/or lazy code monkeys that are at fault.
I did another search before posting. I could find no multi-CPU tests, only single chip tests. So I don't know where you're getting your information about Woodcrest outperforming Opterons in 2P settings.
I did find mention that FB-DIMM has enough headroom for 2 cores, but cloverleaf (4 cores) will most likely start having memory bandwidth contention again.
AMD's memory architecture scales wildly (meaning very well) and also supports NUMA, another performance boost. Lastly, AMD will be coming out with the K8L architecture in about 6-9 months, which is purported to be a significant increase in performance and includes some other enhancements.
Now, with all that said, Core 2 is definitely the way to go for single CPU machines at this time, if you're in the market for a new top-end machine and need to buy all the parts.
First off - kudos to Intel for bringing out a chip that's competitive with AMD, finally. Personally, I too will most likely be buying one of the new E66xx+ chips. They are faster than AMD's best, in a single CPU setup. It depends upon whether I decide to "cheap" it out initially, and only go single CPU, or whether I go multi-CPU.
If you're looking at multiple CPU systems, the entire scenery changes and AMD is still on top, from what I've been able to see. Intel is still subject to the FSB, and still doesn't have a multi-CPU solution. AMD, meanwhile, rocks in this arena, with multiple CPUs being almost indistinguishable from single CPUs.
Lastly, if AMD comes out with 2-4MB cache CPUs, I think they'll at least be equivalent to if not better than the current Intel offerings, and that's with 2+ year old tech. I still eagerly await the next round of AMD CPUs, due in about 9 months, but that won't be for this next upgrade.
the article sold me on waiting for an E6600 for my next upgrade. And, I was definitely in the AMD camp before this - AMD owned pretty much every CPU crown I care about. The E6600 meets or exceeds every spec I care about over the top of the line AMD CPU, and [H]'s article sealed it.
What this means is that after 4 AMD CPUs and a single Intel CPU in the last 4 years, I'll be upgrading my workhorse system to an Intel chip.
Now, to be fair, if I owned any of the X2 or top end FX chips today, I wouldn't upgrade yet. That was something else the article made clear. I was waiting on the price drop of the X2s rumored for a couple of months as I wanted multiple CPUs/cores for video processing - I'm cheap, sue me;) So now I'm a very happy camper, and will eagerly be awaiting the E6600 to arrive in stores. Considering the OC potential of that chip, I'm sure I'll have to stand in line (figuratively) with everyone else that wants one.
Slashdot Mirror
Marketing and perception.
By Intel supporting "AMD64", they've admitted that AMD is better, as they have to support it. Since AMD exists, why would you buy someone else's chip if you can buy the real deal, especially at the same or cheaper cost? Intel has other issues as well, in that their chips until Conroe were barely in the ballpark of performance, which also hurt mindshare and market share.
So I beg to differ, and it matters a great deal.
They may soon. The major disaster of the teleco breakup etc was that the teleco's continue to own the lines and provide services. They do not own the lines, they were paid for by gov provided monopoly grants, and thus should truly be owned by the governments (local/state/fed) anyways. If cables are municipality owned, and service is provided by separate companies, then you can have true competition.
Of course, and the thing that keeps this from happening, is that then the affluent areas that desire the "best" will get it, while "under-privledged" areas (defined as those that have something less) will then "unlawfully be discriminated" against.
That could be regulated by imposing line fees to maintain and upgrade the network as needed, while allowing the affluent areas to upgrade when they want by paying for it themselves. A sort of public/private partnership where the public sector maintains ownership. It's not like they public "owner" can shift the cabling to another area, much like a road or water main cannot be shifted to another area. The output of power generation plants, however, can be.
He rants about UML as well, and the effects of UML and XML and WSDL and WebServices and design issues such as strong typing versus weak typing, although I couldn't figure out if he was for or against weak typing. For API/integration layers, I prefer "weak" typing, as your API becomes cleaner by passing more generic data. I've personally seen a project where the integration API was around 400 methods defined for the API to essentially support about 5 functions, because there were multiple parameters possible for each call.
What he was really ranting about was the "integration" problem, via data modeling, protocols, and architecture, and the fact that all the silver bullets for this have pretty much just shifted the burden of real work somewhere else. I agree with him on this. Whether that was intentional, I don't know, but everything he lists was pretty much spot on for integration. (He did mention a couple of side uses: XML for configuration and UML for Use Cases which do not necessarily apply to integration).
I recall one project where we had to write the design doc and use cases for a bit of code first, to follow process. The problem? Well, this particular design was an adapter for a properietary internal undocumented API. That means that to be able to write the design doc accurrately, we had to write the code.
Process violation! Alarm bells going off. Men in black suits swing down from the ceiling.
Ok, so it wasn't that bad - but we wrote the code while doing the design doc, and then spent the 4 weeks of "build" time refactoring the code to actually be maintainable at a leisurely rate. Actually wound up being a win-win situation. The only reason we were able to do this was because the normal UML guys (BAs in our case) were completely clueless about the internals of the system and didn't even know where to begin drawing use case diagrams. Otherwise, I'm sure we would have gotten a nice set of useless diagrams like "user sits at computer", "magic happens", "user happy", please fill in "magic happens".
Since AMD invented the tech, they can call it anything they want. AMD's original name was x86-64, and they then changed it to AMD64.
Intel probably has to use a different name, as EM64T does not fully implement everything in AMD64, not to mention the marketing disaster for Intel in supporting "AMD64".
So the names are what they are, and Intel mostly supports AMD64, much to their chagrin.
I'll have to admit I've never bothered. I use gmail whenever it's useful, and a host of other email addresses/clients when they're useful. Gmail, shockingly, isn't my primary email service provider.
I'm not entirely sure what you mean by this. Thunderbird, Outlook, and Eudora all allow searches, although Google's search is more straight forward (single line for all contents of an email). Additionally, the reason Outlook/Exchange's mail store is such a cluster is because it's a DB (I believe Outlook's PSTs also are deconstructed, just not as severely). Even Eudora, Elm, and Pine all offered search, with the search able to search all contents, as the mailbox was a single text file containing all messages.
I think this is the purpose of XML with XSLT currently. Except, in that case, it's self defining data (supposedly) with multiple possible transforms (XSLTs) that can convert that data into just about anything else.
I'm not sure I'm following your point on this question either. Is it supposed to be rhetorical? If so, it falls flat, as we've had the capability for at least a decade, and it's been widely available for at least 6 years. Heck, in 1999, I had a GB DB on my personal dev box. Matter of fact, in 1997, I had a TB of production data. I'm sure others were way way way larger earlier than I.
My mind's open, waiting for the next big thing. I'm also skeptical enough not to jump on every latest bandwagon. Ruby on Rails, for example, looks nice. However, it appears to suffer from all scripting langugage issues, namely performance and scalability. ESB/SOA sounds great, but it's no different than using a DB as your "bus". It has to be designed and built, today's version of ERP software.
I recall F5's BigIP Pro back in the late 90s. A really nice slick purple and silver box. Big "F5" on the front. Opened the $25+K box up and lo and behold - a P2-233. Oh, and that box was precisely what you think it was now that you know what was in it. A $25K boat anchor. (apoligies to respectable boat anchors everywhere).
I've heard recently that new deployments of F5's products still suffer some of the same faults we ran across in 99.
Give me a break. Threaded information has been in various clients since at least the late 80s in UNIX mail clients. Some of the best USENET readers were threaded as well, in the early 90s.
Just because mass-market MS doesn't know how to thread worth a shit doesn't make this new or revolutionary. What Google did manage to do was copy the threaded mailer of the 80s and give it a web interface using AJAX (an MS tech, btw) supporting a broad browser spectrum.
I love these statements. They're almost as good as "I'll never..." statements.
Please bookmark this statement somewhere where you'll be able to look at it at least once a year.
You know - I used to think that way. Guess why they have those fees. Might it have to do with the "free" phone you got when you signed the contract? If you buy your own phone, that contract is a lot different, of course, then you've paid your "early termination fee" in the cost of the phone, usually.
Pretty much all the companies suck in one way or another. You have to be a smart shopper, and "Caveat Emptor" has never applied more than today. If you consider that all these stores deal in merchandise that devalues the moment it ships, you realize that it's no wonder they try everything they can to stay in business, much less make a profit. (Yes, I'm aware of the profits some of these bozos make, but it's not from my purchases... heh heh;)
In general, though, I tend to favor one set of stores over others (I happen to be fortunte to live in an area that has multiple stores of most of the electronics/tech sellers within just a 5 mile radius of my house, although only 1 microcenter. This means I have to search multiple ads for best deals if I really want to save money. It's lead to the purchase of a nice laser printer for $8, for example.
I saw a pair of 242s for $120 a few weeks ago. I'm still debating exactly what I want to buy, and how future proof I want to be. I was not really waiting for the Conroe announcement, but now I'm glad I did. (because of the resulting price drops:) The more I've thought about this, the more likely I'm going with a bottom of the barrel budget 939 3800+ setup. At an expected $160 or so, that's just way too much bang for the buck (I've got the other comoponents sitting around waiting to be dropped in, I would have to buy some for the other systems under consideration, making it at least double this cost)
:( I'm guessing you won't see significant drops in any of the Opteron 2x and 8x series until K8L comes out, or Intel actually has a chip that works in that space. (I've yet to see a benchmark of Woodcrest in a 2P config to match up against a 2P Opteron)
You're correct about the dual core Opterons: they have not dropped yet.
With AMD's 65W EE series and full power requirements, I don't see that as big as a concern. Do note that the E6x00 series ate more power @ idle.
/.'s, I didn't read TFA. ;) The GP was based on several articles referenced earlier from ars, anandtech, and THG, among others. They all agree that Conroe has 15-30% better performance than AMD's top FX chip. No one has done a 2P benchmark with the 5150 that I've seen, so the performance of the 2P solution is still out. 4P+, as far as I know, doesn't exist except with AMD's solutions. However, even with 15-30% better raw performance, game performance is largely tied to GPU, so any of these choices are fine for gamers.
I will sheepishly admit that like all good
Concerning THG's proclaimation, I don't buy it. After reading the reviews, I was gung-ho on the E6600. What a chip! Great overclocking abilities, etc. Then I started thinking about my needs over the next day or so. Hmm, $500-$700 for a new E6600 based system, at best, or a sub $200 to $300 AMD 3800+ X2 system? After some more thought, the $200 AMD 3800+ 939 based system seems to be the winner I have the RAM for this system on my desk, I'd have to buy it for any of the other systems, adding an additional $130 or so minimum to the price.
Working with 2+ year old tech sometimes really pays off, especially if that tech is still near enough to the top (20% maximum, with OC'ing the 3800 properly). There's the additional advantage that for uses like HTPC's, you don't require the top of the line system, and this tech fits in perfectly.
If your HTPC isn't $ limitted, the super low power small form factor AMD 3800 might be what you want. (HDTV requires more horsepower, so....) Also, the AM2 revision F EE series and Core 2 are both supposed to offer better hibernate/low power modes, although the drivers may not yet exist to harness these abilities (something I read in infoworld, I think). And there's always the potential to underclock one of these if you don't need full CPU capabilities.
The initial tests show even the E6600 handily beating the best AMD has - @ only $319 MSRP. I don't doubt that a shared 4MB L2 cache is the major reason for the tremendous jump in performance. However, on Friday, AMD's 3800+ X2 drops to $149, and that's a pretty decent OC'er.
So, while at first I was going - oooo - E6600, I started thinking about where AMD is going, and whether I'd like a 2P+ system, and AMD seems to be the better buy in that arena. (I have yet to see a single benchmark of a 2P+ Intel Core 2 system.) Now granted, I'd have to go Opteron for future proofing 2P. I was considering Opteron anyways, and their prices have dropped unbelievably low at this point.
There's also another benefit of going AMD - dirt cheap RAM. Even if I went socket AM2, which gives me some other benies besides being brand new, DDR2 is dirt cheap right now.
They've "re-invented" USENET by the sound of your description. Or rather, what USENET would have evolved into if AOL had not connected to the internet before the web was born.
On the unified cache, having 4MB of L2 cache available across both processors also aids multi-threaded code greatly by allowing both cores to access the same items in cache.
My statement about AMD wiping the floor with Intel - 4+ processors only, with the current design. It's quite obvious that single chip to single chip (1P to 1P) - Intel's the winner for at least the next 6-9 months, unless AMD pulls a surprise. In the 2P arena, I've yet to see any benchmarks, but analysis given by sites such as ars and anandtech both lead me to strongly suspect that Intel's offering will only be competitive against AMD's 2P setup, and will perform worse at 4+P (if Intel even has a player in the 4P space with Core 2).
Let me also say that I'm right now debating about going cheap and picking up a E6600 for my next box, or whether I should go for the 2P AMD AM2 boards. Considering I can start with a single cheap Opteron, or a dual core Opteron, or 2 of each, there's a lot of flexibility there. Also, as it's the new socket, it will most likely be a safe choice for 2 or more years, as far as being able to upgrade to newer CPUs, given AMD's history.
Multimedia editing is why the latter is a potential choice, I just haven't decided if I want to invest that much cash at this time, or just wait another year to do the AMD upgrade, when the new processors (K8L) have come out. The picture will be much clearer then, and the E6600 will do nicely for almost everything I wish to do today.
Well, I guess AMD won that too, by that logic. After all - their dual core offerings beat the Core Duo out the door by a significant margin.
Honestly, when it really comes down to real tests of multi-threaded applications (mostly in the multi-media arena at the moment) AMD will wipe the floor with Intel just based on 3 year old architecture. However, in the single thread arena, Intel holds the crown at the moment. Dual core chips still help with single thread apps, as it will allow the single thread to run on it's own CPU.
When Intel's 4 core chips come out - unless they up the clock rate, it won't help any of the game benchmarks. The same will be true of AMD's 4x4. However, the multimedia multi-threaded benchmarks should point to a winner.
First:
System.out
System.err
They work just fine, and exactly like you'd expect. Now whether the developers used System.err is a different story. Personally, these two items should never be used in production code. (There are exceptions, but start with saying never, and then they'll hopefully only be used when they should be used)
As for logging in general, does anyone use anything but Log4J? Yes, I know a lot use commons-logging, why still boggles my mind. When's the last time you moved a logging system from log4j to anything else? You may have moved from something else (Sun's implementation, cough cough) to log4j however. And log4j can easily be configured to radically pinpoint whatever logging you actually want, provided it was properly implemented in the code, and not hacked by some "I read Learn Java in 24 Hours" architect who wrapped it because it seemed easier to code logs to a single static "Logger" class.
For the novice/sysadmin.
Follow the above process for each version/type you require to be installed, and keep each in their own directory structure. Make sure JAVA_HOME is properly defined for each one, and most likely you will define JAVA_HOME appropriately in the startup scripts for the containers, if you have multi-JDK/container installations. This probably is not a bad idea to do in your situation as part of your best-practices, as it will safe-guard you in case of later changes.
Lastly, let me make this one statement: if a professor "requires" an older version to teach his lesson plan, he doesn't know what he's teaching, with the following two exceptions:
The only other valid reason to run older JDKs in an education environment is that you have a third party proprietary application that only runs on version x, which shouldn't be the case for material taught in classes. (Note - I don't submit to the thought that professors will have custom code that can only run on version 'x'. They're teachers, keeping stuff current is what they're paid to do)
It's been possible for a long long long time. Create a Bookmark for Google with this as the URL:
http://www.google.com/search?hl=en&btnG=Google+Se
and in the keyword field, type something you'll remember, like 'g'. Save and close the bookmark/manager.
Now, in the address bar, type "g <something to search for>" and hit return.
Voila - Google results page for <something to search for>.
PS: this can also be used for sites like dictionary.com (prefaced with 'd' for me), and any other site that uses a parameter in the URL.
You're absolutely right - SQL injection attacks are extremely simple to avoid (note - avoid, as in never being able to do them) Mostly it is incompetent and/or lazy code monkeys that are at fault.
I did another search before posting. I could find no multi-CPU tests, only single chip tests. So I don't know where you're getting your information about Woodcrest outperforming Opterons in 2P settings.
I did find mention that FB-DIMM has enough headroom for 2 cores, but cloverleaf (4 cores) will most likely start having memory bandwidth contention again.
AMD's memory architecture scales wildly (meaning very well) and also supports NUMA, another performance boost. Lastly, AMD will be coming out with the K8L architecture in about 6-9 months, which is purported to be a significant increase in performance and includes some other enhancements.
Now, with all that said, Core 2 is definitely the way to go for single CPU machines at this time, if you're in the market for a new top-end machine and need to buy all the parts.
First off - kudos to Intel for bringing out a chip that's competitive with AMD, finally. Personally, I too will most likely be buying one of the new E66xx+ chips. They are faster than AMD's best, in a single CPU setup. It depends upon whether I decide to "cheap" it out initially, and only go single CPU, or whether I go multi-CPU.
If you're looking at multiple CPU systems, the entire scenery changes and AMD is still on top, from what I've been able to see. Intel is still subject to the FSB, and still doesn't have a multi-CPU solution. AMD, meanwhile, rocks in this arena, with multiple CPUs being almost indistinguishable from single CPUs.
Lastly, if AMD comes out with 2-4MB cache CPUs, I think they'll at least be equivalent to if not better than the current Intel offerings, and that's with 2+ year old tech. I still eagerly await the next round of AMD CPUs, due in about 9 months, but that won't be for this next upgrade.
Thanks for sealing the deal - nice article! I'll be eagerly awaiting the E6600, with probably everyone else.
the article sold me on waiting for an E6600 for my next upgrade. And, I was definitely in the AMD camp before this - AMD owned pretty much every CPU crown I care about. The E6600 meets or exceeds every spec I care about over the top of the line AMD CPU, and [H]'s article sealed it.
;) So now I'm a very happy camper, and will eagerly be awaiting the E6600 to arrive in stores. Considering the OC potential of that chip, I'm sure I'll have to stand in line (figuratively) with everyone else that wants one.
What this means is that after 4 AMD CPUs and a single Intel CPU in the last 4 years, I'll be upgrading my workhorse system to an Intel chip.
Now, to be fair, if I owned any of the X2 or top end FX chips today, I wouldn't upgrade yet. That was something else the article made clear. I was waiting on the price drop of the X2s rumored for a couple of months as I wanted multiple CPUs/cores for video processing - I'm cheap, sue me
with mice, instead of joysticks....