Computing desk
< October 30	<< Sep \| October \| Nov >>	November 1 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

October 31

Linked Data

Could someone please explain to me the practical use of Linked Data? The Wikipedia article is very vague, and I am not exactly sure what the purpose of RDF is and what the data do once they are on the internet. --Munchkinguy (talk) 05:27, 31 October 2012 (UTC)[reply]

The article is linked data, I'm just linking to make the data more practical. OsmanRF34 (talk) 20:40, 31 October 2012 (UTC)[reply]

Har har. --207.161.96.154 (talk) 04:57, 2 November 2012 (UTC)[reply]

yield method in java

Hi sir!yield method makes currently executing thread to pause to make another active thread to run.
i got some doubts on yield method.i previously asked about yield.but this time some what differnent than previous.I am asking based on
below code.
I hope you help me.

Source Code

class thread7
{
    public static void main(String args[])
    {
        Thread count1=new Thread(new CountDownEven());
        Thread count2=new Thread(new CountDownOdd());
        Thread t=Thread.currentThread();
        count1.start();
        count2.start();
        for(int i=11;i<=20;i=i+2)
        {
            System.out.println(t.getName()+"----"+i);
            Thread.yield();
        }
    }
}
class CountDownEven implements Runnable
{
    public void run()
    {
        Thread t=Thread.currentThread();
        for(int i=0;i<10;i=i+2)
        {
            System.out.println(t.getName()+"----"+i);
            Thread.yield();
        }
    }
}
class CountDownOdd implements Runnable
{
    public void run()
    {
        Thread t=Thread.currentThread();
        for(int i=1;i<10;i=i+2)
        {
            System.out.println(t.getName()+"----"+i);
            Thread.yield();
        }
    }
}

Mydoubts:

Does yield method guarantees that after executing yield control goes to another active thread? see in the below output in line 3,4 thread 0 got executed two times.why this happened?Is it due to drawback of yield or due to cpu execution?
what are the drawbacks of yield method?
If it has drawbacks then why yield method?what is the purpose of yield?

Output

Thread-0----0
main----11
Thread-0----2
Thread-0----4
Thread-1----1
main----13
Thread-1----3
Thread-0----6
Thread-1----5
main----15
Thread-1----7
Thread-0----8
Thread-1----9
main----17
main----19

— Preceding unsigned comment added by Phanihup (talk • contribs) 09:25, 31 October 2012 (UTC)[reply]

Yield guarantees nothing - it just hints at the system that it is a good place to give up control if it is needed. To control the order of execution of multiple threads you need to use Thread synchronization. When two threads are running simultaneously, the system can switch back and forth between them at any time, and there is no way to predict it. Synchronization is the only way to control it. 209.131.76.183 (talk) 12:32, 31 October 2012 (UTC)[reply]

Don't use yield. Just forget it exists. -- BenRG (talk) 15:54, 31 October 2012 (UTC)[reply]

Stopped update of Ubuntu, how to get rid from downloaded files

I started downloading the packages for updating Ubuntu from 12.04 to 12.10, but thought it was better to keep 12.04, since it's a LTS version and the new one doesn't promise any meaningful improvement. I didn't screw up the system, but I downloaded a part of these 3 GB needed. How can I get rid of these files? Comploose (talk) 13:35, 31 October 2012 (UTC)[reply]

Just clean up your system with BleachBit, I think that will be enough. OsmanRF34 (talk) 20:33, 31 October 2012 (UTC)[reply]

I'm not 100% sure, but I think apt-get autoclean might do the trick. Shadowjams (talk) 21:01, 31 October 2012 (UTC)[reply]

Unpredictable transfer times over internal socket loopback

I have multiple processes on the same physical Windows 7 based system that communicate with each other by opening local sockets. These processes sometimes need to exchange large quantities of data (e.g. 100s of MB to a few GBs). I've observed that the length of time required for this communication seems quite variable. In order to nail it down, I isolated one sender process and one receiver process and repeatedly ran the same large transfer. I found that the time required for completion varied by more than a factor of ten from less than 4 seconds to more than 50 seconds for my test data. Since I am just moving bytes around inside the computer, I was surprised by the large variation. For the test, I disabled firewall software and other processes that commonly use socket / network communication. Can anyone suggest other factors that might cause such large variation? Assuming I can't avoid using socket communication, is there anything that might be done on the operating system side to make the exchanges faster / more predictable? Dragons flight (talk) 17:31, 31 October 2012 (UTC)[reply]

You should disable antivirus software also, or anything else that might have installed a Winsock Layered Service Provider. HijackThis can list LSPs. You could also install another loopback adapter with a private address like 10.0.0.1 and try using that instead, though it seems unlikely to help. That's all I can think of. -- BenRG (talk) 17:50, 31 October 2012 (UTC)[reply]

I don't know about Windows, but I think even loopback data has to go through the kernel/userspace barrier twice. Depending on other demands on the kernel, this could lead to inconsistent behavior. Can you use shared memory or pipes? --Stephan Schulz (talk) 18:12, 31 October 2012 (UTC)[reply]

Winsock is a variant of the Berkeley sockets API. So it has the same memcpy-in, memcpy-out overhead (unless they've done some exceptional optimisation). But that's mostly a linear, deterministic overhead - you won't get the performance of shared memory, but you shouldn't find an order of magnitude of variation between its best and worst performance. I agree with Nimur, below, that something else is to blame for the variation. -- Finlay McWalterჷTalk 01:44, 1 November 2012 (UTC)[reply]

"What are you measuring"? In other words, are you certain you're measuring exactly and only the transfer over the socket? Is the source of the data resident in main memory? Is it in the processor's cache? On the disk? If you can, isolate exactly and only the socket communication for benchmarking and timing, as opposed to all the other steps necessary to access and copy the data. It isn't clear to me that you've completely separated network traffic performance from all other performance considerations. It is very probable that you're seeing a 10x difference in performance because some tests are bottlenecked by disk access. Nimur (talk) 19:33, 31 October 2012 (UTC)[reply]

The time from when the sending process starts the transfer till when it thinks it has completed. There is no disk access (there shouldn't be and process monitoring confirms that there isn't), and I'm not even sure why you would suggest that. In the test, it is copying about 1 GB of data from the memory space of one process, writing it to the open socket (presumably subject to various buffer limits), while another process is reading from that socket and writing what it sees to a previously allocated block of memory under its control. Of course, it is Windows, so I can't control everything, but a factor of ten is still a large fluctuation for something that is doing nothing except moving bytes around. For that matter, taking 4 seconds to move 1 GB is actually pretty slow to begin with. I don't really have an easy way to change how these programs communicate, so I'm sort of stuck with the sockets, but making it faster and more predictable would still be useful. Dragons flight (talk) 21:01, 31 October 2012 (UTC)[reply]

Have you read MSDN's High-performance Windows Sockets Applications? It provides numerous tips, tricks, debugging suggestions; and particularly, suggests that you determine why your application is going slow before you assume the latency lies in the network layer. You can change your RTT, TCP packet size, and disable TCP delays, to help root-cause the latency if it actually is the fault of the sockets API. You can switch from a stream socket to using a datagram socket, enabling peak throughput and network performance at the cost of requiring more disciplined approaches to sending and receive the data. You can tune the number of simultaneously-open sockets (whether data streams or datagrams). Windows is able to sustain over 200,000 simultaneous network transactions. It is really really really unlikely that your performance bottleneck is actually in the network layer, which is why I'm throwing out some other ideas - like slow disk access, CPU stalling due to other loads, memory paging, and so on. But, if you're certain the problem is in the sockets layer, you can help us track down the problem: what type and version of Windows compiler are you using? What API are you using to construct your sockets? What API(s) or data structures are you using to feed data into the sockets? Nimur (talk) 01:17, 1 November 2012 (UTC)[reply]

Question Changing Page Profile Photo

I am friends and run the official facebook site for actress Catherine Mary Stewart.

We noticed that the photo on her page (http://wiki.riteme.site/wiki/Catherine_Mary_Stewart#External_links) is a random fan photo taken during an autograph signing. We would like to have one of her professional photos representing her but can not see how to change. Could you advise?

Tom Ryan — Preceding unsigned comment added by Ryantbo (talk • contribs) 21:34, 31 October 2012 (UTC)[reply]

Do you want to change her profile picture on Facebook, or on Wikipedia? If on Wikipedia, you'll have to get the photo licensed appropriately. Marnanel (talk) 22:05, 31 October 2012 (UTC)[reply]

Wikipedia:Image use policy. And even then, it will be up to the consensus of the editors whether it will be changed. However if you are able to provide a clearly superior photograph with a license as permissive or more permissive than the one that is currently there, it should make it. ¦ Reisio (talk) 23:48, 31 October 2012 (UTC)[reply]

Graphics hierarchy

I'm trying to get a more detailed understanding of the graphics hierarchy and how everything works together.

So heres a basic view of the hierarchy:

Graphics API (e.g. DirectX, OpenGL)

Graphics driver

GPU/Graphics card

For now what I would like to know is what happens to the graphics code when a program is compiled? --TuringMachine17 (talk) 22:54, 31 October 2012 (UTC)[reply]

A program (lets say a C++ program) is compiled as normal. It either directly makes OpenGL or DirectX calls, or it uses an intermediate library (some kind of middleware) which eventually makes those calls. Those calls are implemented by a userspace library (a dynamic link library or shared object). That library performs some transformations on that data (more on that later) and then performs a system call which transfers control to supervisor mode (kernel space) code (the graphics driver, essentially). That performs more transformations (it's here that contention between multiple programs is resolved). Then that writes into the RAM of the graphics card, which is mapped into the CPU's address space over PCI, or these days over a fancier interconnect that mostly works (from a software perspective) as if it was PCI. That driver code also sends commands over the PCI connection to the graphics card. Compared with the performance of the CPU and GPU at each end, that PCI(like) pipe is relatively constrained (it's a bit like feeding a rabid lion by pushing frankfurters at it down a long, thin pipe). Most of what's getting shoved down that pipe is textures and (to a slightly lesser extent) geometry. Different GPUs can do more or fewer things, so precisely what gets passed over the bus to them is between the driver and the card; older and cheaper cards do more calculations on the CPU, newer and fancier ones can offload more work to the GPU. But (relatively recently) GPU vendors started to allow more than data to travel over the connection. A GPU is, in essence, a mini personal supercomputer cluster, so latterly it's been possible to send it instructions, and not just data (oh my lion metaphor disintegrates here; the rabid lion turns out to be really obedient and outstandingly good at arithmetic). So a developer can now write code (very often in a shading language) which is intended to be run on the GPU. The developer writes in say GLSL. The developer's toolchain compiles that (which mostly produces a squishified binary version of that), and includes that compiled shader as a binary file in the software distribution. At runtime, the C++ program will, as the developer has seen fit, submit that to OGL/DX API. There (at runtime, in user space) the shader code is re-translated into something suitable for the specific GPU in question - then the same process described above for data sends it down the narrow pipe to the arithmetically precocious rabid lion, which runs the program on its many simple processors. -- Finlay McWalterჷTalk 01:24, 1 November 2012 (UTC)[reply]

Phrased another way, a GPU can be described as a specialized, maybe-not-quite-Turing-complete programmable computer with asymmetric access to main system memory. The GPU may be programmed in a high-level language, or in an assembly-like machine language, in a way that takes advantage of special machine instructions. GPU machine instructions often include things like "treat three numbers as a vector, and calculate a cross-product with another three numbers." That sort of operation can be useful for mathematical representations of graphical operations, like projection. The GPU may have special instructions for interpolation; or for two-dimensional FIR filtering. A graphical program can combine these mathematical operations in a way that finally produces a rasterized pixel bitmap. Nimur (talk) 01:29, 1 November 2012 (UTC)[reply]

Okay I was planning on slowly building up to what I mainly wanted to know but I think you just answered it Finlay I just didn't really know how to explain it without going through the basics first. Basically, I was thinking since different GPUs can have different architectures and therefore different instruction sets, how can someone buy a game that uses OGL for example and have that game run on any graphics card (as long as it supports the required features). So the normall C++ part gets compiled for sure. Not sure about the OGL/DX stuff (Finlay you lost me on the bit about making direct calls or through an intermediate library). So what happens it becomes some sort of byte code and then the driver translates it into the required assembly for the GPU (seems unlikely for performance reasons). Or it gets translated into just a call to a OGL function which in the case of Windows would be in a dll. --178.208.219.141 (talk) 02:22, 2 November 2012 (UTC)[reply]

Both OpenGL and DirectX define a portable assembly language for shaders, and each vendor's driver converts that to actual GPU instructions at runtime. The hardware is designed to run DirectX and OpenGL shaders efficiently, since that's what everybody uses. -- BenRG (talk) 04:31, 2 November 2012 (UTC)[reply]

USB 2.0 vs 3.0 plug cycle rating

Do USB 3.0 connectors have different plug/unplug cycle ratings than their USB 2.0 counterparts? --209.133.95.32 (talk) 23:38, 31 October 2012 (UTC)[reply]