"I think they are doing a marketing gimmick. There's zero benefit a consumer gets from that. Predominantly... you need it for memory addressability beyond 4GB. That's it. You don't really need it for performance, and the kinds of applications that 64-bit get used in mostly are large, server-class applications." -- Anand Chandrasekher
Although it was marketed as the first 64-bit gaming system, the Jaguar proved to be a commercial failure and prompted Atari to leave the home video game console market. Despite its commercial failure, the Jaguar has a dedicated fan base that produces homebrew games for it.
people think that 64 bit have better performance because AMD64 has better performance because than x86 because it had much more registers unlike the limited of the x86.
The best would be to have variable length word size just like some old IBMs but programming languages like C would not be able to use that. A modern lisp machine would hide things like word size from the programmer
Name:
Anonymous2014-06-28 19:42
Adding up all my currently running processes minus Firefox and Flash Player gives like 100-200 MB usage (Win 7, 2GB installed) -- I'd really agree on the 1 GB thing: if you can't have a system connect to the internet and read some news or watch a video with <= 1 GB you have some awful software installed on your computer. But we're getting there -- with my setup and usage as above, I still have occasional accesses to the pagefile. Personally, I still mostly compile to x86 (knowing that x86_64 is often faster).
I've been wondering though: what does 'n Bit' (8, 16, 32 or 64) even mean? 8 bit machines could usually address 16 bit, some 32 bit machines had 64 bit wide regs for arithmetic and such (x87 has 80 bits...) and modern x86_64 machines can usually address 'only' 48 bit (most likely less, chipset-dependent) and currently have up to 256 bit wide regs (with AVX; 512 bit wide starting in 2015) -- couldn't/wouldn't they advertise those as 128/256/512 (instead of 64) bit CPUs? We all know the consumer likes bigger numbers even if s/he doesn't know what they mean.
64bits are really about per process memory, and even then 32bit x86 can still utilize 64bit address bus using segments and far pointers. But no, you have to waste 2x memory on 64bit pointers everywhere.
Are you taking me for a web dev? Niggeh, Databases and high I/O servers need that amount of RAM. x86 will not run multiple prolonged queries and transactions in the 100k range, esp. on a server requiring multiple cores by default.
NonStop SQL is designed to run effectively on parallel computers, adding functionality for distributed data, distributed execution, and distributed transactions.
so it doesn't care about the size of address space.
>>16,17 Ok, what are you on? Whether I use a distributed database or a central one, both do not address the core of the 64bit issue: More memory than 64GB is required for today's work, and x86 using PAE does not provide addressing space after the 549755813889th bit.
Unless you are implying that I should cluster multiple CPUs for a Memory problem, not speed. Is that what you are on right now, amphetamine?
If the later was the case, you have to consider that is cheaper to buy RAM over CPUs clustered in a bottleneck network of some sort (like 802.3an).
Name:
Anonymous2014-06-29 0:13
>>17 Distributed transactions sounds slow as fuck.
4-bit get used in mostly are large, server-class applications." -- Anand Chandrasekher
Which is what I was talking about. Even smartphones these days have +8GB of RAM. It's cheaper to solder a DDR3 8GB SO-DIMM RAM on a ARM 64 Arch, than a 32 bit PAE protocol on custom devices with several SO-DIMMs
You guys could stop wasting your time and learn something like category theory instead of learning what SO-DIMM means or what's going on with computing hardware manufacture. Until the day comes when you are actually truly building and soldering your own computer etc like it was done in the 70s/80s for PCs then who gives a shit?
Name:
Anonymous2014-06-29 10:23
>>25 Ha, we had to solder an 8086 computer for CPU architecture class. At least it wasn't wirewrap like they had for the 68k class.
>>25 My point summarized. If you don't need <64GB of RAM, 64bit Archs are not for you. In the mean time, I will continue to use it since I require as much RAM as I can find, saving both time and money than worrying about PAE on obsolete hardware.
>>30 Labeling, and not explain your stance. Why 64bit? More memory required. Why PAE? For limited hardware still under 32bit. Today's need? Lots and lots of memory. You? __________________
Name:
Anonymous2014-07-03 4:24
>>1 PAE a shit. Having a physical address space that's larger than the virtual space means the OS will fuck itself sideways managing the page mappings. DOS did this when the 386 was introduced and it doesn't suck any less now than it did then.
>>7 Word size on x86 is variable. In practice though one always tries to use the default size because the instruction encoding to change the operand size is inefficient. That limitation applies no matter what language you happen to use.
Other ISAs don't impose this encoding penalty, and C language code written with this in mind works fine on them.
>>11 No one is stopping you from running 32 bit applications on a 64 bit OS if you know 3-4 GB per process is all you need.
roses are red violets are blue hax my anus eat da poo
Name:
Anonymous2014-07-03 17:12
>>43 Wow, that actually makes sense. Someone has a prolapsed anus which means that there is an extension out of said anus, and that extension is, obviously, covered in shit (because it is extended out of that person's anus and he hadn't bothered with a bidet).
Yes, it did. Constantly churning page mappings to deal with a limited virtual address space is cumbersome and inefficient.
Actually, kept everything localized and cache friendly.
Name:
Anonymous2014-07-04 22:56
>>48 PAE isn't free. Requiring the OS to remap pages it is using for itself means you are forced to invalidate the PTEs and incur TLB misses every time the OS must access memory that isn't mapped in.
>>49 Neither is EPA. You can't just make the RT write to invalid TULs unless the BLT is fully consumed and the FS is well-aligned, since that would incur TRU remaps to access memory.
>>49 Am I missing something here? 32 bit Linux reserves half of the virtual address space for the kernel, and 32 bit Windows reserves a quarter. PAE or not, why would they need to swap those kernel pages when switching processes?
Name:
Anonymous2014-07-05 8:07
>>52 It's not about swapping or application pages at all. TLB entries always have to be invalidated when context switching and PAE doesn't change that.
The problem with PAE is that the kernel itself doesn't have enough address space to access all of the physical memory in the system at once. If the kernel needs to access something that isn't inside the 4 GB space that's currently mapped, the page mappings must be changed and something else must be evicted from the current mapping to make room. The kernel incurs TLB miss and page table walking penalties every time this is done. IIRC Linus once cited a case where workloads that use a lot of data in kernel high memory (e.g., lots of filesystem stuff) would spend 25% of their time just doing kmap / kunmap.
Name:
Anonymous2014-07-05 8:21
Why couldn't ey just make 40-bit systems?
This post was typed with the Colemak keyboard layout
Name:
Anonymous2014-07-05 21:43
Why couldn't ey just make 18-bit systems like I do?
This post was typed with my experimental 27-key keyboard layout.
Name:
Anonymous2016-10-24 15:14
64-bit is only good for FP
Name:
Anonymous2016-10-25 8:31
Dwarf Fortress needs more than 4GB now, otherwise it starts to run out of memory after a while on 6x6 or even 5x5 maps.
Name:
Anonymous2016-10-25 8:54
>>57 I 2x4gb planks just because some programs and games start swapping with 4gb. Of course i normally stay below 4gb, and enjoy the benefits of completely disabled swap file.
