Re: multi-core software
On Jun 4, 8:35 pm, Roedy Green wrote: > On Thu, 4 Jun 2009 09:46:44 -0700 (PDT), Xah Lee > wrote, quoted or indirectly quoted someone who said : > > >• Why Must Software Be Rewritten For Multi-Core Processors? > > Threads have been part of Java since Day 1. Using threads complicates > your code, but even with a single core processor, they can improve > performance, particularly if you are doing something like combing > multiple websites. > > The nice thing about Java is whether you are on a single core > processor or a 256 CPU machine (We got to run our Athena Integer Java > spreadsheet engine on such a beast), does not concern your code. > > You just have to make sure your threads don't interfere with each > other, and Java/the OS, handle exploiting all the CPUs available. You need to decompose your problem in 256 independent tasks. It can be trivial for some problems and difficult or perhaps impossible for some others. -- http://mail.python.org/mailman/listinfo/python-list
Re: multi-core software
On Jun 6, 1:26 am, Roedy Green wrote: > On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku > wrote, quoted or indirectly quoted someone who > said : > > >Even for problems where it appears trivial, there can be hidden > >issues, like false cache coherency communication where no actual > >sharing is taking place. Or locks that appear to have low contention and > >negligible performance impact on ``only'' 8 processors suddenly turn into > >bottlenecks. Then there is NUMA. A given address in memory may be > >RAM attached to the processor accessing it, or to another processor, > >with very different access costs. > > Could what you are saying be summed up by saying, "The more threads > you have the more important it is to keep your threads independent, > sharing as little data as possible." Besides technical issues such as cache conflicts and synchronization latencies, there are more theoretical issues of task decomposability. It seems it is not always feasible to decompose an algorithm into subprograms that can be executed in parallel. -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
On 30 Set, 01:47, RG wrote:
> In article ,
> Keith Thompson wrote:
>
>
>
> > RG writes:
> > > In article
> > > <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
> > > Squeamizh wrote:
> > >> On Sep 29, 3:02 pm, RG wrote:
> > [...]
> > >> > This is a red herring. You don't have to invoke run-time input to
> > >> > demonstrate bugs in a statically typed language that are not caught by
> > >> > the compiler. For example:
>
> > >> > [...@mighty:~]$ cat foo.c
> > >> > #include
>
> > >> > int maximum(int a, int b) {
> > >> > return (a > b ? a : b);
>
> > >> > }
>
> > >> > int foo(int x) { return 9223372036854775807+x; }
>
> > >> > int main () {
> > >> > printf("%d\n", maximum(foo(1), 1));
> > >> > return 0;}
>
> > >> > [...@mighty:~]$ gcc -Wall foo.c
> > >> > [...@mighty:~]$ ./a.out
> > >> > 1
>
> > >> > Even simple arithmetic is Turing-complete, so catching all type-related
> > >> > errors at compile time would entail solving the halting problem.
>
> > >> > rg
>
> > >> In short, static typing doesn't solve all conceivable problems.
>
> > > More specifically, the claim made above:
>
> > >> in C I can have a function maximum(int a, int b) that will always
> > >> work. Never blow up, and never give an invalid answer.
>
> > > is false. And it is not necessary to invoke the vagaries of run-time
> > > input to demonstrate that it is false.
>
> > But the above maximum() function does exactly that. The program's
> > behavior happens to be undefined or implementation-defined for reasons
> > unrelated to the maximum() function.
>
> > Depending on the range of type int on the given system, either the
> > behavior of the addition in foo() is undefined (because it overflows),
> > or the implicit conversion of the result to int either yields an
> > implementation-defined result or (in C99) raises an
> > implementation-defined signal; the latter can lead to undefined
> > behavior.
>
> > Since 9223372036854775807 is 2**63-1, what *typically* happens is that
> > the addition yields the value 0, but the C language doesn't require that
> > particular result. You then call maximum with arguments 0 and 1, and
> > it quite correctly returns 1.
>
> This all hinges on what you consider to be "a function maximum(int a,
> int b) that ... always work[s] ... [and] never give[s] an invalid
> answer." But if you don't consider an incorrect answer (according to
> the rules of arithmetic) to be an invalid answer then the claim becomes
> vacuous. You could simply ignore the arguments and return 0, and that
> would meet the criteria.
But in your own example the function maximum() does give the correct
answer, therefore your point doesn't stand.
--
http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
On 30 Set, 03:01, RG wrote:
> In article ,
> Keith Thompson wrote:
>
>
>
> > RG writes:
> > > In article ,
> > > Keith Thompson wrote:
>
> > >> RG writes:
> > >> > In article
> > >> > <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
> > >> > Squeamizh wrote:
> > >> >> On Sep 29, 3:02 pm, RG wrote:
> > >> [...]
> > >> >> > This is a red herring. You don't have to invoke run-time input to
> > >> >> > demonstrate bugs in a statically typed language that are not caught
> > >> >> > by
> > >> >> > the compiler. For example:
>
> > >> >> > [...@mighty:~]$ cat foo.c
> > >> >> > #include
>
> > >> >> > int maximum(int a, int b) {
> > >> >> > return (a > b ? a : b);
>
> > >> >> > }
>
> > >> >> > int foo(int x) { return 9223372036854775807+x; }
>
> > >> >> > int main () {
> > >> >> > printf("%d\n", maximum(foo(1), 1));
> > >> >> > return 0;}
>
> > >> >> > [...@mighty:~]$ gcc -Wall foo.c
> > >> >> > [...@mighty:~]$ ./a.out
> > >> >> > 1
>
> > >> >> > Even simple arithmetic is Turing-complete, so catching all
> > >> >> > type-related
> > >> >> > errors at compile time would entail solving the halting problem.
>
> > >> >> > rg
>
> > >> >> In short, static typing doesn't solve all conceivable problems.
>
> > >> > More specifically, the claim made above:
>
> > >> >> in C I can have a function maximum(int a, int b) that will always
> > >> >> work. Never blow up, and never give an invalid answer.
>
> > >> > is false. And it is not necessary to invoke the vagaries of run-time
> > >> > input to demonstrate that it is false.
>
> > >> But the above maximum() function does exactly that. The program's
> > >> behavior happens to be undefined or implementation-defined for reasons
> > >> unrelated to the maximum() function.
>
> > >> Depending on the range of type int on the given system, either the
> > >> behavior of the addition in foo() is undefined (because it overflows),
> > >> or the implicit conversion of the result to int either yields an
> > >> implementation-defined result or (in C99) raises an
> > >> implementation-defined signal; the latter can lead to undefined
> > >> behavior.
>
> > >> Since 9223372036854775807 is 2**63-1, what *typically* happens is that
> > >> the addition yields the value 0, but the C language doesn't require that
> > >> particular result. You then call maximum with arguments 0 and 1, and
> > >> it quite correctly returns 1.
>
> > > This all hinges on what you consider to be "a function maximum(int a,
> > > int b) that ... always work[s] ... [and] never give[s] an invalid
> > > answer."
>
> > int maximum(int a, int b) { return a > b ? a : b; }
>
> > > But if you don't consider an incorrect answer (according to
> > > the rules of arithmetic) to be an invalid answer then the claim becomes
> > > vacuous. You could simply ignore the arguments and return 0, and that
> > > would meet the criteria.
>
> > I don't believe it's possible in any language to write a maximum()
> > function that returns a correct result *when given incorrect argument
> > values*.
>
> > The program (assuming a typical implementation) calls maximum() with
> > arguments 0 and 1. maximum() returns 1. It works. The problem
> > is elsewhere in the program.
>
> That the problem is "elsewhere in the program" ought to be small
> comfort. But very well, try this instead:
>
> [...@mighty:~]$ cat foo.c
> #include
>
> int maximum(int a, int b) { return a > b ? a : b; }
>
> int main() {
> long x = 8589934592;
> printf("Max of %ld and 1 is %d\n", x, maximum(x,1));
> return 0;}
>
> [...@mighty:~]$ gcc -Wall foo.c
> [...@mighty:~]$ ./a.out
> Max of 8589934592 and 1 is 1
So the incorrect behavior happens in a case where C doesn't enforce
strict typing rules.
--
http://mail.python.org/mailman/listinfo/python-list
