# For performance, write it in C

**URL:** <https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952>\
**Category:** Ruby\
**Created:** [July 26, 2006, 10:50am UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952 "2006-07-26T10:50:11Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 2:56pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/21 "2006-07-26T14:56:41Z")

</div>

One important thing about Ruby performance is that Ruby gets very  
inefficient very quickly, as the size of the working set grows. This  
manifests as an observed performance problem, but the tip-off is that  
performance of a particular Ruby program is quite acceptable for small  
data-set sizes (such as in your test fixtures), but falls off a cliff  
with  
production data-sets. Most of the times that I have found myself  
rewriting  
slow Ruby code in C have been to get a program that runs in far less  
memory,  
by manually laying out the data structures. This improves performance  
not  
only for the obvious reasons (less thrashing and less contention with  
other  
processes on a busy server), but also because you can “help” the  
processor’s  
cache manager to get more hits by creating localities of reference and  
by  
stuffing more of your working set into a smaller number of cache lines.  
This  
matters all the more on multiprocessors, which are severely penalized by  
cache misses, to the point that some naively-written programs can run  
noticeably faster on a uniprocessor.

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 5:01pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/22 "2006-07-26T17:01:29Z")

</div>

On 7/26/06, Charles O Nutter [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> there’s nothing about a  
> language’s design that should necessitate it being slower than any other  
> language.

While I accept that you shouldn’t confuse a language with its  
implementation,  
I find that a mildly surprising statement, especially since you said  
in an earlier post:

> for memory-intensive situations Java almost always wins because lazy memory  
> management allows work to get done first, faster

Garbage collection seems to me to be an integral part of Java’s design.

Off the top of my head, I can think of some other design aspects that  
have an effect on performance: method lookup in OO languages, scoping,  
continuations, closures, static vs dynamic typing, type inference,  
double dispatch, consing + car + cdr in Lisp, direct vs indirect  
threading in Forth, etc. These are not just matters of implementation.  
Each is a language design decision with a semantic effect which incurs  
or avoids a computational cost, regardless of how it’s actually  
implemented. For example, Ruby has real closures, Python doesn’t. I  
don’t see how you could ever reduce the cost of Ruby having closures  
to zero - the memory alone is an implied overhead. Sure you can  
optimize till the cows come home but different functionalities have  
different costs and you can’t ever avoid that.

Regards,  
Sean

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 5:11pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/23 "2006-07-26T17:11:35Z")

</div>

On 7/26/06, Sean O’Halpin [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> optimize till the cows come home but different functionalities have  
> different costs and you can’t ever avoid that.

In theory if two programs in two different languages produce the same  
exact results the perfect compilers for each of the languages would  
end up producing the same code. In theory practice is the same as  
theory but in practice it isn’t.

Cheers,

Pedro.

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 5:04pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/24 "2006-07-26T17:04:41Z")

</div>

On 7/26/06, removed\_email\_address@domain.invalid [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> …
> 
> People talk about the 80:20 principle, but in my experience it’s much  
> more like 99:1 for applications. 99% of the code uses 1% of the run  
> time. 1% of the code consumes 99% of the run time. That could be the  
> signal processing and graphics heavy applications that I have  
> experienced though.  
> …

This is the “value proposition” of the “Hot Spot” technology in the  
Java Virtual Machine. On the fly, it looks for byte code sections that  
get executed repeatedly and it then compiles them to object code,  
thereby doing runtime optimization. This allows many Java server  
processes to run with near-native speeds. When Ruby runs on a virtual  
machine, planned for version 2, then Ruby can do that too. The JRuby  
project will effectively accomplish the same goal.

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 5:18pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/25 "2006-07-26T17:18:11Z")

</div>

On Wed, 26 Jul 2006 17:47:13 +0900, Peter H. wrote:

> Whenever the question of performance comes up with scripting languages  
> such as Ruby, Perl or Python there will be people whose response can be  
> summarised as “Write it in C”. I am one such person. Some people take  
> offence at this and label us trolls or heretics of the true programming  
> language (take your pick).

Hi,

When reading your C code, I saw that there is a lot of code that is  
generated. I’d be interested to see how well the C program does if  
it can work for any size of the squares. In this case I think the  
problem  
is well suited for logic languages. I wrote a version in the functional  
logic language Curry, which does reasonably well. It will probably not  
be  
faster than the C version, but a lot faster than a program written in  
Ruby/Perl/Python.

> If you really really want that performance boost then take the following  
> advice very seriously - “Write it in C”.

It can be a good idea to rewrite parts in C, but I would first check if  
the algorithms are good, so that it may not even be needed to write any  
C code. And perhaps there are libraries or tools that do the trick  
efficiently. I would keep writing C code as the last option.

Regards,  
Kristof

-------------------- start of latin.curry ----------------------------  
– upto is a nondeterministic function that evaluates to  
– a number from 1 upto n  
upto 1 = 1  
upto n | n \> 1 = n ? upto (n-1)

– check if the lists r s have no element with the same value at the  
– same position  
elems\_diff r s = and $ zipWith (/=) r s

– extend takes a list of columns, and extends each column with a  
– number for the next row. It checks the number agains the column and  
– against the previous numbers in the row.

extend :: [[Int]] -\> Int -\> [[Int]]  
extend cols n = addnum cols [] where  
addnum [] \_ = []  
addnum (col:cs) prev  
| x =:= upto n &  
(x `elem` prev) =:= False &  
(x `elem` col) =:= False = (x:col) : addnum cs (x:prev)  
where x free

latin\_square n = latin\_square\_ n  
where latin\_square\_ 0 = replicate n [] – initalize columns to nil  
latin\_square\_ m | m \> 0 = extend (latin\_square\_ (m-1)) n

square2str s = unlines $ map format\_col s  
where format\_col col = unwords $ map show col

main = mapIO\_ (putStrLn . square2str) (findall (\s -\> s =:= latin\_square  
5))  
------------------------- end latin.curry -----------------------------

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 5:22pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/26 "2006-07-26T17:22:08Z")

</div>

> > On Wed, 26 Jul 2006 17:47:13 +0900, Peter H. wrote:
> > 
> > > In this post I want to clear some things up and provide benchmarks as to  
> > > why you should take “Write it in C” seriously.

Interesting series of messages! Got to save and read them through at  
leisure …

Just adding my 2c:

[I worked on a fairly complex performance tuning job once, involving HP-UNIX boxes (multiple), Informix ESQL/C batch programs, IBM MQ series (now called Websphere MQ), UNIX IPC, and got a chance to do tuning at several different levels - SQL queries, MQ logs/partitions, the C code, algorithms in it, etc. Was very educational … just sharing some insights gained from that, from reading on the subject, and from smaller hobby projects tuning my own code …]

[Not implying that previous posters on this thread haven’t done any of  
the below].

Performance tuning in general is _very_ complicated. Guesses or  
assumptions like “this code tweak should make it run faster” often do  
not work. The only way is a (semi)scientific approach to  
measure/profile, study profile results, make hypotheses, change code  
accordingly, then re-measure to see if the change made a difference.

Tuning can be done at any of several different levels, ranging from:

- hardware (even here, not just throwing more boxes or faster boxes at  
the problem, but things like hardware architecture - obviously only if  
the skills are available and the problem is worth the effort)

- software architecture

- algorithms and data structures optimization

- plain code tuning (things like common subexpression elimination, e.g.  
using C syntax, changing:

for (i = 0; i \< getLength(my\_collection); i++) { /\* do something with  
my\_collection[i] \*/ }

to

collLength = getLength(my\_collection);  
for (i = 0; i \< collLength; i++) { /\* do something with  
my\_collection[i] \*/ }

/\* which removes the repeated/redundant call to the function  
getLength() \*/

Jon Bentley’s book “Writing Efficient Programs” is a very good book  
which discusses rules, examples and war stories of tuning at almost all  
of these levels, including really excellent advice on code-level  
tuning, which may sometimes be the easiest one to implement on existing  
code.  
Though the examples are in a pseudo-Pascal dialect (easily  
understandable for those knowing C), and though it may be out of print  
now, for those who have a real need for tuning advice, its worth trying  
to get a used copy on eBay, from a friend, whatever.

Its chock-full of code examples with the tuning results (verifiied by  
measurement, as stated above), when (and when not) to apply them, and  
the war stories are really interesting too …

Googling for “performance tuning” and variants thereof will help …

There’s another book (for Java, mostly server-side programming) by a  
guy called Dov (something - forget his last name and the book title, if  
I remember it, will post here) that’s _really_ excellent too - he shows  
(again, with actual measurements) how some of the “expected” results  
were actually wrong/counter-intuitive. He worked with IBM on the web  
software for one of the recent Olympics.

HTH  
Vasudev

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 5:25pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/27 "2006-07-26T17:25:32Z")

</div>

On 7/26/06, Sean O’Halpin [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> in an earlier post:
> 
> > for memory-intensive situations Java almost always wins because lazy  
> > memory  
> > management allows work to get done first, faster
> 
> Garbage collection seems to me to be an integral part of Java’s design.

Garbage collection is a characteristic of the Java VM, not the language.  
Nothing in the language specifies garbage collection or how it should be  
performed. It could just as easily be implemented with  
reference-counting,  
and the language would still look exactly the same. What IS a  
characteristic  
of the language is that you do not explicitly release objects when you  
are  
finished using them. There are many ways to interpret that and many ways  
to  
implement it. Garbage collection is just one among many.

Off the top of my head, I can think of some other design aspects that

> different costs and you can’t ever avoid that.  
> You’re mixing language semantics and implementation details here. The  
> mechanics of method lookup is not a language feature; it’s an  
> implementation  
> detail. On the other hand, the logic of which method gets invoked in a  
> hierarchy of types is a language detail. Scoping is a language feature,  
> but  
> the means by which scope is maintained is an implementation detail.  
> Continuations are a language feature, but the means by which a  
> continuation  
> and its applicable scoping are memoized is an implementation detail.  
> Static  
> and dynamic typing are language features; the means by which type is  
> propagated and used for calls, checks, and memory allocation is an  
> implementation detail. On and on and on…language features always have  
> an  
> associated implementation, but there’s almost always multiple ways to  
> implement a given feature, and those different implementations will have  
> their plusses and minuses.

As for the closure comment…sure, there’s overhead in creating  
closures,  
but it’s _explicit_ overhead. This is no different from creating the  
equivalent of closures in languages that don’t support them. The concept  
of  
a closure has a clear specification and certainly increases the  
complexity  
of a language and an underlying implementation. But that complexity may  
not  
in itself always represent a decrease in performance, since other means  
of  
accomplishing the same task may be even less performant. That’s how it  
is  
for any language feature…you take the good with the bad, and if you  
don’t  
use all of the good you may be less-than-optimal. If using a feature has  
ten  
good aspects and five bad, and you only make use of five good aspects,  
then  
your code is sub-optimal. If you use less than five, you’re even worse  
off  
and perhaps should consider doing things differently. Nothing about the  
feature itself explicitly implies that performance should degrade by  
using  
it…it’s a matter of using those features wisely and making optimal use  
of  
their good aspects, balanced with their bad aspects.

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 5:22pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/28 "2006-07-26T17:22:20Z")

</div>

I will run your Ruby version and the Java version that I write and post  
the results here. Give us a week or so as I have other things to be  
doing.

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 5:25pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/29 "2006-07-26T17:25:43Z")

</div>

Peter H. wrote:

> If you really really want that performance boost then take the following  
> advice very seriously - “Write it in C”.

Assuming you have no choice but C/C++. That’s why I like using the  
jvm or clr with languages like jruby, groovy, or boo. You don’t have  
to use C, you can use java or C# or boo itself (since it is statically  
typed with type inference): [http://boo.codehaus.org/](http://boo.codehaus.org/)  
or C/C++ as well, although it is 100x easier to interface with a C lib  
from the clr than it is from jvm with jni.

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 5:38pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/30 "2006-07-26T17:38:29Z")

</div>

Kristof B. wrote:

> Hi,
> 
> When reading your C code, I saw that there is a lot of code that is  
> generated. I’d be interested to see how well the C program does if  
> it can work for any size of the squares. In this case I think the problem  
> is well suited for logic languages. I wrote a version in the functional  
> logic language Curry, which does reasonably well. It will probably not be

Interesting … I read somewhere that the OCaml language, while  
higher-level than C (and a functional one too), runs some programs at  
least, as fast or faster than C …  
Not sure how true that is …

Vasudev

> **[dancingbison.com](http://ww38.dancingbison.com/)**
>
> Learn Python Programming

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 5:44pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/31 "2006-07-26T17:44:53Z")

</div>

Writing code that runs as fast in Java as it does in C is real work,  
but it’s possible.

Integer ([http://athena.com](http://athena.com)) is a pure Java spreadsheet. I optimized  
the numeric functions and array functions (e.g., SUM(A1:G99)) such  
that Integer runs as fast or faster than Excel and OpenOffice Calc on  
identical hardware. However, it required a mind shift from “standard”  
Java programming.

In addition, because Java has nice semantics for multithreading, I was  
able to implement some very cleaver algorithms such that Integer’s  
recalculation speed scales nearly linearly with additional CPUs up to  
a certain point (the linearity goes away at around 16 processors on a  
big Sun box.) But I digress.

First, I pre-allocated a lot of workspace so that there’s little  
memory allocation going on during recalculation.

Second, I avoid Monitors (synchronized) as much as possible.

Third, I write “C” style Java (lots of switch statements, putting  
parameters and results in buffers rather than passing them on the  
stack, etc.)

Memory usage in Java is higher than in C. If Java has Structs a la  
C#/Mono, it’d be possible to squeeze that much more performance from  
Java.

There are some applications that will never perform as in Java (e.g.,  
stuff that’s heavily oriented to bit manipulation.) But for many  
classes of applications (e.g., spreadsheets) Java can perform as well  
as C.

When I care about computational performance, I go with Java or in a  
rare case, C++ (C style C++, no STL or virtual methods). If I care  
about developer performance, I’ve been going with Ruby more and more.

My 2 cents.

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 5:57pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/32 "2006-07-26T17:57:20Z")

</div>

> > > language (take your pick).  
> > > logic language Curry, which does reasonably well. It will probably not  
> > > be
> 
> Interesting … I read somewhere that the OCaml language, while  
> higher-level than C (and a functional one too), runs some programs at  
> least, as fast or faster than C …  
> Not sure how true that is …
> 
> Vasudev  
> [http://www.dancingbison.com](http://www.dancingbison.com)

You read that correctly. The problem is that nearly every benchmark I’ve  
seen for comparing the performance of various languages has been a  
repeated mathematical operation like computing a Mandelbrot Set or  
running  
Fibonacci Sequences that all but guarantees the edge will belong to  
functional languages like Haskell and OCAML or stripped-down  
assembly-like  
languages like C ([http://shootout.alioth.debian.org/debian/](http://shootout.alioth.debian.org/debian/) for  
samples),  
because they are best suited for straight-up number crunching. Are there  
good benchmarks for OO languages? Or dynamic languages? Are there good  
benchmarks that could actually measure the types of uses I need, where  
I’m  
building a web front end to a DB store? I don’t know about you, but my  
job  
has never involved fractals.

I used to put faith into benchmarks like this, but now I think about  
developer time and maintenance time as well. That seems to be a more  
intelligent approach.

Jake

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 5:41pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/33 "2006-07-26T17:41:43Z")

</div>

On 7/26/06, Pedro Côrte-Real [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> 

In theory, an infinite number of computer scientists hacking for an  
infinite amount of time on a keyboard will eventually almost surely  
produce a perfect compiler.

In practice, I can’t wait that long 😉

Cheers,  
Sean

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 6:03pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/34 "2006-07-26T18:03:59Z")

</div>

On 7/26/06, David P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> In addition, because Java has nice semantics for multithreading, I was  
> able to implement some very cleaver algorithms such that Integer’s  
> recalculation speed scales nearly linearly with additional CPUs up to  
> a certain point (the linearity goes away at around 16 processors on a  
> big Sun box.) But I digress.

This must be evidence of true cutting edge development 😉

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 6:16pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/35 "2006-07-26T18:16:39Z")

</div>

Tomasz W. wrote:

> > right approach.
> 
> Sorry, I just couldn’t resist - but maybe you should code Java instead -  
> [http://kano.net/javabench/](http://kano.net/javabench/) 😉

“The results I got were that Java is significantly faster than  
optimized C++ in many cases… I’ve been accused of biasing the results  
by using the -O2 option for GCC…”

“…so I took the benchmark code for C++ and Java from the now outdated  
Great Computer Language Shootout and ran the tests myself”

Not so outdated  
[http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=java&lang2=gpp](http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=java&lang2=gpp)

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 6:22pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/36 "2006-07-26T18:22:49Z")

</div>

On Thu, 27 Jul 2006 00:55:05 +0900, harrisj wrote:

> > [http://www.dancingbison.com](http://www.dancingbison.com)
> 
> You read that correctly. The problem is that nearly every benchmark I’ve  
> seen for comparing the performance of various languages has been a  
> repeated mathematical operation like computing a Mandelbrot Set or running  
> Fibonacci Sequences that all but guarantees the edge will belong to  
> functional languages like Haskell and OCAML or stripped-down assembly-like  
> languages like C ([http://shootout.alioth.debian.org/debian/](http://shootout.alioth.debian.org/debian/) for samples),  
> because they are best suited for straight-up number crunching.

In some cases the functional version is faster because the problem can  
be  
more easily described in a functional way. But in general code produced  
by ocaml is about twice as slow as C, because the compiler doesn’t do  
the  
same extensive optimizations as for example gcc does. But that’s still  
pretty good.

> Are there  
> good benchmarks for OO languages? Or dynamic languages? Are there good  
> benchmarks that could actually measure the types of uses I need, where I’m  
> building a web front end to a DB store? I don’t know about you, but my job  
> has never involved fractals.

True, benchmarks only measure execution speed, but they don’t show if a  
given programmer will be productive in them. I think that’s also  
largely a personal choice. Some people may be more productive in a  
functional language, some people more in Ruby. And others even in  
perl… 🙂

Kristof

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 6:29pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/37 "2006-07-26T18:29:15Z")

</div>

Greg,

In spreadsheets, it is cutting edge. Name one other commercial  
spreadsheet that can use more than 1 CPU?

David

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 6:26pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/38 "2006-07-26T18:26:01Z")

</div>

On 7/26/06, Gregory B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> On 7/26/06, David P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> 
> > In addition, because Java has nice semantics for multithreading, I was  
> > able to implement some very cleaver algorithms such that Integer’s  
> > recalculation speed scales nearly linearly with additional CPUs up to  
> > a certain point (the linearity goes away at around 16 processors on a  
> > big Sun box.) But I digress.
> 
> This must be evidence of true cutting edge development 😉

No doubt, I wish I had that kind of problem when running my spreadsheet  
application of choice. That’s one hell of a business desktop!

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 6:32pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/39 "2006-07-26T18:32:27Z")

</div>

Sean O’Halpin wrote:

> In theory, an infinite number of computer scientists hacking for an  
> infinite amount of time on a keyboard will eventually almost surely  
> produce a perfect compiler.
> 
> In practice, I can’t wait that long 😉

You’d be waiting a long time indeed :o).

I believe our good friend Mr. Turing proved [1] that such  
a compiler could never exist, some seven decades ago.

Oh well.

Martin

[1] OK. That wasn’t exactly what he proved.  
But only this particular corollary is relevant.

---

<div class="post-metadata">

**Author:** ![tekhne](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90ced4/32.png) [@tekhne](https://www.ruby-forum.com/u/tekhne)\
**Post date:** [July 26, 2006, 6:35pm UTC](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952/40 "2006-07-26T18:35:38Z")

</div>

On Jul 26, 2006, at 11:28 AM, David P. wrote:

> Greg,
> 
> In spreadsheets, it is cutting edge. Name one other commercial  
> spreadsheet that can use more than 1 CPU?

I’m pretty sure Greg was funning around with the comical typo in your  
post. Take a look back at how you spelled “clever.” 😉

James Edward G. II

[Previous page](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952.md?page=1)

[Next page](https://www.ruby-forum.com/t/for-performance-write-it-in-c/99952.md?page=3)