Oracle To Halve Core Count In Next Sparc Processor 200
angry tapir writes "Oracle will halve the number of cores in its next Sparc processor and instead improve its single-thread performance, a weak area for the chip but one that's important for running large databases and back-end applications. The next Sparc chip on Oracle's roadmap, the T4, will have eight cores on each chip, down from 16 in the current Sparc T3."
Concentrate on ST perf? What does this mean? (Score:4, Interesting)
Does it maybe mean more register windows?
Because that would certainly help things like Java, and presumably oracle.
Anybody know how often a large query spills registers?
Re: (Score:3)
I assume they're talking about improving their multiple dispatch, so that they can go from 3 - 4 (or is it 4-5) ops in parallel on a single core. And probably bring up the clock speed. 8 cores at 2ghz beats 16 cores at 1.5 ghz for a lot of applications.
Re: (Score:2)
There are all sorts of common database paths where slow cores are troublesome. Acquiring locks, access to shared memory, writes to redo logs; these are all examples of things that can end up serializing more than is optimal if individual cores are slow. Because of this, half as many cores that run at twice the speed is not the same net speed; it's probably faster, because each process is introducing less contention. Reducing the time things hold onto shared resources is really important for database work
Same as always (Score:2)
I'm pretty sure this was on Suns roadmap. Higher throughput per thread. Higher clock speeds. So have Oracle deviated from the plan Sun had?
incoherent (Score:2)
I don't think the author had any understanding of the history of SPARC or Oracle (Sun)'s product linup. Here is an informative interview from the useful Sun hardware oriented blog on the subject http://www.c0t0d0s0.org/ [c0t0d0s0.org] http://www.oracle.com/us/corporate/innovation/innovator-hetherington-191304.html [oracle.com]
Sparc (Score:5, Informative)
The reduction in cores from 16 to 8 was part of the Sparc road-map [channelregister.co.uk] before Sun was acquired by Oracle. Despite a lot of speculation it appears Oracle is following through with the plans they bought from Sun.
Keep the Cores; Make Them Faster (Score:3)
Reducing the core count lets Oracle make each core bigger, to add features making each faster. But can't Oracle keep the same core count, and instead of increasing the core count in the next generation the way most other CPU makers will, just add circuits to each existing core? Is it really necessary to reduce the count? Process size will probably also be shrinking in that generation, and new tricks developed, as usual. Can't Oracle just make a bigger chip, and also keep the benefits of the high core count Sun already achieved?
Re: (Score:2)
Reducing the core count lets Oracle make each core bigger, to add features making each faster. But can't Oracle keep the same core count, and instead of increasing the core count in the next generation the way most other CPU makers will, just add circuits to each existing core? Is it really necessary to reduce the count? Process size will probably also be shrinking in that generation, and new tricks developed, as usual. Can't Oracle just make a bigger chip, and also keep the benefits of the high core count Sun already achieved?
From what it sounds like, Oracle could be devoting the extra space to cache. A large cache can go a long way in CPU-bound operations; or help make a very fast database.
Making a bigger chip isn't as easy as it sounds. As the die size increases, the probability of a defect within the die increases. (Imagine that you have 5 specs of dust on a wafer, if the die size is larger then the ratio of good to bad is worse.) Large die sizes will also have problems with heat distribution, or could limit total clock spee
Re: (Score:2)
This is why you build each group of cores and the corresponding cache on a separate die, test and bin each die independently, then wire them together [wikipedia.org] inside the package. Sure, there's the added potential for interconnect failure, but so long as you test the integrated module before you epoxy the lid on, you should be able to salvage those parts.
Re: (Score:2)
Oracle could have always gone the route IBM did with the POWER7 chips and have the best of both worlds. With Power7, you can turn half the cores off. The remaining cores will use the cache on the counterparts that are off, and the clock speed gets a decent bump.
This is what Oracle should have done -- if someone is doing a task that is easily split up into parallel parts, or using a lot of domains/VMs, allow for this. If they need more oomph per core, have half the cores flip off, and the others use their
Re: (Score:2)
An increasing number of cores tends to be a challenge to keep clocked at a high speed. Every CPU developer struggles with this, and they all market higher clocked lower core count parts. Choosing to go for a lower core count in your design phase makes a lot of sense if you are single thread bound.
I'll see your 16 cores and raise you 1024... (Score:2)
Sanity, at last! (Score:3, Insightful)
When will people realize that not everything runs better on more cores, especially stuff that's highly dynamic say like a database query which is effectively a long sequence of conditionals. You talk to people and the first thing they ask is "yeah, but how many cores does it have"... it's like multithreading didn't exist until dualcore cpus.
A cpu has a limited amount of processing power; some things you can only do in sequence ergo you can't do them in parallel ergo you're limited by the core-speed ergo you're fucked with 16 core 1GHz machine against a 1 core 2GHz machine.
Re: (Score:2)
Not everything runs better on more cores, but so many things scale close to linearly with cores that it has become what the majority rightly want. Basically every business function that has to support N users can be partitioned over up to N cores, the more cores you pack per chip, the less chips and sockets and boxes you have to buy.
Not what I meant Oracle! (Score:2)
I said "Can HAVE cores plz"!!!!
Re:and? (Score:5, Insightful)
I don't think losing some grumpy OpenOffice and OpenSolaris users qualifies as "everyone has already decided to move away from Oracle". Java will be used for a long time to come, and has big time penetration in the enterprise world, as does Oracle's database offerings. And while I agree that "cores" is a buzz word, I'm not so sure at that level it's all down to the quality of marketing. We're talking very big customers who in a lot of cases have very specific needs, and tailoring your hardware to fit with the market your serving isn't a dumb thing to do.
Re:and? (Score:5, Interesting)
At the very least, Oracle has introduced a great deal of uncertainty into Sun products, so you have to ask "What does Sun hardware offer than other hardware doesn't?". With all the bad press, they have an uphill battle converting people to Sun from other platforms, and for those who have a choice, what *exactly* is the big benefit that can't be purchased from someone else for less? Obviously they will sell some product, (and yes, there is obviously some benefits to some customers, but not all) but I don't see how they are going to grow any new significant market share. There is a lot of options out there, and it isn't that expensive to throw a lot of cores at a problem. Any purchaser has to be wary and consider other options with a more open mind.
The problem is that Oracle is *perceived* to not be that concerned about the Sparc platform, whether it is true or not. If the public (or at least the ones making the buying decisions) thinks that they will just be phasing it out or letting it die on the vine, it doesn't matter if it is true or not. I just think Oracle has done a terrible PR job during the whole Sun transition and it will bite them in the ass over the next few years. They certainly haven't made ANY new friends.
Re: (Score:2)
Sun's Sparc processors have a lot of cores which are great for large amounts of concurrent connections to either an (open source) database, file or webserver (as most of the open source designs spawn processes for a limited number of connections).
I think Oracle is trying to compete with Sparc processors in an area Sparc processors were never designed for -- low-end server systems.
Sparc is great with a well designed system and application underneath it and will beat the crap out of a 48U rack of x86 machines
Re: (Score:2)
The niche is narrower than you suggest. Current sparc procesors are great for highly transactional systems that are low on computation. This means databases which are really acting as fancy smart datastores for various applications.
Certainly that's how databases were traditionally originally considered, but it's pretty common these days for database loads to include computational demands, which don't really fly on Sparc.
Meanwhile a lot of other loads are really foolishly parallelisable, so datasets with l
Re: (Score:3)
Sun's Sparc processors have a lot of cores which are great for large amounts of concurrent connections to either an (open source) database, file or webserver (as most of the open source designs spawn processes for a limited number of connections).
The T series are great web servers. As a db server, your mileage will vary and usually the result is not that great. Application servers also don't fare well on the T systems. Problem is that the T servers are great if you can run multiple instances of the same thing, or if the app is truly multi-threaded. In practice, multi-threaded apps are almost non-existant. Well, at least the apps that you want to run on Solaris are problematic.
Sparc is great with a well designed system and application underneath it and will beat the crap out of a 48U rack of x86 machines on those specific applications in only 6U worth of space. The cost however is heavy initially with the cheapest machinery coming in at ~$10k+ and easily going into the 100k+ for a full set.
Horsefeathers.
Maybe back in Y2K that was true but not now. In comp
Re:and? (Score:4, Informative)
You can even create two domains on the box that act like two separate machines, if you need electrical separation or want to build HA in-a-box. You can replace HW on-the-fly in the M5000. You can put more than 256GB RAM into it, if you want to. You can set up RAM mirroring in case you needed it. We are talking here real enterprise features, not just raw mips.
Anyways, we are comparing here apples to oranges, sparc to x86. If your platform decision goes towards x86, then go for it. In this case, however I would definitely consider the SF X4470 or the X4800 servers if you need raw power. Or an Exadata if you need pretuned, preconfigured RAC on X86 - there you will find the X4800s as well
Re: (Score:2)
The niche is narrower than you suggest. Current sparc procesors are great for highly transactional systems that are low on computation. This means databases which are really acting as fancy smart datastores for various applications.
Certainly that's how databases were traditionally originally considered, but it's pretty common these days for database loads to include computational demands, which don't really fly on Sparc.
Meanwhile a lot of other loads are really foolishly parallelisable, so datasets with low
Re: (Score:2)
More cores. Oh, wait....
crypto (Score:4, Informative)
At the very least, Oracle has introduced a great deal of uncertainty into Sun products, so you have to ask "What does Sun hardware offer than other hardware doesn't?". With all the bad press, they have an uphill battle converting people to Sun from other platforms, and for those who have a choice, what *exactly* is the big benefit that can't be purchased from someone else for less?
Do you care about crypto at all? If so, the T-series CPUs have on-die MD5, SHA-1, SHA-2 family, DES, 3DES, AES (multiple modes of operation), RC4, RSA (up to 2Kb), and ECC acceleration, as well as RNG. The T3s can do almost 80 Kop/sec for RSA 1024. All you have to do is link against the Solaris-provided OpenSSL library and call the appropriate "engine" APIs to activate things (this is built-in to a lot of FLOSS software already (e.g., Apache)).
The T5220 (T2 processor, the T3 just came out) has been benchmarked as doing 44 Gb/s AES128: and that's on the crypto co-processors, so the "real" processors are free to do "actual" work--like serving HTTP requests. At the same time as this, the T2 can also do 38 Kop/sec of RSA 1024. At the time this benchmark was published, a quad-core Xeon 3 GHz could do about 8 Gb/s AES1028 and 9 Kop/s of RSA1024 signing--with little to nothing left over to do anything else.
So you ask, "what can these systems do?" Well, how about: instead of paying for a bunch layer of load balancers to do SSL and RSA, and a whole bunch more machines to do actual web requests, why not just buy a lot fewer T2s (now T3s), and save power, cooling, and rack space?
The T-series is not good at everything, but for the mutl-threaded, multi-client workloads it was designed for it works very well.
Re: (Score:2)
Do you care about crypto at all? If so, the T-series CPUs have on-die MD5, SHA-1, SHA-2 family, DES, 3DES, AES (multiple modes of operation), RC4, RSA (up to 2Kb), and ECC acceleration, as well as RNG. The T3s can do almost 80 Kop/sec for RSA 1024. All you have to do is link against the Solaris-provided OpenSSL library....
No one cares, seriously. encryption acceleration/decryption is not going to save Sun's hardware business nor stop it from losing money. For those that need them they have had hardware accelerated encryption and decryption for some time.
Re: (Score:2)
"The problem is that Oracle is "perceived to not be that concerned about the Sparc platform"
I don't know where people get that impression. Hasn't Oracle always been saying that their customers use Solaris/SPARC more than any other platform to deploy Oracle products on? This move makes sense in that regard as fewer faster cores are better to run Oracle's database on.
Oracle bought sun to be able to deliver an end to end solution to it's customers and extract more revenue from them. A recent interview with McNealy indicated that Sun's lack of a DB solution allowed Oracle to get more revenue from Sun
Re: (Score:2)
Oracle has never been very interested in small business, who are the only ones potentially walking away here. Big business knows what Oracle can do for them and knows how to sign a proper contract with all the guarantees they need. I dare argue that most of these bigger clients care more about keeping Oracle on board than they care about a particular hardware brand. Oracle may in fact switch a number of big boys to Sparc who wouldn't have used it otherwise.
Re: (Score:2)
Solaris is a great o/s. Sun went from one weird CEO to another with no hope for redemption.
When Adrian Cockroft jumped to eBay, you knew there was trouble in the henhouse. Hi tech company that undermined their core technology brain trust.
Sad sad sad.
Re: (Score:2)
It's not that everyone has moved away from Oracle. They've moved away from "Sun/Oracle".
You left a very important bit out.
Even Oracle moved away from "Sun/Oracle".
So this isn't just about disgruntled Star Office users.
It's also about Oracle's core paying customers.
Re: (Score:2)
I think the OP was referring to Oracle's hardware offerings. Yes, Java, mySQL, and OpenOffice will be around for a long time.
Re:and? (Score:4, Interesting)
I don't think losing some grumpy OpenOffice and OpenSolaris users qualifies as "everyone has already decided to move away from Oracle".
The original statement was "Sun/Oracle" not "Oracle" and was referencing h/w sales.
Four years ago, we (network/connectivity company) spent over $50 million annually on Sun servers (h/w only, support was on top of that). That is now almost zero. We still buy lots of servers but they are almost all x86 blades. Sun h/w just can't compete in any of the import aspects that affect h/w purchase decisions (performance, power consumption, stability, reliability, capital cost, support cost, TCO, lifetime cost, transition costs). Java is a non-issue and has nothing to do with server purchasing decisions. I know we are not alone in dropping Sun as a vendor.
Note that we were a dyed-in-the-wool Sun/Solaris shop with a terrific core of dedicated Sun/Solaris admins. Nice thing about all that expertise is that, technically speaking, they had little trouble transferring their skill sets to other h/w and o/s platforms. Hardware and o/s vendors were happy to provide transition training. The cost of transition was a blip in our annual spend. Almost no one wants to go back even though Solaris is a superior o/s in many ways (io performance, network stack, scheduler, SMP).
It will be interesting to see what Oracle reports on Sun h/w sales.
Re: (Score:2)
People have been moving away from Sun since time was time. I got my first sysadmin job because of my Linux/x86 experience and because I had at least seen SunOS before, and I was hired into a fully-Sun shop which wanted to start rolling out x86 PCs to desktops... which I did. I could deploy two PCs with 20" monitors for the price of a single used SS2, which was the "nice" machine on the user desktop, we still had 1s and 1+s in service.
Re: (Score:2)
I don't think losing some grumpy OpenOffice and OpenSolaris users qualifies as "everyone has already decided to move away from Oracle". Java will be used for a long time to come, and has big time penetration in the enterprise world, as does Oracle's database offerings.
Seriously, who mods this crap insightful?
In case you didn't get the memo then the OP said Sun/Oracle, and over the past ten years Sun slowly went bust because Solaris and SPARC users jumped ship to x86 and Linux systems, in particular. Oracle stated that Sun were even losing $100 million per month. If they're running Java they're running it there. Oracle database have been run successfully for a very long time on such systems, and a lot of those customers have already jumped ship. It's going to be a tall
Re: (Score:2)
If everyone did as slashdot wanted, you wouldn't see much of .NET around either, but somehow I doubt slashdot commends the IT industry. The reality is that all the biggest software houses - Micrsoft, IBM, Oracle, SAP, CA etc. are an oligopoly, sure you may shuffle the users around a little as they move from one uncooperative money-hungry giant to the other but they don't leave. While PostgreSQL might be an okay alternative to just SQL Server or Oracle the database, they just don't deliver the whole range of
Re: (Score:2, Insightful)
That's because the industry is financially dominated by clueless customers who purchase what they do not really understand and do not wish to learn. This is true both in the case of corporate management (the techies don't usually make the purchasing decisions) and i
Re: (Score:2)
Ok, just googled "mysql profile" and got:
http://dev.mysql.com/tech-resources/articles/using-new-query-profiler.html [mysql.com]
Re: (Score:2)
Actually, this isn't as far off as I first thought. It lacks a lot of the bells and whistles I am used to... I don't see filtering capabilities and I don't see real time monitoring, but it is a lot better than what I was using a couple years ago. I might have to give this another look.
Thanks.
Re: (Score:2)
If I moved to mySQL, what tool do they have to replace SQL Profiler?
I believe you missed my point. The bigger question is: why should it be difficult to find a truly good replacement when there is such demand for this kind of useful tool?
Why, it's almost as though a few major players have extreme dominance of this market and can get away with that because many of their customers are not tech-savvy.
That's what my previous post was addressing.
Re: (Score:2)
It's probably all down to economics.
How much would it cost to purchase an SQL profiler, supporting it and paying people to work with it.
And how much would it cost to simply add another CPU or database node?
Re: (Score:2)
And there's one thing in particular they don't deliver: cost.
Sure, if you switch to open source you might save your company a million dollars, but you can only do that once. Stick with Oracle and you can negotiate a million-dollar enterprise database contract every year! Much more impressive.
Sadly I am not entirely sure I'm joking.
Re:and? (Score:5, Informative)
No. Nobody's moving away from Oracle - that rhetorical question doesn't make you sound like a smartass, but rather its less intelligent opposite.
What matters to Oracle's customers who buy Sun hardware is that their databases run as fast as possible, as that's the limiting factor on those customers' businesses. That's why Oracle bought Sun: to compete with IBM, which runs DB2 on IBM CPUs at the high end, the HW and SW tweaked to work best together for that operation.
Reducing the number of cores isn't designed to help. It's designed to leave that amount of transistors on the CPU available for making Oracle DBs run as fast as possible in the few simultaneous threads that Oracle needs for DB performance.
Oracle is not selling CPUs to the mass market that can't tell the difference among products, mostly because they don't have a benchmark that describes their use profile specifically. Oracle is selling to customers who pitch $:TPM to their bosses. And the $:TPM buzzword is not only not going out of style, it's what continues to drive $ to Oracle.
Re: (Score:2)
Gosh, somebody who really gets it. Sorry, no mod points today.
Re: (Score:2)
No. Nobody's moving away from Oracle - that rhetorical question doesn't make you sound like a smartass, but rather its less intelligent opposite.
What matters to Oracle's customers who buy Sun hardware is that their databases run as fast as possible, as that's the limiting factor on those customers' businesses.
Bullshit. Who is buying SUN hardware anymore after their buyout? And after Oracle changed prices on the OS?
That's why Oracle bought Sun: to compete with IBM, which runs DB2 on IBM CPUs at the high end, the HW and SW tweaked to work best together for that operation.
Maybe I'm young, or whatever, but in all the "big enterprise costumers" where i've been working i've never ever seen a DB2. I have seen in order of frequency: Oracle DB from ~8 to 11r1 then Sybase. On this operating systems, in order of frequency: Solaris, HPUX, Linux, AIX.
All of them had a DB supporting SAP BTW, and there i think Oracle is pointing.
Reducing the number of cores isn't designed to help. It's designed to leave that amount of transistors on the CPU available for making Oracle DBs run as fast as possible in the few simultaneous threads that Oracle needs for DB performance.
As I'm not a DBA i cant say much on that. Though i re
Re: (Score:3)
You make absolutely no sense.
People using Oracle will be buying SUN hardware in their next upgrade, it's what Oracle says they must use, it will be what they are using - that's the whole point of buying Oracle, they take the blame if it doesn't work, but you *must* buy their medicine.
If we are using emperical evidence, I would make the claim that no one is using Oracle in corporations, because I've never seen anyone use it when working for mega corps. I have however seen MySQL, DB2 and MSSQL - but unlike yo
Re: (Score:2)
No. Nobody's moving away from Oracle - that rhetorical question doesn't make you sound like a smartass, but rather its less intelligent opposite.
It would help if you could actually read. He said Sun/Oracle, which clearly means the old Sun and new business Oracle is now running, not that people are moving off Oracle databases en masse.
What matters to Oracle's customers who buy Sun hardware is that their databases run as fast as possible, as that's the limiting factor on those customers' businesses.
They're already doing that and have done for some time, and many have done it by migrating off Sun hardware and software. That's why Sun got bought out.
Reducing the number of cores isn't designed to help. It's designed to leave that amount of transistors on the CPU available for making Oracle DBs run as fast as possible in the few simultaneous threads that Oracle needs for DB performance.
People have solved single threaded performance over the past ten years by moving to x86, hence the current dire state of Sun's hardware business. IBM operates in a diffe
Re: (Score:3)
And that's why IBM is raking in ever more $BILLIONS in mainframe sales.
You and the post you're defending are like a press release from 1989.
Re: (Score:2)
IBM is raking in billions in sales of x86 clusters running Linux and of POWER-based mainframes running Linux. I have been hearing more and more nerds pitching DB2, which means Oracle must have finally crufted itself beyond IBM.
Re: (Score:2)
relax dude, why are all your posten so serious
Re: (Score:2)
U R _so_ not 1337!!!1!!12!
Re: (Score:2)
They are selling to people that make choices based on hard numbers and not buzz words. Hopefully that is.
There is still a market for big iron like IBMs Power and ZSystems as well as Sparc.
Re: (Score:2)
I understand what you are saying, but the question is why would someone invest in Sparc unless they are already committed to the platform? It would seem that IBM would be a safer choice, and very possibly more cost effective, if not clusters of more generic boxen. Google has the largest platform that I am aware of, and they have shown you can do it with clusters of otherwise commodity grade equipment. I don't think Facebook is running on Sparc either. Obviously enough are to keep them stamping out chips
Re: (Score:2)
Re: (Score:2)
Well not all apps scale well to clusters. Things like billing apps are a good example. For anything involving money you want and ACID data base. If Facebook forgets a few thousand status updates or if they don't show up on some friends wall it isn't a big deal. If a few thousand credit card transactions don't make it into the system....
That is why you Power, Sparc, and ZSystems are still in use.
Re:and? (Score:5, Interesting)
Not trying to be a smartass, but does it really even matter? Hasn't almost everyone already decided to move away from Sun/Oracle, excepting those with a tremendous investment in that area?
I agree. That boat sailed about two years ago for us and we were a major Sun shop ( > 10,000 servers four years ago ). We are now almost exclusively VMware on Intel blades, mostly from IBM, or IBM P systems with IBM o/s. Vendors that were Solaris have moved to Linux. We briefly considered x86 Solaris but there was too much uncertainty with the on-again/off-again support for that platform.
Oracle DB is still at the core of our internal corporate computing because of an excellent licensing deal but we use alternatives for consumer facing services.
IMHO, the Sparc64 is hellishly expensive for the performance provided and the iron in the rack is heavy and power hungry. Nobody likes the M series servers. We don't like buying it, we don't like racking it, and we don't like what it does to our data center power distribution configuration.
The T series are not badly priced and are excellent low power consumption web servers but suck at anything that is single threaded. Almost all application software is effectively single threaded: either there is an explicit single execution path or the app has attempted threading but the threads depend on a core path that is single threaded. Usually I can get a brand name Intel multicore box that provides 4x the execution performance at a lower cost, ... and with 3 yr onsite h/w service thrown in.
Everything about Sun h/w is out of sync with what customers want.
Oracle is almost clueless when it comes to hardware sales and development. Try "www.sun.com"... you get a redirect to the Oracle home page and then you have to search for a link to the server product lineup. It's almost as if they are hiding the fact that they have a hardware product to sell. I don't think the Oracle brain trust knows what to do with Sun h/w and the Solaris o/s.
Oracle is a single core product software shop. That's their whole corporate culture and they don't really do other things well. What were they thinking when they bought Sun's h/w division? Possibly they could have just bought the rights to Solaris and developed it for the x86 h/w and made something of it. An argument could be made for the similarity between db and os development. But h/w? It's a black hole for Oracle. SPARC is dead. Write it off.
Now if IBM had bought Sun and turned their R&D folk loose... there would have been hope for Solaris. Too bad so sad.
Re: (Score:2, Informative)
When I was on the job hunt, I saw exactly this. People took two paths:
1: An exodus from SPARC hardware to x86 servers or blades, and a software exodus from Solaris to RedHat Linux or even Windows.
2: A retooling and a move to IBM POWER6/POWER7 hardware. This hardware has VM support built in from the hardware up. In fact, dedicating a hardware box to a machine is passe, as opposed to having two VIO servers and a LPAR. (LPARs reboot extremely fast because it doesn't have to configure real-life hardware d
Re: (Score:2)
Yup and Yup. You got it exactly. That's what we did and that's what our competition has done.
Spot on.
Re: (Score:2)
Re: (Score:2)
M servers are ugly no matter how you look at them. We had a network h/w vendor whose management app only runs on Solaris and is only certified for the M series. We bought the freakin' h/w but everyone hates it. The worst thing is if you need support you get an idiot from a contracted office IT support company (name left out to protect the incompetent). These guys are used to office PCs and printers and have no clue about 7x24 services and have little experience with the h/w they support. They are alw
Re: (Score:2)
Alternative timeline: Sun should have seen the writing on the wall when NetBSD and Linux started to get popular in the early nineties. Why? Because a lot of us ex-Sun jockeys really, really wanted a Sun at home but just couldn't afford to run even a second hand IPX workstation when a PC was so cheap. Sure the PC was a piece of junk, but loaded up with X windows and all the Gnu tools, you could get most of your support scripts working from home and started not worrying so much about having a Sun.
If they'
Re: (Score:2)
Sun needed heavy investment and lots of R&D to continue to compete in the h/w arena. They didn't have it and Fujitsu was no help. IBM, Intel and AMD poured tons of $$$ into chip development while Sun kept missing release dates. While Intel and IBM developed high-density fabrication methods with remarkable decreases in execution cycle times, Sun was stuck with technology that was rapidly being left behind.
On the o/s side, Solaris is a great stand-alone o/s but Sun almost totally missed the transition
Re: (Score:2)
I was in the same situation as you. I wanted a sparc machine at home for work related and development use back in the 90s but I just couldn't justify (or frankly at the time afford) one. Linux wasn't really up to much at the time but it was better than nothing (or windows) so I got a cheap PC , shoved slackware on it and never looked back.
If Sun has priced their desktop systems realistically it might not in the long run have saved them but it certainly might have helped in some small way. Charging 10K for a
Re: (Score:2)
Oracle DB is still at the core of our internal corporate computing because of an excellent licensing deal but we use alternatives for consumer facing services. ...
Everything about Sun h/w is out of sync with what customers want.
Oracle is almost clueless when it comes to hardware sales and development. Try "www.sun.com"... you get a redirect to the Oracle home page and then you have to search for a link to the server product lineup. It's almost as if they are hiding the fact that they have a hardware product to sell. I don't think the Oracle brain trust knows what to do with Sun h/w and the Solaris o/s.
That's unfair, go to any gigantic company's site. EMC, IBM, HP, GE, Hitachi. These are mega corporations, not storage, hardware, computer, jet, wild guess, etc.
Re: (Score:3)
I rather think if they optimize the Sparc HW for databases it may a chance for the Architecture to survive in the long term. And no, nobody is going to switch because of ideology. They switch because of cost for running their applications. And no, such decicions are not made on the scale of 1-2 years, but a longer timescale.
Re: (Score:2)
Even AMD had to fudge the model names back then to get people to buy the processors, which admittedly were faster per Mhz than Intel, but customers looked at raw numbers. I would think that cores would be the same, even with a more sophisticated buyer.
Really? cores == cores? You say this on an article about a line of processors with a bazillion hardware threads. No doubt computer buyers often don't understand what they're getting, but to a person that naive, a T3 has 128 processors. Have fun debating processor vs. core with a core == core luddite, not to mention this processor line is a SoC with four way SMP, four memory channels, PCI-e, and dual 10gbit nics. /sigh.. it's just one chip though, and my gaming rig has two, so it's twice as fast. Hope
Re: (Score:2)
And reducing the number of cores can't help, as cores is now the buzzword, just like megahertz was back in the Pentium days.
Re:blindly pushing marketable limits... (Score:5, Insightful)
I wasn't aware the Alpha was that bad. I thought it was simply that the benefit of the processors wasn't great enough to convince companies to move from the much cheaper x86 platform. I saw a couple of Alpha desktops and they were pretty impressive.
Re:blindly pushing marketable limits... (Score:5, Informative)
ISTR benchmark after benchmark saying that they performed about as well as a Pentium Pro/II of the same clock speed, when running native code. Except they were doing 533 MHz when Pentium Pros were doing 200. Oh, and the benchmarks I remember showed that the Alpha could emulate x86 code as fast as the Pentium Pro 200 could run it natively, after DEC's emulation software had profiled the code.
The problem is this... they were also, IIRC, more EXPENSIVE than said Pentium Pro machines, and they could (for the Windows market) only run NT, when everyone targeted 95. And the performance advantage was completely wasted if your code wasn't written for Alpha. (So, you could run Office 95 and such on them, but because Microsoft only compiled the OS and maybe some server software, for general desktop AND workstation duty if your business needed Windows, a PPro box was cheaper and may have been able to do the same job.)
(Keep in mind that back then, Microsoft was ambivalent about x86, at least in the workstation and server market. Windows NT was written to run on quite a few popular processor families - MIPS, PPC, and Alpha, in addition to x86. And, Microsoft made what was essentially an AT Architecture MIPS system specification for running NT on MIPS.)
Re: (Score:2)
That's rather my point. The Alpha was anything but a bad chip, it's just that on a cost-benefit scale for what they were being marketed for, it made no sense. The problem, at the server and high-end workstation end, was that while the Alpha could certainly outperform Pentiums, the price made them very unattractive compared to the Intel was throwing out there.
Re: (Score:2)
It really depended on what you were doing too. Alpha's were built for raw speed and were good for certain tasks. Company I worked for back then used them for Lightwave rendering circa 1996/1997. But I believe the average box was somewhere in the neighborhood of $35,000 - $50,000 a pop for Dual 500 Mhz, 2GB of RAM and pretty much were all render nodes. Most of the workstations were SGI/IRIX and in the early days there were even quite a few Amiga around.
Re: (Score:2, Insightful)
Yeah I had a 486-DX100 and a 233 MHz Alpha 21064, both running Red Hat Linux.
The Alpha was so much faster for native compiled stuff, but I couldn't get Netscape for Alpha, and running Netscape for x86 under the EM86! emulator was as slow as browsing the web with a Python based browser at the time. They were both too slow to keep up with "fast" downloads like a 28k modem... So I wound up using the 486 machine as my graphics console, and running all of my batch stuff on the Alpha, with them sitting next to
Re: (Score:2)
If you think the web is a bloated mess now, just wait until you see the hardware the sci-fi-future web will bring to it's knees!
Re: (Score:3)
What amazes me is that I now have a quad core 2.4GHz Intel i7 Xeon with 12 GB of triple-channel RAM and gigabit connection to the internet here at work in a university, and I still get uncomfortable lags with browsing.
I expected us to be in the sci-fi future by the time we had this kind of equipment...
One reason why so many things are still slow is because a lot of timeouts and delays are set to human-scale: on the order of seconds. Not milliseconds or microseconds.
The next reason is the speed of light isn't that fast.
And the last reason is what Intel giveth the Programmers taketh away. I'm guilty of this since I used to do 6502 machine code, but now write stuff in Perl (which on a modern machine can still do loops faster than a 1MHz 6502, but you can see where some of the speed gains have gone - I'm not
Re: (Score:2)
um no...
Alpha systems were well worth 4x their other contemporaries.
They made things possible that were simply unable to scale on Solaris kit.
This is why they were also thrown into some of the early computing clusters and render farms.
OTOH: SGI are the poster boys for overpriced gear with lack luster performance.
Re: (Score:2)
Re: (Score:2)
my first hand experience as funded by the national science foundation says otherwise.
Well let's see some numbers then. My firsthand experience (admittedly not funded by NSF!!!) says you're dead wrong. Secondly, who exactly claimed that Alphas were cheap? They WERE more expensive, but also more powerful.
do you have any insight of your own to provide? why are we all not using alpha chips if they were so affordable and powerful?
Perhaps you've heard the term "Wintel" before?
Re: (Score:2)
alphas weren't much more expensive... if i remember right $800 got a 1.2 Ghtz bare bones system... about the same as a 433Mhtz with pentiums.
got it... so the ignorant public just never UNDERSTOOD how good the alpha product was and that is the reason they didn't buy it.
you're an idiot.
if only microsoft had dedicated itself to a symbiotic relationship with alpha to cross optimize... wahhhhh wahhhhh.
perhaps one day you'll not be an idiot?
Apparently, gratuitous insulting has become the cornerstone of logical arguments. Bravo.
Re: (Score:2)
no, actually the norm is tongue in retarded cheek backhanded rhetorical implications like "Perhaps you've heard the term "Wintel" before?".
Yes, one can easily get into a pissing match over rhetorical techniques, like your "Funded by the NSF!!!" call to authority. Big whoop. My point was perfectly valid, and your inability to respond to anything I said lends credence to the AC who claimed you were a sockpuppeter.
slashdot = stagnated
Says the guy with the high 7-digit UID?
Re: (Score:2)
Hey, hey, hey, don't assign stagnated to slashdot! You mean slashdot == stagnated. (Unless you're writing Ada, then you're right)
Re: (Score:2)
would you rather i post with my 5 digit UUACCOUNTUSERID?
Yes, I would like that, please.
Re: (Score:2)
I was really hoping you would post with your 5-digit number :-(
Re: (Score:2)
did your mother name you "Moridineas".
Interesting question, but no, she didn't. It's actually kind of an amalgamation of a couple different things.
Re: (Score:2)
you cower behind a chosen pseudonym. what are you afraid of?
Oh, could be any number of things...better safe than sorry! On the other hands, pseudonyms have a long and respectable history! You wouldn't criticize Publius, would you?
Re: (Score:2)
alphas weren't much more expensive... if i remember right $800 got a 1.2 Ghtz bare bones system... about the same as a 433Mhtz with pentiums.
got it... so the ignorant public just never UNDERSTOOD how good the alpha product was and that is the reason they didn't buy it.
So what you're saying is that no, you don't have any performance numbers that can remotely back up anything you've claimed?
you're an idiot.
if only microsoft had dedicated itself to a symbiotic relationship with alpha to cross optimize... wahhhhh wahhhhh.
perhaps one day you'll not be an idiot?
Classy.
"Wintel" won as a platform because it was common, cheap, fast (enough) and yes, because Microsoft was very important to the PC landscape! Look at other chips like PowerPCs and so on that had some great performance and energy qualities but were dominated by Intel chips and Microsoft OS/software.
Is it true that you're a notorious sockpuppeting troll? I don't think I've seen your na
Re: (Score:3)
Speaking as someone with an Alpha Station conveniently as a footrest...
I'm calling a double bullshit.
First of all the parent: 1.2GHz for 800 when Pentiums were 433MHz?
21164 Alphas, topped out at mostly 600MHz, and were faster than x86 clock for clock. They were also pushing the MHz limit at the time, being the first to 500MHz, and using a slightly later 533MHz (21164PC) they were damned fast compared to any x86 chip. As far as speed, at the time, they were overall the undisputed fastest processors. (DEC onl
Re: (Score:2)
Re: (Score:2)
Because Intel sued them over patents and buried the tech?
Re: (Score:2)
Alphas ran VMS, NT, or Digital UNIX (nee OSF/1) none of which were designed ground-up for the user experience. But I had an Alphastation 3000/300X and it was tolerably peppy, so I think you're just imagining things.
Re:blindly pushing marketable limits... (Score:4, Informative)
It really depended on what you wanted to do. Sparc machines where great at IO and memory access. Alphas just had the shear grunt to do work (and yes they were running at over 1GHz when most processors where running at half that)
. SGI were crap but if you wanted to visualise it they could not be beat (hudge amounts of custom graphics hardware).
Re: (Score:2)
I have had various experiences. For some of my work the Alphas trounced everything. They were very fast processors. Larger data sets and I found that sunOS on fujisu (sparc) machines worked beter. Mind you I may be biased as the 16 proc machines I had access to were not quie comparable to the alphas (I think the alphas still out performed in floating point though).
But If you wanted to see your data then you had to have something from SGI. SGI really had impressive 3D hardware. Most low end 3D grphics cards
Re: (Score:2)
"That was the first time I used 3D graphics."
Perhaps I should say this was the first time I had used 3D graphics in anger. No textures...just trying to push polygons at the screen. trying to render voxels using GLUT/GL. That is when I started to apprecieate the SGI machine I had access to. It was too slow to compute the scene but nothing else could display it fast enough to get an idea what was going on.
Re: (Score:2)
Oh and this was using the shuttered glasses (LCD) that give you a headacke after ten mins. They claimed 30 hz but that did not really work. The pressure ball controll did work well.
Re: (Score:2)
The DEC Alpha was (and still is) a brilliant architecture. The designers took great care from the start to make sure that it would scale, both in clock and core count. It was simple, elegant and fast.
IIRC, the early chips were fast enough to emulate x86 code at a reasonable speed. If all you wanted to do was run emulated x86 code though, then maybe they were "useless". This was especially true before the BWX extension, which introduced a number of byte oriented instructions.
Native code, on the other han
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The DEC Alpha EV6 bus was licensed for the original Athlon (and continued with the Athlon XP). EV6 in the original Athlon form was a 100MHz double-pumped bus (200MHz effective) and very good in its day, far better than Intel's 100-133MHz bus at the time. In fact it was a major contributor to the Athlon's long-term dominance over comparable Pentium's for some time. In the end, it reached 200MHz double-pumped (400MHz effective) speeds. Intel didn't match that until Netburst, and we all know how well that turn
Re: (Score:2)
That is what compilers are for. It is silly to suggest that there was no software for a Unix based system, especially at that time.
Availability of Windows based software would have helped, but was hardly necessary. The market didn't kill the Alpha, it was pure stupidity on the part of management.
Comment removed (Score:5, Insightful)
Re: (Score:2)
We've found that since most transactions aren't cpu bound, increasing the number of cores, and, therefore the number of transactions which can be simultaneously processed, increased throughput, at least when you're talking about 700 connections (of which probably 100-200 are active). Would love to hear what others are experiencing.
Re: (Score:3)
Well, someone at Oracle didn't quite get "it", I think: the T-series was very specifically designed with high parallelism in mind, and sacrificing some single-threaded performance for the purpose. The series was aimed and marketed specifically at applications that benefit more from threadcount than from pure mips. It got marketed at us like that, too, but we decided we needed more generic performance so we went for a different line of processors.
And, before someone starts hawking about lintel, I'm talking M
Re: (Score:2)
Well, someone at Oracle didn't quite get "it", I think: the T-series was very specifically designed with high parallelism in mind, and sacrificing some single-threaded performance for the purpose.
No, someone at Sun didn't quite get "it", which is why they scrubbed an entire architecture and then ended up with one based on old tech that had shit single-thread performance, much like intel going to the space heater Pentium IV and then going back to the Pentium III... which wouldn't do the same clock rates, and as such didn't have the same single-thread maximum performance (even though it was faster clock for clock) until the "Core" series, which also includes elements from the P4. Sun threw a ton of co