Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

151–159 of 159 posts

Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)

#151

Post by interlocutor »

dekhn wrote: post #54
whitefish wrote: post #23

Earlier quoted context omitted.

Couldn't you say this about the software industry in general? In the 90's I used to have a Sun workstation on my desk. It ran the powerful Solaris operating system, but had just 16MB of RAM! Today you need 1GB of RAM to run an OS comfortably. My question: what does modern Linux do that Solaris from the 90's did not, that it requires 50x more memory?

I'm not sure if you're serious, but modern linux does a lot of things that solaris didn't do back then. A few more points: my linux system ran "OK" with 8MB RAM in 1995, although it started to swap when I ran emacs, X11, and g++ at the same time (this was ultimately fixed by maxxing out the RAM to 32MB). I have small Linux systems today that work comfortable with 128MB of RAM used. What my modern linux system does th…

The SGI Indy came with just 16 MB RAM, and ran the IRIX graphical environment and also had OpenGL. IRIX had excellent system administration tools.

https://en.wikipedia.org/wiki/SGI_Indy

https://en.wikipedia.org/wiki/IRIX

Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)

#152

Post by XorNot »

kazinator wrote: post #136
XorNot wrote: post #46

Earlier quoted context omitted.

GUID partition tables mean we don't need to coordinate identifiers. That's the point.

But in fact, we don't need to coordinate identifiers. Clashes in partition ID's are of no practical consequence. A 32 bit "fourCC" would be more than adequate. It could even be constrained just to readable characters, like LNXF (Linux Filesystem) and LNXS (Linux Swap). If another OS happens to use LNXF for something, and you have that OS in the same darn system, it doesn't matter. You just don't have that "foreign" L…

Why have them at all then?

If the argument you want to make is that they are of no consequence, then you need to answer why your proposal of still doing something is warranted.

Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)

#153

Post by khedoros1 »

oblio wrote: post #36
whitefish wrote: post #23

Earlier quoted context omitted.

Couldn't you say this about the software industry in general? In the 90's I used to have a Sun workstation on my desk. It ran the powerful Solaris operating system, but had just 16MB of RAM! Today you need 1GB of RAM to run an OS comfortably. My question: what does modern Linux do that Solaris from the 90's did not, that it requires 50x more memory?

Well, I don't know, could your Solaris (mostly) seamlessly connect and disconnect to wireless networks? I don't even think there were that many wireless networks in the world back then :) Anyway, this is is just 1 contrived example of something modern OSs do, and that OSs from the 90's didn't do. Sure, there's some bloat, but a lot of it is the "Mozilla kind": "Mozilla is big not because it is full of useless crap. I…

> Anyway, this is is just 1 contrived example of something modern OSs do, and that OSs from the 90's didn't do.

This doesn't add anything, because contrived or not, it doesn't answer the question that was posed: "What does modern Linux do that Solaris from the 90's did not, that it requires 50x more memory?"

It hits the first part of the question, but not the second part. We could add wifi to a 90s OS without severely inflating the memory requirements. My Nintendo DS (with 4MB RAM) "seamlessly connects and disconnects to wireless networks", after all.

You could easily answer the question with a sensible, non-contrived answer, and I'm not sure why you didn't.

Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)

#154

Post by mtdewcmu »

pjmlp wrote: post #148
mtdewcmu wrote: post #143

Earlier quoted context omitted.

.NET Native is new to me. It looks like it helps CIL languages to perform better. I'm not sure what it does to C/C++. I can't tell what the grand strategy is, but I guess they are catching up to Apple in some ways. It's amazing what Microsoft's resources allows them to do. Apple uses LLVM, and, of course, they would not be Microsoft if they adopted LLVM. Microsoft writes their own LLVM from scratch. I think it's good…

Actually Microsoft had their own LLVM first. :) It was called Project Phoenix, developed at MSR. https://en.wikipedia.org/wiki/Phoenix_(compiler_framework)

Microsoft Research is the genuine article. It's a world class research institution.

I guess Phoenixey/LLVM type stuff is probably the way the winds were blowing in the compiler community at large. It's interesting how a lot of things that used to seem impossible are now in multiple software packages.

You figure that once MS is rolling out a compiler technology in a big way, it can't get much more mainstream than that.

I still don't totally understand why it was important for MS to push into JIT-compiled bytecode on Windows. From the end-user's standpoint, it just makes software slower.

Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)

#155

Post by kazinator »

XorNot wrote: post #152
kazinator wrote: post #136

Earlier quoted context omitted.

But in fact, we don't need to coordinate identifiers. Clashes in partition ID's are of no practical consequence. A 32 bit "fourCC" would be more than adequate. It could even be constrained just to readable characters, like LNXF (Linux Filesystem) and LNXS (Linux Swap). If another OS happens to use LNXF for something, and you have that OS in the same darn system, it doesn't matter. You just don't have that "foreign" L…

Why have them at all then? If the argument you want to make is that they are of no consequence, then you need to answer why your proposal of still doing something is warranted.

Because we can usefully assign distinct values in a context like "Windows plus Linux box" in which we don't care about some exotic file system that was once used on a DEC VAX or whatever.

Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)

#156

Post by Const-me »

mtdewcmu wrote: post #154
pjmlp wrote: post #148

Earlier quoted context omitted.

Actually Microsoft had their own LLVM first. :) It was called Project Phoenix, developed at MSR. https://en.wikipedia.org/wiki/Phoenix_(compiler_framework)

Microsoft Research is the genuine article. It's a world class research institution. I guess Phoenixey/LLVM type stuff is probably the way the winds were blowing in the compiler community at large. It's interesting how a lot of things that used to seem impossible are now in multiple software packages. You figure that once MS is rolling out a compiler technology in a big way, it can't get much more mainstream than that…

Security, safety. Also GC is easier to make.

It doesn’t always makes software slower.

Not all software is CPU bound, a lot is IO bound, and .NET framework implements event-based asynchronous I/O since version 1.0.

Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)

#157

Post by XorNot »

kazinator wrote: post #155
XorNot wrote: post #152

Earlier quoted context omitted.

Why have them at all then? If the argument you want to make is that they are of no consequence, then you need to answer why your proposal of still doing something is warranted.

Because we can usefully assign distinct values in a context like "Windows plus Linux box" in which we don't care about some exotic file system that was once used on a DEC VAX or whatever.

So why not use a single byte? How many machines do you know which have more then 255 filesystems on the one disk?

Why not a nibble and just use the other 4 bits for flags?

The point of this line of questioning is you're quibling over bytes which definitely don't matter in any modern context, at the expense of masses of extra management complexity to try and avoid day-to-day problems when people want to stand up new systems.

With GPT, if I want to make a new filesystem type for some application, I just generate a GUID and it will not collide without me needing to coordinate with anyone.

Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)

#158

Post by dekhn »

interlocutor wrote: post #151
dekhn wrote: post #54

Earlier quoted context omitted.

I'm not sure if you're serious, but modern linux does a lot of things that solaris didn't do back then. A few more points: my linux system ran "OK" with 8MB RAM in 1995, although it started to swap when I ran emacs, X11, and g++ at the same time (this was ultimately fixed by maxxing out the RAM to 32MB). I have small Linux systems today that work comfortable with 128MB of RAM used. What my modern linux system does th…

The SGI Indy came with just 16 MB RAM, and ran the IRIX graphical environment and also had OpenGL. IRIX had excellent system administration tools. https://en.wikipedia.org/wiki/SGI_Indy https://en.wikipedia.org/wiki/IRIX

We had Indys with 32MB of RAM in '97-98. They were basically useless- the OpenGL implementation wasn't that great, and the rest of the system was massively underprovisioned (constant slow disk IO). However, we also had a bunch of better SGIs with 64+MB of RAM and those worked great.

Re: Revisiting 64-bit-ness in Visual Studio and elsewhere (2015)

#159

Post by kazinator »

XorNot wrote: post #157
kazinator wrote: post #155

Earlier quoted context omitted.

Because we can usefully assign distinct values in a context like "Windows plus Linux box" in which we don't care about some exotic file system that was once used on a DEC VAX or whatever.

So why not use a single byte? How many machines do you know which have more then 255 filesystems on the one disk? Why not a nibble and just use the other 4 bits for flags? The point of this line of questioning is you're quibling over bytes which definitely don't matter in any modern context, at the expense of masses of extra management complexity to try and avoid day-to-day problems when people want to stand up new s…

Indeed; one byte works for me. Four is a reasonable political compromise between "one byte works for me" and "oh my, what about clashes?"

16 bytes is an obvious example of the "second system effect" described by Fred Brooks in Mythical Man Month.

The fdisk utility now reduces the GUIDs to one byte codes that refer to the GUIDs. For instance, I remember that 29 is Linux RAID (previously FD). Will 29 always be Linux RAID everywhere? Probably not.

> With GPT, if I want to make a new filesystem type for some application ...

Four bytes could have an ample reserved range for local use by hobbyists.

Broad recognition of the code only matters if the application is very widely deployed.

Post reply on HN