I'd expect someone with such an extreme opinion to at least try to argue for it.
Floats are generally enough. They require less hardware and the hardware consume less power per operation. Less memory bandwidth and less memory space are needed. IMO most uses of doubles are either to be safe or to try to compensate for lack of analysis of the problem at hand.
But I can be even more extreme than you: only 128 bit fixpoint numbers should be allowed. Of course stored in ones complement.
I don't think you realize what Interpol is. It's mainly a system to enable some level of co-operation of police forces between different countries. Criminals don't care about borders after all...
Interpol doesn't really do anything but pass information.
X86 is CISC. Even if x86 chips were internally RISC with a translation layer they would still be CISC as the ISA is CISC. Implementation doesn't matter.
But x86 chips aren't RISC processors just CISC processors using a simplified internal representation, a representation that is designed to execute effectively and be a good fit to x86 instructions. They are still far more complicated than RISC instructions.
Not really. The Pentium Pro could perhaps be called internally RISC as it executed simple 2 in - 1 out operations (though they were more complicated than normal RISC instructions). This is easiest visible in relatively simple instructions that have more than one input like ADC.
Modern x86 execute complicated operations that are designed for x86 execution efficiency. Simplified compared to the (worst case) x86 instructions? Absolutely - but far from any RISC design.
Less instruction sets makes assemblers and compilers easier to implement
I'll give you assemblers (though assemblers are so trivial that there's little benefit from this), but not compilers. A big motivation for the original RISC revolution was that compilers were only using a tiny fraction of the microcoded instructions added to CISC chips and you could make the hardware a lot faster by throwing away all of the decoder logic required to support them. Compilers can always restrict themselves to a Turing-complete subset of any ISA.
RISC-V is very simple, but that's not always a good thing. For example, most modern architectures have a way of checking the carry flag for integer addition, which is important for things like constant-time crypto (or anything that uses big integer arithmetic) and also for automatic boxing for dynamic languages. RISC-V doesn't, which makes these operations a lot harder to implement. On x86 or ARM, you have direct access to the carry bit as a condition code.
Similarly, RISC-V lacks a conditional move / select instruction. Krste and I have had some very long arguments about this. Two years ago, I had a student add a conditional move to RISC-V and demonstrate that, for an in-order pipeline, you get around a 20% speedup from an area overhead of under 1%. You can get the same speedup by (roughly) quadrupling the amount of branch predictor state. Krste's objection to conditional move comes from the Alpha, where the conditional move was the only instruction requiring three read ports on the register file. On in-order systems, this is very cheap. On superscalar out-of-order implementations, you effectively get it for free from your register rename engine (executing a conditional move is a register rename operation). On in-order superscalar designs without register renaming, it's a bit painful, but that's a weird space (no ARM chips are in this window anymore, for example). Krste's counter argument is that you can do micro-op fusion on the high-end parts to spot the conditional-branch-move sequence, but that complicates decoder logic (ARM avoids micro-op fusion because of the power cost).
Exactly how do you expect conditional moves to be executed at the renaming stage? They are conditional which means either one have to have the condition ready at the rename stage (extremely unlikely) or one have to speculate. To speculate one have to have a predictor, a way to rollback the operation (and dependents) and tracking logic. This isn't free. One would also need to verify the prediction so some kind of operation have to be executed*.
Just using branches instead would at worst add a few cycles of mispredict latency - from the fetch + decode stages. That would also remove the complications given that branches have to be supported anyway.
(* unless one can piggy-back on another operation)
Most of the other instructions in modern ISAs are there for a reason. For example, ARMv7 and ARMv8 have a rich set of bitfield insert and extract instructions. These are rarely used, but they are used in a few critical paths that have a big impact on overall performance. The scaled addressing modes on RISC-V initially look like a good way of saving opcode space, but unfortunately they preclude a common optimisation in dynamic languages, where you use the low bit to differentiate pointers from integers. If you set the low bit in valid pointers, then you can fold the -1 into your conventional loads. For example, if you want to load the field at offset 8 in an object, you do a load with an immediate offset 7. In RISC-V, a 32-bit load must have an immediate that's a multiple of 4, so this is not possible and you end up requiring an extra arithmetic instruction (and, often, an extra register) for each object / method pair.
This is a disadvantage if one expect that all processors are the same and expect the code optimized for one ISA (and likely microarchitecture) should run
To be relevant to this maybe you could compare Musks claims with CNNs news and provide some proof they are less trustworthy in general? I couldn't be bothered but you seem to be very knowledgeable in the area...
IOW someone else choosing to remove the option is better than allow the user to choose?
There are plenty of good headphones that are efficient and can be driven with high quality audio from the power-optimized DACs of smartphones. The DT770 is available in a 32 ohm version with a reasonable 96 db/mW rating which means they can be driven loud enough for most purposes. Even the 80 ohm version should be reasonable without external amplifier. They are also closed which should eliminate most external noise.
This is speculation based on the specs and having used headphones with similar specs, haven't tested the DT770 (don't like closed headphones).
Yes you can bring out new medication if it's proven relatively safe compared to old medication _and_ is proven effective for treating Y. Then the larger trials begin with willing participants getting the medication in exchange for tighter control of their well-being. After X years when it is proven to be more efficient and with less side-effects it may become the medication of choice for treating Y, the side-effects and interactions with other diseases etc. is all better known so that in cases where older (or other new drugs) would be better those can be used instead. Or if it is less effective but e.g. pose a less danger for e.g. people with kidney problems than older medication it may become the choice for that sub-category.
Adverse reactions from members of the trial group means they will switch to other medication instead and the trial will continue with less participants.
What about it? It isn't effective against cancer and is much less effective in improving quality of life for terminal cases compared to known medication.
Eh, no. No chance in hell. The vote wasn't recognized by anyone, there are known suspect activities surrounding the voting and there were no trusted independent observers. A lot of people have said they would have voted if it was a valid vote rather than some PR activity, this including people that want an independent state and those that want to be part of Spain. So the vote is a joke.
But even if the vote would be valid and recognized as such by the world they would not accept shit before Catalonia had broken free and functioning as a state. Well North Korea could perhaps do that in order to show support for those that fight against Spanish oppression or some shit like that, but that's just trolling or delusional ranting.
Hyper-computer: A computer more powerful than that described by Church-Turing. Power here meaning it being capable to solve problems impossible in a normal computer, like that of the halting problem. It doesn't imply being faster or even more efficient just that it can at least in theory solve problems not possible in what is normally referred to as a Turing machine (or equivalent).
You just told us all you aren't a programmer. One of the basic things one learn to do is divide and conquer - decreasing complexity by dividing the problem into several easier ones. If you don't realize that is what one is doing well - you aren't a good programmer, not even a good code-monkey. I doubt you ever worked as a programmer given your record of just not getting anything related to programming.
Several reasons for that: People don't want to learn if it isn't needed. You may like to solve puzzles (as do many others) but not all do, which leads to: If the design is anything like some of the ones I've seen* it really is like solving a puzzle. Given enough time anybody with minimum IQ (+vision +experience in using touch interfaces etc.) can solve it - but why do that when there's alternatives that doesn't require trial in error in a stressed situation with people waiting behind them.
Coders generally make extremely lousy UI designers. I'm a bad UI designer but I at least have the education to see that.
(* how about a scrolling interface with _no_ indication that one could scroll? How about sometimes one had to scroll horizontally, sometimes vertically with no visual indication? How about sometimes wanting a single tap, sometimes a double-tap - of course with no indication of what was needed? How about showing a number pad on the touchscreen however that being just a picture with the pin needed to be entered on a separate hardware keypad not used otherwise?)
LOL! Started writing a real response then saw it was you again. Ever getting tired of being not only wrong but hilariously so?
Really I like low-level optimization but you are just mashing some words together obviously not understanding what they mean. E.g. why would anybody not doing low-level stuff do memory management tasks instead of doing their work? "..., doing good privilege-separation..." is just words. Side channels... Irrelevant IF ONE ISN'T DOING SECURE STUFF!
Even for low level coding or building a framework for higher levels your rant is completely irrelevant. Anybody with any experience would see that. And a programmer can be skilled and productive not having any idea of any of those areas.
Last memory management stuff I did was a version of the realtime TLSF allocator written in x86-64 assembly. You?
Slashdot Mirror
Dementia.
I'd expect someone with such an extreme opinion to at least try to argue for it.
Floats are generally enough. They require less hardware and the hardware consume less power per operation. Less memory bandwidth and less memory space are needed. IMO most uses of doubles are either to be safe or to try to compensate for lack of analysis of the problem at hand.
But I can be even more extreme than you: only 128 bit fixpoint numbers should be allowed. Of course stored in ones complement.
I don't think you realize what Interpol is. It's mainly a system to enable some level of co-operation of police forces between different countries. Criminals don't care about borders after all...
Interpol doesn't really do anything but pass information.
X86 is CISC. Even if x86 chips were internally RISC with a translation layer they would still be CISC as the ISA is CISC. Implementation doesn't matter.
But x86 chips aren't RISC processors just CISC processors using a simplified internal representation, a representation that is designed to execute effectively and be a good fit to x86 instructions. They are still far more complicated than RISC instructions.
Not really. The Pentium Pro could perhaps be called internally RISC as it executed simple 2 in - 1 out operations (though they were more complicated than normal RISC instructions). This is easiest visible in relatively simple instructions that have more than one input like ADC.
Modern x86 execute complicated operations that are designed for x86 execution efficiency. Simplified compared to the (worst case) x86 instructions? Absolutely - but far from any RISC design.
Less instruction sets makes assemblers and compilers easier to implement
I'll give you assemblers (though assemblers are so trivial that there's little benefit from this), but not compilers. A big motivation for the original RISC revolution was that compilers were only using a tiny fraction of the microcoded instructions added to CISC chips and you could make the hardware a lot faster by throwing away all of the decoder logic required to support them. Compilers can always restrict themselves to a Turing-complete subset of any ISA.
RISC-V is very simple, but that's not always a good thing. For example, most modern architectures have a way of checking the carry flag for integer addition, which is important for things like constant-time crypto (or anything that uses big integer arithmetic) and also for automatic boxing for dynamic languages. RISC-V doesn't, which makes these operations a lot harder to implement. On x86 or ARM, you have direct access to the carry bit as a condition code.
Similarly, RISC-V lacks a conditional move / select instruction. Krste and I have had some very long arguments about this. Two years ago, I had a student add a conditional move to RISC-V and demonstrate that, for an in-order pipeline, you get around a 20% speedup from an area overhead of under 1%. You can get the same speedup by (roughly) quadrupling the amount of branch predictor state. Krste's objection to conditional move comes from the Alpha, where the conditional move was the only instruction requiring three read ports on the register file. On in-order systems, this is very cheap. On superscalar out-of-order implementations, you effectively get it for free from your register rename engine (executing a conditional move is a register rename operation). On in-order superscalar designs without register renaming, it's a bit painful, but that's a weird space (no ARM chips are in this window anymore, for example). Krste's counter argument is that you can do micro-op fusion on the high-end parts to spot the conditional-branch-move sequence, but that complicates decoder logic (ARM avoids micro-op fusion because of the power cost).
Exactly how do you expect conditional moves to be executed at the renaming stage? They are conditional which means either one have to have the condition ready at the rename stage (extremely unlikely) or one have to speculate. To speculate one have to have a predictor, a way to rollback the operation (and dependents) and tracking logic. This isn't free. One would also need to verify the prediction so some kind of operation have to be executed*.
Just using branches instead would at worst add a few cycles of mispredict latency - from the fetch + decode stages. That would also remove the complications given that branches have to be supported anyway.
(* unless one can piggy-back on another operation)
Most of the other instructions in modern ISAs are there for a reason. For example, ARMv7 and ARMv8 have a rich set of bitfield insert and extract instructions. These are rarely used, but they are used in a few critical paths that have a big impact on overall performance. The scaled addressing modes on RISC-V initially look like a good way of saving opcode space, but unfortunately they preclude a common optimisation in dynamic languages, where you use the low bit to differentiate pointers from integers. If you set the low bit in valid pointers, then you can fold the -1 into your conventional loads. For example, if you want to load the field at offset 8 in an object, you do a load with an immediate offset 7. In RISC-V, a 32-bit load must have an immediate that's a multiple of 4, so this is not possible and you end up requiring an extra arithmetic instruction (and, often, an extra register) for each object / method pair.
This is a disadvantage if one expect that all processors are the same and expect the code optimized for one ISA (and likely microarchitecture) should run
Spread fuck news you know?
To be relevant to this maybe you could compare Musks claims with CNNs news and provide some proof they are less trustworthy in general? I couldn't be bothered but you seem to be very knowledgeable in the area...
Please don't post your sexual fantasies. There are forums where that may be appropriate but this isn't one.
How about taking his computer with him? That's pretty damn stupid.
"faggy"? As pertaining to fags a.k.a cigarettes?
There are plenty of contests like that in Europe and nobody thinks they are related to cigarette use.
If each self-driving car have a dedicated road there's no need for advanced AI or sensors.
That's why he started the Boring Company!
IOW someone else choosing to remove the option is better than allow the user to choose?
There are plenty of good headphones that are efficient and can be driven with high quality audio from the power-optimized DACs of smartphones. The DT770 is available in a 32 ohm version with a reasonable 96 db/mW rating which means they can be driven loud enough for most purposes. Even the 80 ohm version should be reasonable without external amplifier. They are also closed which should eliminate most external noise.
This is speculation based on the specs and having used headphones with similar specs, haven't tested the DT770 (don't like closed headphones).
I also have not had terminal cancer (not even once actually). Relevance?
Yes you can bring out new medication if it's proven relatively safe compared to old medication _and_ is proven effective for treating Y. Then the larger trials begin with willing participants getting the medication in exchange for tighter control of their well-being. After X years when it is proven to be more efficient and with less side-effects it may become the medication of choice for treating Y, the side-effects and interactions with other diseases etc. is all better known so that in cases where older (or other new drugs) would be better those can be used instead. Or if it is less effective but e.g. pose a less danger for e.g. people with kidney problems than older medication it may become the choice for that sub-category.
Adverse reactions from members of the trial group means they will switch to other medication instead and the trial will continue with less participants.
Progress.
And no - it isn't due to "big pharma".
What about it? It isn't effective against cancer and is much less effective in improving quality of life for terminal cases compared to known medication.
Eh, no. No chance in hell. The vote wasn't recognized by anyone, there are known suspect activities surrounding the voting and there were no trusted independent observers. A lot of people have said they would have voted if it was a valid vote rather than some PR activity, this including people that want an independent state and those that want to be part of Spain. So the vote is a joke.
But even if the vote would be valid and recognized as such by the world they would not accept shit before Catalonia had broken free and functioning as a state. Well North Korea could perhaps do that in order to show support for those that fight against Spanish oppression or some shit like that, but that's just trolling or delusional ranting.
Hyper-computer: A computer more powerful than that described by Church-Turing. Power here meaning it being capable to solve problems impossible in a normal computer, like that of the halting problem. It doesn't imply being faster or even more efficient just that it can at least in theory solve problems not possible in what is normally referred to as a Turing machine (or equivalent).
That is a pretty precise definition IMO.
You just told us all you aren't a programmer. One of the basic things one learn to do is divide and conquer - decreasing complexity by dividing the problem into several easier ones. If you don't realize that is what one is doing well - you aren't a good programmer, not even a good code-monkey. I doubt you ever worked as a programmer given your record of just not getting anything related to programming.
Really, this is ridiculous!
Several reasons for that:
People don't want to learn if it isn't needed. You may like to solve puzzles (as do many others) but not all do, which leads to:
If the design is anything like some of the ones I've seen* it really is like solving a puzzle. Given enough time anybody with minimum IQ (+vision +experience in using touch interfaces etc.) can solve it - but why do that when there's alternatives that doesn't require trial in error in a stressed situation with people waiting behind them.
Coders generally make extremely lousy UI designers. I'm a bad UI designer but I at least have the education to see that.
(* how about a scrolling interface with _no_ indication that one could scroll? How about sometimes one had to scroll horizontally, sometimes vertically with no visual indication? How about sometimes wanting a single tap, sometimes a double-tap - of course with no indication of what was needed? How about showing a number pad on the touchscreen however that being just a picture with the pin needed to be entered on a separate hardware keypad not used otherwise?)
I think your problem may be a dysfunctional family rather than the shoes... Never seen nor heard of anything like that.
LOL! Started writing a real response then saw it was you again. Ever getting tired of being not only wrong but hilariously so?
Really I like low-level optimization but you are just mashing some words together obviously not understanding what they mean. E.g. why would anybody not doing low-level stuff do memory management tasks instead of doing their work? "..., doing good privilege-separation ..." is just words. Side channels... Irrelevant IF ONE ISN'T DOING SECURE STUFF!
Even for low level coding or building a framework for higher levels your rant is completely irrelevant. Anybody with any experience would see that. And a programmer can be skilled and productive not having any idea of any of those areas.
Last memory management stuff I did was a version of the realtime TLSF allocator written in x86-64 assembly. You?
Unless they were really hardcore. Never reached that level myself :/ C64 coders probably have every instruction memorized however.
Thank you. That's a pet peeve of mine.
You were just a replacement of a ROM and not a programmer as such. Thank $DEITY for cheap ROM, just imagine toggling in a modern UEFI firmware...
Octal. Even some 8-bit machines used octal input/display as that was what people expected. Hexadecimals? Postmodern crap!