fishtank wrote:First of all - where is the proof of the performance benefit Reiknir? Turning off Hyper-threading actually makes a difference in performance, recording @ 32 float versus 24 fixed does not - at least in my testing. Simply stating that it makes a difference does not make it so. Also, recording at 32 float requires conversion at the time of recording (converters are fixed point) and we are also writing more data to the drive than fixed point. My system is most stressed when recording at low latencies - there is no evidence that using 32 float files improves this. One could argue that the system is MORE stressed doing the 32 float conversion when recording. The reality is that there is no noticeable difference - just bigger files.
Don´t ask for proof when you are not offering some yourself
I never mentioned float, you did, I specifically mentioned that as far as the bus is concerned it sees no difference between float and integer, it is the bit width that matters to it and that you think that there is more data involved binary transfers of float than integer shows that you do not even understand the basics of computing, a 32bit set of data is 32bits wide regardless of what it represents. File sizes are a different matter altogether.
A bit width is a similar concept to a lane on a motorway, if the road in question has 8 lanes it can handle a maximum of 8 cars in parallel at any given point regardless of how many cars are there in total, how fast they are driving or if they are big or small. The latter three all affect the throughput or efficiency of the motorway, but have no effect on the basic parallel capacity of the road. At any given stage of processing the computer only sees the point rather than the motorway as a whole, so if a bus presented with 4 cars at one specific point it fills it up with 4 imaginary cars and processes the next point, the CPU or northbridge/hub then has to sort out which cars sent to it by the southbridge are imaginary and which are real.
And turning off hyper threading is not a question of performance but rather you disable hyper threading so that the fake core does not interfere with the RT subsystem by assigning timing sensitive data out of order in the processing stream of the real core, if that happens you can get latencies and hiccups because the real core has to react to an out of order event that does not exist on a non-HT processor or one with HT turned off. Although the reasons are different this is a similar end result to the problems people sometime experience with motherboards that have built in graphics cards that share memory with the processor, the processor occasionally hiccups due to timing errors induced by the processor/northbridge having to wait for the graphics/southbridge to complete a memory access on the same clock cycle, these are so small that you do not notice them while browsing the web but a piece of software that relies on RT response like cubase and the audio driver will get "confused" for a millisecond, this is the reason the cubase manual asks you to place a "real" graphics card on such a machine.
All that hyper threading does is rearrange a virtual thread to a real core, can be useful in some cases for a highly threaded application like a multi user database system or a massive Prolog program, poison to RT applications