 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My PC has a quad-core CPU with hyperthreading. Which means that Windows
claims it has 8 cores, and when I run POV-Ray, it claims to be using
12.5% CPU.
Right now, I have 4 copies of POV-Ray running, each working on a
different task. Each copy is using 12.5% CPU, and Windows reports a
total of 50% CPU usage. (In spite of the fact that I'm actually using
ALL the cores available.)
I wanted to get a quick preview of the animation being built, so I fired
up Virtual Dub. Imagine my surprise when I actually got 62.5% CPU! o_O
Somehow, each core is running a compute-bound task, and yet still had
enough spare cycles to run a /second/ compute-bound task in the
background as well!
(Also slightly unusual is seeing Virtual Dub actually compute-bound.
Usually it's I/O-bound. But in this case - decoding PNG and encoding
H.264 at 1280x720 - it seems to have become compute-bound.)
The only explanation I can come up with is that POV-Ray is using almost
exclusively floating-point arithmetic, while Virtual Dub is using almost
exclusively integer arithmetic. (Can you *do* a discrete cosine
transform in integer arithmetic alone? I didn't though you could...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] dev null> wrote:
> I wanted to get a quick preview of the animation being built, so I fired
> up Virtual Dub. Imagine my surprise when I actually got 62.5% CPU! o_O
> Somehow, each core is running a compute-bound task, and yet still had
> enough spare cycles to run a /second/ compute-bound task in the
> background as well!
I don't understand what's so strange about that. The OS is sharing CPU time
among the processes. That's completely normal. In fact, it would be quite
abnormal if it *didn't* do that.
If you have, let's say for example, a 1-megabit internet connection and
start a big download, you may get (in an optimal situation) a download
speed of about 100 kilobytes/s.
If you now start another big download, you'll notice how the first one drops
to about 50 kilobytes/s and the second one gets a similar speed.
That's not strange, and shouldn't be. Why is sharing CPU time any stranger?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/07/2012 07:38 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull> wrote:
>> I wanted to get a quick preview of the animation being built, so I fired
>> up Virtual Dub. Imagine my surprise when I actually got 62.5% CPU! o_O
>> Somehow, each core is running a compute-bound task, and yet still had
>> enough spare cycles to run a /second/ compute-bound task in the
>> background as well!
>
> I don't understand what's so strange about that. The OS is sharing CPU time
> among the processes. That's completely normal. In fact, it would be quite
> abnormal if it *didn't* do that.
>
> If you have, let's say for example, a 1-megabit internet connection and
> start a big download, you may get (in an optimal situation) a download
> speed of about 100 kilobytes/s.
>
> If you now start another big download, you'll notice how the first one drops
> to about 50 kilobytes/s and the second one gets a similar speed.
>
> That's not strange, and shouldn't be. Why is sharing CPU time any stranger?
If you can get 100 kb/s, and you start a second download, the second
download goes at 50 kb/s, and the first one also slows down to 50 kb/s.
This is not strange.
Now imagine you get 100 kb/s, and you start a second download, and this
/also/ gets 100 kb/s, so your total download rate is now 200 kb/s. THAT
is strange.
This is what I saw happen. 4 tasks, each using 12.5% CPU. I added a 5th
task, and the existing 4 tasks stayed at 12.5%, and the 5th task also
got 12.5%. Even though that's 5 tasks on only 4 cores. Amazing!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] devnull> wrote:
> If you can get 100 kb/s, and you start a second download, the second
> download goes at 50 kb/s, and the first one also slows down to 50 kb/s.
> This is not strange.
> Now imagine you get 100 kb/s, and you start a second download, and this
> /also/ gets 100 kb/s, so your total download rate is now 200 kb/s. THAT
> is strange.
You are confusing usage percentage with speed. Windows doesn't tell you how
fast the processes are running (compared to maximum theoretical speed), only
how many (virtual) cores are currently being used (and at which ratio, if
not fully utilized.)
When Windows tells you that 50% of CPU time is in use, that doesn't mean
that the process is running at 50% of the maximum possible speed. In the
case of hyperthreading that's probably closer to 90% or something.
What the number is telling is how many virtual cores are being used at
the moment by that process (assuming that it's using all of the virtual
cores fully).
50% means that it's using half of all the virtual cores. 100% would mean
that it's using all of them. However, the latter doesn't necessarily mean
that the process is now running twice as fast. (With multithreading it
probably means a 10-30% speed increase, depending a lot on the type of
application.)
(Of course this with the caveat that, as said, the process is using the
core fully. If it's using it only partially, then then the system will
calculate how many %'s of the total available time on that virtual core
is being used by the process, and summing up the values from different
cores where the process is running.
Thus if you have for example 4 virtual cores and the process is using 50%
of two of them, then the total CPU time usage will be 25%, ie. the same as
if only one virtual core were fully utilized.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/07/2012 08:25 PM, Warp wrote:
> What the number is telling is how many virtual cores are being used at
> the moment by that process (assuming that it's using all of the virtual
> cores fully).
Ah, I see. The number measures the amount of processor time /allocated/
by the OS, not the amount of actual computation process made. Got it.
So if a task spends most of its time idle due to cache misses or sharing
executing units with a second hyperthreaded task, or whatever, the OS
can't easily measure that.
I guess the thing to do then is to look at the actual throughput
achieved by all the tasks. Both POV-Ray and Virtual Dub report this
information. (POV-Ray reports pixels/second, Virtual Dub reports
frames/second transcoded.)
Incidentally, does anybody /else/ find POV-Ray's PPS display annoying?
It seems to display the arithmetic mean over the entire image, which is
just /wrong/.
1. It means that if the speed increases or decreases for any reason, the
display takes a /long/ time to respond. I'd prefer to see an
instantaneous speed readout.
2. It includes any mosaic preview or radiosity pretrace rendering, which
has completely different speed characteristics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.07.2012 09:59, schrieb Invisible:
> Incidentally, does anybody /else/ find POV-Ray's PPS display annoying?
> It seems to display the arithmetic mean over the entire image, which is
> just /wrong/.
No, it isn't.
The figure is the ratio between the count of some discrete events and
the time interval over which they are counted, specified in a fixed unit
of pixels per second (or, for lower values, pixels per minute).
Obviously, as we're talking about discrete events, you can't measure
this ratio for a particular /moment/, so you need to measure it over
/some/ timespan. It is up to the experimenter to choose one, and "the
duration of the whole experiment" is a perfectly valid one,
scientifically speaking.
You might consider the information /useless/, but that's something
totally different than being /wrong/.
> 1. It means that if the speed increases or decreases for any reason, the
> display takes a /long/ time to respond. I'd prefer to see an
> instantaneous speed readout.
OTOH it probably gives you a better overview of the render performance
for the scene as a whole.
> 2. It includes any mosaic preview or radiosity pretrace rendering, which
> has completely different speed characteristics.
Yes, but they're part of the effective rendering time.
Bottom line: You do have some point, but it's not nearly as strong as
you claim it to be.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 05.07.2012 20:22, schrieb Orchid Win7 v1:
> My PC has a quad-core CPU with hyperthreading. Which means that Windows
> claims it has 8 cores, and when I run POV-Ray, it claims to be using
> 12.5% CPU.
>
> Right now, I have 4 copies of POV-Ray running, each working on a
> different task. Each copy is using 12.5% CPU, and Windows reports a
> total of 50% CPU usage. (In spite of the fact that I'm actually using
> ALL the cores available.)
You're doing something fundamentally wrong here: You should have a
single instance of POV-Ray running, with 100% CPU utilization :-P
(Hint: Get POV-Ray 3.7!)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/07/2012 11:17 AM, clipka wrote:
> You're doing something fundamentally wrong here: You should have a
> single instance of POV-Ray running, with 100% CPU utilization :-P
>
> (Hint: Get POV-Ray 3.7!)
Maybe when the beta finishes, eh?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/07/2012 11:05 AM, clipka wrote:
> Obviously, as we're talking about discrete events, you can't measure
> this ratio for a particular /moment/, so you need to measure it over
> /some/ timespan.
Sure. But a shorter timespan would be much more useful.
>> 1. It means that if the speed increases or decreases for any reason, the
>> display takes a /long/ time to respond. I'd prefer to see an
>> instantaneous speed readout.
>
> OTOH it probably gives you a better overview of the render performance
> for the scene as a whole.
It might be useful if POV-Ray could actually try to estimate the time
remaining. It's not especially useful looking at the average PPS for the
entire scene.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> > 1. It means that if the speed increases or decreases for any reason, the
> > display takes a /long/ time to respond. I'd prefer to see an
> > instantaneous speed readout.
> OTOH it probably gives you a better overview of the render performance
> for the scene as a whole.
Maybe it should display two numbers: "Overall PPS" and "Current PPS".
The latter one would be the average of the last n pixels (where n would
be something small, such as 10).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> On 06/07/2012 11:17 AM, clipka wrote:
> > You're doing something fundamentally wrong here: You should have a
> > single instance of POV-Ray running, with 100% CPU utilization :-P
> >
> > (Hint: Get POV-Ray 3.7!)
> Maybe when the beta finishes, eh?
It is finished. It's a release candidate.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.07.2012 12:22, schrieb Invisible:
> It might be useful if POV-Ray could actually try to estimate the time
> remaining. It's not especially useful looking at the average PPS for the
> entire scene.
Estimating the time remaining is pretty difficult, as you'll often have
very inhomogenous complexity across the entire image. The sky, for
instance, is usually comparatively simple; the main motif - typically in
the center of the image - is usually quite complex; and the ground may
(or may not) be quite easy again. So any naive prediction is doomed to
be wrong, and may be off by orders of magnitude.
One attempt that might make sense would be to use a more-or-less random
ordering of SMP render tiles, and estimate the remaining time as (blocks
remaining)*(total time spent for the actual render)/(blocks rendered).
That still doesn't help with render time estimation during photon
gathering, radiosity pretrace, or even mosaic preview (anti-aliasing
requirements may be inhomohenous across the image without any necessary
corellation with per-ray render time).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.07.2012 12:20, schrieb Invisible:
> On 06/07/2012 11:17 AM, clipka wrote:
>
>> You're doing something fundamentally wrong here: You should have a
>> single instance of POV-Ray running, with 100% CPU utilization :-P
>>
>> (Hint: Get POV-Ray 3.7!)
>
> Maybe when the beta finishes, eh?
Hint: Beta phase has officially finished quite a while ago, we're in
release candidate phase by now ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/07/2012 11:48 AM, Warp wrote:
> Maybe it should display two numbers: "Overall PPS" and "Current PPS".
> The latter one would be the average of the last n pixels (where n would
> be something small, such as 10).
Well, I'd like that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.07.2012 12:48, schrieb Warp:
> Maybe it should display two numbers: "Overall PPS" and "Current PPS".
> The latter one would be the average of the last n pixels (where n would
> be something small, such as 10).
As of 3.7 that would perfectly useless, as render results (and thus
progress) are reported to the frontend in blocks of (IIRC) typically
32x32 = 1024 pixels. Even the time between incoming render blocks would
be a bad basis, as they may come in a pretty irregular pattern depending
on how well the threads remain in sync. I think the average over the
last N render blocks, where N is the number of render threads, would be
the minimum reasonable value.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-07-06 03:59, Invisible a écrit :
> On 05/07/2012 08:25 PM, Warp wrote:
>
>> What the number is telling is how many virtual cores are being used at
>> the moment by that process (assuming that it's using all of the virtual
>> cores fully).
>
> Ah, I see. The number measures the amount of processor time /allocated/
> by the OS, not the amount of actual computation process made. Got it.
>
> So if a task spends most of its time idle due to cache misses or sharing
> executing units with a second hyperthreaded task, or whatever, the OS
> can't easily measure that.
>
Exactly. On my underpowered Stinkpad, TaskMangler will routinely report
that the 2 cores are about 12-15% each, but the whole PC has become
almost unresponsive since it's swapping and the swapfile sits on a
software encrypted disk*, so the PGP task needs to be swapped in to
encrypt/decrypt every swap file activity.
*Don't ask. Company policy.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Ah, I see. The number measures the amount of processor time /allocated/
>> by the OS, not the amount of actual computation process made. Got it.
>
> Exactly. On my underpowered Stinkpad, TaskMangler will routinely report
> that the 2 cores are about 12-15% each, but the whole PC has become
> almost unresponsive since it's swapping and the swapfile sits on a
> software encrypted disk*, so the PGP task needs to be swapped in to
> encrypt/decrypt every swap file activity.
>
> *Don't ask. Company policy.
Now if a task isn't running because of swapping, /that/ should be quite
easy for the OS to determine. (The OS deschedules it until the disk I/O
request completes, after all...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.07.2012 16:08, schrieb Francois Labreque:
> Exactly. On my underpowered Stinkpad, TaskMangler will routinely report
> that the 2 cores are about 12-15% each, but the whole PC has become
> almost unresponsive since it's swapping and the swapfile sits on a
> software encrypted disk*, so the PGP task needs to be swapped in to
> encrypt/decrypt every swap file activity.
Oh holy hens & scrambled eggs!
How can the PGP task even be swapped in if it's swapped out and needs to
be swapped back in in order to decrypt itself from the swap file? >_<
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/07/2012 03:48 PM, clipka wrote:
> How can the PGP task even be swapped in if it's swapped out and needs to
> be swapped back in in order to decrypt itself from the swap file? >_<
Either the swap file is unencrypted, or PGP is marked non-swappable.
(Yes, you can do that.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.07.2012 17:00, schrieb Invisible:
> On 06/07/2012 03:48 PM, clipka wrote:
>
>> How can the PGP task even be swapped in if it's swapped out and needs to
>> be swapped back in in order to decrypt itself from the swap file? >_<
>
> Either the swap file is unencrypted, or PGP is marked non-swappable.
> (Yes, you can do that.)
I'm reminded of a school colleague of mine, proud owner of a tape
streamer back in good old QIC-80 times, who had the smart idea to back
up the installation media of all his software on tape so that he could
get rid of that huge pile of diskettes collecting dust on his bookshelves.
That's /all/ his software, yes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-07-06 11:00, Invisible a écrit :
> On 06/07/2012 03:48 PM, clipka wrote:
>
>> How can the PGP task even be swapped in if it's swapped out and needs to
>> be swapped back in in order to decrypt itself from the swap file? >_<
>
> Either the swap file is unencrypted, or PGP is marked non-swappable.
> (Yes, you can do that.)
Not encrypting the swap file could lead to very interesting data
leakage, so I'm going to go with (B) the PGP process is not swappable.
I'm sure that most disk encryption companies have figured this one
out... probably after an "oops!" in beta testing.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> How can the PGP task even be swapped in if it's swapped out and needs to
>>> be swapped back in in order to decrypt itself from the swap file? >_<
>>
>> Either the swap file is unencrypted, or PGP is marked non-swappable.
>> (Yes, you can do that.)
>
> Not encrypting the swap file could lead to very interesting data
> leakage,
Yeah. But it's possible to have the OS zero the page file at shutdown.
(This doesn't save you in case of a power failure, mind you.)
Also, when I last read the PGP manual, it claims to demand that the OS
not swap out any security data that PGP itself is managing, e.g.
encryption keys. (It also makes the keys around to different physical
memory pages, and overwrites the old place with random data, to prevent
somebody yanking the RAM chips out and deep-freezing them to try to
recover the data once the power is gone. Really paranoid stuff like that...)
> so I'm going to go with (B) the PGP process is not swappable.
Yeah, I would imagine that's the case.
> I'm sure that most disk encryption companies have figured this one
> out... probably after an "oops!" in beta testing.
More like alpha testing, I should think. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.07.2012 19:27, schrieb Orchid Win7 v1:
>>>> How can the PGP task even be swapped in if it's swapped out and
>>>> needs to
>>>> be swapped back in in order to decrypt itself from the swap file? >_<
>>>
>>> Either the swap file is unencrypted, or PGP is marked non-swappable.
>>> (Yes, you can do that.)
>>
>> Not encrypting the swap file could lead to very interesting data
>> leakage,
>
> Yeah. But it's possible to have the OS zero the page file at shutdown.
Better yet, overwrite it with pseudorandom nonsense.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Not encrypting the swap file could lead to very interesting data
>>> leakage,
>>
>> Yeah. But it's possible to have the OS zero the page file at shutdown.
>
> Better yet, overwrite it with pseudorandom nonsense.
Yeah, that _would_ be better. But there isn't a registry key for that. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Em 06/07/2012 07:20, Invisible escreveu:
> On 06/07/2012 11:17 AM, clipka wrote:
>
>> You're doing something fundamentally wrong here: You should have a
>> single instance of POV-Ray running, with 100% CPU utilization :-P
>>
>> (Hint: Get POV-Ray 3.7!)
>
> Maybe when the beta finishes, eh?
now I understand why you were complaining about really slow rendering of
cornell box... :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> You're doing something fundamentally wrong here: You should have a
>>> single instance of POV-Ray running, with 100% CPU utilization :-P
>>>
>>> (Hint: Get POV-Ray 3.7!)
>>
>> Maybe when the beta finishes, eh?
>
> now I understand why you were complaining about really slow rendering of
> cornell box... :)
Well, that would only make it 4x faster, wouldn't it? It's still not
going to turn a 40-minute render into a 15-second render like you
claimed. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 08.07.2012 15:01, schrieb Orchid Win7 v1:
>>>> You're doing something fundamentally wrong here: You should have a
>>>> single instance of POV-Ray running, with 100% CPU utilization :-P
>>>>
>>>> (Hint: Get POV-Ray 3.7!)
>>>
>>> Maybe when the beta finishes, eh?
>>
>> now I understand why you were complaining about really slow rendering of
>> cornell box... :)
>
> Well, that would only make it 4x faster, wouldn't it? It's still not
> going to turn a 40-minute render into a 15-second render like you
> claimed. :-P
Not exactly, but do expect more than 4x speedup. You may probably also
get away with lower radiosity quality settings.
Are you at least using the 64-bit version of 3.6.2?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Well, that would only make it 4x faster, wouldn't it? It's still not
>> going to turn a 40-minute render into a 15-second render like you
>> claimed. :-P
>
> Not exactly, but do expect more than 4x speedup.
Um, why?
> You may probably also
> get away with lower radiosity quality settings.
How do you work that one out? Running it in parallel doesn't change the
math, it just makes it faster.
> Are you at least using the 64-bit version of 3.6.2?
Yes.
Since I now actually have a 64-bit OS...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 08.07.2012 18:15, schrieb Orchid Win7 v1:
>>> Well, that would only make it 4x faster, wouldn't it? It's still not
>>> going to turn a 40-minute render into a 15-second render like you
>>> claimed. :-P
>>
>> Not exactly, but do expect more than 4x speedup.
>
> Um, why?
Because it has been optimized here and there? (And because you have
hyperthreading besides?)
>> You may probably also
>> get away with lower radiosity quality settings.
>
> How do you work that one out? Running it in parallel doesn't change the
> math, it just makes it faster.
I happen to know that /someone/ (*cough*) had discovered & fixed various
flaws in the radiosity algorithms & math when he made the feature
multithreading-ready.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/6/2012 10:36, clipka wrote:
> Better yet, overwrite it with pseudorandom nonsense.
On modern hard disks, this is useless. And by "modern" I mean pretty much
anything that passed the 1GB boundary.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/5/2012 11:22, Orchid Win7 v1 wrote:
> (In spite of the fact that I'm actually using ALL the cores available.)
You're not, tho. Hyperthreading means you have like 1.5 cores for every
"core". I assume you know what hyperthreading does. You could probably see a
speed-up by running 5 copies of pov-ray instead of 4.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20/07/2012 12:45 AM, Darren New wrote:
> On 7/5/2012 11:22, Orchid Win7 v1 wrote:
>> (In spite of the fact that I'm actually using ALL the cores available.)
>
> You're not, tho. Hyperthreading means you have like 1.5 cores for every
> "core". I assume you know what hyperthreading does. You could probably
> see a speed-up by running 5 copies of pov-ray instead of 4.
As I understand it, hyperthreading allows you to schedule 2 threads on
each core. The first thread gets all available resources. If any are
unused, they are assigned to the second thread.
This means that if, say, one thread is using floating-point arithmetic
and the other is using integer arithmetic, both threads run at nearly
full speed. On the other hand, if both threads are using integer
arithmetic, only one thread runs, and the other makes no progress. (At
least, until the OS reschedules.)
Thus, I can believe that running two different applications might see a
benefit. If they're performing different tasks, they probably use
different execution unit types. But running two copies of the same
application is highly unlikely to see any benefit - unless the
application uses a really variable mix of instruction types...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 20/07/2012 10:03, Invisible a écrit :
> On 20/07/2012 12:45 AM, Darren New wrote:
>> On 7/5/2012 11:22, Orchid Win7 v1 wrote:
>>> (In spite of the fact that I'm actually using ALL the cores available.)
>>
>> You're not, tho. Hyperthreading means you have like 1.5 cores for every
>> "core". I assume you know what hyperthreading does. You could probably
>> see a speed-up by running 5 copies of pov-ray instead of 4.
Well, personal measures about hyperthreading and povray 3.7 seems to
indicate that a HT core is rather between 1.2 and 1.25 core for povray
(see details and graph in povray.benchmarking). at least for the
benchmark scene.
>
> As I understand it, hyperthreading allows you to schedule 2 threads on
> each core. The first thread gets all available resources. If any are
> unused, they are assigned to the second thread.
HT is: a second set of registers. Nothing more. No additional FPU or
fancy integer units.
>
> This means that if, say, one thread is using floating-point arithmetic
> and the other is using integer arithmetic, both threads run at nearly
> full speed. On the other hand, if both threads are using integer
> arithmetic, only one thread runs, and the other makes no progress. (At
> least, until the OS reschedules.)
Well, it's more subtle, due to the Intel pipeline, but globally correct:
if they want the same resources at the same time, there is a contention
and the pipeline will rearrange them. The OS is usually unaware of such
issue: the granularity of the OS is far bigger than the small cycle in
the pipeline.
At best, operation of time 1 + another of time 1 could be done in 1 if
they do not use the same units at the same time... At worst it could be
2. Due to the pipeline splitting an instruction in multiple steps, it's
possible to interleave some steps in the empty slots of the first
thread-core.
>
> Thus, I can believe that running two different applications might see a
> benefit. If they're performing different tasks, they probably use
> different execution unit types. But running two copies of the same
> application is highly unlikely to see any benefit - unless the
> application uses a really variable mix of instruction types...
Guess what, povray is not a single instruction!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20/07/2012 12:20 AM, Darren New wrote:
> On 7/6/2012 10:36, clipka wrote:
>> Better yet, overwrite it with pseudorandom nonsense.
>
> On modern hard disks, this is useless. And by "modern" I mean pretty
> much anything that passed the 1GB boundary.
Care to elaborate on that?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 20/07/2012 18:15, Orchid Win7 v1 nous fit lire :
> On 20/07/2012 12:20 AM, Darren New wrote:
>> On 7/6/2012 10:36, clipka wrote:
>>> Better yet, overwrite it with pseudorandom nonsense.
>>
>> On modern hard disks, this is useless. And by "modern" I mean pretty
>> much anything that passed the 1GB boundary.
>
> Care to elaborate on that?
>
Old fact: reading a hard disk by direct access to the disk, with some
electronic beam device... fine until the density and encoding on the
disk went into modern era.
Nowadays (and since most 1GB hard drive... quite old), its not possible
anymore. Writing 0 or random number is the same: the old data is not
recoverable.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.07.2012 19:31, schrieb Le_Forgeron:
> Le 20/07/2012 18:15, Orchid Win7 v1 nous fit lire :
>> On 20/07/2012 12:20 AM, Darren New wrote:
>>> On 7/6/2012 10:36, clipka wrote:
>>>> Better yet, overwrite it with pseudorandom nonsense.
>>>
>>> On modern hard disks, this is useless. And by "modern" I mean pretty
>>> much anything that passed the 1GB boundary.
>>
>> Care to elaborate on that?
>>
>
> Old fact: reading a hard disk by direct access to the disk, with some
> electronic beam device... fine until the density and encoding on the
> disk went into modern era.
>
> Nowadays (and since most 1GB hard drive... quite old), its not possible
> anymore. Writing 0 or random number is the same: the old data is not
> recoverable.
Quiz: If you had highly sensitive data on your hard drive, and needed to
erase it for sure - would you rather trust this alleged fact, or have
the erasing software write random numbers just in case?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 20/07/2012 19:46, clipka nous fit lire :
>
> Quiz: If you had highly sensitive data on your hard drive, and needed to
> erase it for sure - would you rather trust this alleged fact, or have
> the erasing software write random numbers just in case?
If the data on drive was so sensitive, I would use chemistry first. Then
a bit of heavy hammer physic, and finally a good heat with partial
ionisation, at temperature far above the curie point.
Boiling HCl is probably enough, as a starter. (get ride of most iron &
steel). Wear a protective mask and operate under well vented condition.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.07.2012 20:54, schrieb Le_Forgeron:
> Le 20/07/2012 19:46, clipka nous fit lire :
>>
>> Quiz: If you had highly sensitive data on your hard drive, and needed to
>> erase it for sure - would you rather trust this alleged fact, or have
>> the erasing software write random numbers just in case?
>
> If the data on drive was so sensitive, I would use chemistry first. Then
> a bit of heavy hammer physic, and finally a good heat with partial
> ionisation, at temperature far above the curie point.
>
> Boiling HCl is probably enough, as a starter. (get ride of most iron &
> steel). Wear a protective mask and operate under well vented condition.
Not recommended if you want to continue to use the hard drive though.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/20/2012 10:31, Le_Forgeron wrote:
> Nowadays (and since most 1GB hard drive... quite old), its not possible
> anymore. Writing 0 or random number is the same: the old data is not
> recoverable.
This. Plus, if it's an SSD or has flash backup, you can write it all you
want and unless you rewrite the entire drive multiple times, you're not
guaranteed to get rid of the junk.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/20/2012 13:22, clipka wrote:
> Am 20.07.2012 20:54, schrieb Le_Forgeron:
>> Le 20/07/2012 19:46, clipka nous fit lire :
>>>
>>> Quiz: If you had highly sensitive data on your hard drive, and needed to
>>> erase it for sure - would you rather trust this alleged fact, or have
>>> the erasing software write random numbers just in case?
>>
>> If the data on drive was so sensitive, I would use chemistry first. Then
>> a bit of heavy hammer physic, and finally a good heat with partial
>> ionisation, at temperature far above the curie point.
>>
>> Boiling HCl is probably enough, as a starter. (get ride of most iron &
>> steel). Wear a protective mask and operate under well vented condition.
>
> Not recommended if you want to continue to use the hard drive though.
If it's not sensitive enough to pay to replace the drive, it's not sensitive
enough to worry about whether you're erased with zeros or with random data.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/20/2012 2:58, Le_Forgeron wrote:
> HT is: a second set of registers. Nothing more. No additional FPU or
> fancy integer units.
This. Generally, the second core runs during cache misses of the first core.
The design intent was to help alleviate the problem of having main memory
RAM much slower than CPUs.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20/07/2012 09:31 PM, Darren New wrote:
> On 7/20/2012 2:58, Le_Forgeron wrote:
>> HT is: a second set of registers. Nothing more. No additional FPU or
>> fancy integer units.
>
> This. Generally, the second core runs during cache misses of the first
> core. The design intent was to help alleviate the problem of having main
> memory RAM much slower than CPUs.
Really? I thought the design intent was to utilise idle execution units
if a particular thread is hammering (say) only integer units, leaving
the float units idle.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 20/07/2012 23:07, Orchid Win7 v1 nous fit lire :
> On 20/07/2012 09:31 PM, Darren New wrote:
>> On 7/20/2012 2:58, Le_Forgeron wrote:
>>> HT is: a second set of registers. Nothing more. No additional FPU or
>>> fancy integer units.
>>
>> This. Generally, the second core runs during cache misses of the first
>> core. The design intent was to help alleviate the problem of having main
>> memory RAM much slower than CPUs.
>
> Really? I thought the design intent was to utilise idle execution units
> if a particular thread is hammering (say) only integer units, leaving
> the float units idle.
The "hammering" is no more: a single instruction is split in multiple
different steps, each using different parts. Each step take some cycles,
and some steps could be very long when compared to another.
Hence the possible reordering inside the pipeline, which was a bit
before they think of HT.
Take the instruction decoder: it ends up doing nothing while the FPU is
doing your division. Well... when the division is actually performed at
the FPU, the decoder is actually decoding the fourth or fifth
instruction after the division. Yet, bubbles of empty cycles happen on
the pipeline: your division was followed by an unrelated addition of two
integers... that addition took far less cycles than the division, so
instructions #2,#3,#4 and #5 have already been performed when #1 is
still running. Yet, result of#1 is now needed... and we have all these
decoder, ALU and all which are idle... Let's have a second thread of
execution, absolutely unrelated because it run another piece of code.
All we need is a second set of registers (dedicated) and some circuitry
to use the idle cycles of every sub-parts. (sound easy, it's a bit complex).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/20/2012 12:46 PM, clipka wrote:
> Quiz: If you had highly sensitive data on your hard drive, and needed to
> erase it for sure - would you rather trust this alleged fact, or have
> the erasing software write random numbers just in case?
Why are you disposing of a drive that still works? In every
organization I've worked for, especially the military ones with scads of
sensitive information to manage, a drive was kept (and used) for as long
as it was operational. We simply couldn't afford to let one go if it
was still useful.
For most people, the only sensitive information on their drives is the
passwords to their on-line activities. You protect those by changing them.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-07-21 11:58, John VanSickle a écrit :
> On 7/20/2012 12:46 PM, clipka wrote:
>
>> Quiz: If you had highly sensitive data on your hard drive, and needed to
>> erase it for sure - would you rather trust this alleged fact, or have
>> the erasing software write random numbers just in case?
>
> Why are you disposing of a drive that still works? In every
> organization I've worked for, especially the military ones with scads of
> sensitive information to manage, a drive was kept (and used) for as long
> as it was operational. We simply couldn't afford to let one go if it
> was still useful.
This branching off the original topic was the need of my employer to put
the OS swapfile on an encrypted partition to prevent data leakage in
case of theft.
Why do thiefs get rid of working disks? Because they do not have any
need for them once they have gathered the information that was on them.
> For most people, the only sensitive information on their drives is the
> passwords to their on-line activities. You protect those by changing them.
The company directive mentioned above is not for "most people", but for
people who happen to have confidential material on their work laptops.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If the data on drive was so sensitive, I would use chemistry first. Then
> a bit of heavy hammer physic, and finally a good heat with partial
> ionisation, at temperature far above the curie point.
>
> Boiling HCl is probably enough, as a starter. (get ride of most iron&
> steel). Wear a protective mask and operate under well vented condition.
I'm not so sure acid would actually work. You're assuming that the layer
of iron is at the surface; this is not necessarily the case. It may well
have a layer of lacquer on top.
Also, you would /think/ that soaking plastic in a wide range of
hydrocarbon solvents would destroy it. But having personally tried it
with almost the entire contents of our lab's reagent cupboards, I can
confirm that this is not the case at all. Similarly, mineral acids are
probably not the flesh-eating monsters we all see on TV.
I have also discovered that most drives seem to have platters made of
glass. It's really very, very easy to shatter these, requiring no
specialist equipment at all. (Beyond some way of undoing the screws.
They quite often require unusual drivers... A drill sometimes does the
job though.)
The Curie point of pure iron is 770°C. My oven only goes up to 250°C.
(This is probably related to the fact that my oven is *made of* iron!)
You would need some kind of industrial kiln.
The melting point of glass varies by type. Borosilicate glass melts at
"only" 800°C, but most types melt at well over 1,00°C. (The median
temperature is listed as 1,700°C.) Good luck finding an oven that hot!
Really, unless you work for the DOD, a software wipe with /any/ data
pattern, followed by some gentle prodding with a hammer is quite sufficient.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 23/07/2012 10:05, Invisible a écrit :
>> If the data on drive was so sensitive, I would use chemistry first. Then
>> a bit of heavy hammer physic, and finally a good heat with partial
>> ionisation, at temperature far above the curie point.
>>
>> Boiling HCl is probably enough, as a starter. (get ride of most iron&
>> steel). Wear a protective mask and operate under well vented condition.
>
> I'm not so sure acid would actually work. You're assuming that the layer
> of iron is at the surface; this is not necessarily the case. It may well
> have a layer of lacquer on top.
>
> Also, you would /think/ that soaking plastic in a wide range of
> hydrocarbon solvents would destroy it. But having personally tried it
> with almost the entire contents of our lab's reagent cupboards, I can
> confirm that this is not the case at all. Similarly, mineral acids are
> probably not the flesh-eating monsters we all see on TV.
I had first hand experience (now more than 25 years ago) with *boiling*
HCl. It really eats iron (but not as speedy as shown on TV).
Main interest of HCl, expecially boiling: its huge oxydation capacity.
Nearly all metals are going into solution with enough time (gold,
platine and a few would need to play with regal water (which means
getting some nitric acid... that one is difficult to find as free use
(regulated as components for making explosives))
You do not have to open the disc: put the whole boxed disc inside the
boiling acid and let it work. The metal goes away (including a clean
PCB: no more tracks...)
The engines are deleted as well, and the springs, and the heads...
>
> I have also discovered that most drives seem to have platters made of
> glass. It's really very, very easy to shatter these, requiring no
> specialist equipment at all. (Beyond some way of undoing the screws.
> They quite often require unusual drivers... A drill sometimes does the
> job though.)
Platters are made of glass since 2003, IIRC. Yet, a shattered platter
could be readable by the alien technology, so better rinse them first
and get ride of the magnetic coverage.
Why drill when the acid is there for you. The crew are gone, the casing
is gone...
Put the drive in the acid in the morning, plenty of time to read the
comics while the drive get destroyed: profit!
>
> The Curie point of pure iron is 770°C. My oven only goes up to 250°C.
> (This is probably related to the fact that my oven is *made of* iron!)
> You would need some kind of industrial kiln.
The "ionisation" was to be done with some plasma torch, or alike.
Just check the plasma temperature vs the curie point.
At worst, acetylen+oxygen is high enough for that (3200°C) and not a
problem to get a hand on (usual welding).
>
> The melting point of glass varies by type. Borosilicate glass melts at
> "only" 800°C, but most types melt at well over 1,00°C. (The median
> temperature is listed as 1,700°C.) Good luck finding an oven that hot!
>
> Really, unless you work for the DOD, a software wipe with /any/ data
> pattern, followed by some gentle prodding with a hammer is quite
> sufficient.
DOD has its own procedure. And they can provide the equipment.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/07/2012 12:50 PM, Le_Forgeron wrote:
> You do not have to open the disc: put the whole boxed disc inside the
> boiling acid and let it work. The metal goes away (including a clean
> PCB: no more tracks...)
> The engines are deleted as well, and the springs, and the heads...
We actually /have/ a fume cupboard in the lab. And several litres of
laboratory-grade hydrochloric acid. And a heater.
Holy cow, you probably should not have told me about this... ._.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
