SoylentNews is people
SoylentNews
Motherboard reports on a press release by the University of California Davis, where researchers designed a multiple instruction, multiple data (MIMD) microprocessor. Unlike a GPU, each core can run distinct instructions on distinct data.
According to the researchers the chip has a greater number of cores than any other "fabricated programmable many-core [chip]," exceeding the 336 cores of the Ambric Am2045, which was produced commercially.
IBM was commissioned to fabricate the processor in 32 nm partially depleted silicon-on-insulator (PD-SOI). It is claimed that the device can "process 115 billion instructions per second while dissipating only 1.3 watts." or, when operating at greater supply voltage and clock rate, "execute 1 trillion instructions/sec while dissipating 13.1 W."
(Score: 2) by Gravis on Wednesday June 22 2016, @06:37AM
sure, they made the chip but did they also make a visual debugger to debug the thousand cores? this is actually something Adapteva was working on with the Epiphany III processor for the Parallella board. it's good to have awesome chips but it's equally important to have awesome tools for said chips.
(Score: 2, Funny) by Anonymous Coward on Wednesday June 22 2016, @06:47AM
No all they have to make is the hardware because the way software is developed these days is you create an empty github repo with a description of the software you want and a bunch of naive kids will write it for you before they realize they should have gotten paid to do it.
Here let me explain the relationship between hardware and software in terms you can understand:
https://xkcd.com/644/ [xkcd.com]
(Score: 1, Insightful) by Anonymous Coward on Wednesday June 22 2016, @07:48AM
I don't understand. do you mean debug for hardware issues?
because otherwise you can just debug your code on 4 cores (or maybe 10 if you have the patience), and then you know it's correct on 1000 cores as well.
And for 4 or 10 cores, you can simply use "printf" (or std::cout if you're so inclined).
(Score: 2) by Immerman on Wednesday June 22 2016, @01:38PM
Only if your code is completely free of any synchronization-related bugs that would show up with increased parallelization.
I suspect through, being unfamiliar with massively parallel programming, that they're talking about debuggers designed to make visualizing the workflow in 1000 threads more effective, since a good debugger is also an excellent sidekick for performance analysis.
(Score: 0) by Anonymous Coward on Wednesday June 22 2016, @06:27PM
I do write codes that run on hundreds of CPUs (at least my code sees hundreds of CPUs, I don't know how many of these are cores etc). However, I use MPI (memory is divided among processes, no global addressing), which is the only thing that can handle what I do. For this particular CPU, I guess the shared memory paradigm may work, so things would be slightly different.
Note that what I do is pretty simple, since basically all the cores are doing the same thing but on different data. I believe there are real programmers out there that can handle algorithms where different processes are doing different things, and maybe they have a different idea about debugging...
In any case. I did have bugs that only showed up when I used many processes. It sucks to debug them. But I did it the same way. Good old printf to pinpoint what function failed and on which CPU, and then good old printf to output extra information for that particular CPU in that particular function.
(Score: 2) by HiThere on Wednesday June 22 2016, @08:25PM
I don't know. Shared Memory? in a parallel setup? Even if only one process is allowed to write to any particular section of memory you can get all sorts of races unless caching is eliminated, which has it's own problems. All shared memory needs to be immutable (write protected from every process) if you want to avoid that, and if you do that you're pretty much doing message passing even if the implementation looks different. Lock-based programming just doesn't scale well at all.
OTOH, I'm still getting started in this area, but the stories you hear!!
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by tibman on Wednesday June 22 2016, @01:16PM
Here's a working 12 core example : D
http://store.steampowered.com/app/370360/ [steampowered.com]
SN won't survive on lurkers alone. Write comments.
(Score: 0) by Anonymous Coward on Thursday June 23 2016, @01:05AM
That game is a fucking dildo.
It was fun and novel for a bit but I just gave up. Months later and none of my steam friends got even close to solving the amount I solved.
One day I'll write both my own genetic algorithm that will solve this shit somehow and some arbitrary 'compiler' or high-level modeling language.
(Score: 2) by tibman on Thursday June 23 2016, @01:40AM
Something unexpected happens at the end : ) It's a fun trip into assembly if you never had the opportunity before (born too late).
SN won't survive on lurkers alone. Write comments.
(Score: 2) by DannyB on Wednesday June 22 2016, @09:25PM
Only old people care about debugging.
Is there a chemotherapy treatment for excessively low blood alcohol level?