Re: End of the Free Lunch of Hardware

From: Percival (dragontamer5788_at_yahoo.com)
Date: 03/11/05 

Date: Thu, 10 Mar 2005 23:23:13 -0500

On Fri, 11 Mar 2005 04:34:11 +0100, '\\o//'annabee wrote:

>> I'm suggesting that the
>> "functional" programming languages will have a rebirth from this, as
>> functional languages are 100% thread safe (if they a "pure" functional
>> language, like Haskell)
>
> At some place they must exchange data. So thats sound like just another
> sweet dream.

No destructive updates in the pure functions :) No, inc eax, cause that
means eax increases, and once a value is set, it can't be changed.
Continuous reads won't cause deadlocks.

(yeah, I guess thats what makes Haskell slow... Very slow) Who knows? Bah,
we all know, HLL waste your time and energy :) Still, some interesting
concepts I've learned in my short time with the language. I think its a
good thing to learn other computer languages and see the world of
programming from that perspective, you always learn a different way to
program when your current way is no longer supported.

> Its also possible to create multitasking without threads. This is actually
> the better way, in some cases, when dealing with only one processor.
> Create the logic such that everything can respond to TICKS. You devide a
> task into x ticks. And then you're doing a loop over all the objects,
> ticking each one. Each tick performs only a small piece of work before
> returning. Yet everything is serialized. This is a sort of userdefined
> threads, and they are seriously faster running the window threads.

Thats not multitasking, and that won't take advantage of multiple CPUs
that will come in the future. That is asynchronous I/O. This is definitely
faster on a single CPU, as all that extra synchronization stuff is taken
care of manually. But when you have 2 threads and 2 CPUs, you should use
"true threads" so they run on both CPUs.

> When having more than one processor or hyperthreads, create two or more
> TREEES of task, that can all be performed with TICKS. Assign each TREE to
> a processor, or Thread.

Hmm... I probably should start up learning concurent programming. Even if
multi-core CPUs aren't the future, at least I've learned threads and all
that stuff.

Percival

Relevant Pages

  • Re: A Parable of Two Carpenters
    ... Thats the truth. ... the language is really not a question at all. ... In order to overcome the time barrier, make the code from scratch, but also ... Problem with reading other peoples code, you will take much longer time to ...
    (alt.lang.asm)
  • Re: C++ vs. C#
    ... gives access to .Net framework which is not available to C++ ... Thats why I highlighted "native". ... The language itself is the culprit. ... That doesnt imply C++ doesnt have any ...
    (microsoft.public.vc.mfc)
  • Re: Position of MS regarding the future C++ Standard
    ... C++ is still the language of choice. ... applications that you mention amount to most of them. ... then it will hardly matter how much more performant C++ is over C#. ... The number of CPUs ...
    (microsoft.public.vc.language)
  • Re: dual processor
    ... If what you're doing is not going to be helped by scaling across a bunch of CPUs, then you're just as well off if Python still has the GIL. ... Steve brings up an interesting argument of making the language do some of your thinking for you. ... As the price of computers goes down, the number of CPUs per computer goes up, and the price per CPU in a single system goes down, the ability to utilize a bunch of CPUs is going to become more important. ...
    (comp.lang.python)
  • Re: [OT] Re: Whats the name for this?
    ... I need to point out that the older CPUs ... > language programmers mastered complexity on the CISC VAX. ... the fact that you can design the architectural face a CPU ... who programs with no knowledge of how a compiler works. ...
    (comp.programming)