Okay... So it'll be good for parallel code at some point... Sadly, most code we care about needs to be executed serially.
But say we have code that can be parallelized. And we have all this die space... Why don't we just put more then one standard core on the same die? Oh wait, that's what IBM/Sun/etc. are already doing...
Whether or not the Itanium's 'design is an "architectural advance" remains yet to be seen.
For sure, it's elegant on paper, but consider this: Knowing the number of years and amount of money that Intel's thrown at this thing, why is it's performance only on par with other existing 64 bit chips?
And that's of course if you believe the spectint/spectfp scores that intel publishes will translate to real world performance. Itanium performance is much more application dependent then more conventional chips.
How many people still consider a RAM based audio player when shopping?
Well, I think a better question is how many people consider a hard drive based system when MP3 shopping? A big clunky iPOD might be okay if all you want is music during your commute. But I use my MP3 player in a variety of situations (jogging, at work, etc.), and prefer the small size, better battery life, and ruggedness of the solid state storage based approaches.
You can get a pure Compact Flash based player like the NEX for around $90, and 512MB of compact flash is now less than $100. And as compact flash keeps getting bigger, and prices keep coming down, I think the hard drive based MP3 players will at some point become obsolete.
The current opteron boards can have four DIMM slots per processer (the memory controller is integrated with the processor). With 2GB DIMM's, that's 16GB for a dual processor system.
In any case, OS X is a 32bit OS.... so that fact that you can put 8GB into a Mac doesn't mean much.
I had one of those Cyrix 166 CPU's. They actually ran at 133 MHz....
It was a very inexpensive chip, which was great as I was an undergrad, and it gave reasonably good performance for the time.
It was also the first CPU I'd ever owned that needed a cooling fan. Not believing a CPU really needed its own fan, I opened up the case, booted the system, and tried stalling the CPU fan with my thumb while the OS was running. At least in my case, the computer could run for only a matter of seconds before hard stalling..... That processor was very sensitive to heat.
Anyway, I bought a better fan for the thing, and ran the computer for 5 years without any crashes. Just had to keep the thing cool and it was fine.
The vast majority of OSS projects have one lead developer and a couple of contributors. Linux, Apache, OpenOffice, etc. are the exception, not the rule.
He disparages both C++ and Java as open source development languages, and I agree with his comments on those.
But, besides the compile time issue, straight C seems to me like a good bet. It's such a basic programming language, that it'd be hard to find anyone who programs that doesn't understand the C language. The basic libraries are very standardized. Good debuggers exist. Etc. Etc. Etc.
okay, so you can get a gem either by giving the stick back to the tree, or giving the stick to yoda, waiting for him to leave, and then grabing it from the chest.
what next? i've tried putting glue in the totem mouth, to no avail. and nothing else seems to do anything....
I'd call it learning from previous experience and survival of good ideas. One of the great things about open-source is that great ideas don't have to die with the project they originated in.
This version is not an 8.* point release for precisely the reasons you encountered. There's some incompatible changes (mainly the new thread model) that went into the release, which is why the call it 9 instead of 8.1.
uh, no. i can't speak for the physics side, but the reason genomics and protienomics use so many mac's is entirely historical. most biology phd's cut their teeth on macs, and a lot of biology software came out for mac first. it has absolutely nothing to do with altivec.
this is the same reason you still see sun's in engineering departments, despite the fact that you can get PC's 2 or 3x more powerful for far cheaper. in the late 80's/early 90's sun workstations were the way to go for engineering, and there's a lot of legacy stuff out there.
in my experience, the speed of a G4 is roughly comparable to the speed of an equivalently clocked PC. my 3 year old athlon 750Mhz commonly out performs my 3 month old, 867Mhz powerbook G4.
Cost of Hubble (including design and initial shuttle launch fees) 1.5 billion.
Cost of a single Hubble repair mission: 1 billion. Completed repair missions: 5
So the grand total so far is 6.5 billion.
Now, if the shuttle had never existed, we'd have at least 4 Hubble's, even without taking economies of scale into account. Granted, the 1st one would still be near sighted, but the other 3 would be fine.
Who cares of the shuttle can do repair flights. It's not economically warrented.
Yeah, what you're seeing is the Ximian version of the file picker. If you had installed GNOME directly from the GNOME web site, or installed RedHat's version, you'd see the current, very simplistic file dialog.
While the current file dialog works fine, it's due to be replaced in the near future by something more advanced. I'm sure it just hasn't been a high priority for the GNOME people because it's not currently broke, and it's trivial to replace (as Ximian's shown).
uh, actually the bandwidth is pretty pathetic, it's just that evolution has done a great job of adapting constrained to the limitations of wet ware. the "unsurpassed" quality of human vision is only at the center of your field of view (where you need it), the rest of your retina is low resolution and optimized primarily for motion detection. our skin is likewise fairly low resolution (there's places on your body that can't discriminate between two touches over a centimeter apart), but it's high resolution where it needs to be (primarily the finger tips).
it's okay that we have such low bandwidth, as our brains wouldn't be able to handle more bandwidth anyway.
I said "in the last 20 years". Please try to pay attention. Nothing on that list was developed due to work done on the Shuttle program in the last 20 years. Most of it comes directly from the Apollo program.
Yeah, this is a common problem with NetBSD when people quote how many different type of systems it can run on. They get serial + netboot working, and they call it a port.
If you hold a port to the standard that it should include support for the local console and the machine's own harddrive, I think you'll find that NetBSD doesn't run on many more machines then Linux does.
I specifically remember the first time I saw (or at least remember) this phrase used in mockery.
There was an article on/. several years ago, talking about how the corel computer guys had made a netwinder cluster by taking 10 of their netwinder rack motherboards, screwing them together, and hooking them together via ip-over-scsi. This was a one-off thing for a Linux trade show.
So of course, someone mentioned using this setup as a beowulf, and the obvious reply was it'd be worthless since the ARM processors had no hardware floating point. But then, someone had to chime in, "but imagine a * of these things", and the rest if history.
Oh, found the link: ALS Wrapup, but comments appear to be gone.
Gotta agree with you on this. I spent two years working with labview circa 1997. It's really easy to get a small program up and running in labifew, and it's really a great environment for rapidly developing data acquisition software.
The problem comes in when you try to write either a large program, or a program that involves more then data acquisition/data analysis. For the later, you no longer have a good collection of pre-designed blocks for what your doing. For the former, every time you want to insert new code, you wind up spending time moving wires and blocks around to make space on the screen for the new code. Extending on existing code rapidly becomes a gui nightmare.
That being said, if you restrict labview to uses for which it was really designed for, it can be an extremely useful tool.
Slashdot Mirror
Okay... So it'll be good for parallel code at some point... Sadly, most code we care about needs to be executed serially.
But say we have code that can be parallelized. And we have all this die space... Why don't we just put more then one standard core on the same die? Oh wait, that's what IBM/Sun/etc. are already doing...
IBM's due to release an Opteron workstation next year...
Whether or not the Itanium's 'design is an "architectural advance" remains yet to be seen.
For sure, it's elegant on paper, but consider this: Knowing the number of years and amount of money that Intel's thrown at this thing, why is it's performance only on par with other existing 64 bit chips?
And that's of course if you believe the spectint/spectfp scores that intel publishes will translate to real world performance. Itanium performance is much more application dependent then more conventional chips.
Well, I think a better question is how many people consider a hard drive based system when MP3 shopping? A big clunky iPOD might be okay if all you want is music during your commute. But I use my MP3 player in a variety of situations (jogging, at work, etc.), and prefer the small size, better battery life, and ruggedness of the solid state storage based approaches.
You can get a pure Compact Flash based player like the NEX for around $90, and 512MB of compact flash is now less than $100. And as compact flash keeps getting bigger, and prices keep coming down, I think the hard drive based MP3 players will at some point become obsolete.
The current opteron boards can have four DIMM slots per processer (the memory controller is integrated with the processor). With 2GB DIMM's, that's 16GB for a dual processor system.
In any case, OS X is a 32bit OS.... so that fact that you can put 8GB into a Mac doesn't mean much.
I had one of those Cyrix 166 CPU's. They actually ran at 133 MHz....
It was a very inexpensive chip, which was great as I was an undergrad, and it gave reasonably good performance for the time.
It was also the first CPU I'd ever owned that needed a cooling fan. Not believing a CPU really needed its own fan, I opened up the case, booted the system, and tried stalling the CPU fan with my thumb while the OS was running. At least in my case, the computer could run for only a matter of seconds before hard stalling..... That processor was very sensitive to heat.
Anyway, I bought a better fan for the thing, and ran the computer for 5 years without any crashes. Just had to keep the thing cool and it was fine.
The vast majority of OSS projects have one lead developer and a couple of contributors. Linux, Apache, OpenOffice, etc. are the exception, not the rule.
What are your thoughts on using straight C?
He disparages both C++ and Java as open source development languages, and I agree with his comments on those.
But, besides the compile time issue, straight C seems to me like a good bet. It's such a basic programming language, that it'd be hard to find anyone who programs that doesn't understand the C language. The basic libraries are very standardized. Good debuggers exist. Etc. Etc. Etc.
Any thoughts?
aaaah, found the fruit.
you actually don't need to save, the fruit regrows, so you can go back and get another one.
I've called AT&T (GSM) and they've refused, saying it's not possible.
If anyone else has info, I'd love to know.
okay, so you can get a gem either by giving the stick back to the tree, or giving the stick to yoda, waiting for him to leave, and then grabing it from the chest.
what next? i've tried putting glue in the totem mouth, to no avail. and nothing else seems to do anything....
i just downloaded the nightly build off the web site, and that version seems to work fine.
i'm currently in the escape pod, heading down to the planet.
I wouldn't call it rape and pillage.
I'd call it learning from previous experience and survival of good ideas. One of the great things about open-source is that great ideas don't have to die with the project they originated in.
This version is not an 8.* point release for precisely the reasons you encountered. There's some incompatible changes (mainly the new thread model) that went into the release, which is why the call it 9 instead of 8.1.
You're welcome to go with the SGI.
I'll go with the 3GHz P4 that runs just as fast (if not faster), and use the left over cash to buy a car.
uh, no. i can't speak for the physics side, but the reason genomics and protienomics use so many mac's is entirely historical. most biology phd's cut their teeth on macs, and a lot of biology software came out for mac first. it has absolutely nothing to do with altivec.
this is the same reason you still see sun's in engineering departments, despite the fact that you can get PC's 2 or 3x more powerful for far cheaper. in the late 80's/early 90's sun workstations were the way to go for engineering, and there's a lot of legacy stuff out there.
in my experience, the speed of a G4 is roughly comparable to the speed of an equivalently clocked PC. my 3 year old athlon 750Mhz commonly out performs my 3 month old, 867Mhz powerbook G4.
Cost of Hubble (including design and initial shuttle launch fees) 1.5 billion.
Cost of a single Hubble repair mission: 1 billion.
Completed repair missions: 5
So the grand total so far is 6.5 billion.
Now, if the shuttle had never existed, we'd have at least 4 Hubble's, even without taking economies of scale into account. Granted, the 1st one would still be near sighted, but the other 3 would be fine.
Who cares of the shuttle can do repair flights. It's not economically warrented.
Yeah, what you're seeing is the Ximian version of the file picker. If you had installed GNOME directly from the GNOME web site, or installed RedHat's version, you'd see the current, very simplistic file dialog.
While the current file dialog works fine, it's due to be replaced in the near future by something more advanced. I'm sure it just hasn't been a high priority for the GNOME people because it's not currently broke, and it's trivial to replace (as Ximian's shown).
uh, actually the bandwidth is pretty pathetic, it's just that evolution has done a great job of adapting constrained to the limitations of wet ware. the "unsurpassed" quality of human vision is only at the center of your field of view (where you need it), the rest of your retina is low resolution and optimized primarily for motion detection. our skin is likewise fairly low resolution (there's places on your body that can't discriminate between two touches over a centimeter apart), but it's high resolution where it needs to be (primarily the finger tips).
it's okay that we have such low bandwidth, as our brains wouldn't be able to handle more bandwidth anyway.
Dude,
I said "in the last 20 years". Please try to pay attention. Nothing on that list was developed due to work done on the Shuttle program in the last 20 years. Most of it comes directly from the Apollo program.
Can you even name 3 technological or exploratory advances that the shuttle program has made in the last 20 years?
Or even 3 worthwhile scientific experiments that needed the shuttle to perform them?
We would have been better off had the US cancelled the shuttle program following Challenger.
Yeah, this is a common problem with NetBSD when people quote how many different type of systems it can run on. They get serial + netboot working, and they call it a port.
If you hold a port to the standard that it should include support for the local console and the machine's own harddrive, I think you'll find that NetBSD doesn't run on many more machines then Linux does.
There was an article on /. several years ago, talking about how the corel computer guys had made a netwinder cluster by taking 10 of their netwinder rack motherboards, screwing them together, and hooking them together via ip-over-scsi. This was a one-off thing for a Linux trade show.
So of course, someone mentioned using this setup as a beowulf, and the obvious reply was it'd be worthless since the ARM processors had no hardware floating point. But then, someone had to chime in, "but imagine a * of these things", and the rest if history.
Oh, found the link: ALS Wrapup, but comments appear to be gone.
Gotta agree with you on this. I spent two years working with labview circa 1997. It's really easy to get a small program up and running in labifew, and it's really a great environment for rapidly developing data acquisition software.
The problem comes in when you try to write either a large program, or a program that involves more then data acquisition/data analysis. For the later, you no longer have a good collection of pre-designed blocks for what your doing. For the former, every time you want to insert new code, you wind up spending time moving wires and blocks around to make space on the screen for the new code. Extending on existing code rapidly becomes a gui nightmare.
That being said, if you restrict labview to uses for which it was really designed for, it can be an extremely useful tool.