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

41–50 of 159 posts

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

#41

Post by Cyph0n »

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…

Isn't a significant chunk of OS memory usage caused by the desktop UI? If we're talking about servers, I'm guessing it would be because of drivers and more built-in functionality, some of which is rarely used.

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

#42

Post by Cyph0n »

sp332 wrote: post #28

Security can improve with 64-bit as well. It's a lot harder to break ASLR in a 64-bit address space than a 32-bit one. Though again, that might not apply to VS where a user can get "arbitrary code execution" by design.

That's assuming high entropy for address randomization of course. A 64-bit OS that has a weak ASLR implementation could end up weaker than a 32-bit OS that implements ASLR correctly. Your point definitely stands if both are well made.

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

#43

Post by phkahler »

whitefish wrote: post #29
oobey wrote: post #16

Would he have made those same comments to resist going from 16 to 32 bit? Hell, why not stick with 8 bit? We can just optimize everything to work on that, right?

No. With 8 bit you had to execute multiple instructions to add two numbers. Same with 16 bit. This problem went away with 32 bit. Adding more bits beyond 32 does not bring proportional benefits because the numbers we deal with fit in 32 bit.

I agree, most numbers we deal with fit in 32 bits with the exception of double precision floating point and indexes for really large data sets. As Moore's law seems to be ending perhaps there might be a sweet spot at 48bits for both integer and FP.

The one thing I found absurd with RISC-V is the 128bit variant. Most 64bit processors today don't even support a full 64bit virtual address space do they?

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

#44

Post by hashhar »

whitefish wrote: post #23
marktucker wrote: post #11

In my experience, Visual Studio performance has improved significantly since VS2010, but if you compare it to VC6, it's a joke. There's still an old PC at the office running it, and double clicking a project opens the IDE and loads the project in less than a second. It's beautiful.

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?

If you set up your Linux distro from scratch you can easily manage under 200MB of RAM. I have an LFS I set up which idles at 150MB or so. A LOT of stuff is bloat in modern distributions.

I recommend everyone to try and build an LFS (Linux From Scratch) at least once or at least set up an ArchLinux box to get a feel for how Linux actually works and where the bloat is.

As an example, the music player daemon (MPD) has 110 dependencies among which is wayland or x-org, I don't know why.

Also, using udev to only load needed kernel modules helps with a lot of memory usage.

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

#45

Post by hrydgard »

wolfgke wrote: post #31
hrydgard wrote: post #20

Earlier quoted context omitted.

The FPU stack is only 8 entries in x86-64, yes, but the 128-bit SSE float/SIMD register set was indeed expanded to 16 entries, just like the GPRs (rax, rcx etc). The FPU stack is legacy and is barely used anymore, instead most floating point operations are done with SSE instructions.

> The FPU stack is legacy and is barely used anymore I know that if you implement an algorithm via SSE/AVX it typically is much faster than if you use the FPU. But I still believe that the FPU has its uses: For example it also supports 80 bit precision floating point numbers, while SSE/AVX only support 32 or 64 bit ones. There are applications where this capability can be quite useful. This is one reason why the FPU…

Yes, it has its occasional uses and is still supported, but the point is that x86-64 got a noticable FP capability boost through the doubling of the SSE registers compared to 32-bit x86. SSE is not just for SIMD, it has single/double scalar instructions as well, which mostly replace the old FPU.

If you look at generic floating point code generated for x86 by any modern C/C++ compiler, you won't see any FPU use, it's all SSE scalar, and occasionally SIMD for clever compilers.

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

#46

Post by XorNot »

kazinator wrote: post #19
oobey wrote: post #16

Would he have made those same comments to resist going from 16 to 32 bit? Hell, why not stick with 8 bit? We can just optimize everything to work on that, right?

More is always better. Four wheels is better than two; cars should have eight wheels. Look at GUID partition tables. With MBR, we had to hobble along with only a byte to identify partition types. Now we have 128 bits. We can finally support more filesystem kinds now than there are atoms in the Sun, all in one system installation, and the bootloader just has to look at the GUID. A 32 bit "fourcc" partition label clear…

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

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

#47

Post by phkahler »

wolfgke wrote: post #31
hrydgard wrote: post #20

Earlier quoted context omitted.

The FPU stack is only 8 entries in x86-64, yes, but the 128-bit SSE float/SIMD register set was indeed expanded to 16 entries, just like the GPRs (rax, rcx etc). The FPU stack is legacy and is barely used anymore, instead most floating point operations are done with SSE instructions.

> The FPU stack is legacy and is barely used anymore I know that if you implement an algorithm via SSE/AVX it typically is much faster than if you use the FPU. But I still believe that the FPU has its uses: For example it also supports 80 bit precision floating point numbers, while SSE/AVX only support 32 or 64 bit ones. There are applications where this capability can be quite useful. This is one reason why the FPU…

There was a nice thread last week about bugs due to the internal 80-bit representation in the old FPU. IMHO it should have been deprecated long ago and x64_64 should have disallowed its use entirely. There are 128bit FP these days implemented with new hardware and instructions.

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

#48

Post by will_hughes »

loganmhb wrote: post #40
eb0la wrote: post #17

I remember people favoring the use of their 32bit JVM instead of the 64-bit one for performance reasons but didn't wondered why. Makes sense if you're running Java with -Xmx1024m

When reading about Elasticsearch I was fascinated to learn that the JVM can often use 32-bit object pointers to address about 32GB of RAM when running in 64-bit mode: https://wiki.openjdk.java.net/display/HotSpot/CompressedOops

As someone who comes from the .NET world, this is something that pissed me off about configuring Java applications like Elastic.

If I've got a box with 512GB of ram, it seems I'm supposed to spin up multiple instances to satisfy this, all because the JVM has a hissy fit if you go over ~30GB. This then means worrying about replication and ensuring we don't have both the primary and replicas sitting on the same box.

It seems insane that this is an actual issue in 2017.

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

#49

Post by codeflo »

At work, I have a fast machine with 32 GB of RAM, of which Visual Studio can only access about 3 GB. About once a month, Visual Studio crashes with some kind of out-of-memory error, and more often than that, it slows down to a crawl because it has to garbage collect every few seconds in an attempt to keep its memory usage below this magic limit. Even though the machine has 20 GB of free RAM that Visual Studio just can't use.

The author acknowledges that this can happen:

> So, you’re now out of address space. There are two ways you could try to address this.

> a) Think carefully about your data representation and encode it in a more compact fashion

> b) Allow the program to just use more memory

> I’m the performance guy so of course I’m going to recommend that first option.

As a "performance guy", he should know that using a bit more RAM is essentially free, and much, much easier to code than doing the kind of bit-fiddling wizardry he suggests ("encode it in a more compact fashion"). In practice, that kind of low-level code will not get written anyway, at least not by modern Microsoft, and much less so by most extension authors. Which means that there's an arbitrary and very hard limit on how much you can customize/extend Visual Studio before you hit that 3 GB wall. And again, this is on modern workstation machines with gigabytes of unused RAM lying around.

In short, there may be very valid technical reasons why VS can't go 64-bit, but to claim that this doesn't hurt the product is in my opinion not justified.

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

#50

Post by loarabia »

oobey wrote: post #16

Would he have made those same comments to resist going from 16 to 32 bit? Hell, why not stick with 8 bit? We can just optimize everything to work on that, right?

I think he touched on this a little in a follow-up he did: https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit-vis...

My interpretation of the shift from So the question might be are there any surprising workarounds in the code because you're only dealing with 32 bit code where if you had 64 bits you could write some more elegant solution.

Post reply on HN