I have a few questions because I've been asked to investigate eiffel for use in some embedded development. As you may know, the embedded world is characterized by the following:
1. Variety of chip architectures 2. Most popular OS is linux and the most popular "brand" of linux is "roll your own" 3. Efficient memory utilization is important 4. Many chips are multi-core, which means parallelization is becoming important. 5. For our segement, speed is also very important.
Given these characteristics, I would like to hear opinions from eiffelists about the comparitive strengths of Smarteiffel and EiffelStudio. I like the development enviroment of EiffelStudio (with its case tool and integrated debugger). However, I have read about the reputation of Smarteiffel with regards to speed and efficiency of the executable.
As an aside, I wanted to know about the difficulty of porting eiffel to a new hardware platform. From what I have read, I understood that if there is a c compiler available for that hardware, and the eiffel compiler supports the operating system on that hardware, then there should not be a problem with seamless porting. Is that true?
On Mon, 2006-01-02 at 12:11 -0800, lee wrote: > As an aside, I wanted to know about the difficulty of porting eiffel to > a new hardware platform.
Victor Putz ported SmartEiffel to the Palm PDA http://eiffelzone.com/esd/epalm/index.html The "Documentation" link is not working today, but I seem to recall that Victor describes the issues he encountered and how he resolved or worked around them.
Well if Boehms GC is working on your machine or you are able to port it to the chip, and gcc 4.0 runs on this system. I have another option for you.
I use a patched version of SmallEiffel for my inhouse development. It has all of the features, except (3) as the memory footprint might be high. Unfortunately no eiffel compiler works without GC at the moment.
(4) is not possible with SmartEiffel, and the team is unwilling to see the importance of multithreaded programming.
Thanks for the information. I did look around to see if I could find the files, but no such luck. Actually, it might not matter, because I consider ePalm to be an instance of porting to both a new OS and new hardware. If you are porting to a new OS, then I can see where the eiffel compiler would need to be modified (e.g., to map to the specific system calls, etc.).
I was wondering more about the case where you are porting to a supported OS, but on a new chip.
> (4) is not possible with SmartEiffel, and the team is unwilling to see > the importance of multithreaded programming.
Does that mean you would choose SmartEiffel over EiffelStudio given the characteristics I was looking at (except for 4)? As for 4, I understood that the SmartEiffel team refused to implement multi-threading, and while I do not know their reasons, I am not a fan of multi-threading.
Basically, I have consulted for many large companies with teams of talented (I assume) developers. To increase throughput for large e-commerce systems, they invariably turn to multi-threading. And they invariably have many problems, regardless of the tools/language. My analysis of these issues leads me to believe that threading is so difficult because it is hard to determine the state of a complex program. There are usually deadlock issues as well as correctness problems Therefore, I am more partial to (a) exploring efficient scheduling of processes/jobs within an app (i.e., a single threaded process) and then exploiting parallelization by (b) having multiple instances of an application.
The big missing factor is how to simply assign an app to a particular processor and to change that assignment dynamically. That's why I am interested in SCOOP.
Well you don't need to be fan of multi-threading. Simply look at what happens in the CPU world at the moment. CPU speed is almost the same as 2 years ago so we see a dead end here - there are physical borders. And you can get a dual core CPU in each supermarket and a 32 threaded CPU chip from SUN.
The process modell does only work well for a few kinds of tasks. For others you simply need shared memory structures, otherwise the IPC eats up all the speed.
I agree that at the beginning the multi-threading is a magnitude more difficult and you need very good skills and experience to design such a system. But i don't see any alternative. Over christmas i resurrected an old Occam programming book from 1986. It was interesting to read that 20 year old stuff. Multithreaded sorting algorithm etc.
lee wrote: > I was wondering more about the case where you are porting to a > supported OS, but on a new chip.
For SmartEiffel this should require only that the new chip has a suitable Ansi C compiler. If it takes more than that, I think the SmartEiffel team would regard it as a bug.
lee (asking llothar):
> Does that mean you would choose SmartEiffel over EiffelStudio
They are very different solutions. SmartEiffel is a lean open source command-line compiler that you can port yourself. EiffelStudio is a richly-featured proprietary compiler, but as you don't get the source code to the runtime you will have to get the vendor to port it (which they will be keen to do if it is economically viable for them).
llothar wrote: > > I agree that at the beginning the multi-threading is a magnitude more > difficult and you need very good skills and experience to design such a > system. But i don't see any alternative. Over christmas i resurrected > an old Occam programming book from 1986. It was interesting to read > that 20 year old stuff. Multithreaded sorting algorithm etc.
You have a good point. There are some tasks that are good for multi-threading. In some ways, my negative view of multi-threading is a result of my negative view of development practices. When I studied computer science 20 years ago, we were required to study algorithms. At the time, I was bored to death to learn about notation that looked liked - O(n), etc. I wanted to program a computer that could think!
But, as I entered the "real" world, I noticed that spending time on algorithm development (before actually writing code) could result in orders of magnitude improvement. I do not see developers spending much time on algorithms nowadays. So, instead of trying to create algorithms that limit the number of disk accesses (as an example), developers write code that is inefficient (but at least it is written quickly, I guess). Then, when they need to address performance, they turn to multi-threading. If they had created better algorithms in the first place, then they might have eliminated the performance bottleneck in the first place.
