As I understand it the I7 has 4 cores and each core has a pair of local
caches. So a processor can switch back an forth between 2 threads and the
cache does not have to be rebuilt. Cache memory can cause very interesting
problems. It works very well when multiple caches map widey seperated main
mem
Be careful about the I7. I7 used to mean something that it doesn't
anymore. Many I7's are dual processor. Better verify.
On Wed, Feb 25, 2015 at 4:41 PM, N.N. wrote:
> I want to buy an Intel i7 with Windows.
> 1) does Windows use the 8 processors to run the j-console ?
> 2) is it possible to
That's an interesting point. Unfortunately, it would make my job easier
(as I've already implemented a file-based mutex) and wouldn't give me the
chance to learn something new.
On Thu, Feb 26, 2015 at 11:49 AM, Raul Miller wrote:
> Unless you are using multiple machines, files are probably a be
Certainly, you can implement concurrent processes on top of sockets.
And using select (or poll) can be a big help there. You can also use
threads or processes but that introduces more overhead (but sometimes
that overhead is insignificant for the project you're working on, when
compared to dealing
Sockets are not necessarily a stop-and-wait proposition. The management of
multiple sockets using select() is well established and is used in a quite
a lot of real-world systems for coordinating clusters of cooperative
machines. Introducing the file abstraction into the process might make the
progr
Unless you are using multiple machines, files are probably a better
coordination abstraction than sockets.
(And if you are using multiple machines, you might still want to be
using a file-like abstraction.)
The reason is that sockets give you a "stop and wait" abstraction
while files give you a "
I run parallelized J on multi-core machines and have done so for years. I
looked at the "CPU affinity" thing and concluded it was a waste of time and
an unnecessary constraint for what I was doing. What I've found is that
the OS - Windows in my case - does a fine job on its own of distributing
mu
On Wed, Feb 25, 2015 at 5:41 PM, N.N. wrote:
> 1) does Windows use the 8 processors to run the j-console ?
>
No, J is single threaded
2) is it possible to run 8 j-consoles and assign each console on one
> processor ?
>
You could, but I'm not sure what the benefit would be. You could assign CPU
opies of Jconsole, and
communicate by sockets or files. There is a reasonably small memory footprint
for each J session.
- Original Message -
From: N.N.
To: programm...@jsoftware.com
Cc:
Sent: Wednesday, February 25, 2015 5:41 PM
Subject: [Jprogramming] Window j-console and Intel i7
I
I want to buy an Intel i7 with Windows.
1) does Windows use the 8 processors to run the j-console ?
2) is it possible to run 8 j-consoles and assign each console on one processor ?
3) is it possible to use 1 console and manually create threads
assigning a process on the 7 remaining processors ?
Al
10 matches
Mail list logo
