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

131–140 of 159 posts

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

#131

Post by alkonaut »

taspeotis wrote: post #14

Run devenv /safemode to load the IDE without third party extensions (think ReSharper) and the thing flies. It's not Microsoft's code that's the problem.

This might be the case - but the IDE isn't really complete withiut extensions. I need svn integration, and I need basic refactoring from R# like "move type to new file".

The problem is probably that memory is crowded and plugins must do a lot in-process via COM.

If Microsoft really wanted to make VS fly for a lot of people they could just add the 10% most popular features from the 10most popular extensions. It would want nothing more than to throw out R#

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

#132

Post by mschaef »

wolfgke wrote: post #115
mschaef wrote: post #107

Earlier quoted context omitted.

"One scheme is to consider the value of the used segment register as a pointer to a 16 byte block of memory and use the segment index to adress the specific byte in this block (with an option to increase the index "a little bit" if you want to go further)" This only works in real mode, where the segment is shifted and directly added to the offset. In protected mode, it goes through a selector table. This can be made…

> This only works in real mode, where the segment is shifted and directly added to the offset. In protected mode, it goes through a selector table. Of course this is true. You wrote further above: > In a 16-bit address space (64K), you hit the 16-bit limit _all the time_. I wanted to outline that whether this is a problem or not depends a lot on the concrete 16 bit architecture.

Are you thinking of a specific concrete 16-bit architecture where it's easy to access data objects larger than 64K?

I'd be interested to hears... I really can't. Probably the most capable architecture I'm familiar with that has a native 16-bit pointer type is the 80286, which provides 24-bit physical addressing, virtualizatoin, protections, etc. Even then, at least on Windows, key local heaps within the OS were confined to 64K, the default text editor was confined to a segment... writing image processing tools (which I did) required special handling for all but the smallest scale workloads. These all added to developer workload and reduced system capacity in unfortunate ways.

I get what you're saying that there are exceptions and hacks that make it possible to work within these limitations, but my point is that you have to care about them on 16-bit, and most of the time you really don't on 32-bit. My thesis for why that is goes back to what I was saying initially about the size of the core data types people tend to manipulate.

(And this goes back to the reason I posted in the first place, which was to explain the relative difference in motivation between the 16->32 switch and the 32->64 switch.)

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

#133

Post by gwern »

"Because virtually invariably the reason that programs are running out of memory is that they have chosen a strategy that requires huge amounts of data to be resident in order for them to work properly. Most of the time this is a fundamentally poor choice in the first place. Remember good locality gives you speed and big data structures are slow. They were slow even when they fit in memory, because less of them fits in cache. They aren’t getting any faster by getting bigger, they’re getting slower. Good data design includes affordances for the kinds of searches/updates that have to be done and makes it so that in general only a tiny fraction of the data actually needs to be resident to perform those operations. This happens all the time in basically every scalable system you ever encounter. Naturally I would want people to do this.

...In the VS space there are huge offenders. My favorite to complain about are the language services, which notoriously load huge amounts of data about my whole solution so as to provide Intellisense about a tiny fraction of it. That doesn’t seem to have changed since 2010."

But I'm sure that by remaining 32-bit, in another 5 years maybe everyone will magically optimize their stuff... Any second now...

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

#134

Post by MrBuddyCasino »

The JVM has a neat trick where it uses 32 bit pointers up to 32GB heap sizes, because alignment is 8 bytes and so there are really only 1/8th distinct possible memory adresses for the whole adress space, so you can just easily map them.

Is this something VS could do?

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

#135

Post by ska »

daigoba66 wrote: post #88
bicubic wrote: post #57

Earlier quoted context omitted.

Considering the 64 bit support problem has been going on for over five years now and the magical 3GB limit is increasingly absurd on modern hardware, I wonder if they've considered just giving up on VS and doubling down on VS Code. It also sorts out their desperate need for a UI overhaul.

Visual Studio Code is a wonderful text editor. But it's far from being a full-featured IDE.

Really? I find that really surprising. Because VS itself isn't anywhere close to a wonderful text editor.

Like most IDE's, it is a mediocre text editor with a bunch of compelling (for certain workflows) tooling for project and build management, debugger, etc. Plus usable introspection. As a text editor though, a solid C+ at best.

Is VS Code someone doing something radically different?

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

#136

Post by kazinator »

XorNot wrote: post #46
kazinator wrote: post #19

Earlier quoted context omitted.

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.

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" LNXF in your /etc/fstab, and likewise it doesn't have the Linux ones in its equivalent of /etc/fstab.

The only thing that needs a clash-free label is the EFI boot partition, so the boot firmware can unambiguously identify all these partitions on all attached devices and offer them as boot options.

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

#137

Post by will_hughes »

wolfgke wrote: post #51
will_hughes wrote: post #48

Earlier quoted context omitted.

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…

> 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. What is the actual technical reason why the JVM cannot (easily?) address more than 32 GiB of RAM?

The ES documentation goes into more detail on this.

https://www.elastic.co/guide/en/elasticsearch/guide/current/...

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

#138

Post by intrasight »

pacaro wrote: post #110
intrasight wrote: post #76

Earlier quoted context omitted.

I often wonder the same. In '90 I helped build a primitive web browser, including an interpretive language. Used it to instrument a couple nuclear power plants. Displays were graphically rich, and had to load in When we have less, we make due with less. When we have more, we consume more. It's sort of like money.

Forgive the nitpick, but it is "make do", if only because "make due" reads very awkwardly in British English where "due" is pronounced as if it is spelled with a U and an E, not as if it is spelled with two O's

I learned something grammatical today.

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

#139

Post by ryandrake »

hashhar wrote: post #113
floatboth wrote: post #97

Earlier quoted context omitted.

Don't reinvent collectd :)

Thanks for the recommendation. Exactly what the parent commenter was asking for.

Yup, thanks, collectd seems to be exactly what I was looking for.

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

#140

Post by dmitrygr »

CountSessine wrote: post #111
blauditore wrote: post #74

Disclaimer: I don't know too much about this field Can someone explain why exactly 64-bit is generally slower than 32-bit? I understand that more RAM will be used and I/O to it slowed down due to double the bits pushed around since "chunks" have double the length, which ends up being a lot of empty padding (is that correct?). But everything inside the CPU, like registers or ALUs, are 64 bits wide anyway (right?), so…

Because no one else has mentioned it, paging is more expensive in 64-bit. In 64-bit, the kernel uses a 3 or 4 level page table requiring 3 or 4 SDRAM accesses on a TLB miss. 32-bit kernels can get away with 2 SDRAM accesses (PDE+PTE) if they're doing 32-to-32 translation. On a ~3GHz CPU, each uncached SDRAM access will cost the CPU about 200 cycles which means a worst-case 32-bit scenario would be about 400 cycles bu…

Modern CPUs heavily cache (in L2 & L3) the page table entries (some even speculatively load them into cache), so actual DRAM accesses are rarely needed.
Post reply on HN