This MCS variation ("UnfairMCS"), spreads the CAS latency across multiple `node.next`, as opposed to its CLH counterpart which focuses its CAS pressures on a single point of contention on TAIL (in the `AbstractQueuedSynchronizer` case this is needed because each `prev` field needs to be set), fetching a new memory location on failure, helping offset the latency off of main memory, diverging it to all individual trails of `node.next` equally.
You can give the Israeli part any moral excuse for their barbarity in Gaza.
We will just turn on the screen on any live Israeli TV channel and any propagandist excuse you gave here will be deemed completely irrelevant, overriden by the sick society that arrogance and impunity have fostered.
As LL/SC type architectures get more and more widespread, I am wondering all the novel ways in which programmers may discover new "anomalies" with the old memory model rules and constraints.
speculative execution combined with relaxed semantics... and now LL/SC widespread bubbleless cache exclusiveness acquirement?
In all honestly mathematical operations are still better performed by LOCK prefixed architectures since there is no reason to go to the assembler level to re-read the cache... if all you're going to be doing is perform a mathematical operation.
LL/SC is good for displays/publishing operations (losers win all) ... not for graphics or mathematical ops.
I did not understood op's comment but it is not that hard to come up with a link (without it being a stretch) since both have a common (broad and too generalized) goal: profit maximization, which means there must be an intermediate step of instrumental convergence.
There are methods of profit maximization whose abstract functionality is basically the same, the only thing that changes are the parameters.
I sincerely believe administrative sciences tend to not make clear abstractions out of this, since that is... hard...
My question (if I may), When people say the bytecode is "platform independent" I ask, exactly what platform is it being freed from?
The compiler?
The "cloud"?
And this goes back to my lack of understanding of what "publishing" a package means to Oracle and the ecosystem in general.
If I publish something on Maven, my guess is that it is transformed into bytecode directly, so that when I pull my package from a diff device the code can run.
In this case if the entire "internet" collapses then the only way to run my code would be a flashdrive with the .java file run via a compiler... unless there is a machine that has the JVM installed WITHOUT the compiler... THEN the bytecode is useful... Am I correct?
It is independent of the processor architecture, and to a large extent the operating system. (As opposed to an ordinary binary executable, which depends on both.)
The compiler turns Java source into bytecode. The JVM runs the bytecode. The JVM doesn’t need the compiler to run.
What I get from this is that the processor arch. Is dictated by the compiler at compile time, and by writing to bytecode directly we are skipping this.
I thought the proc. arch. was established by the manufacturer and was unavoidably implemented by the jni at runtime... unless there is an interface on top of the jn-interface to deal with the proc. But it seems absurd... why do this at compile time?
The JVM is a native-code application (i.e., running on the processor directly) that executes the bytecode by interpreting it (starts fast, but runs slowly) and/or converting it into native code and running that code on the processor directly (delayed by the conversion step, but then runs fast). The latter step, translating bytecode to native code, is known as the just-in-time (JIT) compiler.
So somewhat confusingly, Java typically involves two compilers: one from source code to bytecode, the other from bytecode to native code. By nature, the first is processor-independent, the second is processor-dependent. The second happens at runtime on the target machine — thus, “write once, run anywhere”.
It compiles code to an "idealized" instruction set. That instruction set is then mapped to a real instruction set by the jvm at runtime, first in some cases through interpretation, but mostly by recompiling it (potentially better and better as more statistics come in) by the jvm.
A big advantage to this approach has (over the instruction set independence), is the JVM knows exactly what the characteristics of the environment are, cache size, memory size, processor extensions, etc, etc, and can decide at runtime how to compile best. This is in contrast to like a C compiler that will give users compile switches to pick a target environment (which is only sometimes correct).
Compiling to a sort of intermediary representation has distinct advantages over either distributing pure source or pure machine code.
Pure source-based interpretation, where you build software to look directly at human-written text and run a program based on those instructions (eg, BAISC, Python, Lua), are inherently slowed by necessitating that the program be, well, parsed and validated on-the-fly. A lot of the processing time is eaten up by virtue of simply understanding each line of textual source code and making decisions about what code to run based on that. However, the advantage is that code written in one of these languages can be dropped onto another machine running an entirely different operating system or processor architecture and run just fine, since it's the language interpreter which is tasked with interpreting the human-readable instructions, therefore only that interpreter needs to be ported across platforms.
Pure compiled code, eg C/C++, Rust, etc have the advantage of being very fast. When your final product is pure machine code, there is no translation necessary. You just feed your instructions straight to the CPU, and the CPU does its job. However, the tradeoff here is that you need to produce many different sets of instructions, one for each operating environment + processor architecture combination you wish to support. Essentially, the tradeoff of compilation versus interpretation is whether you can justify the up-front cost of maintaining platform-dependent builds of your software, or whether you can justify the downstream cost of slower operating performance.
But there is a middle-ground. A sort of combined approach between compilation and interpretation, which gains us some of the advantages of both, but also pulls in some of the drawbacks. In this "hybrid" approach, software is compiled to an intermediate representation, in this case Java bytecode. You can think of this bytecode as machine code for some abstract machine, the "Java Virtual Machine." So the target processor architecture for this compilation step is therefore the JVM, and our final shippable product is that compiled artifact. We then ship our compiled bytecode, and require end users to have a copy of the JVM on their systems to then execute our bytecode. This JVM is an interpreter of Java bytecode; it reads this bytecode, and makes decisions about which pathways in its code to execute for each given JVM instruction. This Java bytecode interpreter is therefore the platform-dependent component that needs to be maintained and ported across to different processor architectures/operating environments, and yes, you need a copy of this to run any compiled Java artifacts. However, being that Java bytecode is a more rigid format, optimized for simplicity and machine-readability rather than human-readability and expressiveness, the interpreter for Java bytecode is much, much simpler to develop and maintain, and the simplicity of each instruction combined with earlier decisions made by the compilation step allow us to apply optimizations to the bytecode while we're interpreting it, much like a real CPU would do. The advantages of this hybrid approach are thus that we maintain platform independence of interpreted code, but at a reduced ongoing cost as our interpreter component is much simpler; additionally, because of the optimizations we can apply both during the initial compilation step and during interpretation time, we are able to gain quite a fair bit of speed back when compared to standard interpretation. The drawbacks to this hybrid approach, however, are that you do need that external interpreter component in order to execute the final product, and that interpreter still needs to be maintained for each platform you want to run your code on; additionally, because we still use a compiler step along the line, there is still an upfront time cost of translating our human-readable code into bytecode.
This hybrid approach is actually used by some compiled languages. LLVM-based compiler tools, for instance, compile source code into an intermediate representation known as "LLVM IR." However, this intermediate code is not shipped to consumers; rather, it's simply used to apply further optimizations to the code now that it's in a simpler format.
So, longwinded explanations aside... yes. You compile Java code to bytecode, and ship that bytecode rather than either your raw source code or your completely compiled code. That bytecode should be runnable on any platform you're able to get it onto, provided you have a functioning JVM built for that target system. Should the "internet collapse," you will need some way to source a Java Runtime Environment in order to run any compiled Java programs you have, and you will need a Java Development Kit in order to compile and run any Java source code.
Thanks for your explanation, as is often the case for me when I encounter this level of insight, I need to take a break, relax... and digest everything said word for word, this involves opening some tabs and a lot of reading, but these answers are always appreciated, thanks.
BTW you made me lol when you followed my ridiculous "internet collapse" scenario.
Actually LLVM IR is shipped to consumers on the Apple ecosystem mainly on watchOS, the difference being that it isn't the same out of the box LLVM IR used by the LLVM project, rather a massaged version that Apple uses as distribution format.
I think it CAN come to an end.
The backbone of crypto and the blockchain is the willingness to maintain it which has a cost.
The reason why this maintenance is cost effective is because the major holders are few and at a < 1/2 of the entire base.
As long as the "right" people are winning, there will be enough justification to keep the ball rolling.
If there will come a day, in which the ammount of holders become so dilluted that there stops being any clear (lets say) influencers at the top, then the "cool boy's club" will be no more.
This is when exchanges will no longer have any skin in the game.
Massive runs and "outages" until a few weird naive dreamers are left at the helm of the sinking ship.
I see people are forgetting the only reason we care about this number is because someone was not confortable with what bots and non bots were saying.
If they are bots or not is just a convenience because of the price.
I dont have the money to care, yet I was well aware about it...
Musk should sample his followers that would drive the price even lower.
I know.
And Ive been waiting ever since Facebooks IPO when are people going to relize the tech for target marketing is more effective than what it seems.
The reason why it seems not as effective (at lower price brakets) is because the entire industry is based on fake numbers.
This fake degree of effectivity allow them to balloon the prices,
1st By alleging that the ad is "as effective as what you are willing to pay"
2nd. Their "massive" userbases.
In reality lower priced ads are not effective precisely because their userbase is not as massive.
as such what should be defined as normal tier is now the highest priced type of advertisement campaign.
The people hardly dig into this as there is no real incentive, billion dollar companies are not being sold all the time.
The % of bots was known to be between 15 and 20 before he made the deal.
If your plan is to buy a soda company to sell soda I would not believe a good strat is to reveal how cheap the product is, in reality, you are basically cornering yourself.
If he manages to buy it,the issue will immediately dissapear.
If he would genuinly made an effort to unmask the industry to help the consumer, I would be behind that.
For everyone saying the visitor pattern requieres switch statements this is false.
The visitor can build its case inside the iterface/implemetation.
If the complexity is being solved by the "housing" class that the visitor will be visiting you are not doing enough.
When I was younger I thought it was a smart move to be deceiptive and fool people above my paygrade to make them feel important and or smart, to allow them their foolishness.
It is bad to do that as you just justify their behaviour, and allow them to keep behaving as such by giving them what they expect and want.
Maybe my attitude could land me some enemies and prevent me opportunities, but I decided not to continue that vicious cycle.
We need to surround ourselves with people we respect and respects us equally, somewhere were feedback is possible.
Not only for the better of our minds but also for the better of the things we produce.
