|
Not enterpise ready yet
"The lack of a 64-bit implementation of the .Net Framework means that the hard work many Windows developers have put into migrating to the .Net development model is for naught on Windows on Itanium. This includes time spent mastering the intricacies of ASP.Net, ADO.Net, and the C# language, all of which will remain missing in action until Microsoft ships a 64-bit Framework implementation in the second half of 2004. "
I did not know this was not available for Itanium. I just thought it would have been a larger priority. Aren't the J2EE implementations 64 bit capable?
http://www.infoworld.com/article/03/10/17/41FE64winnet_1.html
Cedric
Friday, October 24, 2003
Why rush a release for a processor that's not really being bought? Itanium is dead (at the moment)
GiorgioG
Friday, October 24, 2003
>Why rush a release for a processor that's not really being bought? Itanium is dead (at the moment)
You can buy corporate machines running 64bit Itanium. For most analytics and large data needs an Itanium could very much come in handy.
Li-fan Chen
Friday, October 24, 2003
For 97.33% of the developers, 32-bit is enough.
Of course, 64 bit is nice, but absolutely not a requirement.
Also, if they port it, I would like them to port it to the Athlon 64 and Opteron, for which I can get a decent price motherboard - not to 64 bit machines that are more expensive than God, like the Itanium.
Jaxxon
Friday, October 24, 2003
For 97.33% of the developers...
Reminds me of how roughly 84% of statistics are made up on the spot...
But I agree with your percentage, anyway
Andrew Hurst
Friday, October 24, 2003
The fun one is that neither of the 64-bit platforms are going to look good (unless you are using a pre-existing set of tools that happen to be ported already, like some parts of the Linux world, of course) until all of the goodies are available for it.
I really wonder about the CLR folks because they built it after the widespread adoption of 64 bit workstation/server chips on the other platforms. They could have at least made it easy.
Flamebait Sr.
Friday, October 24, 2003
"For 97.33% of the developers, 32-bit is enough.
Of course, 64 bit is nice, but absolutely not a requirement."
-Jaxxon
"640K should be enough for anybody."
-Bill Gates
Jim Rankin
Friday, October 24, 2003
AMD's x86-64 seems to be a better short term solution than Itanium for 64bit processing and .NET. 32bit apps running on 64bit Windows can address the entire 4GB address space (as opposed to 2GB in 32bit windows). And running 32bit and 64bit code side-by-side is seamless.
Of course, at this stage pretty much everything Microsoft and 64bit is in beta without any hard release dates. It seems that even developing native 64bit apps at this point is a bit premature.
Almost Anonymous
Friday, October 24, 2003
Let me be the first to express my complete ignorance on the implications of 64 bit processors vs 32 bit processors. As a developer, do you code any differently for a 64 bit processor? If not, what is done differently?
notAlGore
Friday, October 24, 2003
Seeing as how I'm a really just a 2 bit user, this won't affect me at all...
Guy Incognito
Friday, October 24, 2003
"As a developer, do you code any differently for a 64 bit processor? If not, what is done differently?"
The biggest implication of having a 64bit processor is the massive increase in address space. 32bit processors a limited to addressing only 4GB of RAM. We're now starting to get the point where that's too constraining.
We'll probably see an increased use of memory mapping of files when 64bit processors become more common.
Almost Anonymous
Friday, October 24, 2003
> "640K should be enough for anybody."
For the record, Bill Gates never said that. I don't care how many people on the internet claim he did, no one can point to an actual source.
Tim Sullivan
Friday, October 24, 2003
84% of statistics are made up on the spot? That's up 12% from last year!
Troy King
Friday, October 24, 2003
In languages that do not expose the underlying hardware implementation, you don't _have_ to change anything for 64 bit, and most probably, you won't get much benefits either.
In C, you have to be aware that, all of a sudden, type sizes change - e.g., sizeof(void *) becomes 8, sizeof(long) _might_ become 8. It is no longer safe to store ints and pointers interchangably. Alignment needs to be 8-byte, not 4-byte, and a variety of other changes.
You _do_ get a 64bit address space, which means that techniques like pointer swizzling and memory mapping can be used more effectively, and give you a significant boost in speed if used correctly.
Ori Berger
Friday, October 24, 2003
.Net has a common type library, so variable types are automagically handled/converted behind the scenes. Should be the same with 64 bit .Net, so a long is a long is a long as far as anyone needs to care.
Philo
Philo
Friday, October 24, 2003
Tim Sullivan...
http://www.urbanlegends.com/celebrities/bill.gates/gates_memory.html
might be interesting. Mr Gates goes on record as denying he said it in fact.
Robert Moir
Saturday, October 25, 2003
Not quite true philo. Brad Abrams has some stuff about the problems in his blog (Oct 15th entry)
As brad puts it:
"We made a few design mistakes in V1 and exposed some properties that are really word sized as Int32’s rather than Int64s. I don’t think there are very many of these, but it seems we need a common pattern for any we do dig up…"
Peter Ibbotson
Saturday, October 25, 2003
> It is no longer safe to store ints and pointers interchangably.
It has NEVER been save to store ints and pointers interchangably.
char* full_name()
Sunday, October 26, 2003
In theory, it has never been safe.
In practice, it has worked on every common 32 bit architecture, including 68k, Sparc, x86, MIPS, and others. Many programs rely on this; And those that use void* as the "common" type rather than int, work just as well on all common 64 bit architectures (Alpha, UltraSparc, MIPS, x86-64, IA64, G5).
For the record, I don't advocate doing that when you write new code.
Ori Berger
Sunday, October 26, 2003
 Recent Topics
Fog Creek Home
| 
