I fail to see how it was in any way a parody aside from the changing of the letters and hawking your links [216.239.39.100] and providing an interface to their engine that can easily be construed as "intentionally confusing" to users.
Of you do. That's because you are a humorless curmudgeon who didn't laugh their ass off like I did when you visited the site to look at it. Hint: the fact that you might make that kind of a mistake in the first place is part of joke.
PC's do not have correct color output, and never will. No matter high end the PC, the colors never look "right" or balenced on the screen.
Hey moron, Macs and PCs use the same graphics processors these days (either an nVidia or an ATI.) These companies don't make "Mac versions" of their chips, or leave out any DAC tweaking capabilities from the PC version.
My nVidia geForce ti 4600 came with a color matching system that had me playing with my monitor settings (it has this official pantome color thingy that I had to hold up to the monitor, as well as other various tests) for about 15 minutes, and the result is a pretty damn perfect screen as far as I can tell.
I've added this story to my collection of Apple tidbits
Of course. But consistency is more important than accuracy -- I'd like to see a standard which says "sin(x) is defined to be the result of running algorithm xyz, and will be within 1.5ulp of the mathematically correct value".
Then you can write a taylor series (or any other approximation) for yourself. Either way, you can't leverage the hardware if you want consistency. Different x86s (even different *INTEL* x86s) have used different algorithms which lead to slight differences.
Since this is an area of open research it seems a little silly to dictate a choice right now, in the standard. In the future mathematicians may prove that sin maps Q\{0} solely to irrationals (probably true), in which case we can at least know that 0.5ulp algorithms are finite. They may state more that can help us implement 0.5ulp within exact bounds. I.e., creating algorithms which are ideally accurate might just be a matter of research. Consider the rather poor choice of "quick sort" as the standard C sorting algorithm (and the initially chosen algorithm for the C++ STL) when "introsort" has now reared its head as a technically superior algorithm.
Now, lets say you want something that is consistent, yet fast? It may turn out (and its certainly quite possible) that Intel and AMD's transcendentals *are* consistent once rounded down to 64 bits. I think that this is a rather difficult thing to check (unless there are numerous obvious counter examples) and so it probably could not be used. We could choose some taylor or rational series today, and in a few years/decades be laughed at by people who manage to prove/check that AMD and Intel's trancendentals are all identical once rounded down to 64 bits.
Writing algorithms in software that are within 1.5ulp might be very difficult. The way that AMD and Intel do it, is by actually implementing more than 80 bits FP numbers internally, and just picking rational series with enough terms (and rotating the results from a given specific range, of course.) It may not be possible to match the performance of these routines at 1.5ulp... maybe we can only get within 10 ulps with these high performance algorithms (if you don't have extra bits in HW, I mean.) Who would ever use such functions?
The IEEE gives consistent +, -, *,/, sqrt. If you need consistency that badly, then chances are you can compromise on your accuracy, which means perhaps you can accept more than 100ulp in error. That would allow you to use taylor or rational series that are even more truncated, and perhaps even faster than the HW algorithms.
But perhaps you need other properties like convexity, or something like that -- in which case, perhaps the rotational thing might not work for you. Perhaps you need for the value to never be *over* estimated, in which case a truncated taylor series may be more appropriate than other algorithms.
In any event, I think the IEEE people have made the best choice. They have created a standard where any other changes to the spec (such as favoring consistency, to speed and accuracy for trancendentals) the ensuing controversy would have prevented the spec from being so widely adopted.
One of the changes since the last time we heard about D is the addition of floats and doubles (32 bit and 64 bit floating-point types, respectively) in addition to the "extended" type (as much precision as available). This is absolutely a Good Thing -- extra precision can be just as bad as insufficient precision, and adding these types allows people to ensure that they're using the right precision.
This is very x86-centric. Most RISC CPUs don't have an extended precision, and some super computers have multiple extended precision modes. x86s are rather unique in their support of exactly one extended precision mode. Oh yeah, and older ARM and x86 processors don't even have FP built-in. So much for "portable".
It would have been really nice to see the same thing for the math library functions; as it is, the only sin function is an extended -> extended function. IEEE doesn't require determinism on transcendental functions the way it does for arithmetic functions (which, I'm guessing, is why it isn't provided here), but there are times when it would be quite helpful.
The reason the IEEE 754 standard does not specify exactness for transcendentals is because there are no provably known finite algorithms for computing them. It is even very difficult to state the bound for how many steps are required for any non-trivial finite set of inputs without computing them all.
The IEEE 754 standard makes the choices which delivers as much as is possible within reasonable practical limits. When the Java committee foolishly tried to establish their own FP standard... well, you can read about it here -- once explained, the Java committee backed down and adopted IEEE 754.
I believe the D guy has probably taken this lesson to heart but probably overstepped by considering the x86 model as the most legitimate model.
Beware of statistics on children killed by guns. Usually they don't differentiate between the 10-year old who accidentally shoots his sister with daddy's pistol and the 17-year old gang banger who gets shot by the owner of a liquor store while attempting an armed robbery.
That's funny -- I don't differentiate between those either. The very fact that you think some people might deserve to die (by being shot) indicates to me, that you are american.
Well, it seems pi is normal, which means any finite sequence appears somewhere along the expansion of the number. So trivially, that image of a circle is in there somewhere, as is an image of a triangle, the source to Linux 4.0, an image of Bush playing with G.I. Joe dolls on his desk and so on.
Actually, it has not been *proven* that PI is normal. It just happens that "most" transcendental numbers are normal, and thus PI, probably is as well.
Pi is worse than irrational - it's trascendental. Merely irrational numbers can be expressed as simple expressions with finite numbers of terms, but transcendentals require an infinite number of terms.
Being "transcendental" just means that its a real number which is not the solution of any polynomial. For example, sin(1), and exp(2), are *probably* trancendental as well even though I wrote them as expressions with finite terms.
This is an important distinction, because there are 5th degree polynomials whose solution I cannot write down in a finite number of symbols, even though that solution is not transcendental.
Well as long as we are being anal retentive -- you will have difficulty writing it as 10 as well. Since this is an irrational base, you are going to need some sort of digit seperator. So something like (1,0)_pi would be more appropriate (so we could write silly things like (1,e)_pi = e + pi)
Do they need to know how to install the OS first, or should I let them look that up on their own while I make them power-users?
Learning to install an OS is a worthless skill to teach forward looking young people. OS's are getting easier and easier to install -- i.e., the crud you need to know to do it today will be obsolete soon anyway. You'll just end up teaching them frustration and how to wait a really long time... . (Of course some Linux distributions let you play tetris while you install...)
What distributions of Linux and BSD should they be first introduced to? (I'm only familiar with Debian, and I know virtually nil about *BSD.)
If you are the one designing the course, you should stick to what you are familliar with.
Initially, do they need to be more adept at the GUI, or do they first need to know how to use the shell?
GUIs were designed for idiots and old people (i.e., the Macintosh's intended audience.) I am not kidding or being facetious. Young people can learn a command line just as easily and will prefer it for its power. The point of a GUI is that you're not supposed to *teach* it to someone -- if a GUI requires training to use, then the GUI has been ill designed. Command lines need training but are well worth the effort to learn.
Should I give away Debian CDs no-questions-asked, or should I talk with the almighty Parents so little Daniel doesn't install Linux over Dad's 'work computer.'
Well, only if Dad's work computer is Windows.;P I think you should just explain the issue to them.
Are there any other key issue I need to think about?"
Yes, you have to come up with content for the course itself. Just letting kids tinker around with free OS's and free software isn't going to be that exciting. You have to create sub-projects for each day -- like 1) root privelege and setting up accounts 2) setting up a network between two different OS's 3) download and recompile an open source project (preferrably something multimedia related like XMM or something)
I wish you the best of luck.
Re: Can anybody compare and contrast the two ...
on
AMD's 64-bit Plot
·
· Score: 2
Short answer: Itanium = IBM PS/2. Hammer = PC AT.
Long answer: Itanium is a VLIW architecture with a new 64 bit instruction set, that performs in-order execution (like an original Pentium, or a Sun UltraSparc.) It has very high floating point performance, because of its dual, fully pipelined FMAC units. The architecture is interesting in that it uses a wide variety of mechanisms (predicates, conditional loads/stores) to avoid branches without using speculation.
Because of its new instruction set, its not compatible with any prior software. *Everything* must be ported from scratch, and there is no prior install base from which to leverage. (Actually that's not strictly true -- it has an x86 compatibility mode that is exceedingly slow; its like a quarter to a third of the performance of leading x86s.)
Compilers in particular are a really different kind of beast on the IA-64. All the "out of order execution" techniques that are in most other modern CPUs have to be somehow implemented in the compiler. The performance of everything depends on these compilers, and so far only Intel and HP's compiler have measured up to snuff. SGI's, Microsoft's and gcc have been ported, but apparently aren't very credible. It appears as though creating good compilers for IA-64 is a truly monumental task.
Microsoft has gone on record as saying that they have no intention of porting Office to Itanium -- its not that kind of platform. Itanium is seen as a server only player. While one is tempted to say "oh but that will come to the desktop eventually", unless Microsoft (or Apple or Sun -- but those are even less likely) is willing to port a significant number of applications to it, that's just not going to happen. Microsoft has ported Windows to IA-64, but has pretty much stopped development of IA-64 at that point.
Itanium has been available for over a year now, and has had a very cold reception in the marketplace. Nobody wants them.
Hammer (Opteron) is just a 64 bit extension of the x86 architecture. If you are an assembly, or system level programmer take a look at this:
http://murl.microsoft.com/LectureDetails.asp?690
Its quite detailed. The key thing to note is that the x86-64 instructions are really just extensions of the IA-32 instructions. That means that all the compilers and tools work almost identically to how they worked for IA-32. The key features that have been added are: 64 bit registers, a 64 bit address space, and twice as many integer and SSE registers.
x86-64 remains backward compatible with ordinary x86 in two ways. If the chip boots as normal with a 32-bit OS, that is unaware of its 64-bit mode, than just like 16-bit DOS before it, it functions like a normal old 32-bit Athlon. It also contains two other interesting modes: 1) Long Mode (this is how 64-bit are enabled) and 2) Compatibility Mode.
Long Mode enables the new instructions, registers, address modes, etc. Compatibility mode allows it to execute the old 32-bit software in a virtual environment, much like the v86 mode used for DOS Boxes under Windows.
It is known that Microsoft has ported Windows to Hammer, and apparently Office and Internet Explorer are up and running on it. But don't be fooled, Microsoft didn't waste their time *porting* Office or Explorer to x86-64. They simply run in compatibility mode under this new Hammer enabled 64 bit Windows. That's the whole beauty of their scheme -- 32 bit and 64 bit applications can be running at the same time, sharing the same OS resources.
Now because x86-64 is so similar to IA-32, it allowed AMD to implement both long mode, and compatibility modes in the same pipelines, with optimal ALU usage, using the same instruction translation super-structures, the same rename registers, etc, etc. I.e., any effort AMD spends in speeding up the critical paths of 64 bit operations, translated back directly to 32 bit operations and vice versa. There is no compromise -- it will be a very fast 32 bit processor, as well as a very fast 64 bit processor.
While Hammer will not be quite at the same performance as IA-64 for floating point, it won't be that far behind, and it will almost surely cream it on integer performance. This much has been revealed by AMD/Intel's Spec CPU claims/disclosures thus far.
As far as selling Hammer? Its just a natural follow-on to Athlon. It won't cost more (it actually has a smaller die size, so it actually costs AMD *less* to make Opterons than Athlons) and it will be just as compatible with your software (Linux, Windows, or whatever.) At the very least, people *will* adopt them for the same reason they adopted the Athlon. So 64-bit ready desktops are going to ship middle of next year, and the customers *will* be lining up to get them (regardless of whether or not they use the 64 bit features, or even get the 64-bit Windows for it.)
Microsoft has gone on record as saying they endorse AMD's approach. And of course they don't need to commit one way or another to porting any applications, since they will all run at top speed on Hammer regardless. While there is nothing more overtly committed by Microsoft, reading between the lines will lead you to realize the Microsoft probably intends to port its DB and IIS to Hammer.
Linux, of course, has been ported to both, but I don't know if they have enabled the compatibility mode for Hammer.
Re:32 bits != 4 gig max
on
AMD's 64-bit Plot
·
· Score: 2, Informative
32 bit architectures are not limited to 4 gigabytes of memory. "32 bit processor" refers to the width of the DATA bus (and registers). It does not refer to the width of the address bus.
This is a marketing term, not a technical one. And as far as the current 32 bit processors are concerned, you have it exactly backwards. x86's today have SSE registers which can hold 64 bit integers. I think the PPC's AltiVec registers can also hold 64bit integers. However, neither processor can access a 64 bit address space.
But even the marketeers knows that you don't call these processors "64bit". With the notable exception of Nintendo, the only time a processor is labelled "64 bits" is when its *address* space is 64 bits, not just its registers/ALUs.
Re:32-bit compatible = a temporary half-solution
on
AMD's 64-bit Plot
·
· Score: 3, Interesting
Yes, but several development houses (including, primarily Microsoft) have had experience porting to other 64 bit architectures. So the problems are known and addressable.
The problems to be hurdled are: 1) Reliance on the fact that size of pointer is equal to size of int.
True. But this is really a bad code practice sort of thing that developers that the C/C++ standard doesn't endorse anyhow. Java developers need not be concerned.
2) Reliance on a particular byte order in the machine word.
Its little endian, like it has always been on Intel. What's the problem? Little endian has the natural LSB/W/D property that makes increasing the natural word size typically a non-issue (unlike big endian where it is a serious PITA.)
3) Using type long and presuming that it always has the same size as int.
It is the same. You need to use "long long", or "_int64" or something like that to move to 64 bits in your C/C++ compiler. AMD's new "long mode" actually defaults to 32 bit data sizes, and only uses 64 bits when specifically overridden to do so. That's the whole point of the x86 architecture -- it supports a variety of data sizes as a consequence of its long history of backward compatibility, not just one (like a typical RISC.)
4) Alignment of stack variables. 5) Different alignment rules in structures and classes.
Same as it has always been. (64 bit integers already exist today in known common ABIs/compilers, in case you were unaware.)
6) Pointer arithmetic.
Eh? You can add/subtract integers to pointers, and subtract two pointers from each other. How does moving to 64 bits change anything?
Both Intel and AMD have been betting big on 64 bit computing and it will be interesting to see how this plays out.
They had nowhere else to go. If we start hitting the 4GB, and there is no solution, software developers and end-users will eventually be crying bloody murder like they were when Intel's 640KB limitation was hit. (That time Intel was slow to react -- this time around AMD and Intel are trying to have a solution in place *before* it becomes a problem.)
Itanium 1 was a flop. Itanium 2 has respectable performance, but is not IA-32 backward compatible, where AMD x86-64 is backward compatible.
Well I like to dig on Intel as much as the next guy, but technically speaking, IA64 is backward compatible with IA32 (it does have a bona fide IA32 mode.) But its slow as molasses (they might as well be emulating IA-32.)
That being said, I don't think Windows device drivers are going to work on IA-64 (the IA-32 mode is not involved in the boot process in any way.) IA-64's compatibility is in fact a "joke", though technically there.
The backward compatibility mode in Hammer, is very different. You can boot 32-bit windows on it, play your old DOS games on it or whatever and you will not know the difference (except it will be a lot faster.)
Re:What desktop users want to know..
on
AMD's 64-bit Plot
·
· Score: 1
will it be faster than 32 bit offerings?
Uhhh... yes? (Hint: it will have higher clock rate and execute more instructions per clock (on average) than Athlon)
For almost anyone out there, it's the only factor when buying a CPU: speed! Adressing >4Gb of memory is not that worries me first:)
Well it will be faster. Look, I don't know about you, but I have 512 MB of memory in my system. I have estimated that system memory capacity roughly doubles every year. At this rate, in 3 years we will be at 4GB in mid to high end machines, just as a natural course of things.
The way I read that, in three years, 32bit-only systems will be obsolete.
You are thinking about large integers. Actually at the circuit level, multiplication is not done in O(log(N)) steps, but instead, they just have blazingly fast adders. Now, of course the additions can be grouped in a parallel tree, so there are essentially log(N) stages. Each adder can be thought of as O(log(N)), so you might say that the multiply is O((log(N))^2) steps.
FUD disguised as a technical comment.
on
AMD's 64-bit Plot
·
· Score: 5, Informative
1. All addresses being 64-bits. For #1, realize that this is going to greatly increase the data size of many applications. The larger the data size, the higher the chance of cache misses. In general, this is a loss, not a win.
This is incorrect. The Hammer "long mode" uses 32 bits as the default data size. 64 bits are only used for pointers and explicitely overridden 64 bit operands. I.e., you still have to declare "long long" or "int64" or whatever, in your languages to access those 64 bits. All your old 32-bit data still occupies the same space.
Furthermore, measurements by AMD indicate that op-code size did not increase with the expanded instructions, but actual *decreased* because the additional registers decreased the typical amount of spill/fill code emitted.
Therefore there is no additional cache pressure. The "code bloat" problem remains solely in the hands of the software developer, and is *NOT* worsened in any way by hammer.
2. All internal integer registers being 64-bits. For #2, realize that some integer operations are O(N) where N is the number of bits involved. 64-bit multiplication and division are slowerthan the same 32-bit operations. Period.
This is also incorrect. There are numerous well known techniques used in ALU design that makes precious few operations "O(bits)". Again, AMD specifically targetted this. For example: the 64-bit integer multiply in hammer is *FASTER* (per clock) than the 32-bit integer multiply in either the Athlon or Pentium 4.
The reason AMD is able to do this is because arithmetic and logic operations can largely be implemented in a "more gates for more speed" fashion. They are closer to O(ln(N)) than O(N). But at this level of circuit design, you don't necessarily think in those terms (since N is constant, everything just looks like O(1)) -- these high speed circuit designers worry about other technical things like "latch speed".
The 64 bit integer divide may be a little slower, however, again you need to explicitely use 64 bit ints in your software, and division is a comparatively uncommon operation.
The gain with 64-bit processors is one of address space and nothing more.
This is the largest gain (big DB people will be very happy with it) but it certainly is not the only gain. Remember that there are now twice as many SSE registers. This opens up some performance possibilities for multimedia applications.
Although I don't know that its related to SSE, it should be pointed out that EPIC (as in the video game company) has ported the Unreal engine to x86-64! Like most people, I was quite surprised that they did this, however, they apparently found doing it to be worthwhile.
Do not underestimate the upside of going to 64 bits in the way that AMD has done it. They have literally made it a no-lose scenario -- that alone should spur (mostly new) application developer interest.
I'll let you in on a little secret... when Columbus came over here, you know what he found? Other people were already here! That's right! A whole civilization of people already here! Sorry, but I think he was beat by at least several hundred in not several thousand years.
Excuse me? The pound of dope was more of a threat (well, more newsworthy) than ASSAULT RIFLES?
What country did you think you were in again? Go see "Bowling for Columbine". It will clear things up for you. Mowing down your neighbors with an assault rifle is as american as apple pie. Smoking dope is only allowed if you can afford it.
Slashdot Mirror
- I fail to see how it was in any way a parody aside from the changing of the letters and hawking your links [216.239.39.100] and providing an interface to their engine that can easily be construed as "intentionally confusing" to users.
Of you do. That's because you are a humorless curmudgeon who didn't laugh their ass off like I did when you visited the site to look at it. Hint: the fact that you might make that kind of a mistake in the first place is part of joke.Here you go
If I am not mistaken, KHTML now runs on Linux, Atheos and now Mac OS X. That's not bad for code that is supposedly "not portable".
- PC's do not have correct color output, and never will. No matter high end the PC, the colors never look "right" or balenced on the screen.
Hey moron, Macs and PCs use the same graphics processors these days (either an nVidia or an ATI.) These companies don't make "Mac versions" of their chips, or leave out any DAC tweaking capabilities from the PC version.My nVidia geForce ti 4600 came with a color matching system that had me playing with my monitor settings (it has this official pantome color thingy that I had to hold up to the monitor, as well as other various tests) for about 15 minutes, and the result is a pretty damn perfect screen as far as I can tell.
I've added this story to my collection of Apple tidbits
- Of course. But consistency is more important than accuracy -- I'd like to see a standard which says "sin(x) is defined to be the result of running algorithm xyz, and will be within 1.5ulp of the mathematically correct value".
Then you can write a taylor series (or any other approximation) for yourself. Either way, you can't leverage the hardware if you want consistency. Different x86s (even different *INTEL* x86s) have used different algorithms which lead to slight differences.Since this is an area of open research it seems a little silly to dictate a choice right now, in the standard. In the future mathematicians may prove that sin maps Q\{0} solely to irrationals (probably true), in which case we can at least know that 0.5ulp algorithms are finite. They may state more that can help us implement 0.5ulp within exact bounds. I.e., creating algorithms which are ideally accurate might just be a matter of research. Consider the rather poor choice of "quick sort" as the standard C sorting algorithm (and the initially chosen algorithm for the C++ STL) when "introsort" has now reared its head as a technically superior algorithm.
Now, lets say you want something that is consistent, yet fast? It may turn out (and its certainly quite possible) that Intel and AMD's transcendentals *are* consistent once rounded down to 64 bits. I think that this is a rather difficult thing to check (unless there are numerous obvious counter examples) and so it probably could not be used. We could choose some taylor or rational series today, and in a few years/decades be laughed at by people who manage to prove/check that AMD and Intel's trancendentals are all identical once rounded down to 64 bits.
Writing algorithms in software that are within 1.5ulp might be very difficult. The way that AMD and Intel do it, is by actually implementing more than 80 bits FP numbers internally, and just picking rational series with enough terms (and rotating the results from a given specific range, of course.) It may not be possible to match the performance of these routines at 1.5ulp
The IEEE gives consistent +, -, *,
But perhaps you need other properties like convexity, or something like that -- in which case, perhaps the rotational thing might not work for you. Perhaps you need for the value to never be *over* estimated, in which case a truncated taylor series may be more appropriate than other algorithms.
In any event, I think the IEEE people have made the best choice. They have created a standard where any other changes to the spec (such as favoring consistency, to speed and accuracy for trancendentals) the ensuing controversy would have prevented the spec from being so widely adopted.
- One of the changes since the last time we heard about D is the addition of floats and doubles (32 bit and 64 bit floating-point types, respectively) in addition to the "extended" type (as much precision as available). This is absolutely a Good Thing -- extra precision can be just as bad as insufficient precision, and adding these types allows people to ensure that they're using the right precision.
This is very x86-centric. Most RISC CPUs don't have an extended precision, and some super computers have multiple extended precision modes. x86s are rather unique in their support of exactly one extended precision mode. Oh yeah, and older ARM and x86 processors don't even have FP built-in. So much for "portable".- It would have been really nice to see the same thing for the math library functions; as it is, the only sin function is an extended -> extended function. IEEE doesn't require determinism on transcendental functions the way it does for arithmetic functions (which, I'm guessing, is why it isn't provided here), but there are times when it would be quite helpful.
The reason the IEEE 754 standard does not specify exactness for transcendentals is because there are no provably known finite algorithms for computing them. It is even very difficult to state the bound for how many steps are required for any non-trivial finite set of inputs without computing them all.The IEEE 754 standard makes the choices which delivers as much as is possible within reasonable practical limits. When the Java committee foolishly tried to establish their own FP standard
I believe the D guy has probably taken this lesson to heart but probably overstepped by considering the x86 model as the most legitimate model.
Now we know where the former Anderson consulting executives have gone to work ...
Here is a quick summary, with a rating for each entry: click here
- Microsoft has been raiding the University of Waterloo for programmers for years now.
Correction -- *decades*.- Beware of statistics on children killed by guns. Usually they don't differentiate between the 10-year old who accidentally shoots his sister with daddy's pistol and the 17-year old gang banger who gets shot by the owner of a liquor store while attempting an armed robbery.
That's funny -- I don't differentiate between those either. The very fact that you think some people might deserve to die (by being shot) indicates to me, that you are american.- Well, it seems pi is normal, which means any finite sequence appears somewhere along the expansion of the number. So trivially, that image of a circle is in there somewhere, as is an image of a triangle, the source to Linux 4.0, an image of Bush playing with G.I. Joe dolls on his desk and so on.
Actually, it has not been *proven* that PI is normal. It just happens that "most" transcendental numbers are normal, and thus PI, probably is as well.- Pi is worse than irrational - it's trascendental. Merely irrational numbers can be expressed as simple expressions with finite numbers of terms, but transcendentals require an infinite number of terms.
Being "transcendental" just means that its a real number which is not the solution of any polynomial. For example, sin(1), and exp(2), are *probably* trancendental as well even though I wrote them as expressions with finite terms.This is an important distinction, because there are 5th degree polynomials whose solution I cannot write down in a finite number of symbols, even though that solution is not transcendental.
n in fact could be any rational, or complex rational, and PI would still not have a finite expansion in that base.
Well as long as we are being anal retentive -- you will have difficulty writing it as 10 as well. Since this is an irrational base, you are going to need some sort of digit seperator. So something like (1,0)_pi would be more appropriate (so we could write silly things like (1,e)_pi = e + pi)
- Do they need to know how to install the OS first, or should I let them look that up on their own while I make them power-users?
Learning to install an OS is a worthless skill to teach forward looking young people. OS's are getting easier and easier to install -- i.e., the crud you need to know to do it today will be obsolete soon anyway. You'll just end up teaching them frustration and how to wait a really long time- What distributions of Linux and BSD should they be first introduced to? (I'm only familiar with Debian, and I know virtually nil about *BSD.)
If you are the one designing the course, you should stick to what you are familliar with.- Initially, do they need to be more adept at the GUI, or do they first need to know how to use the shell?
GUIs were designed for idiots and old people (i.e., the Macintosh's intended audience.) I am not kidding or being facetious. Young people can learn a command line just as easily and will prefer it for its power. The point of a GUI is that you're not supposed to *teach* it to someone -- if a GUI requires training to use, then the GUI has been ill designed. Command lines need training but are well worth the effort to learn.- Should I give away Debian CDs no-questions-asked, or should I talk with the almighty Parents so little Daniel doesn't install Linux over Dad's 'work computer.'
Well, only if Dad's work computer is Windows.- Are there any other key issue I need to think about?"
Yes, you have to come up with content for the course itself. Just letting kids tinker around with free OS's and free software isn't going to be that exciting. You have to create sub-projects for each day -- like 1) root privelege and setting up accounts 2) setting up a network between two different OS's 3) download and recompile an open source project (preferrably something multimedia related like XMM or something)I wish you the best of luck.
Short answer:
0
Itanium = IBM PS/2. Hammer = PC AT.
Long answer:
Itanium is a VLIW architecture with a new 64 bit instruction set, that performs in-order execution (like an original Pentium, or a Sun UltraSparc.) It has very high floating point performance, because of its dual, fully pipelined FMAC units. The architecture is interesting in that it uses a wide variety of mechanisms (predicates, conditional loads/stores) to avoid branches without using speculation.
Because of its new instruction set, its not compatible with any prior software. *Everything* must be ported from scratch, and there is no prior install base from which to leverage. (Actually that's not strictly true -- it has an x86 compatibility mode that is exceedingly slow; its like a quarter to a third of the performance of leading x86s.)
Compilers in particular are a really different kind of beast on the IA-64. All the "out of order execution" techniques that are in most other modern CPUs have to be somehow implemented in the compiler. The performance of everything depends on these compilers, and so far only Intel and HP's compiler have measured up to snuff. SGI's, Microsoft's and gcc have been ported, but apparently aren't very credible. It appears as though creating good compilers for IA-64 is a truly monumental task.
Microsoft has gone on record as saying that they have no intention of porting Office to Itanium -- its not that kind of platform. Itanium is seen as a server only player. While one is tempted to say "oh but that will come to the desktop eventually", unless Microsoft (or Apple or Sun -- but those are even less likely) is willing to port a significant number of applications to it, that's just not going to happen. Microsoft has ported Windows to IA-64, but has pretty much stopped development of IA-64 at that point.
Itanium has been available for over a year now, and has had a very cold reception in the marketplace. Nobody wants them.
Hammer (Opteron) is just a 64 bit extension of the x86 architecture. If you are an assembly, or system level programmer take a look at this:
http://murl.microsoft.com/LectureDetails.asp?69
Its quite detailed. The key thing to note is that the x86-64 instructions are really just extensions of the IA-32 instructions. That means that all the compilers and tools work almost identically to how they worked for IA-32. The key features that have been added are: 64 bit registers, a 64 bit address space, and twice as many integer and SSE registers.
x86-64 remains backward compatible with ordinary x86 in two ways. If the chip boots as normal with a 32-bit OS, that is unaware of its 64-bit mode, than just like 16-bit DOS before it, it functions like a normal old 32-bit Athlon. It also contains two other interesting modes: 1) Long Mode (this is how 64-bit are enabled) and 2) Compatibility Mode.
Long Mode enables the new instructions, registers, address modes, etc. Compatibility mode allows it to execute the old 32-bit software in a virtual environment, much like the v86 mode used for DOS Boxes under Windows.
It is known that Microsoft has ported Windows to Hammer, and apparently Office and Internet Explorer are up and running on it. But don't be fooled, Microsoft didn't waste their time *porting* Office or Explorer to x86-64. They simply run in compatibility mode under this new Hammer enabled 64 bit Windows. That's the whole beauty of their scheme -- 32 bit and 64 bit applications can be running at the same time, sharing the same OS resources.
Now because x86-64 is so similar to IA-32, it allowed AMD to implement both long mode, and compatibility modes in the same pipelines, with optimal ALU usage, using the same instruction translation super-structures, the same rename registers, etc, etc. I.e., any effort AMD spends in speeding up the critical paths of 64 bit operations, translated back directly to 32 bit operations and vice versa. There is no compromise -- it will be a very fast 32 bit processor, as well as a very fast 64 bit processor.
While Hammer will not be quite at the same performance as IA-64 for floating point, it won't be that far behind, and it will almost surely cream it on integer performance. This much has been revealed by AMD/Intel's Spec CPU claims/disclosures thus far.
As far as selling Hammer? Its just a natural follow-on to Athlon. It won't cost more (it actually has a smaller die size, so it actually costs AMD *less* to make Opterons than Athlons) and it will be just as compatible with your software (Linux, Windows, or whatever.) At the very least, people *will* adopt them for the same reason they adopted the Athlon. So 64-bit ready desktops are going to ship middle of next year, and the customers *will* be lining up to get them (regardless of whether or not they use the 64 bit features, or even get the 64-bit Windows for it.)
Microsoft has gone on record as saying they endorse AMD's approach. And of course they don't need to commit one way or another to porting any applications, since they will all run at top speed on Hammer regardless. While there is nothing more overtly committed by Microsoft, reading between the lines will lead you to realize the Microsoft probably intends to port its DB and IIS to Hammer.
Linux, of course, has been ported to both, but I don't know if they have enabled the compatibility mode for Hammer.
- 32 bit architectures are not limited to 4 gigabytes of memory. "32 bit processor" refers to the width of the DATA bus (and registers). It does not refer to the width of the address bus.
This is a marketing term, not a technical one. And as far as the current 32 bit processors are concerned, you have it exactly backwards. x86's today have SSE registers which can hold 64 bit integers. I think the PPC's AltiVec registers can also hold 64bit integers. However, neither processor can access a 64 bit address space.But even the marketeers knows that you don't call these processors "64bit". With the notable exception of Nintendo, the only time a processor is labelled "64 bits" is when its *address* space is 64 bits, not just its registers/ALUs.
- The problems to be hurdled are:
True. But this is really a bad code practice sort of thing that developers that the C/C++ standard doesn't endorse anyhow. Java developers need not be concerned.1) Reliance on the fact that size of pointer is equal to size of int.
- 2) Reliance on a particular byte order in the machine word.
Its little endian, like it has always been on Intel. What's the problem? Little endian has the natural LSB/W/D property that makes increasing the natural word size typically a non-issue (unlike big endian where it is a serious PITA.)- 3) Using type long and presuming that it always has the same size as int.
It is the same. You need to use "long long", or "_int64" or something like that to move to 64 bits in your C/C++ compiler. AMD's new "long mode" actually defaults to 32 bit data sizes, and only uses 64 bits when specifically overridden to do so. That's the whole point of the x86 architecture -- it supports a variety of data sizes as a consequence of its long history of backward compatibility, not just one (like a typical RISC.)- 4) Alignment of stack variables.
Same as it has always been. (64 bit integers already exist today in known common ABIs/compilers, in case you were unaware.)5) Different alignment rules in structures and classes.
- 6) Pointer arithmetic.
Eh? You can add/subtract integers to pointers, and subtract two pointers from each other. How does moving to 64 bits change anything?- Both Intel and AMD have been betting big on 64 bit computing and it will be interesting to see how this plays out.
They had nowhere else to go. If we start hitting the 4GB, and there is no solution, software developers and end-users will eventually be crying bloody murder like they were when Intel's 640KB limitation was hit. (That time Intel was slow to react -- this time around AMD and Intel are trying to have a solution in place *before* it becomes a problem.)- Itanium 1 was a flop. Itanium 2 has respectable performance, but is not IA-32 backward compatible, where AMD x86-64 is backward compatible.
Well I like to dig on Intel as much as the next guy, but technically speaking, IA64 is backward compatible with IA32 (it does have a bona fide IA32 mode.) But its slow as molasses (they might as well be emulating IA-32.)That being said, I don't think Windows device drivers are going to work on IA-64 (the IA-32 mode is not involved in the boot process in any way.) IA-64's compatibility is in fact a "joke", though technically there.
The backward compatibility mode in Hammer, is very different. You can boot 32-bit windows on it, play your old DOS games on it or whatever and you will not know the difference (except it will be a lot faster.)
- will it be faster than 32 bit offerings?
Uhhh- For almost anyone out there, it's the only factor when buying a CPU: speed! Adressing >4Gb of memory is not that worries me first:)
Well it will be faster. Look, I don't know about you, but I have 512 MB of memory in my system. I have estimated that system memory capacity roughly doubles every year. At this rate, in 3 years we will be at 4GB in mid to high end machines, just as a natural course of things.The way I read that, in three years, 32bit-only systems will be obsolete.
You are thinking about large integers. Actually at the circuit level, multiplication is not done in O(log(N)) steps, but instead, they just have blazingly fast adders. Now, of course the additions can be grouped in a parallel tree, so there are essentially log(N) stages. Each adder can be thought of as O(log(N)), so you might say that the multiply is O((log(N))^2) steps.
- 1. All addresses being 64-bits.
This is incorrect. The Hammer "long mode" uses 32 bits as the default data size. 64 bits are only used for pointers and explicitely overridden 64 bit operands. I.e., you still have to declare "long long" or "int64" or whatever, in your languages to access those 64 bits. All your old 32-bit data still occupies the same space.For #1, realize that this is going to greatly increase the data size of many applications. The larger the data size, the higher the chance of cache misses. In general, this is a loss, not a win.
Furthermore, measurements by AMD indicate that op-code size did not increase with the expanded instructions, but actual *decreased* because the additional registers decreased the typical amount of spill/fill code emitted.
Therefore there is no additional cache pressure. The "code bloat" problem remains solely in the hands of the software developer, and is *NOT* worsened in any way by hammer.
- 2. All internal integer registers being 64-bits.
This is also incorrect. There are numerous well known techniques used in ALU design that makes precious few operations "O(bits)". Again, AMD specifically targetted this. For example: the 64-bit integer multiply in hammer is *FASTER* (per clock) than the 32-bit integer multiply in either the Athlon or Pentium 4.For #2, realize that some integer operations are O(N) where N is the number of bits involved. 64-bit multiplication and division are slowerthan the same 32-bit operations. Period.
The reason AMD is able to do this is because arithmetic and logic operations can largely be implemented in a "more gates for more speed" fashion. They are closer to O(ln(N)) than O(N). But at this level of circuit design, you don't necessarily think in those terms (since N is constant, everything just looks like O(1)) -- these high speed circuit designers worry about other technical things like "latch speed".
The 64 bit integer divide may be a little slower, however, again you need to explicitely use 64 bit ints in your software, and division is a comparatively uncommon operation.
- The gain with 64-bit processors is one of address space and nothing more.
This is the largest gain (big DB people will be very happy with it) but it certainly is not the only gain. Remember that there are now twice as many SSE registers. This opens up some performance possibilities for multimedia applications.Although I don't know that its related to SSE, it should be pointed out that EPIC (as in the video game company) has ported the Unreal engine to x86-64! Like most people, I was quite surprised that they did this, however, they apparently found doing it to be worthwhile.
Do not underestimate the upside of going to 64 bits in the way that AMD has done it. They have literally made it a no-lose scenario -- that alone should spur (mostly new) application developer interest.
So I take it that those Transmeta stock options have really paid off?
I'll let you in on a little secret ... when Columbus came over here, you know what he found? Other people were already here! That's right! A whole civilization of people already here! Sorry, but I think he was beat by at least several hundred in not several thousand years.
- Excuse me? The pound of dope was more of a threat (well, more newsworthy) than ASSAULT RIFLES?
What country did you think you were in again? Go see "Bowling for Columbine". It will clear things up for you. Mowing down your neighbors with an assault rifle is as american as apple pie. Smoking dope is only allowed if you can afford it.