3 ms·

IPv6 looks like a the x86 64 bit architecture. On the paper it is better. In real life it brings only headaches that do not worth the trouble. And for those

IPv6 looks like a the x86 64 bit architecture. On the paper it is better. In real life it brings only headaches that do not worth the trouble. And for those who says memory, I answer that it is easy to make a 32 bit CPU with a 64bit memory adressing. IPv6 still requires IPv4 to do MPLS. IPv6 has no de facto standard to make autoconfiguration. IPv4 CPE are already bloated and hardly work with a fair level of simplicity I hardly know any decent IPv4 sysadmin even in ISP. The IoT will imply constant connection from your device to the manufacturer while being connected to your internal network... this is a leak to me. I don't want my lightbulb to be able to sniff on my mails. What IPv6 is good for? A lot of KPEX, concentration in ISP sector, a lock in effect... else I don't see.

netheril96 11y ago
x86-64 is quite successful as it is backwards compatible. Are you thinking about Itanium 64?
- SFjulie1 11y ago
  No I am thinking of the fact that code gets bigger, since assets get bigger, which results in execution is slower. Actually there is a whole domain of application for which 64bits coding results in slower code. Plus extending memory address space results in slower memory access. L1, L2, L3 caches are hardly accessible from python/ruby/...(ahhh using register is sooo fast). Which in turn results in more watt/instructions. Nowadays, the IT industry might be the leading one in its contribution to fossil energy consumption. Do we need to add coal plants to support the cloud insanity bloating web pages to 16Mb for applications that are hardly more than 8 operation calculators to tell you how "green" you are? I have a degree in ASIC design. Modern x86_64 architecture is insane. It has a lot of hidden complex mechanic built in that are de facto additional CPUs inside the CPU for on the fly optimisations (memory+OOP), "security", buses, plug n'play... And who pays? Actual IT industry is literally taxing the masses for something they neither ask nor need. The IT is locking consumers in arbitrary choices that results in higher costs.
tremon 11y ago
And for those who says memory, I answer that it is easy to make a 32 bit CPU with a 64bit memory adressing. Except when it isn't. How do you propose to calculate 64bit addresses with a 32bit alu?
- SFjulie1 11y ago
  By propagating the carries in the ALU? (oh! intel announced they are going to ship this feature) By using indirect addressing? (like PAE) Since they are physical boundary to this world and since linear addressing is constricted by speed of light vs the frequency of computers, there is a definite optimum we will not be able to break easily through for the next decades. Every time we extend the memory address space, we add levels of indirections on the Silicium anyway. C0 (the velocity of light in the void) is our first limit. Available resources/power on earth is our second limit. And money available to the consumers is the last one. Do we really have any good reasons to adopt new technologies that do not prove to be more efficient and/or less costly?
  - tremon 11y ago
    You are correct, that the hardware can do so without too much overhead. But I was arguing from the software point of view: segmented memory means no simple pointer arithmetic above the 32-bit limit. That means that software managing datasets above 4GB will always need special-casing, or be written with indirect allocation in all cases. I don't see a good reason for mandating that kind of complexity in code. If you have a solution for allowing 64bit linear addressing in code, I'm all for it.

netheril96 11y ago

x86-64 is quite successful as it is backwards compatible. Are you thinking about Itanium 64?

SFjulie1 11y ago
No I am thinking of the fact that code gets bigger, since assets get bigger, which results in execution is slower. Actually there is a whole domain of application for which 64bits coding results in slower code. Plus extending memory address space results in slower memory access. L1, L2, L3 caches are hardly accessible from python/ruby/...(ahhh using register is sooo fast). Which in turn results in more watt/instructions. Nowadays, the IT industry might be the leading one in its contribution to fossil energy consumption. Do we need to add coal plants to support the cloud insanity bloating web pages to 16Mb for applications that are hardly more than 8 operation calculators to tell you how "green" you are? I have a degree in ASIC design. Modern x86_64 architecture is insane. It has a lot of hidden complex mechanic built in that are de facto additional CPUs inside the CPU for on the fly optimisations (memory+OOP), "security", buses, plug n'play... And who pays? Actual IT industry is literally taxing the masses for something they neither ask nor need. The IT is locking consumers in arbitrary choices that results in higher costs.

tremon 11y ago

And for those who says memory, I answer that it is easy to make a 32 bit CPU with a 64bit memory adressing. Except when it isn't. How do you propose to calculate 64bit addresses with a 32bit alu?

SFjulie1 11y ago
By propagating the carries in the ALU? (oh! intel announced they are going to ship this feature) By using indirect addressing? (like PAE) Since they are physical boundary to this world and since linear addressing is constricted by speed of light vs the frequency of computers, there is a definite optimum we will not be able to break easily through for the next decades. Every time we extend the memory address space, we add levels of indirections on the Silicium anyway. C0 (the velocity of light in the void) is our first limit. Available resources/power on earth is our second limit. And money available to the consumers is the last one. Do we really have any good reasons to adopt new technologies that do not prove to be more efficient and/or less costly?
- tremon 11y ago
  You are correct, that the hardware can do so without too much overhead. But I was arguing from the software point of view: segmented memory means no simple pointer arithmetic above the 32-bit limit. That means that software managing datasets above 4GB will always need special-casing, or be written with indirect allocation in all cases. I don't see a good reason for mandating that kind of complexity in code. If you have a solution for allowing 64bit linear addressing in code, I'm all for it.