A long chunk of contiguous data will make the best use of the onboard precaching, allowing the disk to reach the reported speeds (e.g. 5500 mb/s reading) and it MAY be a significant improvement for the loading times of large games or large video files. It will shorten the ssd lifespan especially on cheap ones (many will use MLC or TLC to increase the available space at teh cost of longevity), so if you really have this necessity of working on large video files or regularly play huge games with long loading times even on ssd (bad game design) I'd consider buying a high quality lower capacity one for these kind of works. GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++*      Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next

I thought it was going to be graphic cards? M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

That's probably the way to increase battery life... :laugh: :laugh: see 2 messages below M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

It was a silly article, going out of his way to create a bug and then blaming it on the thing he just intentionally broke. But doing things with C++ that rely on platform/compiler specific details is explicitly allowed, and frequently necessary. The C++ specification alone does not make enough guarantees to result in a useful system - intentionally, so that the details can differ.

Kornfeld Eliyahu Peter wrote: VS consuming huge amount of memory isn't new Versus which IDE that uses very little? Kornfeld Eliyahu Peter wrote: I have a solution with around 80 projects in it To me that would be an organization problem. I would break it into different solutions and if that was not possible then it would suggest different sort of problem.

Kent Sharkey wrote: would you do it too? Nope And I would not say Apocalypse... at least not yet. M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

trønderen wrote: it proves that there is a mess that you should clean up! Give someone a foot they take a meter.

Nice! I dunno any of the 20 people using F#, but they must be ecstatic! :)

Not even touching it. I'll wait until .NET 20 is ready - won't be long now. Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.

jschell wrote: obermd wrote:I checked jar files are compiled into machine executables on the first run I don't believe so. Unless Java has changed a lot the last few years, and I am quite sure it hasn't, you are right. But in the beginning, there was Java bytecode, and bytecode was interpreted directly. Just like the Pascal "P4" bytecode, which is said to be an essential inspiration for Java bytecode. I never heard of any compiler for Pascal P-code; it was always interpreted (as far as I know - correct me if I am wrong). Bytecode is just like any other binary instruction set. 'Compiling' Java bytecode for, say, Aarch64 is functionally identical to compiling x86 binary code into Aarch64 binaries, except that x86 is so messy that it is no simple task :-). When Apple Mac switched from PPC to x64, lots of code was compiled from binary PPC to x64. PPC is far tidier than x86, so I guess that job was simpler. A binary instruction set, whether a 'real' one or bytecode for a virtual machine, usually carry a minimum of 'why-information', limited to 'what-information'. If the compiler could know why so-and-so binary code was generated, it would have greater opportunities to generate more optimal code for the target machine. Or rather: It would be a lot easier. If you compare Java binary bytecode with .net IL (Intermediate Language), IL is not suitable for (or intended for) direct interpretation, but it contains a lot more of 'why-information', making it easier to generate optimal target code. .net IL has always been compiled to native code before execution. When compilation of Java bytecode was introduced, the essential reason was to keep up to speed with .net, which claimed the same 'compile once, execute everywhere'. (For all directly compilation from source code to native code, noone expected interpretation of bytecode to be able to complete.) At about the same time, we also got Java compilers generating native code executables, rather than bytecode, to obtain maximum execution speed, but sacrifying the 'compile once, execute everywhere. First of course it would not do that to a jar file. If you refer to the compilation to add to the jar file, you are most certainly correct. The compiler could do like the .net IL compiler: It maintains a persistent cache (in the file system) of compiled assemblies. Before starting compilation of an assembly, the jitter ('Just-In-Time compiler') checks the cache

Fiddle to woodwind translation. That's too much fun.