And I cant believe you've been here almost 2 years, and only felt the need to type 12 posts! Man, join in a bit more will ya? we wanna hear your words of ermmmm, (Let's call it wisdom,) on a more frequent basis

 

With apologies to all the very hip fellows who think that being human requires 64 bit OS, this for Taskforce... I have tried PMing but the cloudflare protection kicks in and thinks I am sending invalid code or something. People who find old tech terrible and disgusting, you needn't read any further. You will be horrified.

Thanks for the info about going beyond 2GB in XP.

Following your suggestion I looked at my boot.ini an found the following line:
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

The difference of course is that /noexecute=optin part before fastdetect. If I add the 3GB and Userva after fastdetect will that noexecute business cause problems?
You suggest a Userva=2560. The Microsoft help page dealing with this topic mentions as much as 2800 or 2900. Is there any reason to prefer 2560? A few more hundred MB would be useful.
I have installed 4GB although TaskManager shows only 3.4 GB physical memory. I recall reading years ago something to the effect that the system reserves the 0.5 GB for itself. Is this true or is there something else going on? Do I have access to the entire memory anyway?
If a modified boot.ini causes troubles, how do I go about re-starting the computer in order to replace it with the backed-up original?

Thanks in advance for your patience. I look forward to your reply.

 

"" OK I am not a newbie when it comes to computer based music production ""

you just proved the exact opposite

 

No apologies necessary, though doing what ~98% of the people are doing

is hardly "hip," it's just normal.

Now, editing ̶C̶o̶n̶f̶i̶g̶.̶s̶y̶s̶ Boot.ini, just to ̶r̶u̶n̶ ̶y̶o̶u̶r̶ ̶c̶o̶m̶p̶u̶t̶e̶r̶ ̶o̶n̶ ̶c̶o̶a̶l̶ use a 32-bit OS?
In this, the year of our Lord 2018?
That's some srs edge

 

Yep it's true.

Even simpler, just add /3GB to the end of the sentence mate, so the sentence reads like:
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect/3GB
Remember to add a restore point to your windows system restore function or make a backup of the c: drive. If for unknown reasons your sys won't boot i can't be responsible, although it's pretty safe to say if your sys works fine, this will be as easy as abc.

 

Simple. With 64bit you're not limited on ram.32bit is limited to 4gb

 

Simple as you didn't bother reading the thread...

 

uhhh look at the best answer. Its exactly what the TS was looking for. You should read.

 

https://msdn.microsoft.com/en-us/library/windows/desktop/aa366796(v=vs.85).aspx

 

A switch that happened OVER 10 years ago.
it means "modern technology"

or in other words


NOT living in the stone age.


imagine someone asking

"what is color televsion?"

l

 

With some due respect, has it not occurred to you that I just might have valid reasons for staying on XP? I even like black and white television.

 

It can also be up to 20% slower if it's an app that uses a lot of pointers (like a compiler), usually not the case with audio though.

This is usually wrong.

There is nothing fast about the "fastcall" Win64 ABI/calling convention, other than just 4 parameters being passed in registers. In fact, it was designed in the Pentium 4 era and works good only on shit processors from that era which had slow instructions like "push". Every new processor (since Sandy Bridge) is faster with push than mov, not to mention trashes the instruction cache far less because push is much smaller in encoding. Thus the Win64 calling convention is a huge detriment to 64-bit bit compared to 32-bit which is, ironically enough, a far better calling convention these days.

The Linux x64 ABI is better though, because it's not so stupidly designed like the Microsoft one. Alas, we're in Windows world, so all 64-bit apps use that extremely inefficient (by today's standards) Win64 calling convention. I guarantee you that all articles you read about the Win64 "MS ABI" being efficient are old or based on rumors/knowledge from Pentium 4 era.

I mean, Win64 is MUCH LESS efficient with memory. It uses far more, both for instruction encodings (just analyze most 64-bit VSTs/apps and see which one is bigger), and for stack space (especially stack space). RAM may be cheap in capacity, but it's not cheap to access compared to L1 cache. The largest bottleneck by far in terms of micro-optimizations like these is access to memory that's outside the L1 cache.

A "register spill" from 32-bit to memory (because it has 8 fewer registers) is only 4 clock cycles of latency because the stack is likely in L1 cache, register operations tend to be 0.5-1 clock cycle. This sounds like a big gain for x64, until you realize 64-bit uses way more than double the amount of stack space, because of the "Win64 ABI/calling convention" which is pure garbage.

First, all parameters are 64-bit, despite most of them being 32-bit integers (int, the most common data type, is still 32-bit in x64, and the "default operand mode" for instructions is also 32-bit in x64, because 64-bit arithmetic default would be a total waste of power). So you lose half the L1 cache for parameters, which is not to say it's much since there's not that many functions, but we are talking about calling conventions right? So we look at calls here.

Then you have a 32-byte home space for every single x64 call (even functions without parameters). In 32 bytes you can fit 8 parameters in 32-bit mode. Very few functions have more than this, so basically x64 wastes more stack space for each function call than some of the largest 32-bit functions, and this is without passing a single parameter in on the stack (which happens when it has more than 4 parameters in x64, since only 4 are passed in registers).

On REAPER pre-release forum you can see 32-bit REAPER is sometimes faster (depending on compiler used) even as the 64-bit version does not use many pointers to trash the cache (but most compilers optimize 32-bit code worse than 64-bit because they're dumb with fewer registers, you only see a handful better).

The reason is because 64-bit is much less efficient with the stack (where parameters are pushed), and since the stack is the hottest path for "level 1 cache", it's like halving your L1 cache, if not more. Most people think it's not a big deal if the program is 30% larger for x64 or it uses 30% more memory "because RAM is cheap", but remember that this means it uses the L1 cache less efficiently. It's not about RAM use, it's about cache use. Code size is very important, because instructions (that get executed) need to also fit in the L1 cache, along with the stack and what else the program uses.

Just to put things in perspective, a L1 cache access is 4 clock cycles, while a main RAM access (we ignore the other caches since it makes things more complicated) is more than 100-120 clock cycles. The faster a CPU is, the larger the difference as well.

Here's an article (which has a few errors, the guy doesn't know that much apparently, but it's "good enough" for non-programmers): https://www.viva64.com/en/b/0069/ His 3rd conclusion is completely bogus since nobody cares about addressing space in x64, but RAM use and cache are a real bottleneck, and those are not "infinite" like the addressing space is.


tl;dr x64 on Windows can very much be slower unless it does intensive calculations on the extra 8 registers (e.g. video encoding tends to be way faster since it doesn't call many functions, nor does it use many data structures with pointers, just raw calculations), because of the Win64 calling convention being designed around "simplicity development" instead of performance, and shit Pentium 4 CPUs, which is dragging it back. (the Linux x64 calling convention is far better)


Lastly I'm talking about 32 bit applications, not OSes. People tend to not make this distinction and automatically think if you have a 64-bit OS you also must run 64-bit apps in benchmarks, which is retarded.

 

Last edited: Mar 15, 2018

Who are you? I don't need to prove my pedigree to you or anyone else! I was most likely selling this gear while you were still in diapers! BUT JUST FOR YOUR INFO- I began selling keyboards and software back in 1996 for a company here in the Midwest.In 2007 we were bought out by Sweetwater where I had the opportunity to join their staff. I turned it down because of my family obligations (wife and three children) plus I had just accepted a position as a manager with Target at the time. I left the music instrument retail scene in 2007. I never bothered to look into the 64 bit question because I never needed too. I did not need to stay current with everything since I had no clients or customers to have answers for. For my personal studio projects, what I had worked well enough and I enjoyed doing it as a semi-hobby. Even though my machine has been 64 bit since 2010 or so the question never was important.I hope this gives you some answers and teaches you not to judge people before you know the full story!

 

Last edited: Mar 16, 2018

Not sure if this was intended for me but I normally just stay in the background and follow along. But if there is a topic that I feel I need to address, I will.

 

@Weasel
Thanks for your input and additional info. I did converse with a bunch of programmers in the past and all agreed that usually the fastcall is faster since it saves 4 memory accesses minimum, and when this is not the case there simply is no increase at speed. That is in both 32 and 64 bit. Referring to Linux, while good to know, doesn't make much of a point since the talk was about Windows versions. You said the Ms implemetation of their x64 Application Binary Interface that uses the fast-call is garbage, and i can accept this as an expert's opinion. Still, you never bothered to explain what IS faster in Win x64 than the fastcall implementation, that is in existing real world applications. You only pointed out that Win32 calling conventions could be considered faster than the fastcall in x64.
If i misunderstood feel free to correct me, no worries :D.
Cheers

 

I did though, that's why I compared it to Linux.

You have to understand that calling conventions (or ABIs) are just that.. conventions. They're not hardwired or part of the CPU itself, it's just a "norm" for functions to use the same one so they know what to expect and don't crash (caller and callee need to agree on the same calling convention, but each function could have its own, as long as both caller and callee agree with it for that particular function).

The "Linux" calling convention is not hardwired into Linux. It's just that Linux world agreed to use it. Microsoft could have done it, but they didn't, because they're Microsoft, always have to be different. It has nothing "Linux specific" in it and in fact you can use it with some compilers (though not Visual Studio) even on Windows (but you have to make sure the caller of the function also uses it when calling the function, so your function can't get called from Visual Studio, therefore nobody does it).

I can't compare Win x64 calling convention with another one useable on Windows because there is no choice with Visual Studio (Microsoft's compiler). Microsoft stubbornly force everyone to use their calling convention, unless you code manually in assembler or hack your own compiler. Sure, you can use a different calling convention (you can even use Linux one on Windows for example), but then it will only work with your code. Libraries compiled with "default options" (which is MS calling convention) will use the MS one, so calling those libraries will force you to use that convention at least for those calls.

In x86 you had some choices, where the 32-bit fastcall passed 2 parameters in registers for example (some compilers like GCC also had a 3-register parameter version). In x64 there is no choice on Windows, if you use Microsoft compilers, which is what almost any dev does (Visual Studio). So while the convention could be changed theoretically, nobody does it, they just go with Microsoft's. So in a practical sense, we're stuck with it, not a theoretical sense.

Microsoft actually added a choice for people programming with vectors, I believe it's called __vectorcall or something, because people whined the x64 one was too inefficient for SIMD (because of its awkward design, every single parameter large than 64-bits, like a SIMD vector, had to be passed by reference, let's just say that's very inefficient). But for normal functions it still sucks.


That said... function calls are rarely the bottleneck in audio. They're the bottleneck in applications that use tons of data structures, function pointers/virtual calls, dynamic dispatching, objects and the like... where such calls are in inner loops. In audio, usually the processing loop has no function calls.


Fun trivia: Because some people think that RAM is "endless" in x64 (they equal RAM with addressing space), here's some food for thought. Even assuming the RAM, itself, as in memory amount, is infinite! (which is obviously not the case)

If you process 4 GB/s of RAM (which is quite high for non-sequential access) it would take you something like 136 years just to go through the entire theoretical addressing space, just once. But we all know data tends to be read/written far more than "just once" in RAM.

Just because the addressing space is so large doesn't mean "memory is cheap". Even if the amount is. The more memory you use, the slower the program is, because accessing it is proportional to its size. (but in fact it's much faster if it's "slim" and fits in the hot cache of the CPU)

 

Last edited: Mar 16, 2018

Try formatting a 3GB HDD in a 32bit environment or getting it to see 64GB of RAM.

In other words - you are not limited to a threshold of 4GB RAM that generally only sees 3GB and a HDD of 2GB.
Plus the 64bit architecture is basically faster with 64bit application versions.
Programmers can get the hardware to number crunch faster as well so a good programmer can make large files load faster.
A perfect example is the latest KONTAKT which loads everything faster in 64bit.

As for 32bit VST's -there are apps on MAC and PC[jbridger(also on MAC)/Arminator] that enable 32bit apps in 64bit environments so musically you lose nothing and only gain.

 

Everything you said is wrong, lol. HDD size has nothing to do with x86/x64, since the filesystem uses 64-bit integers (and yeah, it's shocking, but you can use any size integer with any mode, even 8-bit CPUs can process 64-bit integers, albeit slower, but for an integer for calculating file offsets it's like a couple of nanoseconds, very noticeable indeed). Unless you're using FAT32 but that's limited to 4GB even with x64 so I have no idea what your point is.

Unless you run out of RAM, because the OS then starts to swap pages to disk, then things should not load faster, unless by "loading" you mean "doing calculations". And yeah you can use 64GB of RAM with PAE in a 32-bit OS, but that's just a side note, nobody really uses it for audio.

Obviously you can use 64GB on a 64-bit OS even with 32-bit applications, it's just that not one single app can use more than 3GB. Combined, they can use far more though.

 

32bit does not use all of 64GB of RAM.
You cannot format a 3Terabyte HDD which is what it should have said in 32bit.
So an intelligent person not a nit picker that cannot tell a typo when they come across it which means you are probably under 40, who is trying sweep the floor with his own testosterone would have seen and known that.
So everything you have done is wrong in attitude.

Nobody uses that much RAM in Audio? Lets guess you are one of the millionsof trance MIDI sequencers?
Try mixing an Orchestra or BigBand with only 4GB of RAM. LMFAO - Now who's the moron?
- YOU ARE.

 

Last edited by a moderator: Mar 16, 2018