Yeah, Dr. Rannie is a good guy...unless you get on his bad side. Then he'll make your life a living hell. I didn't do that, but knew a couple people who did...
Actually Northern Illinois University (about 1.5 hours from Chicago) had a total mainframe focused CS degree as of the late 90's. I graduated in '96, and learned my COBOL, Fortran and assembler. Data structures in mainframe assembler are quite fun!
Yes, it is a niche program, but served the needs of the large financial and insurance companies in downtown Chicago. They were very successful program and at the time I graduated, they had an insanely high job placement rate right out of school.
It is true that current Intel processors (both dual core and in 2P SMP systems) are starved for memory. However, the bottleneck really lies between the processor(s) and the memory controller. DDR2 provides plenty of bandwidth between the controller and the memory sticks themselves, but unfortunately, data has to be transmitted over a single, shared, relatively slow 800MHz bus to the processors. And other technologies like dual banking/interleaving the memory don't have much effect because the data still has to pass over this slow bus to the processors.
Even forgetting the power/thermal dissapation issues, increasing the clock speed of the Intel processors does not help performance much because they are still being constrained by the same 800MHz bus when accessing memory.
This reason is why the integrated memory controller is so critical for the performance of AMD processors. The processor is able to talk with the memory controller (and thus the memory itself) so much more quickly over a bus on the processor die itself, and utilizes the memory's capability much more effectively.
Also with AMD processors, the memory controller is clocked at the same speed as the processor, so if you plug in a faster processor to the same motherboard you are also increasing the bandwith/decreasing the latency of the memory access (up to the maximum bandwith of the memory technology used).
This is why AMD processors scale so much better with dual core processors and in SMP systems.
The reason AMD processors won't need a new socket or motherboard is because dual core was designed into the processors from pretty much the beginning.
Intel, on the other hand is trying to retrofit a single core design into something with 2 cores, and trying to do it as quickly as possible before loosing more ground to AMD.
In theory this is true, but in reality creating multi-threaded games does not really benefit as much as you would think.
Mostly this is because of the extra over-head involved with synchronizing the threads. An obvious example is making sure the video and audio are synchronized so the 'Boom' happens at the same time as the 'Flash'.
When different threads are running on different processors with different loads, there is no way to guarantee that they will remain in sync with each other without some communication and/or blocking to make sure everything is timed properly.
AMD has gone to great lengths to make sure their dual-core processors work in current Opteron motherboards. The worst case would be that you would need to upgrade your BIOS, but the power requirements for these chips will be under the maximum that AMD has been telling motherboard makers to support.
The only downside is that they will always be behind in regards to clock speed compared to their single-core processors. I think somewhere in the 2.0 GHz range at initial launch.
If the Slashdot community took out the CIA's webservers, will/. now be labelled a terrorist organization bent on the destruction of American freedoms and way of life?
First we are all communists (well, according to Billy), and now terrorists too!
I have been trying out the beta version of NeoOffice/J, which is based on OpenOffice 1.1.3, and have found it to be much nicer than the X11 version of OpenOffice.
The main downside is that it is somewhat sluggish on my G4 Powerbook being written in Java (using the Carbon interface). But having access to all of my fonts, and better rendering make up for any speed issues I have noticed.
While Linux (with Opie, GPE, etc.) can be installed quite easily on PDA's, there are 2 main factors which limit this same thing happening with cell phones:
1. In the US and other countries, it is illegal to modify/replace a phone's firmware (i.e. OS). Installing and removing apps is fine, but the low-level pieces is not. 2. Phone hardware specs are basically impossible to get. While this will always be a problem for FOSS development (unfortunately), the legal issue above makes companies even less willing to provide people with the information.
The TI chip used (a variant of their OMAP line of processors) contains an ARM core along with a DSP core. They are compatible with ARM processors. And all versions of gcc support it, well at least the ARM core.
Also Opie, as with most Linux software, needs just a recompile to work on other platforms. I have developed and run Opie using x86, x86-64, G4/MacOS and ARM processors. The only changes needed for Opie on different devices is for hardware components such as touch screens, keyboard mappings and sound.
The Itanium2 is a fast processor, especially when it comes to optimized floating-point calculations. Yes, it is expensive and so the price/performance ratio is not as good as common desktop processors mostly for two reasons:
1. Large die area (mostly due to huge amounts of on-die cache) - chip price is directly related to how many cores that fit on a silicon wafer. 2. The Itanium2 is a low volume product, so R&D and verification costs are a higher percentage of chip costs.
The biggest problem with the Itanium2 is not its performance, but the innability of Intel to lower its cost. This causes it to being relagated to niche markets like HPC where performance is everything.
I doubt that the RC5-72 core has been fully optimized for the G5 yet. For example, the 1.5GHz G4 on that same chart scores ~900,000 higher, and I doubt the G4 is that much better of a performer. I would assume (and I could be wrong) that the G5 optimizations are not fully 64 bit yet.
Plus remember benchmarks are about as reliable/accurate as a presidential election pole.
Let's not forget the Challenger accident in the 80's...
There is a pattern emerging with NASA's space program:
1. Tragic accident occurs 2. The government/committees/advisory boards institute new safety regulations and guidelines 3. Everything goes great, guidelines are followed...for a while... 4. Pressure to perform causes shortcuts to be made 5. GOTO 1
Windows is definitely not required. For syncing with a desktop, there is TrollTech's QtopiaDesktop. But even better for KDE users out there is KitchenSync which allows syncing with KDE's addressbook and KOrganizer, and future goal of Evolution support. If you hunt around some, there are various scripts to sync/parse the information on other systems (OS X).
And because of that is a basic hardware platform which has the purpose of allowing developers to write software for it and other hardware developers to have a starting point for their own designs.
IBM is hoping that other companies will pick up on this design and actually make units for public consumption.
So things like keyboards, cameras, larger screens, wireless, etc. are possibilities for consumer versions, but aren't really needed to get developers started.
I am currently the lead developer on a rather large DB/2 application on the mainframe (110+ tables, primarily batch), as well as a Linux enthusiast in my free time.
I was curious as to the comparison between traditional MVS/CICS and the emerging use of Linux on the mainframe.
IBM has, to date, primarily marketed Linux on the mainframe for infrastructure applications (e-mail, web services, server consolidation, etc.), but was wondering if there are plans to extend its reach to the large, enterprise-scale applications?
Also, am curious about the performance differences between Linux and MVS (especially DB/2)? While this might not be a direct apples to apples comparison, would be interested in what the strengths/weaknesses of Linux might be on this type of hardware.
In theory, this would be good. But then the issue with handhelds will always be screen size. Anything larger than roughly 240x240 is hard to view on a small screen.
I used to think that the mainframe was a dinosaur (like so many people want you to believe). In my current job where I am supporting a large client/server/batch application on a S/390, and have come to realize that this is simply not the case.
First, let's take the hardware. There is simply no hardware that is sold where the company will guarentee the uptime level that IBM does. It might not put out the MIP's per dollar that other systems do, but its I/O and redundancy (hot swappable everything)cannot be beat.
Secondly, the software which is developed now is not all ISPF/CICS/character mode screens. In our shop we have several applications which use GUI windows connecting to DB/2 over TCP/IP (yes, it is a Windows GUI, but that's another story). My application has just over 100 tables and is several hundred gigabytes in size, and is used by a call-center handling hundreds of inquiries a day. I challenge anyone to build a system that can match the performance and realiability that we enjoy with our current setup.
A good portion of the world's economy/business runs on mainframes, this wasn't some fluke chance.
Re:Light as opposed to electricity
on
Silicon LED
·
· Score: 1
So they can generate the light signal on chip now, which is a big step. But for light to replace electrical current on/around a chip, how that signal is transmitted? As far as I know, there is not any way to create a fiber optic 'wire' on chip.
I have found (at least in my situation in a large corp.) that in order for management to approve anything done, you need to give concrete dollar amount savings for anything you might feel is the "right thing to do".
I know this is hard sometimes to quantify, but in my experience, you can go on for hours with reasonable/logical arguements about why something should be done.And after all of this you get one question, "That's nice...how much $$$ will this save us over what we have now?"It's not so much the savings, but the immediate costs that are taken into account when making the decision whether to pursue something like this.
A way I got around this:
I recently had an idea for my immediate team that would save a few thousand dollars a year in production support. Instead of presenting it to my manager and listening to them saying that we can't afford to spend time on developing it now (usual B.S. from clueless managers), I just went ahead and starting working on my idea in those spare moments during the day, 15 minutes during lunch, etc.I presented it to them saying that this cost them next to nothing (since it was 90% done, and I wrapped the time into other tasks during the day), and it would be ready to implement in a matter of a few days.
You can try to take the credit early on for an idea, or you can work in your spare time to prove it can be done, and that you are willing to make it happen.The latter is what (whether unfortunately, or not) is what the suits will buy into.
They have always been significantly behind their RISC competition (especially Alpha). This is mostly due to the original design of the x87 instruction set and its stack-based register structure.
In the x86 arena, they have always been in the lead. Not so much because their design was so good, but FP is something companies are willing to skimp on to make a chip, especially in the low-end of the market. Now here comes Athlon which showed everyone that you can still remain compatible to the x87 instruction set, but have signifiantly higher performance. Unfortunately, Intel has decided with the Willy to not try to compete with AMD, but instead shift focus to SSE. Time will tell if this works or not...
Slashdot Mirror
I haven't had any problems with Firefox on OS X (or Linux for that matter). It doesn't work with Safari however...
Yeah, Dr. Rannie is a good guy...unless you get on his bad side. Then he'll make your life a living hell. I didn't do that, but knew a couple people who did...
Actually Northern Illinois University (about 1.5 hours from Chicago) had a total mainframe focused CS degree as of the late 90's. I graduated in '96, and learned my COBOL, Fortran and assembler. Data structures in mainframe assembler are quite fun!
Yes, it is a niche program, but served the needs of the large financial and insurance companies in downtown Chicago. They were very successful program and at the time I graduated, they had an insanely high job placement rate right out of school.
It is true that current Intel processors (both dual core and in 2P SMP systems) are starved for memory. However, the bottleneck really lies between the processor(s) and the memory controller. DDR2 provides plenty of bandwidth between the controller and the memory sticks themselves, but unfortunately, data has to be transmitted over a single, shared, relatively slow 800MHz bus to the processors. And other technologies like dual banking/interleaving the memory don't have much effect because the data still has to pass over this slow bus to the processors.
Even forgetting the power/thermal dissapation issues, increasing the clock speed of the Intel processors does not help performance much because they are still being constrained by the same 800MHz bus when accessing memory.
This reason is why the integrated memory controller is so critical for the performance of AMD processors. The processor is able to talk with the memory controller (and thus the memory itself) so much more quickly over a bus on the processor die itself, and utilizes the memory's capability much more effectively.
Also with AMD processors, the memory controller is clocked at the same speed as the processor, so if you plug in a faster processor to the same motherboard you are also increasing the bandwith/decreasing the latency of the memory access (up to the maximum bandwith of the memory technology used).
This is why AMD processors scale so much better with dual core processors and in SMP systems.
The reason AMD processors won't need a new socket or motherboard is because dual core was designed into the processors from pretty much the beginning.
Intel, on the other hand is trying to retrofit a single core design into something with 2 cores, and trying to do it as quickly as possible before loosing more ground to AMD.
In theory this is true, but in reality creating multi-threaded games does not really benefit as much as you would think.
Mostly this is because of the extra over-head involved with synchronizing the threads. An obvious example is making sure the video and audio are synchronized so the 'Boom' happens at the same time as the 'Flash'.
When different threads are running on different processors with different loads, there is no way to guarantee that they will remain in sync with each other without some communication and/or blocking to make sure everything is timed properly.
AMD has gone to great lengths to make sure their dual-core processors work in current Opteron motherboards. The worst case would be that you would need to upgrade your BIOS, but the power requirements for these chips will be under the maximum that AMD has been telling motherboard makers to support.
The only downside is that they will always be behind in regards to clock speed compared to their single-core processors. I think somewhere in the 2.0 GHz range at initial launch.
If the Slashdot community took out the CIA's webservers, will /. now be labelled a terrorist organization bent on the destruction of American freedoms and way of life?
First we are all communists (well, according to Billy), and now terrorists too!
I have been trying out the beta version of NeoOffice/J, which is based on OpenOffice 1.1.3, and have found it to be much nicer than the X11 version of OpenOffice.
The main downside is that it is somewhat sluggish on my G4 Powerbook being written in Java (using the Carbon interface). But having access to all of my fonts, and better rendering make up for any speed issues I have noticed.
While Linux (with Opie, GPE, etc.) can be installed quite easily on PDA's, there are 2 main factors which limit this same thing happening with cell phones:
1. In the US and other countries, it is illegal to modify/replace a phone's firmware (i.e. OS). Installing and removing apps is fine, but the low-level pieces is not.
2. Phone hardware specs are basically impossible to get. While this will always be a problem for FOSS development (unfortunately), the legal issue above makes companies even less willing to provide people with the information.
The TI chip used (a variant of their OMAP line of processors) contains an ARM core along with a DSP core. They are compatible with ARM processors. And all versions of gcc support it, well at least the ARM core.
Also Opie, as with most Linux software, needs just a recompile to work on other platforms. I have developed and run Opie using x86, x86-64, G4/MacOS and ARM processors. The only changes needed for Opie on different devices is for hardware components such as touch screens, keyboard mappings and sound.
The Itanium2 is a fast processor, especially when it comes to optimized floating-point calculations. Yes, it is expensive and so the price/performance ratio is not as good as common desktop processors mostly for two reasons:
1. Large die area (mostly due to huge amounts of on-die cache) - chip price is directly related to how many cores that fit on a silicon wafer.
2. The Itanium2 is a low volume product, so R&D and verification costs are a higher percentage of chip costs.
The biggest problem with the Itanium2 is not its performance, but the innability of Intel to lower its cost. This causes it to being relagated to niche markets like HPC where performance is everything.
I doubt that the RC5-72 core has been fully optimized for the G5 yet. For example, the 1.5GHz G4 on that same chart scores ~900,000 higher, and I doubt the G4 is that much better of a performer. I would assume (and I could be wrong) that the G5 optimizations are not fully 64 bit yet.
Plus remember benchmarks are about as reliable/accurate as a presidential election pole.
Let's not forget the Challenger accident in the 80's...
There is a pattern emerging with NASA's space program:
1. Tragic accident occurs
2. The government/committees/advisory boards institute new safety regulations and guidelines
3. Everything goes great, guidelines are followed...for a while...
4. Pressure to perform causes shortcuts to be made
5. GOTO 1
Windows is definitely not required. For syncing with a desktop, there is TrollTech's QtopiaDesktop. But even better for KDE users out there is KitchenSync which allows syncing with KDE's addressbook and KOrganizer, and future goal of Evolution support. If you hunt around some, there are various scripts to sync/parse the information on other systems (OS X).
Dan
And because of that is a basic hardware platform which has the purpose of allowing developers to write software for it and other hardware developers to have a starting point for their own designs.
IBM is hoping that other companies will pick up on this design and actually make units for public consumption.
So things like keyboards, cameras, larger screens, wireless, etc. are possibilities for consumer versions, but aren't really needed to get developers started.
I am currently the lead developer on a rather large DB/2 application on the mainframe (110+ tables, primarily batch), as well as a Linux enthusiast in my free time.
I was curious as to the comparison between traditional MVS/CICS and the emerging use of Linux on the mainframe.
IBM has, to date, primarily marketed Linux on the mainframe for infrastructure applications (e-mail, web services, server consolidation, etc.), but was wondering if there are plans to extend its reach to the large, enterprise-scale applications?
Also, am curious about the performance differences between Linux and MVS (especially DB/2)? While this might not be a direct apples to apples comparison, would be interested in what the strengths/weaknesses of Linux might be on this type of hardware.
Thanks!
Oh and check out the OPIE Project.
In theory, this would be good. But then the issue with handhelds will always be screen size. Anything larger than roughly 240x240 is hard to view on a small screen.
International text display: If I am not mistaken...not everyone reads/writes English...
Are available on their FTP site. Enjoy!
First, let's take the hardware. There is simply no hardware that is sold where the company will guarentee the uptime level that IBM does. It might not put out the MIP's per dollar that other systems do, but its I/O and redundancy (hot swappable everything)cannot be beat.
Secondly, the software which is developed now is not all ISPF/CICS/character mode screens. In our shop we have several applications which use GUI windows connecting to DB/2 over TCP/IP (yes, it is a Windows GUI, but that's another story). My application has just over 100 tables and is several hundred gigabytes in size, and is used by a call-center handling hundreds of inquiries a day. I challenge anyone to build a system that can match the performance and realiability that we enjoy with our current setup.
A good portion of the world's economy/business runs on mainframes, this wasn't some fluke chance.
So they can generate the light signal on chip now, which is a big step. But for light to replace electrical current on/around a chip, how that signal is transmitted? As far as I know, there is not any way to create a fiber optic 'wire' on chip.
I have found (at least in my situation in a large corp.) that in order for management to approve anything done, you need to give concrete dollar amount savings for anything you might feel is the "right thing to do".
I know this is hard sometimes to quantify, but in my experience, you can go on for hours with reasonable/logical arguements about why something should be done.And after all of this you get one question, "That's nice...how much $$$ will this save us over what we have now?"It's not so much the savings, but the immediate costs that are taken into account when making the decision whether to pursue something like this.
A way I got around this:
I recently had an idea for my immediate team that would save a few thousand dollars a year in production support. Instead of presenting it to my manager and listening to them saying that we can't afford to spend time on developing it now (usual B.S. from clueless managers), I just went ahead and starting working on my idea in those spare moments during the day, 15 minutes during lunch, etc.I presented it to them saying that this cost them next to nothing (since it was 90% done, and I wrapped the time into other tasks during the day), and it would be ready to implement in a matter of a few days.
You can try to take the credit early on for an idea, or you can work in your spare time to prove it can be done, and that you are willing to make it happen.The latter is what (whether unfortunately, or not) is what the suits will buy into.
Just one person's experience...
Simply because their FP performance stinks!
They have always been significantly behind their RISC competition (especially Alpha). This is mostly due to the original design of the x87 instruction set and its stack-based register structure.
In the x86 arena, they have always been in the lead. Not so much because their design was so good, but FP is something companies are willing to skimp on to make a chip, especially in the low-end of the market. Now here comes Athlon which showed everyone that you can still remain compatible to the x87 instruction set, but have signifiantly higher performance. Unfortunately, Intel has decided with the Willy to not try to compete with AMD, but instead shift focus to SSE. Time will tell if this works or not...