Live data from Hacker News

A 32nm 1000-Processor Array

vcl.ece.ucdavis.edu

101–107 of 107 posts

Re: A 32nm 1000-Processor Array

#101

Earlier quoted context omitted.

>Functional programming languages do not _require_ a GC. They just largely have it. No they just require Infinite Memory [1] XOR GC. Pure Functional programming has no concept of Alloc/Delloc. Let alone the concept of binding/assignment can fail. These are real. To quote James Michens [2] >Pointers are real. They’re what the hardware understands. Somebody has to deal with them. You can’t just place a LISP book on top…

PreScheme was a LISP to replace C for low-level programming. Used manual, memory management instead of GC. Very fast and efficient. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.3.4... Formally verified plus a Scheme48 interpreter as part of VLISP project. https://en.wikipedia.org/wiki/PreScheme ATS has no garbage collector that I'm aware of. I've seen it used in device drivers and 8-bit MCU's. https://en.…

Well yeah but these languages aren't purely functionally which was what the original discussion was centered on. If you throw imperative elements into FP they're very useful yes. But you've broken the functional paradigm.

Also if all these things are amazing why aren't anyway using them?

Re: A 32nm 1000-Processor Array

#102

Earlier quoted context omitted.

PreScheme was a LISP to replace C for low-level programming. Used manual, memory management instead of GC. Very fast and efficient. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.3.4... Formally verified plus a Scheme48 interpreter as part of VLISP project. https://en.wikipedia.org/wiki/PreScheme ATS has no garbage collector that I'm aware of. I've seen it used in device drivers and 8-bit MCU's. https://en.…

Well yeah but these languages aren't purely functionally which was what the original discussion was centered on. If you throw imperative elements into FP they're very useful yes. But you've broken the functional paradigm. Also if all these things are amazing why aren't anyway using them?

Lambda Calculus and Turing Machine are equivalent in power. You can, as many academics have, model imperative programs as functional ones. You can compile functional programs, as almost all compilers do, to imperative code in C or assembler. We often make the distinction on syntax and structure a bit but they're both passing state into functions that optionally produce state. Edit to add that my forays in hardware show it's all functional (analog) underneath: mathematical functions running continuously without memory emulating abstract machines.

"Also if all these things are amazing why aren't anyway using them?"

Social and economic factors as usual. See Gabriel's essay Worse is Better:

https://www.jwz.org/doc/worse-is-better.html

Just take C language. I have its history in detail and with citations. It was literally an engineered language chopped up to run on bad hardware, chopped again with arbitrary alterations on bad hardware, and slightly extended for bad hardware again. Most people had bad hardware. Worked good on that. Spread like a virus with gradual improvements. Still nowhere near what engineered languages can pull off in various tradeoffs to consider. Yet, almost everything is written in it now thanks to it working on half-assed hardware, a MULTICS chop called UNIX doing so, UNIX distributed freely, and UNIX written in C. Social & economic factors spread it like a virus plus improved it to approximate solutions designed under cathedral model with better properties.

http://pastebin.com/UAQaWuWG

Meanwhile, alternatives sprang up that kicked both their butts in capabilities. The LISP machines, functional's answer to whole systems, had a flow and consistency you still can't match with modern stacks. B5000, a HW/OS combo designed for safe languages, would've given hackers hell. Amiga's combined SW and HW offloaders for excellent performance... like today's servers & game consoles. BeOS screamed in concurrency, multimedia, and ease of use while popular Windows and Mac boxes couldn't do but a fraction of it. AS/400's and VMS boxes ran, ran, and then ran some more with at least one person forgetting how to reboot them haha. Some in high-security survived NSA pentesting while things that get easily smashed by amateurs prevail today for security-critical work. I think it's clear a language or system's technical superiority has almost no causal relationship with mainstream adoption by laypeople or technical people.

Actually and sadly, it's usually better to bet on Worse is Better approaches with slight improvements for success or adoption. Occasionally, you can bet on The Right Thing with a win as Mozilla is doing with Rust. Heck, even Burroughs B5000 lives on in Unisys mainframes. OpenVMS lives on in Windows NT family as it cloned it for desktops minus strong focus on quality (sighs). ZeroMQ is a good example in middleware. Nix applying database-style principles to package management. Technically superior stuff occasionally mainstreams but not often. Human nature usually wins. :(

Re: A 32nm 1000-Processor Array

#103
post #56

Earlier quoted context omitted.

> My naive assumption would be that pure code could be adapted for a 1000-core machine with only changes to the compiler and runtime environment. Perhaps for use cases where current, garbage collected languages are suitable. For areas where (today) asm/c/c++/rust is a must, you would need a functional language that can give you guarantees about garbage generation, so you can be sure you won't need to collect garbage,…

> For areas where (today) asm/c/c++/rust is a must, you would need a functional language that can give you guarantees about garbage generation That's the entire point of the "purity" idea. Pure FP languages give you very strict guarantees about garbage generation. The only question is if everyday code has enough pure code to fill a 1000 cores processor.

> Pure FP languages give you very strict guarantees about garbage generation

I thought the only guarantee is they don't have side effects.

Re: A 32nm 1000-Processor Array

#104
post #103

Earlier quoted context omitted.

> For areas where (today) asm/c/c++/rust is a must, you would need a functional language that can give you guarantees about garbage generation That's the entire point of the "purity" idea. Pure FP languages give you very strict guarantees about garbage generation. The only question is if everyday code has enough pure code to fill a 1000 cores processor.

> Pure FP languages give you very strict guarantees about garbage generation I thought the only guarantee is they don't have side effects.

They are immutable, there's no implicit cross-dependency between data upper on the calling hierarchy, and any shared data can be recalculated as many times as needed.

That's what I get from the top of my mind. There are probably more features that will help. Purity is a very strict guarantee.

Re: A 32nm 1000-Processor Array

#105

Earlier quoted context omitted.

I'm an ex game engine developer and I bristle anytime anyone thinks any existing functional language is better for multicore. Specifically garbage collection alone will make any language an order of magnitude slower generally per a single core. Also the C/C++ game development community at least has great approaches to multicore which makes C/C++ linearly scale with scores to boot, see for example: http://www.gdcvault…

> I bristle anytime anyone thinks any existing functional language is better for multicore. .. and have they read the paper for this multicore? Though it has a large number of processors, there are severe resource constraints per node, with respect to how large a local program can be and how much memory is available.

But virtualizing such things is what OSs are all about.

Re: A 32nm 1000-Processor Array

#106
post #90

Earlier quoted context omitted.

Perhaps you've noticed the architecture of the new top top500 system. There's currently an HPC guessing game on filling in blanks in " rel="nofollow">http://www.netlib.org/utk/people/JackDongarra/PAPERS/sunway-... but of course CPU comparisons stop at Knights Landing. One of the things I wondered about is how Linux is adapted to such an architecture. I couldn't find anything from REX on operating system support.

Yep, have seen it... it seems to not be exactly what was described by the Chinese at ISC or SC last year (their original description being much more in line with a DSP), though there is not much data available. All of the articles I am seeing today are calling it DEC Alpha "like", though the only real source for this seems to be the wikipedia article for the family of processors, with the latest version being in 2013…

Oh, so I guess the Sunway thing isn't as much like Neo conceptually as it looked to me from what little information I had. (I wasn't thinking about the ISA.) Of course the media are mainly useful for indications to chase primary sources.

The point about the OS related to the Linux-based one for Sunway, but maybe it only runs on the management processor anyhow, with just offload to the others. I'd commented in that respect that we really don't want something like Linux in an ideal world, so I'm pleased to see mention of L4.

Thanks for the comments, and good luck.

Re: A 32nm 1000-Processor Array

#107
> KiloCore processors ... store data and instructions inside i) local memory, ii) an arbitrary number of nearby processors, iii) on-chip independent memory modules, or iv) off-chip memory.

Ah, like GreenArrays' GA144, which contains 144 discrete cores - each with a small amount of memory - that can communicate with each other. The rationale with this chip is that you store data in the memory of one or more neighboring core(s) if it won't fit in the ~64 bytes (IIRC) of the core you're working in.

Post reply on HN