Comments on: May’s Law and Parallel Software http://www.linux-mag.com/id/8422/ Open Source, Open Standards Sat, 05 Oct 2013 13:48:18 +0000 hourly 1 http://wordpress.org/?v=3.1 By: gujjar http://www.linux-mag.com/id/8422/#comment-824109 gujjar Fri, 22 Mar 2013 10:07:19 +0000 http://www.linux-mag.com/?p=8422#comment-824109 It's hard to tell with these Internet startups if they're really interested in building companies or if they're just interested in the money. I can tell you, though: If they don't really want to build a company, they won't luck into it. That's because it's so hard that if you don't have a passion, you'll give up. <a href="http://www.prescientlaw.co.uk/" rel="nofollow">Divorce solicitors london</a> It’s hard to tell with these Internet startups if they’re really interested in building companies or if they’re just interested in the money. I can tell you, though: If they don’t really want to build a company, they won’t luck into it. That’s because it’s so hard that if you don’t have a passion, you’ll give up.
Divorce solicitors london

]]> By: mad prof http://www.linux-mag.com/id/8422/#comment-573241 mad prof Fri, 16 Nov 2012 12:19:10 +0000 http://www.linux-mag.com/?p=8422#comment-573241 agreed jonathan, perhaps he and Carl Sassenrath, CTO REBOL Technologies and lead amiga OS tech can talk now that REBOL is goign open source http://rebol.com/ " Fighting software complexity... Software systems have become too complex, layers upon layers of complexity, each more brittle and vulnerable to failure. In the end software becomes the problem, not the solution. We rebel against such complexity, fighting back with the most powerful tool available: language itself." the fact this artical is over 12 months old now perhaps Douglas and linux mag might like to get them together and do a retrospect from two long time legends and how they can help the new massive ARM Linux commercial world vendors di it right and give the world a new direction in KISS agreed jonathan, perhaps he and Carl Sassenrath, CTO
REBOL Technologies and lead amiga OS tech can talk now that REBOL is goign open source http://rebol.com/
” Fighting software complexity…
Software systems have become too complex, layers upon layers of complexity, each more brittle and vulnerable to failure. In the end software becomes the problem, not the solution. We rebel against such complexity, fighting back with the most powerful tool available: language itself.”

the fact this artical is over 12 months old now perhaps Douglas and linux mag might like to get them together and do a retrospect from two long time legends and how they can help the new massive ARM Linux commercial world vendors di it right and give the world a new direction in KISS

]]> By: pavlik http://www.linux-mag.com/id/8422/#comment-9242 pavlik Tue, 22 Mar 2011 13:57:02 +0000 http://www.linux-mag.com/?p=8422#comment-9242 Surely, why not an Occam revival? Great idea, great language! Ahead of his time? Surely, why not an Occam revival? Great idea, great language! Ahead of his time?

]]> By: Jonathan May http://www.linux-mag.com/id/8422/#comment-9233 Jonathan May Sun, 20 Mar 2011 18:50:57 +0000 http://www.linux-mag.com/?p=8422#comment-9233 David May would have been a good person to interview about this! I am sure he has quite a strong view - particularly given your very specific interpretation of his law. David very publicly takes the view that parallel programming, concurrency, real-time software and event-driven programming are all easy: simple problems to solve given the right tools. In fact, much of his commercial work (transputer, Occam, <a href="http://xmos.com" rel="nofollow">XMOS</a> etc), and his academic work, has been about making highly efficient, easy-to-use concurrent devices, compilers and languages. Can I suggest a follow-up article where you interview him? I can arrange an introduction if you like. David May would have been a good person to interview about this! I am sure he has quite a strong view – particularly given your very specific interpretation of his law.

David very publicly takes the view that parallel programming, concurrency, real-time software and event-driven programming are all easy: simple problems to solve given the right tools. In fact, much of his commercial work (transputer, Occam, XMOS etc), and his academic work, has been about making highly efficient, easy-to-use concurrent devices, compilers and languages.

Can I suggest a follow-up article where you interview him? I can arrange an introduction if you like.

]]> By: markhahn http://www.linux-mag.com/id/8422/#comment-9225 markhahn Fri, 18 Mar 2011 19:17:48 +0000 http://www.linux-mag.com/?p=8422#comment-9225 if your code only uses send/recv, it's either trivial or has reimplemented some of the higher-order communication forms that MPI provides. reimplementing is not the greatest sin, but often results in poorer versions. for instance, do your collectives scale as well as MPIs? do they take advantage of hardware support that the interconnect may provide? if your code only uses send/recv, it’s either trivial or has reimplemented some of the higher-order communication forms that MPI provides. reimplementing is not the greatest sin, but often results in poorer versions. for instance, do your collectives scale as well as MPIs? do they take advantage of hardware support that the interconnect may provide?

]]> By: wgodoy http://www.linux-mag.com/id/8422/#comment-9220 wgodoy Fri, 18 Mar 2011 16:47:27 +0000 http://www.linux-mag.com/?p=8422#comment-9220 I think the author of this article needs to take a look at Java Threads. It's not even mentioned. Java threads (which is not hard to program) combined with MPI gives a boost to HPC and more control on your code then OpenMP. I think the author of this article needs to take a look at Java Threads. It’s not even mentioned. Java threads (which is not hard to program) combined with MPI gives a boost to HPC and more control on your code then OpenMP.

]]> By: linus_cal http://www.linux-mag.com/id/8422/#comment-9216 linus_cal Thu, 17 Mar 2011 23:31:29 +0000 http://www.linux-mag.com/?p=8422#comment-9216 Great post DEadline...your prediction couldn't have come at a better time. Let the wars begin... http://blogs.forbes.com/briancaulfield/2011/03/17/intel-snaps-up-mobile-multimedia-specialist-silicon-hive/ Great post DEadline…your prediction couldn’t have come at a better time.
Let the wars begin…
http://blogs.forbes.com/briancaulfield/2011/03/17/intel-snaps-up-mobile-multimedia-specialist-silicon-hive/

]]> By: zakhurlifesbane http://www.linux-mag.com/id/8422/#comment-9215 zakhurlifesbane Thu, 17 Mar 2011 18:28:52 +0000 http://www.linux-mag.com/?p=8422#comment-9215 Gee, Erlang is parallel and fault-tolerant. I am thinking some hardware needs to "back off" in terms of how it manages cache and processors need dedicated roles in the sense that some (like GPUs) do computation and others do logic, setup, cleanup, AND cache management. Hardware cache management is optimized for linear computing and not always for that. Put that back under program control (well sorts, like setting up DMAs and defining limit addresses for incoming, outgoing and working cache with rollin-rollout of each) CPU Cache is many times faster than main memory and needs good management. HPC will use all of those, but we are still a long way from any really viable AI except in limited areas. Many of those require breakthroughs in other areas of understanding--such as speech-to-text where hardware can hear a lot more than the human ear and we need to focus on what makes speech meaningful. Gee, Erlang is parallel and fault-tolerant. I am thinking some hardware needs to “back off” in terms of how it manages cache and processors need dedicated roles in the sense that some (like GPUs) do computation and others do logic, setup, cleanup, AND cache management. Hardware cache management is optimized for linear computing and not always for that. Put that back under program control (well sorts, like setting up DMAs and defining limit addresses for incoming, outgoing and working cache with rollin-rollout of each) CPU Cache is many times faster than main memory and needs good management.

HPC will use all of those, but we are still a long way from any really viable AI except in limited areas. Many of those require breakthroughs in other areas of understanding–such as speech-to-text where hardware can hear a lot more than the human ear and we need to focus on what makes speech meaningful.

]]> By: coolul007 http://www.linux-mag.com/id/8422/#comment-9204 coolul007 Thu, 17 Mar 2011 13:20:19 +0000 http://www.linux-mag.com/?p=8422#comment-9204 Unfortunately, MPI and others want to start a religion rather than solve a problem. Yes, communication is the key to all HPC. Creating a communication interface with more instructions than the host language does not endear one to writing programs. What ever happened to "send and receive"? Unfortunately, MPI and others want to start a religion rather than solve a problem. Yes, communication is the key to all HPC. Creating a communication interface with more instructions than the host language does not endear one to writing programs. What ever happened to “send and receive”?

]]>